RE: coreutils refresh request (again)

RE: coreutils refresh request (again)

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> https://cygwin.com/pipermail/cygwin/2020-June/245104.html

Wow dude!  I did not expect a whole sob story out of that simple reminder;
I did not urge anybody to do it right away, yet I just mentioned that the package
was way out of its release cycle.  I think that the time it took you to write
all that response was pretty much comparable to the time required to package
the new coreutils:

$ ./configure
...
$ time make
...
real    6m33.420s
user    4m10.671s
sys     1m53.034s

(and it builds just out of the box, FYI)

Re: coreutils refresh request (again)

[Marco Atzeri]

On 10.06.2020 18:21, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> https://cygwin.com/pipermail/cygwin/2020-June/245104.html
> 
> Wow dude!  I did not expect a whole sob story out of that simple reminder;
> I did not urge anybody to do it right away, yet I just mentioned that the package
> was way out of its release cycle.  I think that the time it took you to write
> all that response was pretty much comparable to the time required to package
> the new coreutils:
> 
> $ ./configure
> ...
> $ time make
> ...
> real    6m33.420s
> user    4m10.671s
> sys     1m53.034s
> 
> (and it builds just out of the box, FYI)
> 

but it is missing the patch used to adapt it to Cygwin.
The patch modifies 27 files and unfortunately does not applies
clean to latest upstream source.


The are at lest 3 points that need rewriting

Re: coreutils refresh request (again)

[Brian Inglis]

On 2020-06-10 10:21, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> https://cygwin.com/pipermail/cygwin/2020-June/245104.html
> 
> Wow dude!  I did not expect a whole sob story out of that simple reminder;
> I did not urge anybody to do it right away, yet I just mentioned that the package
> was way out of its release cycle.  I think that the time it took you to write
> all that response was pretty much comparable to the time required to package
> the new coreutils:

That's an explanation and some possibilities for why there may be delays for a
lot of packages in the near future.
If you download the source package, update the .cygport file to the latest
upstream version, and you can:

	$ cygport pkg.cygport download all tests

and you feel confident, you can install with:

	$ tar -xf pkg-ver-?.x86{_64}/dist/pkg/pkg-ver-?.tar.xz -C /

-- 
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 IEC units and prefixes, physical quantities in SI.]

RE: coreutils refresh request (again)

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> but it is missing the patch used to adapt it to Cygwin.
> The patch modifies 27 files and unfortunately does not applies
> clean to latest upstream source.

Fair enough (and again, there was no pushing);  but are you sure that all 27 patches are still actual?

Testsuite ran pretty well, though.  I looked as some failures (not all), and they looked rather benign.

============================================================================
Testsuite summary for GNU coreutils 8.32
============================================================================
# TOTAL: 621
# PASS:  413
# SKIP:  167
# XFAIL: 0
# FAIL:  33
# XPASS: 0
# ERROR: 8

> The are at lest 3 points that need rewriting

Okay;  maybe those should be reported upstream, as Cygwin is largely standard-compliant these days?

Re: coreutils refresh request (again)

[Marco Atzeri]

On 10.06.2020 20:24, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> but it is missing the patch used to adapt it to Cygwin.
>> The patch modifies 27 files and unfortunately does not applies
>> clean to latest upstream source.
> 
> Fair enough (and again, there was no pushing);  but are you sure that all 27 patches are still actual?
> 
> Testsuite ran pretty well, though.  I looked as some failures (not all), and they looked rather benign.
> 
> ============================================================================
> Testsuite summary for GNU coreutils 8.32
> ============================================================================
> # TOTAL: 621
> # PASS:  413
> # SKIP:  167
> # XFAIL: 0
> # FAIL:  33
> # XPASS: 0
> # ERROR: 8
> 
>> The are at lest 3 points that need rewriting
> 
> Okay;  maybe those should be reported upstream, as Cygwin is largely standard-compliant these days?
> 

the testsuite is not relevant for these changes.

Coreutils are tweaked to manage "program" and "program.exe" as they
are the same thing and other similar things.
Some changes were propagated upstream and some not; I looked at the
first patch rejected, and upstream have reversed the logic of a test
that the patch was modifying to add one of these cases, so modifying the
source is not banal and need some consideration and test.

Both requires time that someone need to put for it.

Regards
Marco

coreutils refresh request (again)

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Hi All,

Having upgraded my Cygwin install today, I still see the old coreutils package v8.26, from 2016.
Looks like the current version is now 8.32, released in March this year.  Can Cygwin please get this updated?

Thanks,
Anton

Re: coreutils refresh request (again)

[Brian Inglis]

On 2020-05-31 08:52, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Having upgraded my Cygwin install today, I still see the old coreutils
> package v8.26, from 2016.
> Looks like the current version is now 8.32, released in March this year.
> Can Cygwin please get this updated?

Upgrades, especially of a multi-program package, are not always easy, with many
features added each release, and often bugs, sometimes Cygwin specific.
The volunteer maintainers may have to negotiate with upstream maintainers about
whether they can get bug fixes made upstream, or bug fixes or feature support by
other Cygwin library or package volunteer maintainers, or their upstream
maintainers.

All of these people are busy with work and life: many volunteer, and some also
work, on multiple projects; some may have been or are now sick (hopefully few to
none), or have conditions or illnesses which make them unable to contribute
temporarily.

Some core volunteers on this project also have jobs at RedHat (which supports
the infrastructure) and was bought by IBM, who is once again betting the company
on a new direction, so some volunteers may now have limited or no time for other
projects.
One such volunteer maintainer of over 2500/25% of Cygwin packages has had to
give them all up due to having no time to spare now.

Add to that the current pandemic issues, particularly badly handled in some
major Western countries, and perhaps users could be somewhat patient and
understanding of the situations of volunteer maintainers, who may now be working
remotely, likely overtime to support volumes of issues or scaling.

Developers who are corporate (or personal) users could think of contributing to
the project by maintaining packages they use and are interested in (2500+ are up
for grabs), spreading the load, or get some of their corporate IT development
staff to help them and their organization out by doing upgrades to packages they
need or use, and contributing those upgrades to the project.

The Cygwin cygport package build infrastructure is an extensive and professional
job and takes care of a lot of the upgrade mechanics, but build failures need
thought and work to diagnose and generate a fix, submit patches upstream, decide
whether to wait for an upstream patch to land, or release sooner with a Cygwin
patch, bearing in mind that Cygwin is only a minor volunteer blip in the
otherwise fairly well funded software distribution ecosystem.

-- 
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 IEC units and prefixes, physical quantities in SI.]