upset, genini: different version ordering

upset, genini: different version ordering

[Achim Gratz]

I've just found that upset and genini will order versions differently.
For perl-Carp, genini produces:

version: 1.36-1                                                                                                                                                                
[prev]                                                                                                                                                                         
version: 1.3301-2                                                                                                                                                              

while upset comes up with:

version: 1.3301-2
[prev]
version: 1.36-1

For the way Perl distributions are versioned, genini is correct here
(although it would fail when a distribution switches from x.y.z
versioning to canonical x.y versioning as PDL has done in the past).

Upset seems to order based on the individual parts in the split version
string?  In any case, at least for Perl distributions it should rather
use version objects.

http://search.cpan.org/~jpeacock/version-0.9912/lib/version.pod


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Jon TURNEY]

On 20/07/2015 19:03, Achim Gratz wrote:
>
> I've just found that upset and genini will order versions differently.
> For perl-Carp, genini produces:
>
> version: 1.36-1
> [prev]
> version: 1.3301-2
>
> while upset comes up with:
>
> version: 1.3301-2
> [prev]
> version: 1.36-1
>
> For the way Perl distributions are versioned, genini is correct here
> (although it would fail when a distribution switches from x.y.z
> versioning to canonical x.y versioning as PDL has done in the past).
>
> Upset seems to order based on the individual parts in the split version
> string?  In any case, at least for Perl distributions it should rather
> use version objects.
>
> http://search.cpan.org/~jpeacock/version-0.9912/lib/version.pod

If I recall correctly, genini is just broken, doing some kind of lexical 
sort which e.g. sorts 1.10 before 1.9.

Re: upset, genini: different version ordering

[Achim Gratz]

Jon TURNEY writes:
> If I recall correctly, genini is just broken, doing some kind of
> lexical sort which e.g. sorts 1.10 before 1.9.

Yes, it just globs the filenames, so the order is dependent on the
locale.  But I can't tell what upset is doing, except that Yaakov fixed
something recently w.r.t. the release numbers.  Once I know I can go and
fix genini, but as the example shows another fix might need to be
applied to upset as well.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Jul 20 20:42, Achim Gratz wrote:
> Jon TURNEY writes:
> > If I recall correctly, genini is just broken, doing some kind of
> > lexical sort which e.g. sorts 1.10 before 1.9.
> 
> Yes, it just globs the filenames, so the order is dependent on the
> locale.  But I can't tell what upset is doing, except that Yaakov fixed
> something recently w.r.t. the release numbers.  Once I know I can go and
> fix genini, but as the example shows another fix might need to be
> applied to upset as well.

Why?  Version 1.10 is obviously < 1.100 or 1.1000.  How's this handled
in rpm?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> Why?  Version 1.10 is obviously < 1.100 or 1.1000.  How's this handled
> in rpm?

Dunno about rpm.  But for Perl, version numbers are handled a bit
differently and that extends to the versioning of distributions.  Your
above example is valid for "numified" version numbers, but not other
variants.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Jul 20 22:09, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Why?  Version 1.10 is obviously < 1.100 or 1.1000.  How's this handled
> > in rpm?
> 
> Dunno about rpm.  But for Perl, version numbers are handled a bit
> differently and that extends to the versioning of distributions.  Your
> above example is valid for "numified" version numbers, but not other
> variants.

How do you tell upset that a package uses a different numbering
scheme?  You'd have two scenarios which can't be recognized 
automatically, don't you?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> How do you tell upset that a package uses a different numbering
> scheme?  You'd have two scenarios which can't be recognized 
> automatically, don't you?

In the case of Perl distributions, I know the ordering scheme and it's
built in to upset already, sort-of, only has to be used.  For the rest
upset should probably keep doing what it was doing before, but I want to
fix genini to do the same.

In the long run we might want to add some keyword in setup.hint that
specifies which ordering algorithm to use.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Jul 21 18:59, Achim Gratz wrote:
> Corinna Vinschen writes:
> > How do you tell upset that a package uses a different numbering
> > scheme?  You'd have two scenarios which can't be recognized 
> > automatically, don't you?
> 
> In the case of Perl distributions, I know the ordering scheme and it's
> built in to upset already, sort-of, only has to be used.  For the rest
> upset should probably keep doing what it was doing before, but I want to
> fix genini to do the same.
> 
> In the long run we might want to add some keyword in setup.hint that
> specifies which ordering algorithm to use.

That's not sufficient, probably.  I'm pretty sure you'd have to tweak
setup as well.

And then there's still the questionable license of upset...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> That's not sufficient, probably.  I'm pretty sure you'd have to tweak
> setup as well.

Maybe, but the order setup itself imposes really comes into play only if
the system has a version installed that is not in setup.ini anymore and
that setup would order before all other versions listed there.  And
forcing "curr" to be installed (the sync toggle that has been proposed)
takes care of that.

> And then there's still the questionable license of upset...

That's why I don't really want to look at the code.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On Jul 21 21:13, Achim Gratz wrote:
> Corinna Vinschen writes:
> > That's not sufficient, probably.  I'm pretty sure you'd have to tweak
> > setup as well.
> 
> Maybe, but the order setup itself imposes really comes into play only if
> the system has a version installed that is not in setup.ini anymore and
> that setup would order before all other versions listed there.  And
> forcing "curr" to be installed (the sync toggle that has been proposed)
> takes care of that.

But then, for the time being, you can take care of this weird ordering
with prev and cutrr markers, right?

> > And then there's still the questionable license of upset...
> 
> That's why I don't really want to look at the code.

Well, apart from "me, no perl", me neither.  Nevertheless I looked into
upset briefly (I'm tainted anyway), and it turns out that the version
number handling is entirely hand-made.  Version.pm is a 85 lines perl
script, providing two functions, Normalize($;$) and Sort(\@)

Your suggestion was to change upset to use the version handling lib
from http://search.cpan.org/~jpeacock/version-0.9912/lib/version.pod,
right?

Is anybody here willing to rework a set of perl scripts to improve the
version handling :}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> But then, for the time being, you can take care of this weird ordering
> with prev and curr markers, right?

Yes, I could, but since I test things with genini locally I'll have to
guess when to to that.

> Well, apart from "me, no perl", me neither.  Nevertheless I looked into
> upset briefly (I'm tainted anyway), and it turns out that the version
> number handling is entirely hand-made.  Version.pm is a 85 lines perl
> script, providing two functions, Normalize($;$) and Sort(\@)

Thanks, that confirms my suspicions.  Could you tell me what Normalize
uses as the two inputs and how it returns the result?

> Your suggestion was to change upset to use the version handling lib
> from http://search.cpan.org/~jpeacock/version-0.9912/lib/version.pod,
> right?

Just for modules starting with "perl".  For the other ones we need to
keep doing what we did before, until such time that we can specify the
ordering algorithm.

> Is anybody here willing to rework a set of perl scripts to improve the
> version handling :}

I've started something in genini already


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Jul 22 18:20, Achim Gratz wrote:
> Corinna Vinschen writes:
> > But then, for the time being, you can take care of this weird ordering
> > with prev and curr markers, right?
> 
> Yes, I could, but since I test things with genini locally I'll have to
> guess when to to that.
> 
> > Well, apart from "me, no perl", me neither.  Nevertheless I looked into
> > upset briefly (I'm tainted anyway), and it turns out that the version
> > number handling is entirely hand-made.  Version.pm is a 85 lines perl
> > script, providing two functions, Normalize($;$) and Sort(\@)
> 
> Thanks, that confirms my suspicions.  Could you tell me what Normalize
> uses as the two inputs and how it returns the result?

I'm not really sure.  It seems the input is a filename and something
optional called a "prematch".  The return value is apparently a pair,
normalized version and version.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
>> Thanks, that confirms my suspicions.  Could you tell me what Normalize
>> uses as the two inputs and how it returns the result?
>
> I'm not really sure.  It seems the input is a filename and something
> optional called a "prematch".

Is that optional paremeter ever used?

> The return value is apparently a pair, normalized version and version.

OK, so it would seem that the sort routine will use the first for
ordering and the second for any literal use of the version string.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

On Jul 23 19:08, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Thanks, that confirms my suspicions.  Could you tell me what Normalize
> >> uses as the two inputs and how it returns the result?
> >
> > I'm not really sure.  It seems the input is a filename and something
> > optional called a "prematch".
> 
> Is that optional paremeter ever used?

Yes.  In the function itself prematch is generated from some regex if
it's not given as parameter.  There are three places calling Normalize,
two of them with a 2nd parameter.

On closer inspection it seems there's already some provisioning for
different versioning schemes.  At one point the second parameter
is constructed from an entry in setup.hint called "verpat" and a keyword
"verpat" is recognized for that.  If "verpat: ,,," is not given for a package,
the pattern used as 2nd parameter is set to the package name, a dash,
followed by any character string, followed by ".tar", followed by an
arbitrary string.

Paramter 1 can be a path, not only a filename, btw.

Uh oh.  There's also a snippet of code at the end of Normalize which
"normalizes" the file suffix.  All .tar* variants are "normalized" into
.tar.gz, presumably for sorting purposes.

> > The return value is apparently a pair, normalized version and version.
> 
> OK, so it would seem that the sort routine will use the first for
> ordering and the second for any literal use of the version string.

Maybe.  Actually, I was wrong.  Normalize can return a single value
*or* an array with three values.  It seems only the three-value array
return variant is used.  The places from where Normalize is called
cuts out the values of interest.

I'm really sorry, but AFAICS the code should be able to win the
obfuscated perl contest hands down.  No noticable commenting either.

We could really need help from somebody knowing perl well enough
to understand and describe code :}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Jul 23 21:17, Corinna Vinschen wrote:
> On Jul 23 19:08, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > >> Thanks, that confirms my suspicions.  Could you tell me what Normalize
> > >> uses as the two inputs and how it returns the result?
> > >
> > > I'm not really sure.  It seems the input is a filename and something
> > > optional called a "prematch".
> > 
> > Is that optional paremeter ever used?
> 
> Yes.  In the function itself prematch is generated from some regex if
> it's not given as parameter.  There are three places calling Normalize,
> two of them with a 2nd parameter.
> 
> On closer inspection it seems there's already some provisioning for
> different versioning schemes.  At one point the second parameter
> is constructed from an entry in setup.hint called "verpat" and a keyword
> "verpat" is recognized for that.  If "verpat: ,,," is not given for a package,
> the pattern used as 2nd parameter is set to the package name, a dash,
> followed by any character string, followed by ".tar", followed by an
> arbitrary string.
> 
> Paramter 1 can be a path, not only a filename, btw.
> 
> Uh oh.  There's also a snippet of code at the end of Normalize which
> "normalizes" the file suffix.  All .tar* variants are "normalized" into
> .tar.gz, presumably for sorting purposes.

Uh oh, because this code snippet doesn't know about tar.xz, afaics.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> Yes.  In the function itself prematch is generated from some regex if
> it's not given as parameter.  There are three places calling Normalize,
> two of them with a 2nd parameter.
>
> On closer inspection it seems there's already some provisioning for
> different versioning schemes.  At one point the second parameter
> is constructed from an entry in setup.hint called "verpat" and a keyword
> "verpat" is recognized for that.  If "verpat: ,,," is not given for a package,
> the pattern used as 2nd parameter is set to the package name, a dash,
> followed by any character string,

Any character string or starting with a digit?

In any case, that second parameter is then basically telling how to
split the package name up into its constituents.

> followed by ".tar", followed by an
> arbitrary string.
>
> Paramter 1 can be a path, not only a filename, btw.

Should be, yes.

> Uh oh.  There's also a snippet of code at the end of Normalize which
> "normalizes" the file suffix.  All .tar* variants are "normalized" into
> .tar.gz, presumably for sorting purposes.

Except for some of the code details and "verpat:" (which I don't think
have ever been described or used anywhere i can remember), that closely
resembles what setup.exe is doing.  Actually, setup parses like this:

path goes from the start of string to the last path separator

package name from the remainder of the string until the first "-" that's
followed by a digit (exclusive the actual "-")

package release from the last "-" until the ".tar.*" extension.

Packages can have a "-src" and a "-patch" suffix.  Only the "-src"
suffix is currently used AFAIK, althoug I'd wish that "-debuginfo",
"-devel" and  maybe "-doc" could also be treated like that.

> I'm really sorry, but AFAICS the code should be able to win the
> obfuscated perl contest hands down.  No noticable commenting either.

https://www.unix-ag.uni-kl.de/~conrad/shocc/xd3.html#nr288

Perl that doesn't look like line noise even to the person that wrote it
four weeks ago is inefficient.  :-)

> We could really need help from somebody knowing perl well enough
> to understand and describe code :}

I'd rather write new code when the objectives can be agreed upon.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On Jul 23 21:37, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Yes.  In the function itself prematch is generated from some regex if
> > it's not given as parameter.  There are three places calling Normalize,
> > two of them with a 2nd parameter.
> >
> > On closer inspection it seems there's already some provisioning for
> > different versioning schemes.  At one point the second parameter
> > is constructed from an entry in setup.hint called "verpat" and a keyword
> > "verpat" is recognized for that.  If "verpat: ,,," is not given for a package,
> > the pattern used as 2nd parameter is set to the package name, a dash,
> > followed by any character string,
> 
> Any character string or starting with a digit?

Any string.  I guess that works because the string prefix is fixed.
It's the name of the package.

> > I'm really sorry, but AFAICS the code should be able to win the
> > obfuscated perl contest hands down.  No noticable commenting either.
> 
> https://www.unix-ag.uni-kl.de/~conrad/shocc/xd3.html#nr288
> 
> Perl that doesn't look like line noise even to the person that wrote it
> four weeks ago is inefficient.  :-)

Argh!

> > We could really need help from somebody knowing perl well enough
> > to understand and describe code :}
> 
> I'd rather write new code when the objectives can be agreed upon.

New code as in "new version checks for upset"?  Or as in "new upset
from scratch"?

Still, it would be helpful to have some perl guru understanding the
code being able to describe it to a coder.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> Any string.  I guess that works because the string prefix is fixed.
> It's the name of the package.

True, it already knows that from setup.hint.  But then it's still a
difference from how setup.exe handles things.  Maybe I need to check
again because setup.exe could also know the name of the package when it
tries to extract the version from the filename.

>> I'd rather write new code when the objectives can be agreed upon.
>
> New code as in "new version checks for upset"?  Or as in "new upset
> from scratch"?

Both.  Let me get something going in genini and then try to transplant
it into upset.  A possible replacement for upset is at least a year
away, given how much (or rather little) time I can put into that at the
moment.

> Still, it would be helpful to have some perl guru understanding the
> code being able to describe it to a coder.

You've just described two persons.  Who's the sond one?  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Jul 23 22:02, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Any string.  I guess that works because the string prefix is fixed.
> > It's the name of the package.
> 
> True, it already knows that from setup.hint.  But then it's still a
> difference from how setup.exe handles things.  Maybe I need to check
> again because setup.exe could also know the name of the package when it
> tries to extract the version from the filename.
> 
> >> I'd rather write new code when the objectives can be agreed upon.
> >
> > New code as in "new version checks for upset"?  Or as in "new upset
> > from scratch"?
> 
> Both.  Let me get something going in genini and then try to transplant
> it into upset.  A possible replacement for upset is at least a year
> away, given how much (or rather little) time I can put into that at the
> moment.

That's ok.  I'm also not overly blessed with time for Cygwin in
the months to come, working on Linux kernel network drivers...

> > Still, it would be helpful to have some perl guru understanding the
> > code being able to describe it to a coder.
> 
> You've just described two persons.  Who's the sond one?  :-)

Haha.  But... sond?  I wasn't able to make out a word from that :}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
>> You've just described two persons.  Who's the sond one?  :-)
>
> Haha.  But... sond?  I wasn't able to make out a word from that :}

Second.  Somehow the two keypresses sisn't register.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Achim Gratz]

Achim Gratz writes:
> Corinna Vinschen writes:
>>> You've just described two persons.  Who's the sond one?  :-)
>>
>> Haha.  But... sond?  I wasn't able to make out a word from that :}
>
> Second.  Somehow the two keypresses sisn't register.

…didn't register.  Either this keyboard needs replacement or my fingers
are getting a lot wider than they used to be.  :-(


Regard,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: upset, genini: different version ordering

[Achim Gratz]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

Achim Gratz writes:
> I've just found that upset and genini will order versions differently.

Here's a patch for genini that will take care of the versions in a
better way than before, and it's extensible (in genini) and configurable
(from setup.hint) if you're into that kind of thing.  It's also largely
compatible to how upset treats things, to the extent that I understand
what upset is doing.  The code in genini should be able to be integrated
into upset to have both tools share their world-view, since I fixed some
things that bothered me about upset along the way (treatment of
pre-releases, mostly).  It'll need a bit more polishing, but keep the
comments coming.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: genini.cvs.diff --]
[-- Type: text/x-patch, Size: 6833 bytes --]

? genini.cvs.diff
Index: genini
===================================================================
RCS file: /cvs/cygwin-apps/genini/genini,v
retrieving revision 1.16
diff -u -p -r1.16 genini
--- genini	23 Jun 2015 17:50:00 -0000	1.16
+++ genini	18 Aug 2015 18:25:03 -0000
@@ -9,7 +9,7 @@ use File::Basename;
 use Digest::MD5;
 use Digest::SHA;
 use Getopt::Long;
-
+use version 0.77 qw( is_lax );
 use strict;
 
 sub mywarn(@);
@@ -23,6 +23,8 @@ my $arch = 'x86';
 my $digest = 'sha512';
 my $release;
 my @cmp_fmts = qw(xz bz2 lzma gz);
+my $cmp_fmts_grep = join('|', @cmp_fmts);
+my $cmp_fmts_glob = join(',', @cmp_fmts);
 
 GetOptions('okmissing=s'=>\@okmissing,
 	   'output=s'=>\$outfile,
@@ -33,6 +35,81 @@ GetOptions('okmissing=s'=>\@okmissing,
 	   'recursive'=>\$recursive) or usage;
 $help and usage;
 
+my %vercmp;
+%vercmp = (
+    naturally => sub { # mostly from Sort::Naturally
+	my @A = (parsever($a) =~ /([-.]|\d+|[^-.\d]+)/g);
+	my @B = (parsever($b) =~ /([-.]|\d+|[^-.\d]+)/g);
+	my ($A, $B);
+	my ($Adash, $Bdash, $Adot, $Bdot);
+	while (@A and @B) {
+	    $A = shift @A; $B = shift @B;
+	    ($Adash, $Bdash, $Adot, $Bdot) =
+		($A eq '-', $B eq '-', $A eq '.', $B eq '.');
+	    if ($Adash and $Bdash) {
+		next;
+	    } elsif ( $Adash ) {
+		return -1;
+	    } elsif ( $Bdash) {
+		return 1;
+	    } elsif ($Adot and $Bdot) {
+		next;
+	    } elsif ( $Adot ) {
+		return -1;
+	    } elsif ( $Bdot ) {
+		return 1;
+	    } elsif ($A =~ /\A\d+\Z/ and $B =~ /\A\d+\Z/) {
+		my $ab;
+		if ($A =~ /^0/ || $B =~ /^0/) {
+		    $ab = $A cmp $B;
+		} else {
+		    $ab = $A <=> $B;
+		}
+		return $ab if $ab;
+	    } else {
+		$A = uc $A;
+		$B = uc $B;
+		my $ab = $A cmp $B;
+		return $ab if $ab;
+	    }
+	}
+	# all components have compared equal so far, the array with
+	# the larger number of entries wins (at least one is empty)
+	my $ab = @A <=> @B;
+	# however, if it was a pre-release version of some sort, then
+	# it should order before the final
+	$A = ($ab > 0 ) ? shift @A : shift @B;
+	my $Adashdot = ( $A =~ m/-./ );
+	$A = ($ab > 0 ) ? shift @A : shift @B if $Adashdot;
+	my $Arc = ( $A =~ m/\A(pre|rc|alpha|beta|b\d+)/i );
+	return $Arc ? -$ab : $ab;
+    },
+    natural => sub {
+	my (undef, $av, $ar) = parsever($a);
+	my (undef, $bv, $br) = parsever($b);
+	map {
+	    # ISO date most likely
+	    s/g(?:it)?((?:19|20)[0-9]{2}(?:0[1-9]|1[012])(?:0[1-9]|[12][0-9]|3[01]))/\1/ig;
+	    # SHA1 not orderable
+	    s/g(?:it)?[0-9a-f]+/git/ig;
+	    s/[+~_]+/./g;
+	} ( \$av, \$bv );
+	return $vercmp{naturally}($av, $bv) ||
+	    $vercmp{naturally}($ar, $br);
+    },
+    perl => sub {
+	my (undef, $av, $ar) = parsever($a);
+	my (undef, $bv, $br) = parsever($b);
+	return (is_lax($av) && is_lax($bv)
+		? (version->parse($av) <=> version->parse($bv))
+		: $vercmp{natural}($av, $bv)) ||
+	    $vercmp{natural}($ar, $br);
+    },
+    lexical => sub {
+	$a cmp $b;
+    },
+    );
+
 @main::okmissing{@okmissing} = @okmissing;
 
 sub arch_handler (@) {
@@ -81,7 +158,8 @@ for my $p (sort keys %pkg) {
     print "\n@ $p\n";
     for my $key ('sdesc', 'ldesc', 'category', 'requires', 'message') {
 	my $val = $pkg{$p}{''}{$key};
-	if (!defined($val) && $pkg{$p}{''}{'install'} !~ /_obsolete/o) {
+	my $pobsolete = ( $pkg{$p}{''}{'install'} =~ m:/_obsolete/:o );
+	if (!defined($val) && !$pobsolete) {
 	    mywarn "package $p is missing a $key field"
 	      unless defined $main::okmissing{$key};
 	} else {
@@ -128,7 +206,7 @@ sub get {
 	    s/(\S)\s+$/$1/;
 	    $val .= "\n" . $_;
 	}
-    } 
+    }
     $val =~ s/(.)"(.)/$1'$2/mog;
     return $val;
 }
@@ -206,26 +284,30 @@ sub parsedir {
     return unless -e $setup_hint;
     parse("$setup_hint", $pname);
     next unless exists $pkg{$pname};
+    my $pobsolete = ( $d =~ m:/_obsolete/:o );
     my $explicit = 0;
     for my $what ('', "[prev]\n", "[test]\n") {
 	my $x = $pkg{$pname}{$what};
+	$x->{'obsolete'} = $pobsolete;
 	next unless $x->{'version'};
 	$explicit = 1;
 	addfiles($pname, $x, $d);
     }
-
     return if $explicit;
-    my $cmp_fmts_grep = join('|', @cmp_fmts);
-    my $cmp_fmts_glob = join(',', @cmp_fmts);
-    my @files = sort grep{!/-src\.tar\.($cmp_fmts_grep)/} glob("$d/*.tar.{$cmp_fmts_glob}");
+    $pkg{$pname}{''}{'version-order'} //= ($pname =~ m(\Aperl(?:[_-].+)?\Z)) ? "perl" : "natural";
+    my $vercmp = $vercmp{$pkg{$pname}{''}{'version-order'}} //
+	( myerror("unknown version ordering requested by package '$pname'"), $vercmp{'natural'} );
+    my @files = sort $vercmp grep{!/-src\.tar\.($cmp_fmts_grep)/} glob("$d/*.tar.{$cmp_fmts_glob}");
     if (!@files) {
-	myerror "not enough package files in $d";
+	@files = glob("$d/*-src.tar.{$cmp_fmts_glob}"); # source-only package?
+	myerror "not enough package files in $d" unless @files;
 	return;
     }
     for my $what ('', "[prev]\n") {
 	my $f = pop @files or last;
 	$pkg{$pname}{$what}{-unused} = 1;
 	my $x = $pkg{$pname}{$what};
+	$x->{'obsolete'} = $pobsolete;
 	my $p;
 	($p, $x->{'version'}) = getver($f);
 	addfiles($p, $x, $d);
@@ -244,14 +326,20 @@ sub addfiles {
 	$d = finddir($d, $pname) or return;
     }
 
-    my $source  = tarball($d, $pname, $x->{'version'}, 'src');
+    my $source = tarball($d, $pname, $x->{'version'}, 'src');
     filer($x, 'source', $source);
 }
 
 sub getver {
-    my $f = basename($_[0]);
-    my @a = ($f =~ /^(.*?)-(\d.*)\.tar/);
-    return wantarray ? @a : $a[1];
+    my $fn = basename shift;
+    my ($pn, $vr) = ($fn =~ m|\A(.*?)-(\d.*)\.tar\.($cmp_fmts_grep)\Z|);
+    return wantarray ? ($pn, $vr) : $vr;
+}
+
+sub parsever {
+    my ($pn, $vr) = getver(shift);
+    my ($v, $r) = ($vr =~ m|\A(\d.*?)-(\d.*)\Z|);
+    return wantarray ? ($pn, $v//$vr, $r//0) : $vr;
 }
 
 sub filer {
@@ -259,7 +347,8 @@ sub filer {
     my $what = shift;
     my $f = shift;
     open(*F, '<', $f) or do {
-	myerror "can't open $f - $!" unless $main::okmissing{$what};
+	myerror "can't open $f - $!"
+	    unless $main::okmissing{$what} or $x->{'obsolete'};
 	return undef;
     };
     my ( $chk, $sum );
@@ -280,15 +369,9 @@ sub filer {
 
 sub tarball {
     my $d = shift;
-    my $b = join('-', @_) . '.tar.';
-    for my $e (@cmp_fmts) {
-      my $f = "$d/" . "$b" . "$e";
-      if (-e "$f") {
-        return "$f";
-      }
-    }
-    # default to .nf (because we know it is missing)
-    return "$d/" . "$b" . "nf";
+    my $fg = "$d/" . join('-', @_) . ".tar.{$cmp_fmts_glob}";
+    my ($f, undef) = grep {-e} glob($fg);
+    return $f // $fg;
 }
 
 sub fnln {
@@ -306,7 +389,7 @@ sub myerror(@) {
 sub finddir {
     my $d = $_[0];
     my $pname = $_[1];
-    while (($d = dirname($d)) ne '.' && length($d)) {
+    while (($d = dirname($d)) && (length($d) > 1)) {
 	return "$d/$pname" if -d "$d/$pname";
     }
     myerror "couldn't find package directory for external-source '$pname'";

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Aug 18 20:34, Achim Gratz wrote:
> Achim Gratz writes:
> > I've just found that upset and genini will order versions differently.
> 
> Here's a patch for genini that will take care of the versions in a
> better way than before, and it's extensible (in genini) and configurable
> (from setup.hint) if you're into that kind of thing.  It's also largely
> compatible to how upset treats things, to the extent that I understand
> what upset is doing.  The code in genini should be able to be integrated
> into upset to have both tools share their world-view, since I fixed some
> things that bothered me about upset along the way (treatment of
> pre-releases, mostly).  It'll need a bit more polishing, but keep the
> comments coming.

Comments?  On perl code?  You're kidding...

You know, if you're willing to improve the long neglected genini, all
power to you.  I don't know how many people are actually using genini,
but I'm pretty sure every one of them welcomes an improvement.

So,  as soon as you're happy to upstream your code, and if nobody
complains about your changes within a reasonable timeframe, feel free
to apply your genini changes.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> Comments?  On perl code?  You're kidding...

Well, maybe not from you personally, to save you the exasperation. :-)

> You know, if you're willing to improve the long neglected genini, all
> power to you.  I don't know how many people are actually using genini,
> but I'm pretty sure every one of them welcomes an improvement.

Well, what is the alternative if you want to incorporate some extra
packages into a local install hierarchy?

> So,  as soon as you're happy to upstream your code, and if nobody
> complains about your changes within a reasonable timeframe, feel free
> to apply your genini changes.

OK…  then just one question: would it be possible to migrate genini (and
perhaps run, too) to Git?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Aug 18 22:06, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Comments?  On perl code?  You're kidding...
> 
> Well, maybe not from you personally, to save you the exasperation. :-)

Heh, yeah.

> > You know, if you're willing to improve the long neglected genini, all
> > power to you.  I don't know how many people are actually using genini,
> > but I'm pretty sure every one of them welcomes an improvement.
> 
> Well, what is the alternative if you want to incorporate some extra
> packages into a local install hierarchy?

I don't know.  I'm not using it :}

> > So,  as soon as you're happy to upstream your code, and if nobody
> > complains about your changes within a reasonable timeframe, feel free
> > to apply your genini changes.
> 
> OK…  then just one question: would it be possible to migrate genini (and
> perhaps run, too) to Git?

I need an overseer to create the final symlink to access the repo
as /git/..., but for a start, try

  git clone cygwin.com:/sourceware/projects/cygwin-apps-home/cygwin-genini.git
  git clone cygwin.com:/sourceware/projects/cygwin-apps-home/cygwin-run.git


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Jon TURNEY]

On 18/08/2015 19:34, Achim Gratz wrote:
>> I've just found that upset and genini will order versions differently.
>
> Here's a patch for genini that will take care of the versions in a
> better way than before, and it's extensible (in genini) and configurable
> (from setup.hint) if you're into that kind of thing.  It's also largely
> compatible to how upset treats things, to the extent that I understand
> what upset is doing.  The code in genini should be able to be integrated
> into upset to have both tools share their world-view, since I fixed some
> things that bothered me about upset along the way (treatment of
> pre-releases, mostly).  It'll need a bit more polishing, but keep the
> comments coming.

The idea that we need different way of sorting version strings for 
different packages seems really strange.

Does any other distro have something like this?  How do linux distros 
handle the special version number sorting requirements that perl 
apparently has?

Re: upset, genini: different version ordering

[Achim Gratz]

Jon TURNEY writes:
> The idea that we need different way of sorting version strings for
> different packages seems really strange.

To me the idea of using a sort finction that is known to produce wrong
results seemed more strange.

> Does any other distro have something like this?  How do linux distros
> handle the special version number sorting requirements that perl
> apparently has?

Honestly, I don't know.  Perl and Perl distributions had their
versioning scheme sorted out years ago when CPAN entered the scene and
it became apparent that things were a lot more complicated than a quick
look would easily reveal.

The only discernible effect (and the desired one) in any case is that
you have to less often explicitly state which version is corrent or
previous.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Aug 19 10:25, Corinna Vinschen wrote:
> On Aug 18 22:06, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > Comments?  On perl code?  You're kidding...
> > 
> > Well, maybe not from you personally, to save you the exasperation. :-)
> 
> Heh, yeah.
> 
> > > You know, if you're willing to improve the long neglected genini, all
> > > power to you.  I don't know how many people are actually using genini,
> > > but I'm pretty sure every one of them welcomes an improvement.
> > 
> > Well, what is the alternative if you want to incorporate some extra
> > packages into a local install hierarchy?
> 
> I don't know.  I'm not using it :}
> 
> > > So,  as soon as you're happy to upstream your code, and if nobody
> > > complains about your changes within a reasonable timeframe, feel free
> > > to apply your genini changes.
> > 
> > OK…  then just one question: would it be possible to migrate genini (and
> > perhaps run, too) to Git?
> 
> I need an overseer to create the final symlink to access the repo
> as /git/..., but for a start, try
> 
>   git clone cygwin.com:/sourceware/projects/cygwin-apps-home/cygwin-genini.git
>   git clone cygwin.com:/sourceware/projects/cygwin-apps-home/cygwin-run.git

Disregard the above, use these instead:

  git clone cygwin.com:/git/cygwin-genini.git
  git clone cygwin.com:/git/cygwin-run.git

as well as

  git clone cygwin.com:/git/cygwin-cygrunsrv.git


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> Disregard the above, use these instead:
>
>   git clone cygwin.com:/git/cygwin-genini.git
>   git clone cygwin.com:/git/cygwin-run.git

Thanks.  I'll try to get run up-to-date w.r.t. the released version over
the weekend.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Achim Gratz]

Achim Gratz writes:
> Corinna Vinschen writes:
>> Disregard the above, use these instead:
>>
>>   git clone cygwin.com:/git/cygwin-genini.git
>>   git clone cygwin.com:/git/cygwin-run.git
>
> Thanks.  I'll try to get run up-to-date w.r.t. the released version over
> the weekend.

Done.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> I need an overseer to create the final symlink to access the repo

The cgit web-page lists http:// URL for repos on sourceware, but you'll
generally end up with a 403 if you try to use them.  That's bad for
folks behind firewalls, so it would be nice if that could be fixed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Aug 22 12:51, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I need an overseer to create the final symlink to access the repo
> 
> The cgit web-page lists http:// URL for repos on sourceware, but you'll
> generally end up with a 403 if you try to use them.  That's bad for
> folks behind firewalls, so it would be nice if that could be fixed.

What cgit web page?  I only see perfectly valid https links on, e.g,

  https://sourceware.org/git/?p=cygwin-run.git;a=summary


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
> What cgit web page?  I only see perfectly valid https links on, e.g,
>
>   https://sourceware.org/git/?p=cygwin-run.git;a=summary

I'm talking about the URLs for cloning the repo on the top of that
page.  It lists a URL for HTTP access that doesn't actually work:

http://sourceware.org/git/cygwin-genini.git


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Aug 22 17:11, Achim Gratz wrote:
> Corinna Vinschen writes:
> > What cgit web page?  I only see perfectly valid https links on, e.g,
> >
> >   https://sourceware.org/git/?p=cygwin-run.git;a=summary
> 
> I'm talking about the URLs for cloning the repo on the top of that
> page.  It lists a URL for HTTP access that doesn't actually work:
> 
> http://sourceware.org/git/cygwin-genini.git

That's overseers territory.  Do you want to ask them or shall I?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Yaakov Selkowitz]

On Thu, 2015-08-20 at 12:37 +0100, Jon TURNEY wrote:
> The idea that we need different way of sorting version strings for 
> different packages seems really strange.
> 
> Does any other distro have something like this?  How do linux distros
> handle the special version number sorting requirements that perl 
> apparently has?

On Fedora, some Perl packages add extra dots to the package version so
that they sort as expected, e.g.:

0.23 => 0.23
0.2301 => 0.23.01
0.24 => 0.24
etc.

--
Yaakov

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Aug 24 06:25, Yaakov Selkowitz wrote:
> On Thu, 2015-08-20 at 12:37 +0100, Jon TURNEY wrote:
> > The idea that we need different way of sorting version strings for 
> > different packages seems really strange.
> > 
> > Does any other distro have something like this?  How do linux distros
> > handle the special version number sorting requirements that perl 
> > apparently has?
> 
> On Fedora, some Perl packages add extra dots to the package version so
> that they sort as expected, e.g.:
> 
> 0.23 => 0.23
> 0.2301 => 0.23.01
> 0.24 => 0.24
> etc.

So, shouldn't we do the same?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
>> On Fedora, some Perl packages add extra dots to the package version so
>> that they sort as expected, e.g.:
>> 
>> 0.23 => 0.23
>> 0.2301 => 0.23.01
>> 0.24 => 0.24
>> etc.
>
> So, shouldn't we do the same?

Please not, a dumb idea doesn't get smarter by repeating it's bad parts.

The only way I can keep my sanity with a few hundred of these packages
is if the package name and version number matches CPAN exactly.  That
allows me to script most of the grunt work of checking CPAN for updates
and keeping the cygport files up-to-date.

Again, versioning schemes differ, but as long as upstream sticks to one
scheme no manual interventions should be necessary.  But that requires
to support different schemes (at the moment, two of them) for different
packages.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Aug 24 09:27, Corinna Vinschen wrote:
> On Aug 22 17:11, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > What cgit web page?  I only see perfectly valid https links on, e.g,
> > >
> > >   https://sourceware.org/git/?p=cygwin-run.git;a=summary
> > 
> > I'm talking about the URLs for cloning the repo on the top of that
> > page.  It lists a URL for HTTP access that doesn't actually work:
> > 
> > http://sourceware.org/git/cygwin-genini.git
> 
> That's overseers territory.  Do you want to ask them or shall I?

Turned out this was my own fault.  I didn't activate the post-receive
hook in the cygwin-FOO.git repos, which is required to handle the http
dumb transport.  Duh.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Jon Turney]

On 20/07/2015 19:10, Jon TURNEY wrote:
> On 20/07/2015 19:03, Achim Gratz wrote:
>> I've just found that upset and genini will order versions differently.
>> For perl-Carp, genini produces:
[...]
> If I recall correctly, genini is just broken, doing some kind of lexical
> sort which e.g. sorts 1.10 before 1.9.
Something which seems to be missing from this discussion is how Cygwin 
version numbers are supposed to be sorted.

This needs to be simple, documented (and ideally, similar to other 
package managers), so that package maintainers can easily anticipate how 
their package versions are going to be ordered, but [1] seems silent on 
this subject, apart from describing it as 'intuitive'

Here's a list of existing package versions ordered by upset, which I 
think sort differently in setup:

x86:

makeself 2.1.5+20120813+gitdcbe778-1 < 2.1.5-3
tcl-itcl 3.4b1-1                     < 3.4.1-1
tidy     20090325-1                  < 041206-1
wput     0.6.2+git20130413-2         < 0.6.2-1

x86_64:

bzr      2.6.0+bzr6602-1 < 2.6.0-2 < 2.6b2-1
cgdb     0.6.7+20150214+git3a710f9-1 < 0.6.7-1

The result for tidy is particularly unexpected, and looking at the date 
of the package files, just wrong. (This appears to be due to upset 
truncating numeric parts to 4 digits!)

I don't really want to spend effort on unravelling the complexities of 
the sorting that upset does, since I don't think it's worth keeping, and 
we should switch to a scheme which can be described in a paragraph,
e.g. the scheme used by setup and RPM:

Compare contiguous chunks of digits or non-digits.
Non-digit chunks sort before digit chunks.
Digit chunks sort numerically, non-digit chunks sort lexicographically.
The version with a suffix remaining is the greater

[1] https://cygwin.com/setup.html

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

On Oct  9 14:24, Jon Turney wrote:
> On 20/07/2015 19:10, Jon TURNEY wrote:
> >On 20/07/2015 19:03, Achim Gratz wrote:
> >>I've just found that upset and genini will order versions differently.
> >>For perl-Carp, genini produces:
> [...]
> >If I recall correctly, genini is just broken, doing some kind of lexical
> >sort which e.g. sorts 1.10 before 1.9.
> Something which seems to be missing from this discussion is how Cygwin
> version numbers are supposed to be sorted.
> 
> This needs to be simple, documented (and ideally, similar to other package
> managers), so that package maintainers can easily anticipate how their
> package versions are going to be ordered, but [1] seems silent on this
> subject, apart from describing it as 'intuitive'
> 
> Here's a list of existing package versions ordered by upset, which I think
> sort differently in setup:
> 
> x86:
> 
> makeself 2.1.5+20120813+gitdcbe778-1 < 2.1.5-3
> tcl-itcl 3.4b1-1                     < 3.4.1-1
> tidy     20090325-1                  < 041206-1
> wput     0.6.2+git20130413-2         < 0.6.2-1
> 
> x86_64:
> 
> bzr      2.6.0+bzr6602-1 < 2.6.0-2 < 2.6b2-1
> cgdb     0.6.7+20150214+git3a710f9-1 < 0.6.7-1
> 
> The result for tidy is particularly unexpected, and looking at the date of
> the package files, just wrong. (This appears to be due to upset truncating
> numeric parts to 4 digits!)
> 
> I don't really want to spend effort on unravelling the complexities of the
> sorting that upset does, since I don't think it's worth keeping, and we
> should switch to a scheme which can be described in a paragraph,
> e.g. the scheme used by setup and RPM:
> 
> Compare contiguous chunks of digits or non-digits.
> Non-digit chunks sort before digit chunks.
> Digit chunks sort numerically, non-digit chunks sort lexicographically.
> The version with a suffix remaining is the greater

Sounds right to me.  If we can make the version handling equivalent to
RPM's, it would be really helpful, I think.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Corinna Vinschen writes:
>> I don't really want to spend effort on unravelling the complexities of the
>> sorting that upset does, since I don't think it's worth keeping, and we
>> should switch to a scheme which can be described in a paragraph,
>> e.g. the scheme used by setup and RPM:
>> 
>> Compare contiguous chunks of digits or non-digits.
>> Non-digit chunks sort before digit chunks.
>> Digit chunks sort numerically, non-digit chunks sort lexicographically.
>> The version with a suffix remaining is the greater
>
> Sounds right to me.  If we can make the version handling equivalent to
> RPM's, it would be really helpful, I think.

While that is by far the most widespread system thanks to GNU/Linux, it
is not the only one.  Emacs uses a very similar scheme, but treats

1.0alpha < 1.0beta < 1.0pre < 1.0 == 1.0.0 == 1.0.0.0

which sort of makes sense, but can't be handled by a simple
lexicographical sort.  You also have to be able to ignore non-sortable
components like Git commits.  All of this is already existing in Cygwin,
so unless you're proposing that these version numbers should all be
changed to conform to the one true version scheme (which will be painful
in other ways), then I still propose that we need to make the version
ordering switchable.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: upset, genini: different version ordering

[Yaakov Selkowitz]

On Mon, 2015-10-19 at 19:19 +0200, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> I don't really want to spend effort on unravelling the complexities of the
> >> sorting that upset does, since I don't think it's worth keeping, and we
> >> should switch to a scheme which can be described in a paragraph,
> >> e.g. the scheme used by setup and RPM:
> >> 
> >> Compare contiguous chunks of digits or non-digits.
> >> Non-digit chunks sort before digit chunks.
> >> Digit chunks sort numerically, non-digit chunks sort lexicographically.
> >> The version with a suffix remaining is the greater
> >
> > Sounds right to me.  If we can make the version handling equivalent to
> > RPM's, it would be really helpful, I think.
> 
> While that is by far the most widespread system thanks to GNU/Linux, it
> is not the only one.  Emacs uses a very similar scheme, but treats
> 
> 1.0alpha < 1.0beta < 1.0pre < 1.0 == 1.0.0 == 1.0.0.0
> 
> which sort of makes sense, but can't be handled by a simple
> lexicographical sort.  You also have to be able to ignore non-sortable
> components like Git commits.  All of this is already existing in Cygwin,
> so unless you're proposing that these version numbers should all be
> changed to conform to the one true version scheme (which will be painful
> in other ways), then I still propose that we need to make the version
> ordering switchable.

Switchable versioning schemes means that code has to be multiplied in
both setup and upset, which is just asking for problems.  There needs to
be one single versioning scheme, period, and using RPM's makes sense.

As for existing packages with nonconforming version numbers, yes, they
will need to be switched whenever they are next updated.  Adding an
"Epoch" equivalent (which is anyways needed for other cases) would solve
this.

--
Yaakov

Re: upset, genini: different version ordering

[Achim Gratz]

Yaakov Selkowitz writes:
> Switchable versioning schemes means that code has to be multiplied in
> both setup and upset, which is just asking for problems.  There needs to
> be one single versioning scheme, period, and using RPM's makes sense.

You do know that RPM specifically has an emergency exit in the form of
"serials", do you?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Oct 19 20:13, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> > Switchable versioning schemes means that code has to be multiplied in
> > both setup and upset, which is just asking for problems.  There needs to
> > be one single versioning scheme, period, and using RPM's makes sense.
> 
> You do know that RPM specifically has an emergency exit in the form of
> "serials", do you?

I don't.  Brief description?  What about epoche handling as Yaakov
suggested, does that help?  Jon, as our local upset guru, how tricky
would it be to add epoches to upset?

Or, in other words, how complicated would it be to have the same
RPM version handling in setup and upset both?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Jon Turney]

On 20/10/2015 11:27, Corinna Vinschen wrote:
> On Oct 19 20:13, Achim Gratz wrote:
>> Yaakov Selkowitz writes:
>>> Switchable versioning schemes means that code has to be multiplied in
>>> both setup and upset, which is just asking for problems.  There needs to
>>> be one single versioning scheme, period, and using RPM's makes sense.
>>
>> You do know that RPM specifically has an emergency exit in the form of
>> "serials", do you?
>
> I don't.  Brief description?

This is a reference to the RPM "Serial:" tag

This seems to be pretty obscure, but [1] says "Like the Epoch:, the 
Serial: directive should be a number that counts upward. Modern packages 
should use the Epoch: directive instead of Serial:, since Serial: has 
been deprecated for many, many rpm versions. "

> What about epoch handling as Yaakov
> suggested, does that help?  Jon, as our local upset guru, how tricky
> would it be to add epoches to upset?
>
> Or, in other words, how complicated would it be to have the same
> RPM version handling in setup and upset both?

I've done the first step, which is to change upset to use the same 
ordering as setup (which uses an RPM-like ordering)

Patch not attached due to upset license uncertainties, but you can find 
it at 
/sourceware1/cygwin-staging/setup/0001-upset-Change-version-sorting.patch on 
sourceware.

[2] is the list of packages whose ordering would change if this was 
used.  On further study, it appears that upset is ordering all of these 
but tcl-itcl in the opposite order to the chronological (and presumably 
intended) order.

Adding epoch parsing would be additional work.  I'm not sure how much 
value that would have since (a) we are effectively limited to 2 package 
versions, and (b) we can force a given ordering using setup.hint

[1] 
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
[2] https://cygwin.com/ml/cygwin-apps/2015-10/msg00003.html

Re: upset, genini: different version ordering

[Jon Turney]

On 19/10/2015 18:19, Achim Gratz wrote:
> Corinna Vinschen writes:
>>> I don't really want to spend effort on unravelling the complexities of the
>>> sorting that upset does, since I don't think it's worth keeping, and we
>>> should switch to a scheme which can be described in a paragraph,
>>> e.g. the scheme used by setup and RPM:
>>>
>>> Compare contiguous chunks of digits or non-digits.
>>> Non-digit chunks sort before digit chunks.
>>> Digit chunks sort numerically, non-digit chunks sort lexicographically.
>>> The version with a suffix remaining is the greater
>>
>> Sounds right to me.  If we can make the version handling equivalent to
>> RPM's, it would be really helpful, I think.
>
> While that is by far the most widespread system thanks to GNU/Linux, it
> is not the only one.  Emacs uses a very similar scheme, but treats
>
> 1.0alpha < 1.0beta < 1.0pre < 1.0 == 1.0.0 == 1.0.0.0

I think in upset sorting 1.0 < 1.0.0

> which sort of makes sense, but can't be handled by a simple
> lexicographical sort.  You also have to be able to ignore non-sortable
> components like Git commits.

These have to be preceded by a unique, sortable component (e.g. date) or 
you just can't get anywhere.  A scheme where 1.0.0-gitAAAAAAAA == 
1.0.0-gitBBBBBBBB isn't any use.

 >  All of this is already existing in Cygwin,

It exists in upset, but not in way that anyone can rely on working the 
way they think it's going to, since the implementation is bewildering 
and undocumented.

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

On Oct 20 14:33, Jon Turney wrote:
> On 20/10/2015 11:27, Corinna Vinschen wrote:
> >On Oct 19 20:13, Achim Gratz wrote:
> >>Yaakov Selkowitz writes:
> >>>Switchable versioning schemes means that code has to be multiplied in
> >>>both setup and upset, which is just asking for problems.  There needs to
> >>>be one single versioning scheme, period, and using RPM's makes sense.
> >>
> >>You do know that RPM specifically has an emergency exit in the form of
> >>"serials", do you?
> >
> >I don't.  Brief description?
> 
> This is a reference to the RPM "Serial:" tag
> 
> This seems to be pretty obscure, but [1] says "Like the Epoch:, the Serial:
> directive should be a number that counts upward. Modern packages should use
> the Epoch: directive instead of Serial:, since Serial: has been deprecated
> for many, many rpm versions. "

Ok, so the match epoch-serial ends 1:0.

> >What about epoch handling as Yaakov
> >suggested, does that help?  Jon, as our local upset guru, how tricky
> >would it be to add epoches to upset?
> >
> >Or, in other words, how complicated would it be to have the same
> >RPM version handling in setup and upset both?
> 
> I've done the first step, which is to change upset to use the same ordering
> as setup (which uses an RPM-like ordering)
> 
> Patch not attached due to upset license uncertainties, but you can find it
> at /sourceware1/cygwin-staging/setup/0001-upset-Change-version-sorting.patch
> on sourceware.

You could sell me the moon if the contract is written in perl, so I'm
going to trust you here :)

> [2] is the list of packages whose ordering would change if this was used.
> On further study, it appears that upset is ordering all of these but
> tcl-itcl in the opposite order to the chronological (and presumably
> intended) order.

Just 6 packages.  This is a very overseeable list.  We might be able to
get away with simple manual changes to setup.hint or find out that the
reordering actually fixes things.  No reason not to go forward.

> Adding epoch parsing would be additional work.  I'm not sure how much value
> that would have since (a) we are effectively limited to 2 package versions,
> and (b) we can force a given ordering using setup.hint

Yaakov thinks we need epoch.  Yaakov, could you briefly outline why we
should need it?  Do we have real-world examples in the distro where we
could need it?  I guess Achim's perl packages are particulary nice
examples?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Yaakov Selkowitz]

On Tue, 2015-10-20 at 17:50 +0200, Corinna Vinschen wrote:
> > Adding epoch parsing would be additional work.  I'm not sure how much value
> > that would have since (a) we are effectively limited to 2 package versions,
> > and (b) we can force a given ordering using setup.hint
> 
> Yaakov thinks we need epoch.  Yaakov, could you briefly outline why we
> should need it?  Do we have real-world examples in the distro where we
> could need it?  I guess Achim's perl packages are particulary nice
> examples?

First, let's remember that this isn't just about upset getting prev: and
curr: right, but also about setup knowing when to upgrade by default.
Therefore, simply tweaking setup.hint files is insufficient.

Besides sorting out our current discrepancies, here is a perfect example
of a use for epoch:

https://cygwin.com/ml/cygwin-announce/2015-07/msg00015.html
https://cygwin.com/ml/cygwin-announce/2015-07/msg00050.html

In short, xdelta was updated from 1.x to 3.x, then it was realized that
both were needed, and so xdelta was reverted to 1.x and xdelta3 was
created.  Instead of saying "oh btw you need to revert xdelta to 1.x
yourself" (which is all we could do currently), the solution would be to
bump epoch on xdelta-1.x, which would force it to be considered newer
than the short-lived xdelta-3.x by both upset and setup.

As for implementation, the idea would be to use a special character in
the version number of tarballs as so (pseudocode):

    char epoch[N] = {}, *sep;
    if ((sep = strchr(version, SEPARATOR))) {
      strncpy(epoch, version, sep - version);
      version = sep + 1;
    } else
      epoch[0] = "0";

Then compare epochs first, then version and release to determine which
is newer.  As for the separator, in RPM it is ':' but as we will need to
have this character in the tarball name and Windows doesn't allow that
in filenames, we will need to pick something else.

On the cygport side, this would be triggered by defining EPOCH in
the .cygport file, *not* by using this character in VERSION.

--
Yaakov

Re: upset, genini: different version ordering

[Achim Gratz]

Jon Turney writes:
>>  All of this is already existing in Cygwin,
>
> It exists in upset, but not in way that anyone can rely on working the
> way they think it's going to, since the implementation is bewildering
> and undocumented.

I was talking about the sort of version numbering schemes that are in
use (or have been used in the past two or three years) in Cygwin.  We
can always placate upset by telling it how to order things in
setup.hint if that sort of thing happens.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: upset, genini: different version ordering

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

On Oct 20 12:03, Yaakov Selkowitz wrote:
> On Tue, 2015-10-20 at 17:50 +0200, Corinna Vinschen wrote:
> > > Adding epoch parsing would be additional work.  I'm not sure how much value
> > > that would have since (a) we are effectively limited to 2 package versions,
> > > and (b) we can force a given ordering using setup.hint
> > 
> > Yaakov thinks we need epoch.  Yaakov, could you briefly outline why we
> > should need it?  Do we have real-world examples in the distro where we
> > could need it?  I guess Achim's perl packages are particulary nice
> > examples?
> 
> First, let's remember that this isn't just about upset getting prev: and
> curr: right, but also about setup knowing when to upgrade by default.
> Therefore, simply tweaking setup.hint files is insufficient.
> 
> Besides sorting out our current discrepancies, here is a perfect example
> of a use for epoch:
> 
> https://cygwin.com/ml/cygwin-announce/2015-07/msg00015.html
> https://cygwin.com/ml/cygwin-announce/2015-07/msg00050.html
> 
> In short, xdelta was updated from 1.x to 3.x, then it was realized that
> both were needed, and so xdelta was reverted to 1.x and xdelta3 was
> created.  Instead of saying "oh btw you need to revert xdelta to 1.x
> yourself" (which is all we could do currently), the solution would be to
> bump epoch on xdelta-1.x, which would force it to be considered newer
> than the short-lived xdelta-3.x by both upset and setup.
> 
> As for implementation, the idea would be to use a special character in
> the version number of tarballs as so (pseudocode):
> 
>     char epoch[N] = {}, *sep;
>     if ((sep = strchr(version, SEPARATOR))) {
>       strncpy(epoch, version, sep - version);
>       version = sep + 1;
>     } else
>       epoch[0] = "0";
> 
> Then compare epochs first, then version and release to determine which
> is newer.  As for the separator, in RPM it is ':' but as we will need to
> have this character in the tarball name and Windows doesn't allow that
> in filenames, we will need to pick something else.

SEPARATOR=@

?

> On the cygport side, this would be triggered by defining EPOCH in
> the .cygport file, *not* by using this character in VERSION.

And adding an extra test for the epoch doesn't seem overly tricky
in setup.  Upset, well, Jon?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: upset, genini: different version ordering

[Achim Gratz]

Yaakov Selkowitz writes:
> In short, xdelta was updated from 1.x to 3.x, then it was realized that
> both were needed, and so xdelta was reverted to 1.x and xdelta3 was
> created.  Instead of saying "oh btw you need to revert xdelta to 1.x
> yourself" (which is all we could do currently), the solution would be to
> bump epoch on xdelta-1.x, which would force it to be considered newer
> than the short-lived xdelta-3.x by both upset and setup.

Once you've used an epoch-extended version you'd be forced to always use
it, however.  I think this is creating more problems than it solves and
I don't see why any of you would like the idea.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: upset, genini: different version ordering

[Yaakov Selkowitz]

On Tue, 2015-10-20 at 21:53 +0200, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> > In short, xdelta was updated from 1.x to 3.x, then it was realized that
> > both were needed, and so xdelta was reverted to 1.x and xdelta3 was
> > created.  Instead of saying "oh btw you need to revert xdelta to 1.x
> > yourself" (which is all we could do currently), the solution would be to
> > bump epoch on xdelta-1.x, which would force it to be considered newer
> > than the short-lived xdelta-3.x by both upset and setup.
> 
> Once you've used an epoch-extended version you'd be forced to always use
> it, however.

Correct, just like with RPM.

> I think this is creating more problems than it solves

Such as?

> and I don't see why any of you would like the idea.

Because it is a well-established solution for the same issue on other
platforms.

--
Yaakov

Re: upset, genini: different version ordering

[Achim Gratz]

Yaakov Selkowitz writes:
>> and I don't see why any of you would like the idea.
>
> Because it is a well-established solution for the same issue on other
> platforms.

I have never seen this used (I don't claim it isn't used somewhere, mind
you) and I still can't think of a good reason for why anybody should.

And "other platforms", including those that use plain rpm, seem to be
using fine-grained versioned dependencies in the concrete scenario
you've outlined.  I did look at zypper about a year ago, but
unfortunately the dependencies on other libraries were quite extensive,
so I didn't go forward.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: upset, genini: different version ordering

[Yaakov Selkowitz]

On Wed, 2015-10-21 at 18:45 +0200, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> >> and I don't see why any of you would like the idea.
> >
> > Because it is a well-established solution for the same issue on other
> > platforms.
> 
> I have never seen this used (I don't claim it isn't used somewhere, mind
> you) and I still can't think of a good reason for why anybody should.

https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs

> And "other platforms", including those that use plain rpm, seem to be
> using fine-grained versioned dependencies in the concrete scenario
> you've outlined.

That's not related to this issue.

--
Yaakov

Re: upset, genini: different version ordering

[Jon Turney]

On 20/10/2015 14:33, Jon Turney wrote:
> On 20/10/2015 11:27, Corinna Vinschen wrote:
>> What about epoch handling as Yaakov
>> suggested, does that help?  Jon, as our local upset guru, how tricky
>> would it be to add epoches to upset?
>>
>> Or, in other words, how complicated would it be to have the same
>> RPM version handling in setup and upset both?
>
> I've done the first step, which is to change upset to use the same
> ordering as setup (which uses an RPM-like ordering)
>
> Patch not attached due to upset license uncertainties, but you can find
> it at
> /sourceware1/cygwin-staging/setup/0001-upset-Change-version-sorting.patch on
> sourceware.
>
> [2] is the list of packages whose ordering would change if this was
> used.  On further study, it appears that upset is ordering all of these
> but tcl-itcl in the opposite order to the chronological (and presumably
> intended) order.

I've applied this patch to upset on sourceware.

As a consequence, the curr version for the following packages has 
changed (to what seems to be the intended, most recent version):

x86:

makeself 2.1.5+20120813+gitdcbe778-1
tidy     20090325-1
wput     0.6.2+git20130413-2

x86_64:

bzr      2.6.0+bzr6602-1 (enforced via setup.hint)
cgdb     0.6.7+20150214+git3a710f9-1

(additionally I added a setup.hint for x86 tcl-itcl to keep 3.4.1-1 as 
the current version)

> [2] https://cygwin.com/ml/cygwin-apps/2015-10/msg00003.html