Revert coreutils 9.1 to test 8.32 to curr stable

Revert coreutils 9.1 to test 8.32 to curr stable

[Brian Inglis]

Verified below issue with coreutils 9.1 promoted last night to stable!
Problem does not occur in 8.32, so can we please revert coreutils 9.1 to 
test and restore 8.32 to stable.
Or is there some process by which I can do so?


On 2022-05-24 10:33, Jim Reisert AD1C wrote:
>> The following test package has been uploaded to the Cygwin distribution:
>>
>> * coreutils     9.1
> 
> I am having a problem with "cp" that is not present in the previous
> (non-test) version.  I'm running the latest Cygwin on Windows 10:
> 
>      CYGWIN_NT-10.0-19044 8PZCBK3 3.3.5-341.x86_64 2022-05-13 12:27 UTC
> x86_64 Cygwin
> 
> 
> The "cp" commands are in a Makefile.  These are all text (not binary)
> files.  "here" is a directory.
> 
> if [ -a 2022/QSN2205.EXC ]; then cp -pvf 2022/QSN2205.EXC here; fi
> if [ -a 2022/QSN2205.TXT ]; then cp -pvf 2022/QSN2205.TXT here; fi
> if [ -a 2022/ignore.csv  ]; then cp -pvf 2022/ignore.csv  here; fi
> 
> 
> These are the target files that are being copied *to*:
> 
> -rw-rw----+ 1 jr920141 Domain Users    11022 May 23 08:01 here/ignore.csv
> -rw-rw----+ 1 jr920141 Domain Users   303543 May 23 10:25 here/QSN2205.EXC
> -rw-rw----+ 1 jr920141 Domain Users 14395440 May 23 08:00 here/QSN2205.TXT
> 
> 
> These are the source files that are being copied *from*:
> 
> -rw-rw----+ 1 jr920141 Domain Users    11303 May 24 08:20 ignore.csv
> -rw-rw----+ 1 jr920141 Domain Users    20944 May 24 10:17 QSN2205.EXC
> -rw-rw----+ 1 jr920141 Domain Users 14941120 May 24 08:19 QSN2205.TXT
> 
> 
> It just so happens that the files are (now) the same.  I had already done
> the copy and no longer have the old files that were in the "here"
> directory.  But it doesn't matter whether the files are the same or
> different.  The problem still occurs.
> 
> This is the result:
> 
> [8PZCBK3:~/DXspots] $ make here
> 
> '2022/QSN2205.EXC' -> 'here/QSN2205.EXC'
> '2022/QSN2205.TXT' -> 'here/QSN2205.TXT'
> cp: cannot create regular file 'here/QSN2205.TXT': File exists
> 
> 
> It makes no sense to me that the .EXC file was copied overtop of the
> existing file, file but the .TXT file was not.  The TXT file has DOS line
> endings.  The EXC file does not.  I don't see why that would/should make a
> difference.
> 
> cygcheck.out is attached.
> 
> 


-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Revert coreutils 9.1 to test 8.32 to curr stable

[Brian Inglis]

Uploading
x86{,_64}/release/coreutils{,/coreutils-debuginfo}/{override.hint,!ready}
with override.hint contents "replace-versions: 9.1-1"
seems to have done the trick.

Is there some convention for announcing the reversion?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]


On 2022-06-06 17:33, Brian Inglis wrote:
> Verified below issue with coreutils 9.1 promoted last night to stable!
> Problem does not occur in 8.32, so can we please revert coreutils 9.1 to 
> test and restore 8.32 to stable.
> Or is there some process by which I can do so? 


> On 2022-05-24 10:33, Jim Reisert AD1C wrote:
>>> The following test package has been uploaded to the Cygwin distribution:
>>>
>>> * coreutils     9.1
>>
>> I am having a problem with "cp" that is not present in the previous
>> (non-test) version.  I'm running the latest Cygwin on Windows 10:
>>
>>      CYGWIN_NT-10.0-19044 8PZCBK3 3.3.5-341.x86_64 2022-05-13 12:27 UTC
>> x86_64 Cygwin
>>
>>
>> The "cp" commands are in a Makefile.  These are all text (not binary)
>> files.  "here" is a directory.
>>
>> if [ -a 2022/QSN2205.EXC ]; then cp -pvf 2022/QSN2205.EXC here; fi
>> if [ -a 2022/QSN2205.TXT ]; then cp -pvf 2022/QSN2205.TXT here; fi
>> if [ -a 2022/ignore.csv  ]; then cp -pvf 2022/ignore.csv  here; fi
>>
>>
>> These are the target files that are being copied *to*:
>>
>> -rw-rw----+ 1 jr920141 Domain Users    11022 May 23 08:01 here/ignore.csv
>> -rw-rw----+ 1 jr920141 Domain Users   303543 May 23 10:25 
>> here/QSN2205.EXC
>> -rw-rw----+ 1 jr920141 Domain Users 14395440 May 23 08:00 
>> here/QSN2205.TXT
>>
>>
>> These are the source files that are being copied *from*:
>>
>> -rw-rw----+ 1 jr920141 Domain Users    11303 May 24 08:20 ignore.csv
>> -rw-rw----+ 1 jr920141 Domain Users    20944 May 24 10:17 QSN2205.EXC
>> -rw-rw----+ 1 jr920141 Domain Users 14941120 May 24 08:19 QSN2205.TXT
>>
>>
>> It just so happens that the files are (now) the same.  I had already done
>> the copy and no longer have the old files that were in the "here"
>> directory.  But it doesn't matter whether the files are the same or
>> different.  The problem still occurs.
>>
>> This is the result:
>>
>> [8PZCBK3:~/DXspots] $ make here
>>
>> '2022/QSN2205.EXC' -> 'here/QSN2205.EXC'
>> '2022/QSN2205.TXT' -> 'here/QSN2205.TXT'
>> cp: cannot create regular file 'here/QSN2205.TXT': File exists
>>
>>
>> It makes no sense to me that the .EXC file was copied overtop of the
>> existing file, file but the .TXT file was not.  The TXT file has DOS line
>> endings.  The EXC file does not.  I don't see why that would/should 
>> make a
>> difference.
>>
>> cygcheck.out is attached.

Re: Revert coreutils 9.1 to test 8.32 to curr stable

[Jon Turney]

On 07/06/2022 00:33, Brian Inglis wrote:
> Verified below issue with coreutils 9.1 promoted last night to stable!
> Problem does not occur in 8.32, so can we please revert coreutils 9.1 to 
> test and restore 8.32 to stable.
> Or is there some process by which I can do so?

You seem to have figured this out, but FTR:
* Remove [1] or re-upload [2] the package with test: added to hints
* Upload an override.hint with replace-versions: [3]

Note that due to the way the depsolver works, replace-versions: doesn't 
do anything if the package would still be chosen to install.

(calm tries to warn about that, but it seems you've tripped over a bug 
where it doesn't take test: into consideration and warns when it shouldn't)

[1] https://cygwin.com/package-upload.html#deleting
[2] Re-uploading a package with the same (or missing!) archives, but 
modified hints is currently allowed for historical reasons
[3] https://cygwin.com/packaging-hint-files.html#override.hint

Re: Revert coreutils 9.1 to test 8.32 to curr stable

[Brian Inglis]

On 2022-06-07 03:39, Jon Turney wrote:
> On 07/06/2022 00:33, Brian Inglis wrote:
>> Verified below issue with coreutils 9.1 promoted last night to stable!
>> Problem does not occur in 8.32, so can we please revert coreutils 9.1 
>> to test and restore 8.32 to stable.
>> Or is there some process by which I can do so?
> 
> You seem to have figured this out, but FTR:
> * Remove [1] or re-upload [2] the package with test: added to hints
> * Upload an override.hint with replace-versions: [3]
> 
> Note that due to the way the depsolver works, replace-versions: doesn't 
> do anything if the package would still be chosen to install.
> 
> (calm tries to warn about that, but it seems you've tripped over a bug 
> where it doesn't take test: into consideration and warns when it shouldn't)
> 
> [1] https://cygwin.com/package-upload.html#deleting
> [2] Re-uploading a package with the same (or missing!) archives, but 
> modified hints is currently allowed for historical reasons
> [3] https://cygwin.com/packaging-hint-files.html#override.hint

Thanks Jon, fo looking into this, but package-test rebuild and upload 
[2] resulted in ERROR and discards:

ERROR: discarding, different /sourceware/cygwin-staging/home/Brian 
Inglis/x86/release/coreutils/coreutils-9.1-1-src.tar.xz is already in 
release area (perhaps you should rebuild with a different 
version-release identifier?)
INFO: discarding, identical /sourceware/cygwin-staging/home/Brian 
Inglis/x86/release/coreutils/coreutils-9.1-1.tar.xz is already in 
release area
INFO: discarding, identical /sourceware/cygwin-staging/home/Brian 
Inglis/x86/release/coreutils/coreutils-debuginfo/coreutils-debuginfo-9.1-1.tar.xz 
is already in release area
ERROR: error while reading uploaded arch x86 packages from maintainer 
Brian Inglis
SUMMARY: 2 ERROR(s), 2 INFO(s)

and same for other arch.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Revert coreutils 9.1 to test 8.32 to curr stable

[Jon Turney]

On 07/06/2022 17:48, Brian Inglis wrote:
> On 2022-06-07 03:39, Jon Turney wrote:
>> On 07/06/2022 00:33, Brian Inglis wrote:
>>> Verified below issue with coreutils 9.1 promoted last night to stable!
>>> Problem does not occur in 8.32, so can we please revert coreutils 9.1 
>>> to test and restore 8.32 to stable.
>>> Or is there some process by which I can do so?
>>
>> You seem to have figured this out, but FTR:
>> * Remove [1] or re-upload [2] the package with test: added to hints
>> * Upload an override.hint with replace-versions: [3]
>>
>> Note that due to the way the depsolver works, replace-versions: 
>> doesn't do anything if the package would still be chosen to install.
>>
>> (calm tries to warn about that, but it seems you've tripped over a bug 
>> where it doesn't take test: into consideration and warns when it 
>> shouldn't)
>>
>> [1] https://cygwin.com/package-upload.html#deleting
>> [2] Re-uploading a package with the same (or missing!) archives, but 
>> modified hints is currently allowed for historical reasons
>> [3] https://cygwin.com/packaging-hint-files.html#override.hint
> 
> Thanks Jon, for looking into this, but package-test rebuild and upload 
> [2] resulted in ERROR and discards:

I didn't say rebuild, I just said re-upload.

I don't expect the package build is reproducible (not least because the 
file timestamps inside the package archive will be different)

You can't upload package archives with the same name but different 
contents, because that would be a really bad idea.

You are only allowed to change .hint files (although this is still 
somewhat a bad idea).

> ERROR: discarding, different /sourceware/cygwin-staging/home/Brian 
> Inglis/x86/release/coreutils/coreutils-9.1-1-src.tar.xz is already in 
> release area (perhaps you should rebuild with a different 
> version-release identifier?)
> INFO: discarding, identical /sourceware/cygwin-staging/home/Brian 
> Inglis/x86/release/coreutils/coreutils-9.1-1.tar.xz is already in 
> release area
> INFO: discarding, identical /sourceware/cygwin-staging/home/Brian 
> Inglis/x86/release/coreutils/coreutils-debuginfo/coreutils-debuginfo-9.1-1.tar.xz 
> is already in release area
> ERROR: error while reading uploaded arch x86 packages from maintainer 
> Brian Inglis
> SUMMARY: 2 ERROR(s), 2 INFO(s)
> 
> and same for other arch.