subtle problem with x86_64 automake1.4

subtle problem with x86_64 automake1.4

[Christopher Faylor]

Chuck,
upset's version normalizer considers (not unreasonably I think)
4-1.4p6-11 to be the same as 4-1.4-p6-11.  So, having both files in the
same directory is going to confuse things.

I've added a kludge to the version sorter that upset uses which causes
-p6 to sort before p6 but, please don't create packages with different
patch number versioning schemes like this.

This manifested as a neverending setup.ini creation.  Every time there
was a new run of upset, a new version of setup.ini would be created
because the a "new" automake1.4 package was constantly being detected.
That meant that mirrors could never catch up and the result is that we
have almost no mirrors available currently.

cgf

Re: subtle problem with x86_64 automake1.4

[Yaakov (Cygwin/X)]

On 2013-09-10 12:50, Christopher Faylor wrote:
> upset's version normalizer considers (not unreasonably I think)
> 4-1.4p6-11 to be the same as 4-1.4-p6-11.  So, having both files in the
> same directory is going to confuse things.

This would be partially my fault.  I NMU'd 1.4-p6-11 as part of the 
x86_64 bootstrap, with they hyphen per the upstream tarball versioning, 
not realizing the x86 package was versioned 1.4p6 (without the hyphen), 
and bumped the release number due to the addition of Fedora's patchset. 
  When Chuck got around to redoing his packages, his last x86 release 
was 10, so he bumped his to 11, probably not realizing that it needed to 
be 12 because of my x86_64-only bump.

> I've added a kludge to the version sorter that upset uses which causes
> -p6 to sort before p6 but, please don't create packages with different
> patch number versioning schemes like this.

I removed my bootstrap packages in favour of Chuck's to be safe.


Yaakov

Re: subtle problem with x86_64 automake1.4

[Christopher Faylor]

On Tue, Sep 10, 2013 at 01:40:00PM -0500, Yaakov (Cygwin/X) wrote:
>On 2013-09-10 12:50, Christopher Faylor wrote:
>> upset's version normalizer considers (not unreasonably I think)
>> 4-1.4p6-11 to be the same as 4-1.4-p6-11.  So, having both files in the
>> same directory is going to confuse things.
>
>This would be partially my fault.  I NMU'd 1.4-p6-11 as part of the 
>x86_64 bootstrap, with they hyphen per the upstream tarball versioning, 
>not realizing the x86 package was versioned 1.4p6 (without the hyphen), 
>and bumped the release number due to the addition of Fedora's patchset. 
>  When Chuck got around to redoing his packages, his last x86 release 
>was 10, so he bumped his to 11, probably not realizing that it needed to 
>be 12 because of my x86_64-only bump.
>
>> I've added a kludge to the version sorter that upset uses which causes
>> -p6 to sort before p6 but, please don't create packages with different
>> patch number versioning schemes like this.
>
>I removed my bootstrap packages in favour of Chuck's to be safe.

Argh.  This introduces YA round of mirror churn.  I specifically didn't
do this because I was trying to get the mirrors stabilized.

cgf

Re: subtle problem with x86_64 automake1.4

[Charles Wilson]

On 9/10/2013 1:50 PM, Christopher Faylor wrote:

> upset's version normalizer considers (not unreasonably I think)
> 4-1.4p6-11 to be the same as 4-1.4-p6-11.  So, having both files in the
> same directory is going to confuse things.

Yaakov explained downthread how this came about. I /did/ notice that the 
Release numbers (11) were the same between my "new" version and Yaakov's 
bootstrap version, but figured that since the Version numbers differed 
in format that upset would handle it (I may have even specifically added 
prev: and curr: entries to the setup.hint to disambiguate priority, in 
case upset sorted differently than I wanted; but I'm not sure about that).

> I've added a kludge to the version sorter that upset uses which causes
> -p6 to sort before p6 but, please don't create packages with different
> patch number versioning schemes like this.

Sorry for the confusion; it's just one of those bootstrap/NMU things 
we'll slowly work thru as the "real" maintainers catch up to all of 
Yaakov's wonderful work with the 64bit bootstrapping.

> This manifested as a neverending setup.ini creation.  Every time there
> was a new run of upset, a new version of setup.ini would be created
> because the a "new" automake1.4 package was constantly being detected.
> That meant that mirrors could never catch up and the result is that we
> have almost no mirrors available currently.

Yikes. That's...bad. :-(

Sorry I didn't catch this thread earlier; I've been really sick this week.

--
Chuck

Re: subtle problem with x86_64 automake1.4

[Christopher Faylor]

On Fri, Sep 13, 2013 at 08:56:40AM -0400, Charles Wilson wrote:
>On 9/10/2013 1:50 PM, Christopher Faylor wrote:
>>upset's version normalizer considers (not unreasonably I think)
>>4-1.4p6-11 to be the same as 4-1.4-p6-11.  So, having both files in the
>>same directory is going to confuse things.
>
>Yaakov explained downthread how this came about.  I /did/ notice that
>the Release numbers (11) were the same between my "new" version and
>Yaakov's bootstrap version, but figured that since the Version numbers
>differed in format that upset would handle it (I may have even
>specifically added prev: and curr: entries to the setup.hint to
>disambiguate priority, in case upset sorted differently than I wanted;
>but I'm not sure about that).

You did do that but upset doesn't care about dashes in version numbers
that much.

>>I've added a kludge to the version sorter that upset uses which causes
>>-p6 to sort before p6 but, please don't create packages with different
>>patch number versioning schemes like this.
>
>Sorry for the confusion; it's just one of those bootstrap/NMU things
>we'll slowly work thru as the "real" maintainers catch up to all of
>Yaakov's wonderful work with the 64bit bootstrapping.
>
>>This manifested as a neverending setup.ini creation.  Every time there
>>was a new run of upset, a new version of setup.ini would be created
>>because the a "new" automake1.4 package was constantly being detected.
>>That meant that mirrors could never catch up and the result is that we
>>have almost no mirrors available currently.
>
>Yikes.  That's...bad.  :-(
>
>Sorry I didn't catch this thread earlier; I've been really sick this
>week.

Hey, me too!  101.something fever.  I'm just starting to feel normal.

cgf