parchive-devel — Parchive Specification and Client Developer Discussion List

Re: [parchive-devel] We must get rid of Sourceforge!

[Ike D. <ike...@gm...>]

Op zaterdag 10 juni 2017 13:54:45 CEST schreef Rhialto:
> Stupid sourceforge wants me to "reconfirm" my mailing list subscriptions,
> using a stupid javascript-laden webpage with captchas that does not work.
> I've lost a good part of an hour now on that crap and it still doesn't
> work.
> 
> I've had it with sourceforge. We should get rid of it. Immediately.
> 
> -Olaf.
> --
> ___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
> \X/ rhialto/at/xs4all.nl    -- are condemned to reinvent it. Poorly.

Almost everything is on github. I could scrape the current site and move it 
like that to github too.

-- 
Ike

Re: [parchive-devel] [Vice-emu-mail] We must get rid of Sourceforge!

[Rhialto <rh...@fa...>]

On Sat 10 Jun 2017 at 19:05:13 +0200, Tristan Miller wrote:
> I'm a bit surprised y'all didn't drop it a couple years ago when they
> were found to be bundling adware with installer downloads.

I think there was a discussion about it then as well.
It is also when I started to make a private mirror of the svn repo for
VICE, just in case it would ne needed. (I'm updating it by hand so it
will always be a bit behind though).

> Tristan
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl    -- are condemned to reinvent it. Poorly.

[parchive-devel] We must get rid of Sourceforge!

[Rhialto <rh...@fa...>]

Stupid sourceforge wants me to "reconfirm" my mailing list subscriptions,
using a stupid javascript-laden webpage with captchas that does not work.
I've lost a good part of an hour now on that crap and it still doesn't
work.

I've had it with sourceforge. We should get rid of it. Immediately.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl    -- are condemned to reinvent it. Poorly.

Re: [parchive-devel] Latest par2cmdline - Thank you.

[Gary S. <gse...@gm...>]

I want to say "Thank you"* to all who have contributed* to developing this
great software!

Gary Sellars

On Tue, Apr 5, 2016 at 4:37 PM, Ike Devolder <ike...@gm...> wrote:

> On Tue, Apr 05, 2016 at 02:59:03PM +0000, Przemek Kowalczyk wrote:
> > Is the latest release 0.6.13 or 0.6.14? I think the "Latest Release"
> label
> > is confusing on this page
> https://github.com/Parchive/par2cmdline/releases
> >
>
> Its 0.6.14, I have no idea why github still marks 0.6.13 as latest.
>
> --
> Ike
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Parchive-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parchive-devel
>
>


-- 








--
http://www.cleareyesight.info/  <<- Remove your glasses & fix your eyes
http://healingrooms.com/?src=content&cid=4

Most people don't let the Bible interfere with their theology. -- Andrew
Wommack <http://www.awmi.net/extra/audio>

The truth about Islam --> <http://www.youtube.com/watch?v=Ib9rofXQl6w
<http://www.youtube.com/watch?v=Ib9rofXQl6w>>

Do your own research on Smart Meter radiation. As established by a Court in
Santa Cruz, California, it is harmful and is 50 to 480 times even more
powerful/dangerous than a cell phone! They will also be used as a
monitoring device and will tell the government when you're asleep and when
you're showering. Consider the potential harm to you and your loved ones.

Re: [parchive-devel] Latest par2cmdline - Thank you.

[Ike D. <ike...@gm...>]

On Tue, Apr 05, 2016 at 02:59:03PM +0000, Przemek Kowalczyk wrote:
> Is the latest release 0.6.13 or 0.6.14? I think the "Latest Release" label
> is confusing on this page https://github.com/Parchive/par2cmdline/releases
> 

Its 0.6.14, I have no idea why github still marks 0.6.13 as latest.

-- 
Ike

Re: [parchive-devel] Latest par2cmdline - Thank you.

[Przemek K. <prz...@gm...>]

Is the latest release 0.6.13 or 0.6.14? I think the "Latest Release" label
is confusing on this page https://github.com/Parchive/par2cmdline/releases

On Tue, Oct 20, 2015 at 12:41 AM Ike Devolder <ike...@gm...>
wrote:

> On Mon, Oct 19, 2015 at 07:37:13PM -0600, Robin Laing wrote:
> > Hello,
> >
> > I just wanted to say that the latest Github par2cmd line repaired a set
> > of files that the Fedora 22 release version wouldn't repair.  I had to
> > use the -N option but it did work.
> >
> > I just wanted to say thank you.
> >
> > Robin Laing
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Parchive-devel mailing list
> > Par...@li...
> > https://lists.sourceforge.net/lists/listinfo/parchive-devel
>
> I'm glad you got your files fixed.
>
> And thanks for the thank you to everyone who ever contributed to par2.
>
> --
> Ike
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Parchive-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parchive-devel
>

Re: [parchive-devel] Latest par2cmdline - Thank you.

[Ike D. <ike...@gm...>]

On Mon, Oct 19, 2015 at 07:37:13PM -0600, Robin Laing wrote:
> Hello,
> 
> I just wanted to say that the latest Github par2cmd line repaired a set 
> of files that the Fedora 22 release version wouldn't repair.  I had to 
> use the -N option but it did work.
> 
> I just wanted to say thank you.
> 
> Robin Laing
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Parchive-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parchive-devel

I'm glad you got your files fixed.

And thanks for the thank you to everyone who ever contributed to par2.

-- 
Ike

[parchive-devel] Latest par2cmdline - Thank you.

[Robin L. <MeSat@TelusPlanet.net>]

Hello,

I just wanted to say that the latest Github par2cmd line repaired a set 
of files that the Fedora 22 release version wouldn't repair.  I had to 
use the -N option but it did work.

I just wanted to say thank you.

Robin Laing

Re: [parchive-devel] integrating asm speedups in par2 mainline

[Peter C. <pe...@co...>]

On Thu, Jul 30, 2015 at 08:32:56PM -0600, Ace Olszowka wrote:
> please make sure that a "reference" implementation is kept in fairly
> Portable C.

 Yes, of course!  It needs to work on all platforms, so the pure C
version needs to be there.

I got some responses to
http://stackoverflow.com/questions/31734263/write-x86-asm-functions-portably-win-linux-osx-without-a-build-depend-on-yasm

I'm inclined to just use masm syntax, and have ./configure search for
nasm or yasm.  (unless I can figure out a way to get gas to assemble
it, maybe with CPP macros.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

Re: [parchive-devel] integrating asm speedups in par2 mainline

[Ace O. <aol...@gm...>]

Too low level for me to make a meaningful comment on the actual
implementation, I just wanted to chime in and say that: If you do choose to
provide a super hand optimized Assembly Routine for some functionality
please make sure that a "reference" implementation is kept in fairly
Portable C. I think this same sentiment has been voiced on the mailing list
before, but probably bears repeating.

Thank you for the work you've done on this, I can tell that you've put a
lot of thought and effort into it and as an end user I appreciate it
greatly!

On Thu, Jul 30, 2015 at 2:43 PM, Peter Cordes <pe...@co...> wrote:

> See my prev message about the specific asm.
>
> gcc doesn't always generate good code from intrinsics, so I wrote some
> of my routines directly in asm.  The question is how to include these
> functions in a way that they can be used by multiple compilers on
> Linux, Windows, and OS X.
>
> Inline asm is not very portable, so defining a function in a separate
> file is the way to go.
>
>   If I use AT&T syntax, then it can build with gcc / clang / icc, but
> IDK anything about MSVC.  Do we care about MSVC?
>
>  The GNU assembler supports Intel syntax for opcodes, but it would
> still use AT&T-style assembler directives, not NASM / YASM style.
> (e.g. .align  rather than align).
>
>
>  I'm not sure there's a clean solution without introducing a
> build-dependency on yasm (http://yasm.tortall.net/).  If we did use
> yasm for asm code, that would work everywhere.  x264 uses yasm.
>
> However, most people have gcc but not yasm installed.
>
> So, thoughts on having asm speedups in the par2 mainline?  I'm just
> talking about an alternative version of rs_process(), so it shouldn't
> impact code clarity.
>
>  There are significant speed gains here.  I think something like a 50%
> speedup over C.
>
>  I'm going to post a question on stackoverflow about portable asm, and
> see if there are any good ways to make it portable without introducing
> a dependency on yasm, and without keeping two versions of the same
> code in sync.  (One MASM syntax for MSVC, which I think it can handle
> natively, and one AT&T / gas syntax for everything else.)
>
> --
> #define X(x,y) x##y
> Peter Cordes ;  e-mail: X(peter@cor , des.ca)
>
> "The gods confound the man who first found out how to distinguish the
> hours!
>  Confound him, too, who in this place set up a sundial, to cut and hack
>  my day so wretchedly into small pieces!" -- Plautus, 200 BC
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iLwEAQEIAAYFAlW6jIIACgkQBaSaEuRa5FPNtgT+PaWjRga/Ii5yqCTwEurzdoVj
> b9R6JapQMmLU6o2/PlUyabc9I8nC+1hTkhM4DR2BiwuaOLuBgfINeR+N6kNyWSP1
> acOmqbNcLd0pFcULjPgSLa0p7tt/fiytikeL6iSC7Vk8TradJ7bis80k2afhQRRr
> 38vi+qI24iihGLuLVblv2gScreXFGsA7X9CbH+qrwN1kMBGQEROHSxoXct0BKg==
> =FKXV
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Parchive-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parchive-devel
>
>

[parchive-devel] integrating asm speedups in par2 mainline

[Peter C. <pe...@co...>]

See my prev message about the specific asm.

gcc doesn't always generate good code from intrinsics, so I wrote some
of my routines directly in asm.  The question is how to include these
functions in a way that they can be used by multiple compilers on
Linux, Windows, and OS X.

Inline asm is not very portable, so defining a function in a separate
file is the way to go.

  If I use AT&T syntax, then it can build with gcc / clang / icc, but
IDK anything about MSVC.  Do we care about MSVC?

 The GNU assembler supports Intel syntax for opcodes, but it would
still use AT&T-style assembler directives, not NASM / YASM style.
(e.g. .align  rather than align).


 I'm not sure there's a clean solution without introducing a
build-dependency on yasm (http://yasm.tortall.net/).  If we did use
yasm for asm code, that would work everywhere.  x264 uses yasm.

However, most people have gcc but not yasm installed.

So, thoughts on having asm speedups in the par2 mainline?  I'm just
talking about an alternative version of rs_process(), so it shouldn't
impact code clarity.

 There are significant speed gains here.  I think something like a 50%
speedup over C.

 I'm going to post a question on stackoverflow about portable asm, and
see if there are any good ways to make it portable without introducing
a dependency on yasm, and without keeping two versions of the same
code in sync.  (One MASM syntax for MSVC, which I think it can handle
natively, and one AT&T / gas syntax for everything else.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

[parchive-devel] ASM speedup for rs_process

[Peter C. <pe...@co...>]

I've been playing around with some x86 asm speedups for rs_process.
I'll send another mail in a sec about practical considerations for
merging this into par2 mainline.


https://github.com/pcordes/par2-asm-experiments

Compile with:

gcc -DIACA_MARKS_OFF -o rs-asmbench -g -Wall -march=native -funroll-loops -O3 -std=gnu11 main.c process-purec.c intrin-nolut.c reedsolomon-x86_64-mmx.s reedsolomon-x86_64-mmx-orig.s asm-avx2-vgatherdd.s intrin-pinsrw.c asm-pinsrw*.s
(I'm lazy and didn't make a Makefile for it.)

 That git repo has some implementations, and a little benchmark driver
that runs various routines in a loop and prints RDTSC counts 
for each.  (Take the minimum: RDTSC counts at constant rate, even if
your CPU isn't running at max frequency.  Also, interrupts / other
events can cause a glitch in one run.)   Some of the functions aren't
don't actually give correct results, I just wanted to see if they ran
any faster when a certian bottleneck was removed.  (e.g. pinsrw-nodep
uses different registers for successive inserts, to see if the
dependency chain was an issue.)

The interesting functions are:

pinsrw128: my best so far, on Sandybridge.  see below
orig-MMX: maybe fastest on Nehalem.  (code from par2tbb)
nolut AVX: see below
AVX2 vgather: uses VPGATHERDD.  Might be close to pinsrw128 on Broadwell.

Others are there just as experiments, and for something to do while
the CPU ramps up to full speed.


*****************
My best general-purpose version so far uses SSE2 PINSRW:

https://github.com/pcordes/par2-asm-experiments/blob/master/asm-pinsrw.s

which is about 16% faster than the MMX punpck code from par2tbb:
https://github.com/pcordes/par2-cleanhistory/blob/par2tbb-upstream/reedsolomon-x86_64-mmx.s

Tested on Intel Sandybridge (i5-2500k) no hyperthreading,
single-threaded.  Last I tested, it was slower on Nehalem.  The loop
doesn't quite fit in the loop buffer, so decode is a bottleneck on
Nehalem.  par2 should choose which rs_process function to use, based
on the CPU.  On Nehalem (or CPUs without AVX), it should probably
choose the MMX version.


*********************
 When the GF16 factor to multiply a source block has few significant
bits, the straightforward non-LUT Peasant's Algorithm
(https://en.wikipedia.org/wiki/Finite_field_arithmetic#Multiplication)
actually wins.

https://github.com/pcordes/par2-asm-experiments/blob/master/intrin-nolut.c

Checking how many leading zeroes there are in factor is trivial (one
instruction), so dispatching based on a break-even threshold for that
is the way to go.

 The nolut routine, with factor having a full 16 significant bits
performs like so on SnB / Haswell CPUs:

* AVX: theoretical throughput of 3.33c per source byte, in practice
    3.35c (unless that number is off because RDTSC's clock was running
    slower than the actual CPU turbo frequency.)

* AVX2: 1.66c / source byte.   Twice as fast: same code, but twice as
    wide.  Memory prefetch should still easily be able to keep up.

* AVX512BW: 0.666c / source byte.  (more than twice as fast, since
    masked operations save 2 of 10 uops (instructions) in the inner loop.)
    Available on Xeon-only Skylake, and then hopefully on
    desktop/laptop CPUs in the generation after that.


This is compared to ~1c / source byte for my pinsrw loop.  So until AVX512,
the standard LUT version is fastest (when factor has most of its bits
set).


******************************
 I never really tried to implement Alexander Wegel's 256b LUT for
4-bit halves.  I think it might be viable with separate 128b LUTs, and
shuffling or masking to combine the results, since before the LUT,
some elements were having their high bits set.  Anyway, it looked like
a lot of shuffling needed.  It's worth looking into with AVX2.


******************************
 I did make a version that uses Intel's AVX2 gather instruction to do
the lookup.  It takes about 1.7x as much time as the PINSRW loop, on
Haswell.  Broadwell is supposed to speed up gather by a factor of
about 1.6, so it's going to only a bit of a loss to use it on
Broadwell.  If Skylake speeds it up any more, it might be worth
looking at.  (I'd like to see benchmark output from anyone that can
run this on a broadwell CPU.)

https://github.com/pcordes/par2-asm-experiments/blob/master/asm-avx2-vgatherdd.s

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

Re: [parchive-devel] Moving Parchive to github

[Ike D. <ike...@gm...>]

UPDATE:

On Thu, May 21, 2015 at 08:58:21PM +0200, Ike Devolder wrote:
> 1. create parchive organization on github (done)

Done.

> 
> 2. move the repo's over to that organization (par2cmdline is there
> already)

Done.

> 
> 3. use cleaned up history for relevant repos and rename original imports
> to ...-archived, or ...-imported

In the long run.

> 
> 4. move tickets from sourceforge to the correct repo's

TODO.

> 
> 5. make website available on parchive.github.io (now it has nothing ;))
> 
> 6. make sure the documents linked to from the website are on github
> 
> 7.  redirect most stuff from sourceforge to github
> 
> users:
> - confirm who is who to add to the parchive organization on github
> - determine who will take the lead for specific repo's/things to be done
> 
> unclear:
> - forums, github does not do forums
> - mailing lists, could just stay on sourceforge or migrate to something
>   else
> 
> -- 
> Ike

If there is someone who clould send me the tarball containing the files
for the current 'parchive.sourceforge.net' website, please do.

Also If you want to be added to the Parchive organization on github,
drop me a note.

-- 
Ike

Re: [parchive-devel] Moving Parchive to github

[Ike D. <ike...@gm...>]

On Fri, May 29, 2015 at 12:30:33PM +0900, Yutaka Sawada wrote:
> Hello, Ike Devolder and SourceForge users.
>  I could not post mail on mailing-list for long.
> 
> > If you are interested in contributing,
> > you can state what your main interest is
> > so we can organize who's doing what.
> 
>  I can compile par2cmdline binary for Windows OS.
> Because most Windows users don't compile an application themselves,
> available ready made binary is useful.
> Is it possible to put it on Parchive's web-site ?
> 
>  At this time, I put my compiled binary on MultiPar's web-forum.
> "https://www.livebusinesschat.com/smf/index.php?topic=5737.0"
> Though my MultiPar doesn't use par2cmdline as PAR2 client,
> some users wanted direct upgrade from old version par2cmdline.
> 
> Best regards,
> Yutaka Sawada
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Parchive-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parchive-devel

Yutaka,

That would be nice of you to do.

I'll take the binary and upload it to github.

When the website is transferred to gh-pages we can ofcourse add proper
links and such to the windows binaries.

-- 
Ike

Re: [parchive-devel] Moving Parchive to github

[Yutaka S. <te...@ou...>]

Hello, Ike Devolder and SourceForge users.
 I could not post mail on mailing-list for long.

> If you are interested in contributing,
> you can state what your main interest is
> so we can organize who's doing what.

 I can compile par2cmdline binary for Windows OS.
Because most Windows users don't compile an application themselves,
available ready made binary is useful.
Is it possible to put it on Parchive's web-site ?

 At this time, I put my compiled binary on MultiPar's web-forum.
"https://www.livebusinesschat.com/smf/index.php?topic=5737.0"
Though my MultiPar doesn't use par2cmdline as PAR2 client,
some users wanted direct upgrade from old version par2cmdline.

Best regards,
Yutaka Sawada

[parchive-devel] par2cmdline 0.6.13 released

[Ike D. <ike...@gm...>]

par2cmdline 0.6.13
==================

BlackEagle (2):
      create test for #49
      bump 0.6.13

Ike Devolder (1):
      Merge pull request #48 from jcfp/patch-1

PeterBClements (4):
      Fixes to enable "make distcheck" to work:
      Fix issue #50 (scan failure) / Correct fix for issue #31 (slow scan)
      Add test19
      Merge pull request #51 from jcfp/master

Sami Väisänen (1):
      Fix for #49 (Scanning extra files messes up verification)

jcfp (3):
      add missing argument for the block-count option
      add -N / -S options to manpage
      Update commandline.cpp

-- 
Ike

Re: [parchive-devel] Moving Parchive to github

[Ike D. <ike...@gm...>]

On Thu, May 21, 2015 at 08:58:21PM +0200, Ike Devolder wrote:
> 1. create parchive organization on github (done)
> 
> 2. move the repo's over to that organization (par2cmdline is there
> already)
> 
> 3. use cleaned up history for relevant repos and rename original imports
> to ...-archived, or ...-imported
> 
> 4. move tickets from sourceforge to the correct repo's
> 
> 5. make website available on parchive.github.io (now it has nothing ;))
> 
> 6. make sure the documents linked to from the website are on github
> 
> 7.  redirect most stuff from sourceforge to github
> 
> users:
> - confirm who is who to add to the parchive organization on github
> - determine who will take the lead for specific repo's/things to be done
> 
> unclear:
> - forums, github does not do forums
> - mailing lists, could just stay on sourceforge or migrate to something
>   else
> 
> -- 
> Ike

The people who want to stay/get involved, please send me an email so I
can invite you to the Parchive organization on github.

If you are interested in contributing, you can state what your main
interest is so we can organize who's doing what.

- If you are interested to create a new or improve the current website,
  let me know.
- If someone is interested in any part of Parchive let me know.
- Someone who is interested to create something new related to parchive,
  welcome!

-- 
Ike

[parchive-devel] Moving Parchive to github

[Ike D. <ike...@gm...>]

1. create parchive organization on github (done)

2. move the repo's over to that organization (par2cmdline is there
already)

3. use cleaned up history for relevant repos and rename original imports
to ...-archived, or ...-imported

4. move tickets from sourceforge to the correct repo's

5. make website available on parchive.github.io (now it has nothing ;))

6. make sure the documents linked to from the website are on github

7.  redirect most stuff from sourceforge to github

users:
- confirm who is who to add to the parchive organization on github
- determine who will take the lead for specific repo's/things to be done

unclear:
- forums, github does not do forums
- mailing lists, could just stay on sourceforge or migrate to something
  else

-- 
Ike

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Ace O. <aol...@gm...>]

It might be worth noting that the Par2TBB site is back online and there is
a new drop from May 5th (20150505) which fixes a bug in the Windows
Version; from the release notes:

- in the Windows version, it was not possible to repair files which were
larger than
  2GB in size because of a 32-bit signed integer extension bug when
handling file
  offsets. Fixed by always treating file offsets as a 64-bit unsigned
integer in both
  the 32-bit and 64-bit versions of the program. This problem only affected
the Windows
  version so there are no new binary builds of the Mac or Linux versions.

It was unclear if any of that code was being used by anyone? I don't see
the Author on this chain I'll forward him this message.


On Fri, May 15, 2015 at 3:49 AM, Ike Devolder <ike...@gm...>
wrote:

> simple steps:
>
> 1. create parchive organization on github (done)
> 2. move the repo's over to that organization (par2cmdline is there already)
> 3. use cleaned up history for relevant repos and rename original imports
> to ...-archived, or ...-imported
> 4. move tickets from sourceforge to the correct repo's
> 5. make website available on parchive.github.io (now it has nothing ;))
> 6. make sure the documents linked to from the website are on github
> 7. redirect most stuff from sourceforge to github
>
> users:
> - confirm who is who to add to the parchive organization on github
> - determine who will take the lead for specific repo's/things to be done
>
> unclear:
> - forums, github does not do forums
> - mailing lists, could just stay on sourceforge or migrate to something
> else
>
> I'm currently having issues to get online so it might take a while for me
> to get my home configuration back in its normal shape.
>
> 2015-05-13 15:53 GMT+02:00 Michael Nahas <mik...@gm...>:
>
>> Ike,
>>
>> It looks like there's a CVS project called "www".  I'm guessing that
>> holds the website.
>>
>> CVS instructions:
>> http://sourceforge.net/p/parchive/code/?source=navbar
>>
>> CVS web viewer:
>> http://parchive.cvs.sourceforge.net/viewvc/parchive/
>>
>> If you can't access it, I can try to build a tarball for you this evening.
>>
>>
>> Ike, do we have a step-by-step plan for moving everything?  I know I'm
>> still on the hook for the mailinglist.  I'll check that out this evening.
>>
>> Mike
>>
>>
>>
>> On Wed, May 13, 2015 at 12:45 AM, Ike Devolder <ike...@gm...>
>> wrote:
>>
>>> On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote:
>>> > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote:
>>> > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote:
>>> > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote:
>>> > > > >
>>> > > > >  I'll prob. do my cleanup anyway, and put it up on a github repo.
>>> > > > > I might tell github it's a "fork" of your repo, so people can
>>> find it,
>>> > > > > even though they would share no commits.  (Different parent but
>>> same
>>> > > > > tree for later commits, once line endings stabilized.)
>>> > > >
>>> > > >  Ok, I have a sanitized-history version of the par2cmdline repo.
>>> > > >
>>> > > >  It's probably going to be a pain to move commits between sanitized
>>> > > > and full-history trees, except with git format-patch and stuff like
>>> > > > that.  So IDK if it makes sense for new development to happen
>>> against
>>> > > > that tree, or if we should just keep it around for reference.  I'll
>>> > > > see what happens with a pull request on github.
>>> >
>>> >  What happens is:
>>> >
>>> >       There isn't anything to compare.
>>> >
>>> >       Parchive:master and pcordes:master are
>>> >        entirely different commit histories.
>>> >
>>> >
>>> >  The last 2 commits on pcordes:master are an update to .gitignore, and
>>> > a .gitattributes that should avoid anyone creating commits with
>>> > non-Unix line endings in the future.
>>> >
>>> >  Attached git format-patch output for them, so you can cherry-pick
>>> > them into Parchive:master.
>>> >
>>> >
>>> > > Thanks for this magnificent work.
>>> > >
>>> > > --
>>> > > Ike
>>> >
>>> >  Thanks, hopefully it's of some use.
>>> >
>>> >  Any thoughts on moving mainline development onto this tree, and
>>> > keeping around the messy-line-endings and permissions history as the
>>> > historical archive?  Instead of the other way around.
>>> >
>>> >  If the official repo can't push/pull from mine, it's not very useful,
>>> > and I should probably rebase tbb onto a non-rewritten version of your
>>> > tree.  Then people could potentially pull branches into their dev
>>> > trees to compare against code from other forks.
>>> >
>>> > --
>>> > #define X(x,y) x##y
>>> > Peter Cordes ;  e-mail: X(peter@cor , des.ca)
>>> >
>>> > "The gods confound the man who first found out how to distinguish the
>>> hours!
>>> >  Confound him, too, who in this place set up a sundial, to cut and hack
>>> >  my day so wretchedly into small pieces!" -- Plautus, 200 BC
>>>
>>> > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001
>>> > From: Peter Cordes <pe...@co...>
>>> > Date: Thu, 7 May 2015 02:08:48 -0300
>>> > Subject: [PATCH 1/2] gitignore: Add more scratch files
>>> >
>>> > Ignore files generated from:
>>> > * performance tuning
>>> > * Eclipse
>>> > * Mac ._ stuff
>>> > * VC++ .suo apparently are local-options and shouldn't be committed
>>> >
>>> > I sometimes run par2 c test.par2 ... while testing stuff, so ignore
>>> test.*
>>> > Tweak this if you want to commit a test.h or something.
>>> > ---
>>> >  .gitignore | 16 ++++++++++++++++
>>> >  1 file changed, 16 insertions(+)
>>> >
>>> > diff --git a/.gitignore b/.gitignore
>>> > index 0e5bcaf..bc2e01f 100644
>>> > --- a/.gitignore
>>> > +++ b/.gitignore
>>> > @@ -10,6 +10,7 @@ par2
>>> >  # test output
>>> >  *.trs
>>> >  *.log
>>> > +testdir/
>>> >
>>> >  # autotools output
>>> >  aclocal.m4
>>> > @@ -23,3 +24,18 @@ config.status
>>> >  configure
>>> >  stamp-h
>>> >  stamp-h1
>>> > +
>>> > +test.*
>>> > +# Linux perf record output
>>> > +perf.*
>>> > +# gcc -fprofile-use
>>> > +*.gcda
>>> > +
>>> > +# eclipse stuff you get when you point it at a Makefile project
>>> > +.cproject
>>> > +.project
>>> > +.settings
>>> > +
>>> > +# par2tbb tarballs have MacOS properties floating around, and VC++
>>> .suo
>>> > +._*
>>> > +*.suo
>>> > --
>>> > 2.3.7
>>> >
>>>
>>> > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001
>>> > From: Peter Cordes <pe...@co...>
>>> > Date: Thu, 7 May 2015 02:14:10 -0300
>>> > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits
>>> use Unix
>>> >  line endings.
>>> >
>>> > ---
>>> >  .gitattributes | 30 ++++++++++++++++++++++++++++++
>>> >  1 file changed, 30 insertions(+)
>>> >  create mode 100644 .gitattributes
>>> >
>>> > diff --git a/.gitattributes b/.gitattributes
>>> > new file mode 100644
>>> > index 0000000..08d58f0
>>> > --- /dev/null
>>> > +++ b/.gitattributes
>>> > @@ -0,0 +1,30 @@
>>> > +# Auto detect text files and perform LF normalization
>>> > +# see
>>> http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>> > +
>>> > +*        text=auto
>>> > +
>>> > +*.cpp    text
>>> > +*.h      text
>>> > +*.txt    text
>>> > +*.s   text
>>> > +
>>> > +*.csproj   text merge=union
>>> > +*.sln      text=unset merge=union
>>> > +*.vcproj   text=unset merge=union
>>> > +*.vcxproj* text=unset merge=union
>>> > +
>>> > +# The VC++ files were already in the repo with DOS line endings
>>> > +# This setting would make git store them internally with LF
>>> > +#*.sln      text merge=union eol=crlf
>>> > +
>>> > +# instead, use text=unset to tell git to not do any conversions on
>>> > +# those files
>>> > +
>>> > +
>>> > +# This will only work well in a repo where all the files have Unix
>>> line
>>> > +# endings.  Having this file in a repo with DOS text files in the
>>> tree will
>>> > +# make git see those files as changed (to Unix line endings,
>>> regardless of
>>> > +# what they are in your working copy).
>>> > +
>>> > +# Conversely, this will make all new commits of text files commit
>>> with Unix
>>> > +# line endings, regardless of what they are in your working copy.
>>> > --
>>> > 2.3.7
>>> >
>>>
>>> When I have sufficient time, I'll check all your work and start moving
>>> everything that is available on sourceforge in its original format to
>>> github.
>>>
>>> I'll probably suffix the original repo's with -archive to indicate those
>>> are just imported repos from sourceforge.
>>>
>>> The cleaned up repo's might become the new upstream after I verified
>>> everything.
>>>
>>> thx
>>>
>>>
>>> --
>>> Ike
>>>
>>
>>
>
>
> --
> Ike
>

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Ike D. <ike...@gm...>]

simple steps:

1. create parchive organization on github (done)
2. move the repo's over to that organization (par2cmdline is there already)
3. use cleaned up history for relevant repos and rename original imports to
...-archived, or ...-imported
4. move tickets from sourceforge to the correct repo's
5. make website available on parchive.github.io (now it has nothing ;))
6. make sure the documents linked to from the website are on github
7. redirect most stuff from sourceforge to github

users:
- confirm who is who to add to the parchive organization on github
- determine who will take the lead for specific repo's/things to be done

unclear:
- forums, github does not do forums
- mailing lists, could just stay on sourceforge or migrate to something else

I'm currently having issues to get online so it might take a while for me
to get my home configuration back in its normal shape.

2015-05-13 15:53 GMT+02:00 Michael Nahas <mik...@gm...>:

> Ike,
>
> It looks like there's a CVS project called "www".  I'm guessing that holds
> the website.
>
> CVS instructions:
> http://sourceforge.net/p/parchive/code/?source=navbar
>
> CVS web viewer:
> http://parchive.cvs.sourceforge.net/viewvc/parchive/
>
> If you can't access it, I can try to build a tarball for you this evening.
>
>
> Ike, do we have a step-by-step plan for moving everything?  I know I'm
> still on the hook for the mailinglist.  I'll check that out this evening.
>
> Mike
>
>
>
> On Wed, May 13, 2015 at 12:45 AM, Ike Devolder <ike...@gm...>
> wrote:
>
>> On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote:
>> > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote:
>> > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote:
>> > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote:
>> > > > >
>> > > > >  I'll prob. do my cleanup anyway, and put it up on a github repo.
>> > > > > I might tell github it's a "fork" of your repo, so people can
>> find it,
>> > > > > even though they would share no commits.  (Different parent but
>> same
>> > > > > tree for later commits, once line endings stabilized.)
>> > > >
>> > > >  Ok, I have a sanitized-history version of the par2cmdline repo.
>> > > >
>> > > >  It's probably going to be a pain to move commits between sanitized
>> > > > and full-history trees, except with git format-patch and stuff like
>> > > > that.  So IDK if it makes sense for new development to happen
>> against
>> > > > that tree, or if we should just keep it around for reference.  I'll
>> > > > see what happens with a pull request on github.
>> >
>> >  What happens is:
>> >
>> >       There isn't anything to compare.
>> >
>> >       Parchive:master and pcordes:master are
>> >        entirely different commit histories.
>> >
>> >
>> >  The last 2 commits on pcordes:master are an update to .gitignore, and
>> > a .gitattributes that should avoid anyone creating commits with
>> > non-Unix line endings in the future.
>> >
>> >  Attached git format-patch output for them, so you can cherry-pick
>> > them into Parchive:master.
>> >
>> >
>> > > Thanks for this magnificent work.
>> > >
>> > > --
>> > > Ike
>> >
>> >  Thanks, hopefully it's of some use.
>> >
>> >  Any thoughts on moving mainline development onto this tree, and
>> > keeping around the messy-line-endings and permissions history as the
>> > historical archive?  Instead of the other way around.
>> >
>> >  If the official repo can't push/pull from mine, it's not very useful,
>> > and I should probably rebase tbb onto a non-rewritten version of your
>> > tree.  Then people could potentially pull branches into their dev
>> > trees to compare against code from other forks.
>> >
>> > --
>> > #define X(x,y) x##y
>> > Peter Cordes ;  e-mail: X(peter@cor , des.ca)
>> >
>> > "The gods confound the man who first found out how to distinguish the
>> hours!
>> >  Confound him, too, who in this place set up a sundial, to cut and hack
>> >  my day so wretchedly into small pieces!" -- Plautus, 200 BC
>>
>> > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001
>> > From: Peter Cordes <pe...@co...>
>> > Date: Thu, 7 May 2015 02:08:48 -0300
>> > Subject: [PATCH 1/2] gitignore: Add more scratch files
>> >
>> > Ignore files generated from:
>> > * performance tuning
>> > * Eclipse
>> > * Mac ._ stuff
>> > * VC++ .suo apparently are local-options and shouldn't be committed
>> >
>> > I sometimes run par2 c test.par2 ... while testing stuff, so ignore
>> test.*
>> > Tweak this if you want to commit a test.h or something.
>> > ---
>> >  .gitignore | 16 ++++++++++++++++
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/.gitignore b/.gitignore
>> > index 0e5bcaf..bc2e01f 100644
>> > --- a/.gitignore
>> > +++ b/.gitignore
>> > @@ -10,6 +10,7 @@ par2
>> >  # test output
>> >  *.trs
>> >  *.log
>> > +testdir/
>> >
>> >  # autotools output
>> >  aclocal.m4
>> > @@ -23,3 +24,18 @@ config.status
>> >  configure
>> >  stamp-h
>> >  stamp-h1
>> > +
>> > +test.*
>> > +# Linux perf record output
>> > +perf.*
>> > +# gcc -fprofile-use
>> > +*.gcda
>> > +
>> > +# eclipse stuff you get when you point it at a Makefile project
>> > +.cproject
>> > +.project
>> > +.settings
>> > +
>> > +# par2tbb tarballs have MacOS properties floating around, and VC++ .suo
>> > +._*
>> > +*.suo
>> > --
>> > 2.3.7
>> >
>>
>> > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001
>> > From: Peter Cordes <pe...@co...>
>> > Date: Thu, 7 May 2015 02:14:10 -0300
>> > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits use
>> Unix
>> >  line endings.
>> >
>> > ---
>> >  .gitattributes | 30 ++++++++++++++++++++++++++++++
>> >  1 file changed, 30 insertions(+)
>> >  create mode 100644 .gitattributes
>> >
>> > diff --git a/.gitattributes b/.gitattributes
>> > new file mode 100644
>> > index 0000000..08d58f0
>> > --- /dev/null
>> > +++ b/.gitattributes
>> > @@ -0,0 +1,30 @@
>> > +# Auto detect text files and perform LF normalization
>> > +# see
>> http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>> > +
>> > +*        text=auto
>> > +
>> > +*.cpp    text
>> > +*.h      text
>> > +*.txt    text
>> > +*.s   text
>> > +
>> > +*.csproj   text merge=union
>> > +*.sln      text=unset merge=union
>> > +*.vcproj   text=unset merge=union
>> > +*.vcxproj* text=unset merge=union
>> > +
>> > +# The VC++ files were already in the repo with DOS line endings
>> > +# This setting would make git store them internally with LF
>> > +#*.sln      text merge=union eol=crlf
>> > +
>> > +# instead, use text=unset to tell git to not do any conversions on
>> > +# those files
>> > +
>> > +
>> > +# This will only work well in a repo where all the files have Unix line
>> > +# endings.  Having this file in a repo with DOS text files in the tree
>> will
>> > +# make git see those files as changed (to Unix line endings,
>> regardless of
>> > +# what they are in your working copy).
>> > +
>> > +# Conversely, this will make all new commits of text files commit with
>> Unix
>> > +# line endings, regardless of what they are in your working copy.
>> > --
>> > 2.3.7
>> >
>>
>> When I have sufficient time, I'll check all your work and start moving
>> everything that is available on sourceforge in its original format to
>> github.
>>
>> I'll probably suffix the original repo's with -archive to indicate those
>> are just imported repos from sourceforge.
>>
>> The cleaned up repo's might become the new upstream after I verified
>> everything.
>>
>> thx
>>
>>
>> --
>> Ike
>>
>
>


-- 
Ike

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Ike D. <ike...@gm...>]

I'm going to have some delay om some stuff, my router died so I'm not as
connected as I should be.

2015-05-13 21:13 GMT+02:00 Ryan Gallagher <cli...@gm...>:

>
> On Wed, May 13, 2015 at 8:53 AM, Michael Nahas <mik...@gm...>
> wrote:
>
>> It looks like there's a CVS project called "www".  I'm guessing that
>> holds the website.
>
>
> We almost checked the website into cvs at one point.  nothing there.
> tarball is the way to go, someone who has shell access can zip it up,
> otherwise I can fetch it for you, just let me know.
>
> Ryan
> binerman / clickykbd
>



-- 
Ike

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Ryan G. <cli...@gm...>]

On Wed, May 13, 2015 at 8:53 AM, Michael Nahas <mik...@gm...> wrote:

> It looks like there's a CVS project called "www".  I'm guessing that holds
> the website.


We almost checked the website into cvs at one point.  nothing there.
tarball is the way to go, someone who has shell access can zip it up,
otherwise I can fetch it for you, just let me know.

Ryan
binerman / clickykbd

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Michael N. <mik...@gm...>]

Ike,

It looks like there's a CVS project called "www".  I'm guessing that holds
the website.

CVS instructions:
http://sourceforge.net/p/parchive/code/?source=navbar

CVS web viewer:
http://parchive.cvs.sourceforge.net/viewvc/parchive/

If you can't access it, I can try to build a tarball for you this evening.


Ike, do we have a step-by-step plan for moving everything?  I know I'm
still on the hook for the mailinglist.  I'll check that out this evening.

Mike



On Wed, May 13, 2015 at 12:45 AM, Ike Devolder <ike...@gm...>
wrote:

> On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote:
> > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote:
> > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote:
> > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote:
> > > > >
> > > > >  I'll prob. do my cleanup anyway, and put it up on a github repo.
> > > > > I might tell github it's a "fork" of your repo, so people can find
> it,
> > > > > even though they would share no commits.  (Different parent but
> same
> > > > > tree for later commits, once line endings stabilized.)
> > > >
> > > >  Ok, I have a sanitized-history version of the par2cmdline repo.
> > > >
> > > >  It's probably going to be a pain to move commits between sanitized
> > > > and full-history trees, except with git format-patch and stuff like
> > > > that.  So IDK if it makes sense for new development to happen against
> > > > that tree, or if we should just keep it around for reference.  I'll
> > > > see what happens with a pull request on github.
> >
> >  What happens is:
> >
> >       There isn't anything to compare.
> >
> >       Parchive:master and pcordes:master are
> >        entirely different commit histories.
> >
> >
> >  The last 2 commits on pcordes:master are an update to .gitignore, and
> > a .gitattributes that should avoid anyone creating commits with
> > non-Unix line endings in the future.
> >
> >  Attached git format-patch output for them, so you can cherry-pick
> > them into Parchive:master.
> >
> >
> > > Thanks for this magnificent work.
> > >
> > > --
> > > Ike
> >
> >  Thanks, hopefully it's of some use.
> >
> >  Any thoughts on moving mainline development onto this tree, and
> > keeping around the messy-line-endings and permissions history as the
> > historical archive?  Instead of the other way around.
> >
> >  If the official repo can't push/pull from mine, it's not very useful,
> > and I should probably rebase tbb onto a non-rewritten version of your
> > tree.  Then people could potentially pull branches into their dev
> > trees to compare against code from other forks.
> >
> > --
> > #define X(x,y) x##y
> > Peter Cordes ;  e-mail: X(peter@cor , des.ca)
> >
> > "The gods confound the man who first found out how to distinguish the
> hours!
> >  Confound him, too, who in this place set up a sundial, to cut and hack
> >  my day so wretchedly into small pieces!" -- Plautus, 200 BC
>
> > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001
> > From: Peter Cordes <pe...@co...>
> > Date: Thu, 7 May 2015 02:08:48 -0300
> > Subject: [PATCH 1/2] gitignore: Add more scratch files
> >
> > Ignore files generated from:
> > * performance tuning
> > * Eclipse
> > * Mac ._ stuff
> > * VC++ .suo apparently are local-options and shouldn't be committed
> >
> > I sometimes run par2 c test.par2 ... while testing stuff, so ignore
> test.*
> > Tweak this if you want to commit a test.h or something.
> > ---
> >  .gitignore | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 0e5bcaf..bc2e01f 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -10,6 +10,7 @@ par2
> >  # test output
> >  *.trs
> >  *.log
> > +testdir/
> >
> >  # autotools output
> >  aclocal.m4
> > @@ -23,3 +24,18 @@ config.status
> >  configure
> >  stamp-h
> >  stamp-h1
> > +
> > +test.*
> > +# Linux perf record output
> > +perf.*
> > +# gcc -fprofile-use
> > +*.gcda
> > +
> > +# eclipse stuff you get when you point it at a Makefile project
> > +.cproject
> > +.project
> > +.settings
> > +
> > +# par2tbb tarballs have MacOS properties floating around, and VC++ .suo
> > +._*
> > +*.suo
> > --
> > 2.3.7
> >
>
> > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001
> > From: Peter Cordes <pe...@co...>
> > Date: Thu, 7 May 2015 02:14:10 -0300
> > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits use
> Unix
> >  line endings.
> >
> > ---
> >  .gitattributes | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> >  create mode 100644 .gitattributes
> >
> > diff --git a/.gitattributes b/.gitattributes
> > new file mode 100644
> > index 0000000..08d58f0
> > --- /dev/null
> > +++ b/.gitattributes
> > @@ -0,0 +1,30 @@
> > +# Auto detect text files and perform LF normalization
> > +# see
> http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
> > +
> > +*        text=auto
> > +
> > +*.cpp    text
> > +*.h      text
> > +*.txt    text
> > +*.s   text
> > +
> > +*.csproj   text merge=union
> > +*.sln      text=unset merge=union
> > +*.vcproj   text=unset merge=union
> > +*.vcxproj* text=unset merge=union
> > +
> > +# The VC++ files were already in the repo with DOS line endings
> > +# This setting would make git store them internally with LF
> > +#*.sln      text merge=union eol=crlf
> > +
> > +# instead, use text=unset to tell git to not do any conversions on
> > +# those files
> > +
> > +
> > +# This will only work well in a repo where all the files have Unix line
> > +# endings.  Having this file in a repo with DOS text files in the tree
> will
> > +# make git see those files as changed (to Unix line endings, regardless
> of
> > +# what they are in your working copy).
> > +
> > +# Conversely, this will make all new commits of text files commit with
> Unix
> > +# line endings, regardless of what they are in your working copy.
> > --
> > 2.3.7
> >
>
> When I have sufficient time, I'll check all your work and start moving
> everything that is available on sourceforge in its original format to
> github.
>
> I'll probably suffix the original repo's with -archive to indicate those
> are just imported repos from sourceforge.
>
> The cleaned up repo's might become the new upstream after I verified
> everything.
>
> thx
>
>
> --
> Ike
>

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Ike D. <ike...@gm...>]

On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote:
> On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote:
> > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote:
> > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote:
> > > > 
> > > >  I'll prob. do my cleanup anyway, and put it up on a github repo.
> > > > I might tell github it's a "fork" of your repo, so people can find it,
> > > > even though they would share no commits.  (Different parent but same
> > > > tree for later commits, once line endings stabilized.)
> > > 
> > >  Ok, I have a sanitized-history version of the par2cmdline repo.
> > > 
> > >  It's probably going to be a pain to move commits between sanitized
> > > and full-history trees, except with git format-patch and stuff like
> > > that.  So IDK if it makes sense for new development to happen against
> > > that tree, or if we should just keep it around for reference.  I'll
> > > see what happens with a pull request on github.
> 
>  What happens is:
> 
> 	There isn't anything to compare.
> 
> 	Parchive:master and pcordes:master are
> 	 entirely different commit histories. 
> 
> 
>  The last 2 commits on pcordes:master are an update to .gitignore, and
> a .gitattributes that should avoid anyone creating commits with
> non-Unix line endings in the future.
> 
>  Attached git format-patch output for them, so you can cherry-pick
> them into Parchive:master.
> 
> 
> > Thanks for this magnificent work.
> > 
> > -- 
> > Ike
> 
>  Thanks, hopefully it's of some use.
> 
>  Any thoughts on moving mainline development onto this tree, and
> keeping around the messy-line-endings and permissions history as the
> historical archive?  Instead of the other way around.
> 
>  If the official repo can't push/pull from mine, it's not very useful,
> and I should probably rebase tbb onto a non-rewritten version of your
> tree.  Then people could potentially pull branches into their dev
> trees to compare against code from other forks.
> 
> -- 
> #define X(x,y) x##y
> Peter Cordes ;  e-mail: X(peter@cor , des.ca)
> 
> "The gods confound the man who first found out how to distinguish the hours!
>  Confound him, too, who in this place set up a sundial, to cut and hack
>  my day so wretchedly into small pieces!" -- Plautus, 200 BC

> From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001
> From: Peter Cordes <pe...@co...>
> Date: Thu, 7 May 2015 02:08:48 -0300
> Subject: [PATCH 1/2] gitignore: Add more scratch files
> 
> Ignore files generated from:
> * performance tuning
> * Eclipse
> * Mac ._ stuff
> * VC++ .suo apparently are local-options and shouldn't be committed
> 
> I sometimes run par2 c test.par2 ... while testing stuff, so ignore test.*
> Tweak this if you want to commit a test.h or something.
> ---
>  .gitignore | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 0e5bcaf..bc2e01f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -10,6 +10,7 @@ par2
>  # test output
>  *.trs
>  *.log
> +testdir/
>  
>  # autotools output
>  aclocal.m4
> @@ -23,3 +24,18 @@ config.status
>  configure
>  stamp-h
>  stamp-h1
> +
> +test.*
> +# Linux perf record output
> +perf.*
> +# gcc -fprofile-use
> +*.gcda
> +
> +# eclipse stuff you get when you point it at a Makefile project
> +.cproject
> +.project
> +.settings
> +
> +# par2tbb tarballs have MacOS properties floating around, and VC++ .suo
> +._*
> +*.suo
> -- 
> 2.3.7
> 

> From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001
> From: Peter Cordes <pe...@co...>
> Date: Thu, 7 May 2015 02:14:10 -0300
> Subject: [PATCH 2/2] .gitattributes: make everyone's future commits use Unix
>  line endings.
> 
> ---
>  .gitattributes | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>  create mode 100644 .gitattributes
> 
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 0000000..08d58f0
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1,30 @@
> +# Auto detect text files and perform LF normalization
> +# see http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
> +
> +*        text=auto
> +
> +*.cpp    text
> +*.h      text
> +*.txt    text
> +*.s	 text
> +
> +*.csproj   text merge=union
> +*.sln      text=unset merge=union
> +*.vcproj   text=unset merge=union
> +*.vcxproj* text=unset merge=union
> +
> +# The VC++ files were already in the repo with DOS line endings
> +# This setting would make git store them internally with LF
> +#*.sln      text merge=union eol=crlf
> +
> +# instead, use text=unset to tell git to not do any conversions on
> +# those files
> +
> +
> +# This will only work well in a repo where all the files have Unix line
> +# endings.  Having this file in a repo with DOS text files in the tree will
> +# make git see those files as changed (to Unix line endings, regardless of
> +# what they are in your working copy).
> +
> +# Conversely, this will make all new commits of text files commit with Unix
> +# line endings, regardless of what they are in your working copy.
> -- 
> 2.3.7
> 

When I have sufficient time, I'll check all your work and start moving
everything that is available on sourceforge in its original format to
github.

I'll probably suffix the original repo's with -archive to indicate those
are just imported repos from sourceforge.

The cleaned up repo's might become the new upstream after I verified
everything.

thx


-- 
Ike

Re: [parchive-devel] Blessing of github.com/BlackIkeEagle/par2cmdline

[Ike D. <ike...@gm...>]

On Thu, Apr 30, 2015 at 01:46:28PM -0500, Ryan Gallagher wrote:
> On Thu, Apr 30, 2015 at 10:04 AM, Michael Nahas <mik...@gm...>
> wrote:
> 
> > Right now, I'll try to contact the people who have administrator
> > privileges on SourceForge.  We will need them for the mailing list archives
> > and to eventually shutter the project there.
> 
> 
> Hi Mike.
> 
> I'm still around, and happy to grant you admin privs if it will let me, if
> you have trouble raising any of the other admins that is.
> My original involvement was just the website, and what a relic it is now
> (though glad you still love the banner), I didn't deserve admin privs but
> back then you had to have them to get shell access on sourceforge i think.
> (which is probably still how you need to access the public web files).
> 
> Can't commit much time to help you, but happy to flip bits or grab things
> that only an admin can do if necessary.
> 
> Ryan Gallagher

> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

> _______________________________________________
> Parchive-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parchive-devel

Hi Ryan,

Could you send me the website code ? What is currently up on
parchive.sourceforge.net ?

I could just import the old website on github and start from there to
update it a little bit.

Once the old website is imported on github, maybe the
parchive.sourceforge.net could redirect to parchive.github.io.

thx

-- 
Ike