Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-19 Thread Ken Brown via Cygwin

On 9/19/2021 9:32 AM, Thomas Wolff wrote:

Am 19.09.2021 um 14:27 schrieb Ken Brown via Cygwin:
On the other hand, maybe we could do a better job of documenting how to 
rebuild a package from source via cygport.


And via git clone, please, because that's the way developers start if they want 
to contribute to cygwin.
I still claim it's a bad idea to hide that script in a subdirectory; it should 
at least reside in the top-level directory, so if someone sees a script 
"auto..." there, it will be an attempt to proceed with.


The reason it's in the winsup directory is that the change has only been done 
for Cygwin so far, not for newlib.  But maybe there could be a README.Cygwin in 
the top-level directory that calls attention to it, or an autogen_cygwin.sh script.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-19 Thread Thomas Wolff



Am 19.09.2021 um 14:27 schrieb Ken Brown via Cygwin:

On 9/19/2021 2:42 AM, ASSI wrote:

I'm pretty sure the GNU coding standards have required
it since day 1.  Automake generates tons of makefile real estate just
for this.


I don't see that requirement in the current document:

https://www.gnu.org/prep/standards/standards.html

There is a requirement that the sources for such files are provided
alongside the instruction on how to re-generate them.


I'm not sure how much we should worry about the GNU standards for 
release tarballs.  Those standards are written for GNU projects, which 
are supposed to run on many different systems.  The cygwin package 
runs only on Cygwin.


On the other hand, maybe we could do a better job of documenting how 
to rebuild a package from source via cygport.
And via git clone, please, because that's the way developers start if 
they want to contribute to cygwin.
I still claim it's a bad idea to hide that script in a subdirectory; it 
should at least reside in the top-level directory, so if someone sees a 
script "auto..." there, it will be an attempt to proceed with.




Ken




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-19 Thread Ken Brown via Cygwin

On 9/19/2021 2:42 AM, ASSI wrote:

I'm pretty sure the GNU coding standards have required
it since day 1.  Automake generates tons of makefile real estate just
for this.


I don't see that requirement in the current document:

https://www.gnu.org/prep/standards/standards.html

There is a requirement that the sources for such files are provided
alongside the instruction on how to re-generate them.


I'm not sure how much we should worry about the GNU standards for release 
tarballs.  Those standards are written for GNU projects, which are supposed to 
run on many different systems.  The cygwin package runs only on Cygwin.


On the other hand, maybe we could do a better job of documenting how to rebuild 
a package from source via cygport.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread ASSI
Hans-Bernhard Bröker writes:
> It _is_ very surprising for tarballs, though.  Those are generally
> expected  to be buildable without having to run autoconf, automake, 
> gettext, etc.

To provide a different data point: I generally remove all obviously
generated files before even starting to look at the rest of the build if
I use a release tarball.

> I'm pretty sure the GNU coding standards have required
> it since day 1.  Automake generates tons of makefile real estate just
> for this.

I don't see that requirement in the current document:

https://www.gnu.org/prep/standards/standards.html

There is a requirement that the sources for such files are provided
alongside the instruction on how to re-generate them.


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

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Hans-Bernhard Bröker

Am 19.09.2021 um 00:32 schrieb Ken Brown via Cygwin:

Finally, I'd like to mention that it's extremely common for 
autotools-based packages to have an autogen script like Cygwin's 
(sometimes called bootstrap or bootstrap.sh).  There's nothing 
surprising about this.


It's unsurprising to have that state of things in git checkouts.

It _is_ very surprising for tarballs, though.  Those are generally 
expected  to be buildable without having to run autoconf, automake, 
gettext, etc.  I'm pretty sure the GNU coding standards have required it 
since day 1.  Automake generates tons of makefile real estate just for 
this.


Generally speaking, removing the generated files (configure, aclocal.m4, 
Makefile.in, etc.) from git, while laudable, comes at the cost of three 
extra pieces of effort:


1) Unless a simple "autoreconf -is" is sufficient to do the job, a 
script like autogen.sh has to be prepared and put into the git


2) To the greatest extent feasible, maintainer rules have to be made to 
actually work to auto-update those generated files without the hassle of 
having to re-run autogen.sh


3) Preparing a release tarball is no longer quite as simple as just 
zipping up an other wise unchanged, fresh checkout (without the .git). 
That checkout will differ from a proper tarball in both directions: 
there will be files that should be in the tarball, but not in the 
checked-out copy, and there will be files in the check-out that should 
not got into the tarball.  autogen.sh itself, and the special README 
telling people about it, are among the latter.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Ken Brown via Cygwin

On 9/18/2021 5:30 PM, Thomas Wolff wrote:

Am 18.09.2021 um 22:20 schrieb Ken Brown via Cygwin:

On 9/18/2021 4:01 PM, Denis Excoffier wrote:
It seems to me that the files Makefile.in, aclocal.m4, configure (and the 
like) are missing from the folder (and sub-folders of) newlib-cygwin/winsup
found within the 
cygwin-3.3.0-0.1.9814cfd8f693.src/newlib-cygwin-3.3.0.tar.bz2 file stored in 
cygwin-3.3.0-0.1.9814cfd8f693-src.tar.xz.


The build now uses automake, and the missing files you refer to are all 
generated.  Start by running winsup/autogen.sh.
This is a very bad idea (as I had commented before). There are too many build 
system around already and now there's even a proprietary script to run as a 
first step for cygwin. If there's anything useful that this script accomplishes, 
why can't it just be invoked automatically from the makefile or configure script 
so everything works as expected? It's a gross violation of the principle of 
least surprise.


The standard way of building a Cygwin package from source is to download the 
source using Cygwin's setup program and then run cygport.  That will work in 
this case too.  (The cygport script runs autogen.sh.)  If you choose instead to 
try to build from the source tarball without even looking at the cygport file, 
you get what you paid for.


In the case of the Cygwin package, there is an alternative: You can follow the 
instructions at


  https://cygwin.com/faq.html#faq.programming.building-cygwin

for building Cygwin from source.  This explicitly mentions running autogen.sh. 
This only has to be done once, after first cloning Cygwin's git repo.  After 
that, everything is updated as needed by the Makefile.  Prior to running 
autogen.sh, there's no Makefile and no configure script.  So I guess autogen.sh 
accomplishes something useful.


Finally, I'd like to mention that it's extremely common for autotools-based 
packages to have an autogen script like Cygwin's (sometimes called bootstrap or 
bootstrap.sh).  There's nothing surprising about this.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Thomas Wolff



Am 18.09.2021 um 22:20 schrieb Ken Brown via Cygwin:

On 9/18/2021 4:01 PM, Denis Excoffier wrote:
On 2021-09-17 22:33, Ken Brown via Cygwin-announce 
 wrote:


The following packages have been uploaded to the Cygwin distribution 
as test

releases:

* cygwin-3.3.0-0.1.9814cfd8f693
* cygwin-devel-3.3.0-0.1.9814cfd8f693
* cygwin-doc-3.3.0-0.1.9814cfd8f693



Hello,

It seems to me that the files Makefile.in, aclocal.m4, configure (and 
the like) are missing from the folder (and sub-folders of) 
newlib-cygwin/winsup
found within the 
cygwin-3.3.0-0.1.9814cfd8f693.src/newlib-cygwin-3.3.0.tar.bz2 file 
stored in cygwin-3.3.0-0.1.9814cfd8f693-src.tar.xz.


The build now uses automake, and the missing files you refer to are 
all generated.  Start by running winsup/autogen.sh.
This is a very bad idea (as I had commented before). There are too many 
build system around already and now there's even a proprietary script to 
run as a first step for cygwin. If there's anything useful that this 
script accomplishes, why can't it just be invoked automatically from the 
makefile or configure script so everything works as expected? It's a 
gross violation of the principle of least surprise.


Ken




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Ken Brown via Cygwin

On 9/18/2021 4:01 PM, Denis Excoffier wrote:

On 2021-09-17 22:33, Ken Brown via Cygwin-announce  
wrote:

The following packages have been uploaded to the Cygwin distribution as test
releases:

* cygwin-3.3.0-0.1.9814cfd8f693
* cygwin-devel-3.3.0-0.1.9814cfd8f693
* cygwin-doc-3.3.0-0.1.9814cfd8f693



Hello,

It seems to me that the files Makefile.in, aclocal.m4, configure (and the like) 
are missing from the folder (and sub-folders of) newlib-cygwin/winsup
found within the cygwin-3.3.0-0.1.9814cfd8f693.src/newlib-cygwin-3.3.0.tar.bz2 
file stored in cygwin-3.3.0-0.1.9814cfd8f693-src.tar.xz.


The build now uses automake, and the missing files you refer to are all 
generated.  Start by running winsup/autogen.sh.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Ken Brown via Cygwin

On 9/18/2021 3:03 PM, Chris Roehrig wrote:


I'm not sure how to try out a test release without risking destabilizing my 
system, but I re-cloned and rebuilt the master branch and installed just the 
cygwin1.dll and all looks good to me so far.   No issues with any of my script 
pipes or fifos and I am getting full gigabit speeds with rsync.

I too have been following all the pipe rework on Cygwin-developers and want to 
express my appreciation for Takashi, Ken and Corinna for tackling this.You 
folks have made Cygwin so much more usable for a lot of applications!


Thanks for the feedback.  Just FYI, I don't think you've increased the stability 
of your system by just installing cygwin1.dll rather than the test cygwin 
package.  Here's a list of the files contained in the latter:


$ cygcheck -l cygwin
/etc/defaults/etc/cygserver.conf
/usr/bin/chattr.exe
/usr/bin/cygcheck.exe
/usr/bin/cygpath.exe
/usr/bin/cygserver-config
/usr/bin/cygwin-console-helper.exe
/usr/bin/cygwin1.dll
/usr/bin/dumper.exe
/usr/bin/gencat.exe
/usr/bin/getconf.exe
/usr/bin/getfacl.exe
/usr/bin/gmondump.exe
/usr/bin/kill.exe
/usr/bin/ldd.exe
/usr/bin/ldh.exe
/usr/bin/locale.exe
/usr/bin/lsattr.exe
/usr/bin/minidumper.exe
/usr/bin/mkgroup.exe
/usr/bin/mkpasswd.exe
/usr/bin/mount.exe
/usr/bin/passwd.exe
/usr/bin/pldd.exe
/usr/bin/profiler.exe
/usr/bin/ps.exe
/usr/bin/regtool.exe
/usr/bin/setfacl.exe
/usr/bin/setmetamode.exe
/usr/bin/ssp.exe
/usr/bin/strace.exe
/usr/bin/tzset.exe
/usr/bin/umount.exe
/usr/sbin/cygserver.exe
/usr/share/cygwin/cygwin.ldif
/usr/share/doc/Cygwin/COPYING
/usr/share/doc/Cygwin/cygserver.README
/usr/share/doc/Cygwin/CYGWIN_LICENSE

Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Denis Excoffier


> On 2021-09-17 22:33, Ken Brown via Cygwin-announce 
>  wrote:
> 
> The following packages have been uploaded to the Cygwin distribution as test 
> releases:
> 
> * cygwin-3.3.0-0.1.9814cfd8f693
> * cygwin-devel-3.3.0-0.1.9814cfd8f693
> * cygwin-doc-3.3.0-0.1.9814cfd8f693
> 

Hello,

It seems to me that the files Makefile.in, aclocal.m4, configure (and the like) 
are missing from the folder (and sub-folders of) newlib-cygwin/winsup
found within the cygwin-3.3.0-0.1.9814cfd8f693.src/newlib-cygwin-3.3.0.tar.bz2 
file stored in cygwin-3.3.0-0.1.9814cfd8f693-src.tar.xz.

I’m unable to build this release from sources.

Regards,

Denis Excoffier.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Chris Roehrig


I'm not sure how to try out a test release without risking destabilizing my 
system, but I re-cloned and rebuilt the master branch and installed just the 
cygwin1.dll and all looks good to me so far.   No issues with any of my script 
pipes or fifos and I am getting full gigabit speeds with rsync.  

I too have been following all the pipe rework on Cygwin-developers and want to 
express my appreciation for Takashi, Ken and Corinna for tackling this.You 
folks have made Cygwin so much more usable for a lot of applications!

-- Chris


On Fri Sep 17 2021, at 1:33 PM, Ken Brown via Cygwin-announce via Cygwin 
 wrote:

> The following packages have been uploaded to the Cygwin distribution as test 
> releases:
> 
> * cygwin-3.3.0-0.1.9814cfd8f693
> * cygwin-devel-3.3.0-0.1.9814cfd8f693
> * cygwin-doc-3.3.0-0.1.9814cfd8f693
> 
> This release comes with an overhaul of the internal pipe code.  In theory, 
> there should be no user-visible changes except for bug fixes and performance 
> improvements.  But of course there will be new bugs.  Please test!
> 
> ===
> 
> What's new:
> ---
> 
> - An IP-sampling profiler named 'profiler' has been added.  It can be
>  used to profile any Cygwin program along with any DLLs loaded.
> 
> - A new tool 'gmondump' has been added.  It can dump the raw
>  information of any "gmon.out" file created by profiler, ssp, or use
>  of the gcc/g++ option '-pg'.  (Continue using gprof to get symbolic
>  profile displays.)
> 
> - New GNU-specific APIs, slated to become part of the next POSIX
>  standard:  pthread_cond_clockwait, pthread_mutex_clocklock,
>  pthread_rwlock_clockrdlock, pthread_rwlock_clockwrlock,
>  sem_clockwait.
> 
> - New Solaris-specific APIs, slated to become part of the next POSIX
>  standard:  sig2str, str2sig.
> 
> 
> What changed:
> -
> 
> - The speed argument to cfsetspeed(3) can now be a numerical baud rate
>  rather than a Bnnn constant, as on Linux.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248887.html
> 
> - The internal implementation of pipes has been overhauled; this
>  should result in improved performance.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-August/249238.html
> 
> 
> Bug Fixes
> -
> 
> - Fix values returned by select(2) for shutdown sockets.
>  Addresses: 
> https://cygwin.com/pipermail/cygwin-developers/2021-April/012092.html
> 
> - Introduce a new hypotl(3) function not suffering unnecessary
>  overflows.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-April/248302.html
> 
> - Fix path handling for paths spanning native symlinks.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-April/248307.html
> 
> - Fix tab position evaluation after console window resize.
> 
> - Fix a regression in pseudo console handling, resulting in rlwrap not
>  being able to start a new pseudo console.
> 
> - Handle two race conditions in pseudo console usage.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-April/248292.html
> 
> - Fix a bug in recognizing a successful completion of connect(2) on a
>  datagram socket.
> 
> - Fix connect(2) when called with an address structure whose family is
>  AF_UNSPEC.  As specified by POSIX and Linux, this is allowed on
>  datagram sockets, and its effect is to reset the socket's peer
>  address.
> 
> - Fix nanosleep(2) returning negative rem. NtQueryTimer appears to be
>  able to return a negative remaining time (less than the timer
>  resolution) for unsignalled timers.
> 
> - Fix getifaddrs(3) returning address family 0 or IPv4 address 0.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248970.html
> 
> - Fix getaddrinfo(3) to return valid ai_socktype and ai_protocol
>  values if the underlying GetAddrInfoW screws up.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248985.html
> 
> - Fix duplicate /proc/partitions entries and (presumably) duplicate
>  PIDs in ps(1) output.
>  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248998.html
> https://cygwin.com/pipermail/cygwin/2021-August/249124.html
> 
> ===
> 
> 
> Have fun,
> 
> Ken Brown, on behalf of Corinna
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-18 Thread Achim Gratz
Ken Brown via Cygwin-announce via Cygwin writes:
> - The internal implementation of pipes has been overhauled; this
>   should result in improved performance.
>   Addresses: https://cygwin.com/pipermail/cygwin/2021-August/249238.html

That works great, thanks!  I can finally use the full 1 GiB/s of the LAN
connection between the Cygwin machine and my Linux box via SSH.  There
is also a notable speed improvement for SSH tunneled X11 applications
that seems to indicate the latency is reduced as well.


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

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

2021-09-17 Thread Ken Brown via Cygwin-announce via Cygwin
The following packages have been uploaded to the Cygwin distribution as test 
releases:


* cygwin-3.3.0-0.1.9814cfd8f693
* cygwin-devel-3.3.0-0.1.9814cfd8f693
* cygwin-doc-3.3.0-0.1.9814cfd8f693

This release comes with an overhaul of the internal pipe code.  In theory, there 
should be no user-visible changes except for bug fixes and performance 
improvements.  But of course there will be new bugs.  Please test!


===

What's new:
---

- An IP-sampling profiler named 'profiler' has been added.  It can be
  used to profile any Cygwin program along with any DLLs loaded.

- A new tool 'gmondump' has been added.  It can dump the raw
  information of any "gmon.out" file created by profiler, ssp, or use
  of the gcc/g++ option '-pg'.  (Continue using gprof to get symbolic
  profile displays.)

- New GNU-specific APIs, slated to become part of the next POSIX
  standard:  pthread_cond_clockwait, pthread_mutex_clocklock,
  pthread_rwlock_clockrdlock, pthread_rwlock_clockwrlock,
  sem_clockwait.

- New Solaris-specific APIs, slated to become part of the next POSIX
  standard:  sig2str, str2sig.


What changed:
-

- The speed argument to cfsetspeed(3) can now be a numerical baud rate
  rather than a Bnnn constant, as on Linux.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248887.html

- The internal implementation of pipes has been overhauled; this
  should result in improved performance.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-August/249238.html


Bug Fixes
-

- Fix values returned by select(2) for shutdown sockets.
  Addresses: 
https://cygwin.com/pipermail/cygwin-developers/2021-April/012092.html

- Introduce a new hypotl(3) function not suffering unnecessary
  overflows.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-April/248302.html

- Fix path handling for paths spanning native symlinks.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-April/248307.html

- Fix tab position evaluation after console window resize.

- Fix a regression in pseudo console handling, resulting in rlwrap not
  being able to start a new pseudo console.

- Handle two race conditions in pseudo console usage.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-April/248292.html

- Fix a bug in recognizing a successful completion of connect(2) on a
  datagram socket.

- Fix connect(2) when called with an address structure whose family is
  AF_UNSPEC.  As specified by POSIX and Linux, this is allowed on
  datagram sockets, and its effect is to reset the socket's peer
  address.

- Fix nanosleep(2) returning negative rem. NtQueryTimer appears to be
  able to return a negative remaining time (less than the timer
  resolution) for unsignalled timers.

- Fix getifaddrs(3) returning address family 0 or IPv4 address 0.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248970.html

- Fix getaddrinfo(3) to return valid ai_socktype and ai_protocol
  values if the underlying GetAddrInfoW screws up.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248985.html

- Fix duplicate /proc/partitions entries and (presumably) duplicate
  PIDs in ps(1) output.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248998.html
 https://cygwin.com/pipermail/cygwin/2021-August/249124.html

===


Have fun,

Ken Brown, on behalf of Corinna

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple