[ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

[ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)

[Ken Brown via Cygwin-announce]

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

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

[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

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

[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 <cygwin@cygwin.com> 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

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

[Denis Excoffier]

> On 2021-09-17 22:33, Ken Brown via Cygwin-announce <cygwin-announce@cygwin.com> 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.

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

[Ken Brown]

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

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

[Ken Brown]

On 9/18/2021 4:01 PM, Denis Excoffier wrote:
>> On 2021-09-17 22:33, Ken Brown via Cygwin-announce <cygwin-announce@cygwin.com> 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

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

[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 
>>> <cygwin-announce@cygwin.com> 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
>

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

[Ken Brown]

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

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

[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.

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

[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

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

[Ken Brown]

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

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

[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
>

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

[Ken Brown]

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