Re: MinTTY requires gdiplus.dll ?
On 2018-12-01 04:18, Brian Inglis wrote: On 2018-11-30 01:33, Houder wrote: [snip] Now I know, there should be an "GdiPlus.dll" in "system32". Alas, I have no idea how to recover it (and neither does Microsoft). Thanks for the feedback, Brian. You should have a selection of alternatives available under: $ (cd /proc/cygdrive/c/WINDOWS/WinSxS/; l *gdiplus*/gdiplus.dll) [snip] Correct! 24 of them. ... and all w/ a hardlink count of 1 ... ... you obviously do not run Windows 7 ... The directories below "winsxs" have different names in my case :-) In my case, the latest entry with systemcopy matches that in System32: Nope, here no subdirectories w/ "systemcopy" in their name ... [snip] So you may want to try listing the former and copying to the latter. Copying or hardlinking makes cygcheck "very happy", but "my" Windows 7 does not care (it remains indifferent to my attempts to correct this). Hope that fixes things for you. It did not :-) I found heaps and heaps of "advice" on the "net" by Microsoft Support. Mostly irrational, no fundamental reasoning. Do this, do that, and in the end: reinstall your system. Following this kind of advice is not an option for me. I do not like doing things "blind-folded". Yes, I tried some things that seemed harmless to me ... Among them registering the GdiPlus.dll (in various ways) ... 64-C:\Windows\system32># regsvr32 gdiplus.dll elicited the following response: The module "gdiplus.dll" was loaded but the entry-point DllRegisterServer was not found. Euh, what? The thing that matters to me, is that the "DLL loading mechanism" invoked by the cygwin1.dll, is able to find the DLL's. Good! Granted, they are NOT found in c:/Windows/system32, but it appears that I cannot help that (w/o completely reinstalling my system). Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ? (2)
On 2018-11-30 14:19, Corinna Vinschen wrote:
[snip]
I'm trying to avoid remote debugging so I rather try to reproduce this
@work. However, if you're interested in debugging this, set a
breakpoint to clk_monotonic_t::now() and observe how the call to the
virtual init() method hangs or crashes. If you find out why, I'd be
most grateful.
Below I included parts of the diff between 1126 and 1129. You have been
refactoring the code related to "timing".
Above you state that the call to init() (clk_monotonic_t::init(), is my
understanding) from clk_monotonic_t::now() makes the cygwin1.dll end up
in "some mysterious loop" (my wording). At least on pre-W10 ...
Looking at the code (trying to understand it), it appears to me that it
is NOT "Windows version" dependent ...
My question: why do you claim in
https://cygwin.com/ml/cygwin/2018-11/msg00261.html
that Windows 10 is NOT affected? Does W10 run a different "thread" in
the Cygwin codebase?
Regards,
Henri
==
https://cygwin.com/snapshots/x86/cygwin-diffs-20181126-20181129
FILE: winsup/cygwin/clock.h:
+class clk_t
+{
+ protected:
+ LONG inited;
+ LONGLONG ticks_per_sec;
+ virtual void init ();
+ virtual int now (clockid_t, struct timespec *) = 0
...
+class clk_monotonic_t : public clk_t
+{
+ protected:
+ virtual void init ();
+ private:
+ virtual int now (clockid_t, struct timespec *);
+};
...
FILE: winsup/cygwin/clock.cc:
+void
+clk_t::init ()
+{
+ spinlock spin (inited, 1);
+ if (!spin)
+ticks_per_sec = system_tickcount_resolution ();
+}
+
...
+void
+clk_monotonic_t::init ()
+{
+ spinlock spin (inited, 1);
+ if (!spin)
+ticks_per_sec = system_qpc_resolution ();
+}
...
+int
+clk_monotonic_t::now (clockid_t clockid, struct timespec *ts)
+{
+ if (wincap.has_precise_interrupt_time ())
+{
+ /* Suspend time not taken into account, as on Linux */
+ ULONGLONG now;
+
+ QueryUnbiasedInterruptTimePrecise (&now);
+ ts->tv_sec = now / NS100PERSEC;
+ now %= NS100PERSEC;
+ ts->tv_nsec = now * (NSPERSEC/NS100PERSEC);
+}
+ else
+{
+ /* https://stackoverflow.com/questions/24330496. Skip rounding
since
+ its almost always wrong when working with timestamps */
+ UINT64 bias;
+ LARGE_INTEGER now;
+ struct timespec bts;
+
+ if (inited <= 0)
+ init ();// Henri: invocation of
clk_monotonic_t::init()
+ do
+ {
+ bias = SharedUserData.InterruptTimeBias;
+ QueryPerformanceCounter(&now);
+ }
+ while (bias != SharedUserData.InterruptTimeBias);
+ /* Convert perf counter to timespec */
+ ts->tv_sec = now.QuadPart / ticks_per_sec;
+ now.QuadPart %= ticks_per_sec;
+ ts->tv_nsec = (now.QuadPart * NSPERSEC) / ticks_per_sec;
+ /* Convert bias to timespec */
+ bts.tv_sec = bias / NS100PERSEC;
+ bias %= NS100PERSEC;
+ bts.tv_nsec = bias * (NSPERSEC/NS100PERSEC);
+ /* Subtract bias from perf */
+ ts_diff (bts, *ts);
+}
+ return 0;
+}
=
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ? (2)
On Dec 1 09:57, Houder wrote: > On 2018-11-30 14:19, Corinna Vinschen wrote: > [snip] > > > I'm trying to avoid remote debugging so I rather try to reproduce this > > @work. However, if you're interested in debugging this, set a > > breakpoint to clk_monotonic_t::now() and observe how the call to the > > virtual init() method hangs or crashes. If you find out why, I'd be > > most grateful. > > Below I included parts of the diff between 1126 and 1129. You have been > refactoring the code related to "timing". > > Above you state that the call to init() (clk_monotonic_t::init(), is my > understanding) from clk_monotonic_t::now() makes the cygwin1.dll end up > in "some mysterious loop" (my wording). At least on pre-W10 ... > > Looking at the code (trying to understand it), it appears to me that it > is NOT "Windows version" dependent ... > > My question: why do you claim in > > https://cygwin.com/ml/cygwin/2018-11/msg00261.html > > that Windows 10 is NOT affected? Does W10 run a different "thread" in > the Cygwin codebase? On W10, wincap.has_precise_interrupt_time () is true. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Something makes curl hang for 5 minutes after connection refused
On Nov 30 20:42, Brian Inglis wrote: > On 2018-11-30 12:49, Lee wrote: > > On 11/30/18, Basin Ilya wrote: > >> Hi. > >> > >> Recently I noticed that `curl` does not fail immediately after connection > >> refused, but waits for 5 minutes. > >> > >> This only happens on my machine and only with the `Cygwin` version of > >> `curl`. The mingw version is unaffected. > >> I tried downgrading curl, but it didn't help. I thought there's a rogue > >> setting in `/etc` or in home or maybe some environment variable, but I > >> couldn't find it. > >> > >> basin@BASIN /cygdrive/c/Users/basin > >> $ >/dev/null /usr/bin/curl -v http://127.0.0.1:2/ > >> * STATE: INIT => CONNECT handle 0x80048658; line 1404 (connection > >> #-5000) > >> * Added connection 0. The cache now contains 1 members > >> * Trying 127.0.0.1... > >> * TCP_NODELAY set > >> * STATE: CONNECT => WAITCONNECT handle 0x80048658; line 1456 > >> (connection > >> #0) > > <.. snip ..> > >> curl: (28) Connection timed out after 300145 milliseconds > >> > >> basin@BASIN /cygdrive/c/Users/basin > >> $ /usr/bin/curl --version > >> curl 7.59.0 (i686-pc-cygwin) libcurl/7.59.0 OpenSSL/1.0.2p zlib/1.2.11 > >> libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.7.0 nghttp2/1.31.0 > > > >> Can someone try to reproduce it? > > > > I get the same behavior: > > $ /usr/bin/curl -v http://127.0.0.1:2/ > > * STATE: INIT => CONNECT handle 0x600057ad0; line 1404 (connection #-5000) > > * Added connection 0. The cache now contains 1 members > > * Trying 127.0.0.1... > > * TCP_NODELAY set > > * STATE: CONNECT => WAITCONNECT handle 0x600057ad0; line 1456 (connection > > #0) > > * Connection timed out after 300324 milliseconds > > * multi_done > > * stopped the pause stream! > > * Closing connection 0 > > * The cache now contains 0 members > > curl: (28) Connection timed out after 300324 milliseconds > > > > $ /usr/bin/curl --version > > curl 7.59.0 (x86_64-unknown-cygwin) libcurl/7.59.0 OpenSSL/1.0.2p > > zlib/1.2.11 libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.7.0 > > nghttp2/1.31.0 > > > > > > I also get an almost immediate 'failed to connect' notice on windows: > > C:\>C:\UTIL\curl\curl.exe -v http://127.0.0.1:2/ > > * Trying 127.0.0.1... > > * TCP_NODELAY set > > * connect to 127.0.0.1 port 2 failed: Connection refused > > * Failed to connect to 127.0.0.1 port 2: Connection refused > > * Closing connection 0 > > curl: (7) Failed to connect to 127.0.0.1 port 2: Connection refused > > > > with either version of curl: > > C:\>where curl > > C:\UTIL\curl\curl.exe > > C:\Windows\System32\curl.exe > > Ditto all the way! > > Could this be caused by network speed improvements made to Cygwin a while > back? > Or were those patches never sent/received/applied from Daniel Havey (MS > Windows > Program Manager for Transports and IP)? Somebody may want to bisect this... Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
On Nov 30 21:27, Brian Inglis wrote:
> On 2018-11-30 05:56, Corinna Vinschen wrote:
> > On Nov 30 07:43, James E. King III wrote:
> >> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote:
> >>> On Nov 29 17:38, James E. King III wrote:
> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote:
> > I created a patch and uploaded new developer snapshots to
> > https://cygwin.com/snapshots/ Please give them a try.
> This fixed the issue for me. What's the best way to detect cygwin
> with this support?
> >>> This will show up in version 2.12.0(*) so checking the release field
> >>> from uname(2) should do the trick.
> >> Is there a programmatic way to check this without having to parse a
> >> bunch of char[20] from utsname.h?
> > How would you do this on Linux?
>
> Same:
> https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-in-c
>
> - read /proc/version which is generated from utsname fields (or vice versa)
> using e.g fscanf
>
> $ head /proc/version
> CYGWIN_NT-10.0 version 2.11.2(0.329/5/3) (cori...@calimero.vinschen.de) (gcc
> version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34
>
> - read (or source) /{etc,usr/lib}/os-release VERSION_ID line (or variable):
>
> $ head /{etc,usr/lib}/os-release
> ==> /etc/os-release <==
> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> NAME="Debian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> ID=debian
> HOME_URL="https://www.debian.org/";
> SUPPORT_URL="https://www.debian.org/support";
> BUG_REPORT_URL="https://bugs.debian.org/";
>
> ==> /usr/lib/os-release <==
> ... [same]
>
> Could also be supported under Cygwin:
We don't have OS releases. Every component in Cygwin has its own
release cycle and the version number of the Cygwin DLL is *not* a
os release number. What sense would this file have for us?
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Yes, I know ... must wait your message
Hi Corinna, Hard work pays off ... (you did it again). 64 LANG = en_US.utf-8, LC_ALL = => LANG = en_US.utf-8 PATH (64) = /usr/local/bin:/usr/bin:/drv/c/... LET OP: v2.12.0 of cygwin1.dll /ext/build/mknetrel/src/cygwin-snapshot-20181201-1/winsup/cygwin/cygheap.cc 64-%% uname -a CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin 64-%% Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
hangs in 20181129 snapshot hopefully fixed
I pushed a patch and uploaded a 20181201 developer snapshot to https://cygwin.com/snapshots which hopefully fixes all observed problems related to the new extensible clock implementation in the 20181129 snapshot. Basically it should fix clock hangs, as well as a dumb thinko in the Vista-only implementation of CLOCK_MONOTONIC_COARSE: In fact, despite its name, Windows' GetTickCount64() does not return clock ticks as GetTickCount does. Rather, it returns milliseconds since boottime, supposedly biased (aka "suspend time taken into account"). So it's not the best fit for CLOCK_MONOTONIC_COARSE, but without a working QueryUnbiasedInterruptTime function...(*) Please test. Thanks, Corinna (*) Do we still have any Vista users on this list? Or can we just pull the plug on Vista support? -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Yes, I know ... must wait your message
On Dec 1 15:31, Houder wrote: > Hi Corinna, > > Hard work pays off ... (you did it again). > > 64 LANG = en_US.utf-8, LC_ALL = > => LANG = en_US.utf-8 > PATH (64) = /usr/local/bin:/usr/bin:/drv/c/... > LET OP: v2.12.0 of cygwin1.dll > /ext/build/mknetrel/src/cygwin-snapshot-20181201-1/winsup/cygwin/cygheap.cc > 64-%% uname -a > CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin Hmm, ok. First I thought this is a problem with the new clock, but in fact the timestamp is generated at build time and I'm building on Linux. I can't reproduce this with a local build, so it must be something in terms of the DLL being build for a snapshot DLL, hmm... Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
On 2018-12-01 02:53, Corinna Vinschen wrote:
> On Nov 30 21:27, Brian Inglis wrote:
>> On 2018-11-30 05:56, Corinna Vinschen wrote:
>>> On Nov 30 07:43, James E. King III wrote:
On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote:
> On Nov 29 17:38, James E. King III wrote:
>> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote:
>>> I created a patch and uploaded new developer snapshots to
>>> https://cygwin.com/snapshots/ Please give them a try.
>> This fixed the issue for me. What's the best way to detect cygwin
>> with this support?
> This will show up in version 2.12.0(*) so checking the release field
> from uname(2) should do the trick.
Is there a programmatic way to check this without having to parse a
bunch of char[20] from utsname.h?
>>> How would you do this on Linux?
>>
>> Same:
>> https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-in-c
>>
>> - read /proc/version which is generated from utsname fields (or vice versa)
>> using e.g fscanf
>>
>> $ head /proc/version
>> CYGWIN_NT-10.0 version 2.11.2(0.329/5/3) (cori...@calimero.vinschen.de) (gcc
>> version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34
>>
>> - read (or source) /{etc,usr/lib}/os-release VERSION_ID line (or variable):
>>
>> $ head /{etc,usr/lib}/os-release
>> ==> /etc/os-release <==
>> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
>> NAME="Debian GNU/Linux"
>> VERSION_ID="9"
>> VERSION="9 (stretch)"
>> ID=debian
>> HOME_URL="https://www.debian.org/";
>> SUPPORT_URL="https://www.debian.org/support";
>> BUG_REPORT_URL="https://bugs.debian.org/";
>>
>> ==> /usr/lib/os-release <==
>> ... [same]
>>
>> Could also be supported under Cygwin:
>
> We don't have OS releases. Every component in Cygwin has its own
> release cycle and the version number of the Cygwin DLL is *not* a
> os release number. What sense would this file have for us?
Cygwin to me is a Unix package distro which provides bits and flavours of POSIX,
Linux, and BSD userlands and APIs, that happens to be based on top of Windows,
and provides extensive functionality and interoperability with and under that
environment, which makes it easier working for or in many orgs and with most
users and systems.
The Cygwin release is similar to Linux kernel versions, which may vary
independent of distros and releases, but is also similar to distro releases like
Debian 10 Buster or Ubuntu 19 Disco Dingo, which mark the time and progress e.g.
1.0 (RTM), 1.5 (Legacy), 1.7 (No9x/IPv6/LSA/charsets/IPC), 2.0 (NoPasswd), 2.5.2
(LastXP), 2.6 (PostXP/Locales), 2.10 (NoKR/ssp/FORTIFY), ... in somewhat
arbitrary steps.
The file centralizes and standardizes distro info previously spread across
multiple files in some distros (four on Fedora) with many names depending on
distros: /etc/*[-_]{release,version} and can be handy identifying in scripts, on
logs, or creating/selecting network directories, where something was run or
originated; see:
http://0pointer.de/blog/projects/os-release
https://www.freedesktop.org/software/systemd/man/os-release.html
That's valuable for and to system/net/db support staff who have to support
diverse legacy (in the sense of not the current corp standard distro or release)
systems or contract/external staff who have to support multiple orgs with
different standard distros or releases.
--
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.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Yes, I know ... must wait your message
On 2018-12-01 16:05, Corinna Vinschen wrote: On Dec 1 15:31, Houder wrote: Hi Corinna, Hard work pays off ... (you did it again). 64 LANG = en_US.utf-8, LC_ALL = => LANG = en_US.utf-8 PATH (64) = /usr/local/bin:/usr/bin:/drv/c/... LET OP: v2.12.0 of cygwin1.dll /ext/build/mknetrel/src/cygwin-snapshot-20181201-1/winsup/cygwin/cygheap.cc 64-%% uname -a CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin Hmm, ok. First I thought this is a problem with the new clock, but in fact the timestamp is generated at build time and I'm building on Linux. I can't reproduce this with a local build, so it must be something in terms of the DLL being build for a snapshot DLL, hmm... Huh? Hi Corinna, I had to get out in a hurry ... so I did not see your reply to my clumsy message ... I was studying the text of your latest commit ... and thought: "Well, if that is the case ..." I changed over to the "snapshot page" and it changed in front of my eyes. So, in a hurry I downloaded the tarball, replaced the cygwin1.dll in my test setup and posted my finding ... Sorry. I wanted you to know that it worked on W7 ... No problems yet ... Henri P.S. are you referring to string? (plural). That is me! (.bash_profile) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Yes, I know ... must wait your message
On 2018-12-01 16:52, Houder wrote: On 2018-12-01 16:05, Corinna Vinschen wrote: On Dec 1 15:31, Houder wrote: Hi Corinna, Hard work pays off ... (you did it again). THANK YOU ! Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Yes, I know ... must wait your message
On Dec 1 16:52, Houder wrote: > On 2018-12-01 16:05, Corinna Vinschen wrote: > > On Dec 1 15:31, Houder wrote: > > > Hi Corinna, > > > > > > Hard work pays off ... (you did it again). > > > > > > 64 LANG = en_US.utf-8, LC_ALL = > > > => LANG = en_US.utf-8 > > > PATH (64) = /usr/local/bin:/usr/bin:/drv/c/... > > > LET OP: v2.12.0 of cygwin1.dll > > > /ext/build/mknetrel/src/cygwin-snapshot-20181201-1/winsup/cygwin/cygheap.cc > > > 64-%% uname -a > > > CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin > > > > Hmm, ok. First I thought this is a problem with the new clock, but in > > fact the timestamp is generated at build time and I'm building on Linux. > > > > I can't reproduce this with a local build, so it must be something > > in terms of the DLL being build for a snapshot DLL, hmm... > > Huh? > > Hi Corinna, > > I had to get out in a hurry ... so I did not see your reply to my clumsy > message ... > > I was studying the text of your latest commit ... and thought: "Well, if > that is the case ..." > > I changed over to the "snapshot page" and it changed in front of my eyes. > > So, in a hurry I downloaded the tarball, replaced the cygwin1.dll in my > test setup and posted my finding ... > > Sorry. I wanted you to know that it worked on W7 ... > > No problems yet ... > > Henri > > P.S. are you referring to string? (plural). That is me! (.bash_profile) I'm referring to the missing date in uname -a (aka uname -v). Apparently this is a long-standing problem (2.5 yrs) in the script creating the version information when building a snapshot. I uploaded YA snapshot to https://cygwin.com/snapshots/ which should be back to a valid date info. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Yes, I know ... must wait your message
On 2018-12-01 17:09, Corinna Vinschen wrote: On Dec 1 16:52, Houder wrote: On 2018-12-01 16:05, Corinna Vinschen wrote: > On Dec 1 15:31, Houder wrote: > > Hi Corinna, > > > > Hard work pays off ... (you did it again). > > > > 64 LANG = en_US.utf-8, LC_ALL = > > => LANG = en_US.utf-8 > > PATH (64) = /usr/local/bin:/usr/bin:/drv/c/... > > LET OP: v2.12.0 of cygwin1.dll > > /ext/build/mknetrel/src/cygwin-snapshot-20181201-1/winsup/cygwin/cygheap.cc > > 64-%% uname -a > > CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin > > Hmm, ok. First I thought this is a problem with the new clock, but in > fact the timestamp is generated at build time and I'm building on Linux. > > I can't reproduce this with a local build, so it must be something > in terms of the DLL being build for a snapshot DLL, hmm... Huh? [snip] I'm referring to the missing date in uname -a (aka uname -v). Apparently this is a long-standing problem (2.5 yrs) in the script creating the version information when building a snapshot. I uploaded YA snapshot to https://cygwin.com/snapshots/ which should be back to a valid date info. Got it. Repeated procedure ... /ext/build/mknetrel/src/cygwin-snapshot-20181201-1/winsup/cygwin/cygheap.cc 64-%% uname -v 2018-12-01 16:02 64-%% uname -a CYGWIN_NT-6.1 Seven 2.12.0s(0.330/5/3) 2018-12-01 16:02 x86_64 Cygwin 64-%% Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: perl-5.26.3-1
Perl has been updated to version 5.26.3-1 on Cygwin. This is the third upstream maintenance release for Perl 5.26, released on Nov 29, 2018. Release notes: https://metacpan.org/changes/release/SHAY/perl-5.26.3 -- *** 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: protobuf-3.6.1-1
This is an update to the latest upstream release for protobuf. -- *** 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New: libcerf-1.7-1
This is a new package in Cygwin. Libcerf is a self-contained numeric library that provides an efficient and accurate implementation of complex error functions, along with Dawson, Faddeeva, and Voigt functions. -- *** 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Test: gnuplot-5.2.5-1
Gnuplot version 5.2.5 is available as a test version on Cygwin now. Notes: -- The configuration has changed to not include "backwards compatibility) any longer, which removes partial support for deprecated features. Unless I hear of problems with this change, this version will be promoted to be the current version in a few weeks, so please test your scripts with the new version. This build makes use of the new libcerf library package, so gnuplot should be able to use all functionality that depends on it. -- *** 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] jansson 2.12-1
The following packages have been uploaded to the Cygwin distribution: * libjansson4-2.12-1 * libjansson-devel-2.12-1 * libjansson-doc-2.12-1 Jansson is a C library for encoding, decoding, and manipulating JSON data. This is an update to the latest upstream release. It is a bug fix release. See https://groups.google.com/forum/#!topic/jansson-users/acNwlvHBIvU for details. Ken Brown Cygwin's Jansson maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Drop Vista Support? (Was: hangs in 20181129 snapshot hopefully fixed)
On 2018-12-01 07:44, Corinna Vinschen wrote: > (*) Do we still have any Vista users on this list? > Or can we just pull the plug on Vista support? Vista extended support ended 18 months ago; standard support 5 years before; all browsers but Opera and Lunascape (and IE9 on Vista SP2) dropped support for Vista and XP 6 months ago or earlier; estimates of remaining Vista users are an order of magnitude less than XP users: W10 ~ W7 ~45% each >> W8.1 ~ XP ~5% each > W8 ~1% > Vista ~.3-.6% or 1/166-333 systems * setup exe download annual unique IP count? Does anyone do regular analysis of sourceware access logs to justify support? What do the sourceware setup exe download and/or mailing list user agent strings tell you? N.B. W7/2008 extended (security) support ends in just over a year. Start migrating those systems to VMs behind firewalls. MS describes this as $100G opportunity (AKA user cost)! -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Drop Vista Support? (Was: hangs in 20181129 snapshot hopefully fixed)
For what it's worth: Vista does not even rise above the noise at https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam and is just barely present at https://netmarketshare.com/operating-system-market-share.aspx?id=platformsDesktopVersions If I were still supporting Vista on anything, I'd be thinking seriously about dropping it like a stone. - Dan On Sat, Dec 1, 2018 at 1:36 PM Brian Inglis wrote: > > On 2018-12-01 07:44, Corinna Vinschen wrote: > > (*) Do we still have any Vista users on this list? > > Or can we just pull the plug on Vista support? > > Vista extended support ended 18 months ago; standard support 5 years before; > all > browsers but Opera and Lunascape (and IE9 on Vista SP2) dropped support for > Vista and XP 6 months ago or earlier; estimates of remaining Vista users are > an > order of magnitude less than XP users: > > W10 ~ W7 ~45% each >> W8.1 ~ XP ~5% each > W8 ~1% > Vista ~.3-.6% or 1/166-333 > systems * setup exe download annual unique IP count? > > Does anyone do regular analysis of sourceware access logs to justify support? > What do the sourceware setup exe download and/or mailing list user agent > strings > tell you? > > N.B. W7/2008 extended (security) support ends in just over a year. > Start migrating those systems to VMs behind firewalls. > MS describes this as $100G opportunity (AKA user cost)! > > -- > 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. > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
