Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)
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] xwin-xdg-menu-20210918-1
The following packages have been updated in the Cygwin distribution: * xwin-xdg-menu xwin-xdg-menu is an XDG Desktop Menu Specification [1] menu for the X Window System running in the Cygwin environment. xwin-xdg-menu reads the menu specification and desktop entries, and constructs a menu which is accessed from a notification area icon. [1] http://standards.freedesktop.org/menu-spec/menu-spec-latest.html The changes since 20170623-2 are: * Fix leaking ignore SIGPIPE into child processes (Thanks to Takashi Yano for the patch). Addresses: https://cygwin.com/pipermail/cygwin/2019-August/242060.html -- 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] Updated: less-581.2-1
On 2021-05-02 04:04, Marco Atzeri wrote: New version 581.2-1 of less is available in the Cygwin distribution Running less +F (follow ) or less +G then F or less then F does not seem to work (since at least v 530) on logs updated every second or so or longer, showing only the last line(s) when started, unlike tail -f or xtail: Compare: $ for ((i = 1; i < 1000; ++i)); do echo $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i sleep 1 done > t & less +F t [wait] ^C G q $ kill %1 to: $ for ((i = 1; i < 1000; ++i)); do echo $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i sleep 1 done > t & tail -f t ... ^C $ kill %1 or: $ for ((i = 1; i < 1000; ++i)); do echo $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i $i sleep 1 done > t & xtail t ... ^C *** recently changed files *** 1 2021-09-18 11:47:50 t currently watching: 1 files 0 dirs 0 unknown entries Exit (y/N)? y $ kill %1 -- 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.] -- 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)
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
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: x86/x86_64 -- perl-Proc-ProcessTable-0.620-1 perl-Scalar-List-Utils-1.59-1 noarch -- perl-Test-Simple-1.302187-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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)
> 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)
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)
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)
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)
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
autorebase and user-installed dynamic objects
Achim, In preparation for using emacs's new native compilation feature, I've been experimenting with using autorebase to rebase the *.eln files created in a user's home directory. As a start, I created a file /var/lib/rebase/user.d/kbrown containing the line /home/kbrown/.emacs.d/eln-cache . I also modified /usr/bin/rebaseall and /usr/bin/rebaselst so that they would recognize 'eln' as a suffix of a file needing to be rebased. I then ran setup and let it do its autorebase, but the *.eln files didn't get rebased. Looking into /usr/bin/rebaselst, I think I see the problem. The function rebase_user() greps the file /var/lib/rebase/user.d/kbrown for the relevant suffixes, instead of looking for files in /home/kbrown/.emacs.d/eln-cache. Shouldn't rebase_user use a variable "userLocs" analogous to the variable "dynLocs" used by rebase_dyn()? Or am I completely misunderstanding how this is supposed to work? Thanks. 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)
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
[ANNOUNCEMENT] Updated: qrencode 4.1.1-3
The following packages have been updated: * qrencode-4.1.1-3 * libqrencode-devel-4.1.1-3 * libqrencode4-4.1.1-3 * qrencode-4.1.1-3-src * qrencode-debuginfo-4.1.1-3 Note: This update fixes a bug in the upstream. Fix the issue #188 in the upstream: https://github.com/fukuchi/libqrencode/issues/188 The patch comes from a comment https://github.com/fukuchi/libqrencode/issues/188#issuecomment-912814481 -- QR Code symbol library Libqrencode is a C library for encoding data in a QR Code symbol, a kind of 2D symbology that can be scanned by handy terminals such as a mobile phone with CCD. The capacity of QR Code is up to 7000 digits or 4000 characters, and is highly robust. HomePage: https://fukuchi.org/works/qrencode/index.html.en News: https://github.com/fukuchi/libqrencode/blob/v4.1.1/NEWS Source: https://github.com/fukuchi/libqrencode/tree/v4.1.1 License: LGPL-2.1 License https://github.com/fukuchi/libqrencode/blob/v4.1.1/COPYING Cygwin Package Summary: https://www.cygwin.com/packages/summary/qrencode-src.html Cygport Source: https://cygwin.com/git/?p=git/cygwin-packages/qrencode.git -- Lemures Lemniscati -- 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
[ANNOUNCEMENT] Updated: libuninameslist-20210917-1
The following packages have been updated: - libuninameslist-devel-20210917-1 - libuninameslist1-20210917-1 This is an update to the latest upstream. Note: Additionally, libuninameslist-devel-20091231-2, and libuninameslist0-20091231-2 have been updated with rearranged packaging: docs are moved from libuninameslist0 to libuninameslist-devel in that version, for avoiding confliction. Libuninameslist provides a Library of Unicode names and annotation data. This release contains NamesList.txt 14.0 released Sept14, 2021, and ListeDesNoms 13.0 (plus improvements). See release notes for more details. https://github.com/fontforge/libuninameslist/releases/tag/20210917 Note: This Cygwin release contains libuninameslist with a large (sparse) array mapping each unicode code point to the annotation data for it provided in http://www.unicode.org/Public/UNIDATA/NamesList.txt , and libuninameslist-fr as a French version. But, Python wrapper uninameslist.py (ver0.2) is NOT included. -- Lemures Lemniscati -- 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: autorebase and user-installed dynamic objects
Ken Brown via Cygwin writes: > Looking into /usr/bin/rebaselst, I think I see the problem. The > function rebase_user() greps the file /var/lib/rebase/user.d/kbrown > for the relevant suffixes, That's how it was originally intended to work, IIRC (but the documentation indeed wrongly suggests to put paths there). Obviously since we didn't have that situation before I never fully tested and completed this part. > instead of looking for files in > /home/kbrown/.emacs.d/eln-cache. Shouldn't rebase_user use a variable > "userLocs" analogous to the variable "dynLocs" used by rebase_dyn()? > Or am I completely misunderstanding how this is supposed to work? For reasons I don't exactly remember, I wanted to avoid that. Probably because the user directory might not be available or accessible for the install user, but then obviously you'd just as likely have a problem with the actual rebasing also. I've been mulling the idea of having user specific rebase databases on top of the system one (or more generally a hierarchy of rebase DB) several times and that's one of the reasons they might be needed. Let's discuss how this can and should work on cygwin-apps. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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)
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
[ANNOUNCEMENT] Updated: libjpeg-turbo 2.1.1p3-1
The following packages have been uploaded to the Cygwin distribution: * jpeg-2.1.1p3-1 * libjpeg-devel-2.1.1p3-1 * libjpeg8-2.1.1p3-1 * libturbojpeg-devel-2.1.1p3-1 * libturbojpeg0-2.1.1p3-1 * libjpeg-turbo-2.1.1p3-1-src * libjpeg-turbo-debuginfo-2.1.1p3-1 This is an update to the latest upstream, which is 3 commits after 2.1.1 and contains bug fixes. -- libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as the unmodified version of libjpeg, all else being equal. HomePage: https://libjpeg-turbo.org/ News: https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.1.1 Source: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/2.1.1 License: The IJG (Independent JPEG Group) License The Modified (3-clause) BSD License The zlib License https://github.com/libjpeg-turbo/libjpeg-turbo/blob/2.1.1/LICENSE.md Cygwin Package Summary: https://www.cygwin.com/packages/summary/libjpeg-turbo-src.html Cygport Source: https://cygwin.com/git/?p=git/cygwin-packages/libjpeg-turbo.git -- Lemures Lemniscati -- 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
