[ANNOUNCEMENT] GNOME 3.18.2
The following packages (and their respective subpackages) have been uploaded to the Cygwin distribution: * abiword-3.0.1-5 * adwaita-icon-theme-3.18.0-1 * anjuta-3.18.2-1 * at-spi2-atk-2.18.1-1 * at-spi2-core-2.18.3-1 * atk1.0-2.18.0-1 * atkmm1.6-2.24.1-1 * atomix-3.18.0-1 * autoconf-archive-2015.09.25-1 * baobab-3.18.1-1 * cairo-1.14.4-1 * cairomm1.0-1.12.0-1 * cantarell-fonts-0.0.18.1-1 * caribou-0.4.19-1 * clutter-gst2.0-2.0.16-1 * clutter-gst3.0-3.0.14-1 * clutter-gtk1.0-1.6.6-1 * clutter1.0-1.24.2-1 * cogl-1.22.0-1 * corebird-1.1-1 * dconf-0.24.0-1 * dconf-editor-3.18.2-1 * deja-dup-34.0-1 * desktop-file-utils-0.22-1 * duplicity-0.7.05-1 * easytag-2.4.0-1 * eog-3.18.1-1 * eog-plugins-3.16.3-1 * eom-plugins-1.10.0-2 * epiphany-3.8.2-3 * evince-3.18.2-1 * evolution-3.18.2-1 * evolution-data-server-3.18.2-1 * evolution-ews-3.18.2-1 * file-roller-3.16.4-1 * five-or-more-3.18.0-1 * folks-0.11.1-1 * four-in-a-row-3.18.2-1 * gcr-3.18.0-1 * gdk-pixbuf2.0-2.32.2-1 * gdl3-3.18.0-1 * geany-plugins-1.25-2 * gedit-3.18.2-1 * gedit-code-assistance-3.16.0-1 * gedit-plugins-3.18.0-1 * geocode-glib-3.18.0-1 * gfbgraph0.2-0.2.3-1 * ghex-3.18.0-1 * gjs-1.44.0-1 * glabels-3.2.1-2 * glib2.0-2.46.2-1 * glib2.0-networking-2.46.1-1 * glibmm2.4-2.46.2-1 * gmime2.6-2.6.20-2 * gnome-applets-3.18.1-1 * gnome-backgrounds-3.18.0-1 * gnome-calculator-3.18.2-1 * gnome-calendar-3.18.1-1 * gnome-chess-3.18.0-1 * gnome-clocks-3.18.0-1 * gnome-code-assistance-3.16.0-1 * gnome-common-3.18.0-1 * gnome-contacts-3.18.1-1 * gnome-control-center-3.18.1-1 * gnome-desktop-3.18.2-1 * gnome-devel-docs-3.18.1-1 * gnome-dictionary-3.18.0-1 * gnome-directory-thumbnailer-0.1.6-1 * gnome-epub-thumbnailer-1.5-1 * gnome-exe-thumbnailer-0.9.3-1 * gnome-flashback-3.18.1-1 * gnome-font-viewer-3.16.2-1 * gnome-getting-started-docs-3.18.2-1 * gnome-keyring-3.18.3-1 * gnome-klotski-3.18.2-1 * gnome-kra-ora-thumbnailer-1.3-3 * gnome-mahjongg-3.18.0-1 * gnome-mines-3.18.2-1 * gnome-nibbles-3.18.2-1 * gnome-online-accounts-3.18.2.1-1 * gnome-panel-3.18.1-1 * gnome-robots-3.18.1-1 * gnome-screenshot-3.18.0-1 * gnome-session-3.18.1.2-1 * gnome-settings-daemon-3.18.2-1 * gnome-sudoku-3.18.2-1 * gnome-system-monitor-3.18.2-1 * gnome-taquin-3.18.2-1 * gnome-terminal-3.18.2-1 * gnome-tetravex-3.18.0-1 * gnome-themes-standard-3.18.0-1 * gnome-todo-3.18.1-1 * gnome-tweak-tool-3.18.1-1 * gnome-user-docs-3.18.1-1 * gnome-weather-3.18.1-1 * gnome-xcf-thumbnailer-1.0-1 * gnumeric-1.12.24-1 * gobject-introspection-1.46.0-1 * goffice0.10-0.10.24-1 * gom-0.3.1-1 * goocanvasmm2.0-1.90.11-1 * grilo0.2-0.2.14-1 * grilo0.2-plugins-0.2.16-1 * gsettings-desktop-schemas-3.18.1-1 * gsound-1.0.2-1 * gspell-0.1.1-1 * gstreamer1.0-1.6.1-1 * gstreamer1.0-plugins-bad-free-1.6.1-1 * gstreamer1.0-plugins-base-1.6.1-1 * gstreamer1.0-plugins-good-1.6.1-1 * gtk-doc-1.24-1 * gtk3-3.18.5-1 * gtkmm3.0-3.18.0-1 * gtksourceview3.0-3.18.1-1 * gtksourceviewmm3.0-3.18.0-1 * gtranslator-2.91.7-1 * gucharmap-3.18.2-1 * gvfs-1.26.2-1 * harfbuzz-1.0.6-1 * hitori-3.16.2-1 * iagno-3.18.2-1 * imsettings-1.6.8-2 * intltool-0.51.0-1 * json-glib1.0-1.0.4-1 * krb5-auth-dialog-3.15.4-1 * latexila-3.18.1-1 * libchamplain0.12-0.12.11-1 * libcroco0.6-0.6.9-1 * libgda5.0-5.2.4-1 * libgdamm5.0-4.99.11-1 * libgdata-0.17.3-1 * libgee0.8-0.18.0-1 * libgit2-0.23.4-1 * libgit2-glib1.0-0.23.6-1 * libgsf-1.14.34-1 * libgtop2.0-2.32.0-1 * libgweather-3.18.1-1 * libgxps-0.2.3.2-1 * libical-1.0.1-1 * libmediaart2.0-1.9.0-1 * libopenraw-0.0.9-4 * libpeas-1.16.0-1 * librsvg2-2.40.11-1 * libsecret1-0.18.3-1 * libsigc2.0-2.6.2-1 * libsoup2.4-2.52.2-1 * lightsoff-3.18.0-1 * metacity-3.18.1-1 * midori-0.5.11-1 * mm-common-0.9.8-1 * mozjs24-24.2.0-1 * mutter-3.18.2-1 * nautilus-3.18.2-1 * notification-daemon-3.18.1-1 * pango1.0-1.38.1-1 * pangomm1.4-2.38.1-1 * pkg-config-0.29-1 * python-cloudfiles-1.7.11-1 * python-dropbox-3.22-1 * python-gi-3.18.2-1 * python-pyatspi-2.18.0-1 * qqwing-1.3.4-1 * quadrapassel-3.18.0-1 * seahorse-3.18.0-1 * shared-mime-info-1.5-1 * swell-foop-3.18.1-1 * tali-3.18.0-1 * totem-3.18.1-1 * vala-0.30.0-1 * vinagre-3.18.2-1 * vino-3.18.1-1 * vte2.90-0.36.5-1 * vte2.91-0.42.1-1 * webkitgtk-2.0.4-5 * yelp-3.16.1-1 * yelp-tools-3.18.0-1 * yelp-xsl-3.18.1-1 * zenity-3.18.1.1-1 -- Yaakov -- 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: Setup suggestion: Check for running processes before uninstalling anything.
On 2.12.2015 0:11, Andrey Repin wrote: Greetings, All! I just got a hard case of stupidity... Started Cygwin setup before checking if anything is running Cygwin. Guess, what? It indeed did run. However, setup managed to uninstall mintty before telling me that there's ssh-pageant running in the background. I had to dig up and start shell manually to gracefully shutdown the agent. I think it would be pretty nice of the Setup to check for running processes before starting to make changes to the environment. IMHO. Hi Andrey. Before updating Cygwin is useful to stop running services (as you wrote), to check newer version of Setup, then again resume running services. It is tedious to do it manually on each update. So, I wrote a short script that can be useful http://pastebin.com/5rR8pbRe -- .: Vlado :. -- 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: Incorrect Python errors when using os.remove to delete a directory
On Fri, Nov 27, 2015 at 04:09:52PM +0100, Michael Wild wrote:
> On Fri, Nov 27, 2015 at 3:51 PM, Adam Dinwoodie wrote:
> > If I use os.remove in Python to remove a directory, I expect it to fail
> > with an OSError on Python2 or a IsADirectoryError on Python3. On
> > Python2, I get OSError, but with the wrong error code, whereas on
> > Python3 I get completely the wrong exception.
>
> This is a bug in Python itself, and not Cygwin specific. At least I
> get the same behavior with my Anaconda installation.
So, having dug a bit more, the problem here is that Python is calling unlink,
which is setting errno to EPERM. On Linux systems, it's set to EISDIR instead,
but Cygwin's unlink conforms to POSIX[0], and the POSIX standard specifies the
errno in this case should be EPERM.[1]
So, depending on your perspective, the bug is either (a) that Cygwin conforms
to POSIX and not some other standard, (b) that Python3 doesn't correctly
distinguish between the different reasons a POSIX-compliant "unlink" might
return EPERM, or (c) there is no bug, and per [1] the calling code should
handle both exceptions ("Applications written for portability to both
POSIX.1-2008 and the LSB should be prepared to handle either error code.").
I think claiming (a) is not going to achieve much, and distinguishing between
(b) and (c) is something to take upstream to the Python mailing lists or
similar.
[0]: https://cygwin.com/cygwin-api/compatibility.html#std-susv4
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/unlink.html
--
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: control-R broken in bash (__fzf_history__)
> If you want to keep installing everything but want to maintain existing > Ctrl-R behaviour, your best bet is to explicitly bind Ctrl-R to the Bash > reverse-search function. You can do this by adding the following line > to your .bashrc, which (unless you're doing something odd) is executed > after the contents of /etc/profile.d: > > bind '\C-r:reverse-search-history' > > Adam Thank you, Adam. I asked an earlier question about fzf (different thread,) so I followed this with interest. The bind entry for ~/.bashrc works fine. Keith -- 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: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
On 11/27/2015 2:31 AM, Eli Zaretskii wrote: Date: Thu, 26 Nov 2015 22:20:18 +0100 From: Dominique de Waleffe So... started my homework... Got fresh w10 vm, put cygwin64 and both versions of emacs 24.4 and 24.5 from fsf ftp onto it And trying to start bash as shell fails under both versions! => I was mistaken in the origin of my instance of 24.4 (it must have come from another source, and I do not remember which) It says: GNU Emacs 24.4.1 (x86_64-w64-mingw32) of 2014-10-21 on KAEL => both versions from fsf ftp appear to be compiled using mingw GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570 GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-24 on LEG570 So the difference seems to be in the difference of mingw compilation mode. That's as far as I got tonight. Maybe someone has knowledge to share about the cause and what to do about this? I'd say this is somehow related to 64-bit Cygwin programs being run by 32-bit native Windows programs. The version which works for you is a 64-bit executable, those that don't are 32-bit. Just to follow up on this for the sake of the archives, Eli is correct (no surprise). The problem seems to be a result of recent changes to Windows 10, and Corinna is working on a fix. See https://www.cygwin.com/ml/cygwin/2015-12/msg3.html Ken -- 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
libuv
Hi, Lots of project such as node.js or neovim are using libuv (https://github.com/libuv/libuv) which is incompatible with Cygwin. I've spent some time trying to build it, but I get issues with pthread. The wonderful Neovim project has several opened issues regarding the portability of libuv (https://github.com/neovim/neovim/issues/873) It seems Windows are missing some POSIX system calls that Cygwin cannot emulate possibly regarding pthread. Unfortunately I did not find any trustable information about the feasibility to build libuv on Cygwin one day. I'll take a chance to get some information about this here... Cheers, Yves -- 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: libuv
Lots of project such as node.js or neovim are using libuv (https://github.com/libuv/libuv) which is incompatible with Cygwin. I've spent some time trying to build it, but I get issues with pthread. The first compilation error you'll get will look like "unknown type name 'pthread_barrier_t'" but that's actually pretty simple to work around in libuv. The harder part is the lack of support in Cygwin for epoll, inotify, and other async IO syscalls that libuv uses on unices. It might be possible to graft together a build configuration for libuv on Cygwin that uses WinAPI IOCP for the async parts but cygwin's posix layer for the rest, but it would be quite a bit of work. -Tony -- 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: libuv
On Dec 2, 2015, at 12:32 PM, Mr. Coin wrote: > > Lots of project such as node.js or neovim are using libuv > which is incompatible with Cygwin. Why are you trying to stack two I/O abstraction layers? The whole point of libuv is that it lets you use the same code on *ix and Windows. Why do you also need Cygwin? I realize that libuv doesn’t completely abstract the platform, but there are a bunch of libraries that you can use together to achieve that. libapr for general OS facilities, Qt/Gtk for GUIs, etc. Presumably you’re interested in libuv rather than select(2) because you need the code to be really fast and scalable. So again, why bring Cygwin into it? That’s just going to eat up a bunch of the speed you gained by using advanced I/O polling mechanisms. If you’re just trying to get node running, why not use the native binaries? -- 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: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On Dec 1 22:44, David Macek wrote: > On 1. 12. 2015 18:40, David Macek wrote: > > On 1. 12. 2015 15:01, Corinna Vinschen wrote: > >> On Dec 1 21:07, nu774 wrote: > There must be a bug in the new CMD somewhere. But, anyway, I'll look > into it when I finally managed to update my W10 test machine. > >>> > >>> No, cmd.exe is just an example. Any 32bit process can be an trigger. > >>> I guess something has changed in TH2 kernel regarding process memory > >>> management or something that interferes cygwin's fork(). > >> > >> If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then > >> there's some foul-up in the WOW64 layer in terms of starting 64 bit > >> processes, perhaps. Sigh, it's a rather unexpected change after it > >> worked fine for so long :( > > > > Yup. I can confirm. > > Just for the record, we did some debugging over IRC and it seems it's an > issue with WOW64 where the stack in the first 64-bit process is offset for > some reason. > > Citing Corinna: "I wonder if we have to resurrect the old > wow64_respawn_process function for this border case" Along these lines, is anybody here still running a 64 bit Windows 10 which has *NOT* been updated to 1511? If so, I just need the output of a call to `cat /proc/self/maps' once for comparison. Thanks in advance, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpzDhiKNKJCV.pgp Description: PGP signature
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On 12/2/2015 4:15 PM, Corinna Vinschen wrote: > Along these lines, is anybody here still running a 64 bit Windows 10 > which has *NOT* been updated to 1511? If so, I just need the output > of a call to `cat /proc/self/maps' once for comparison. Under 64-bit Cygwin: $ cat /proc/self/maps 0001-0002 rw-s : 0 [win heap 1 default shared] 0002-00021000 rw-s : 0 0003-00044000 r--s : 0 0005-00247000 ===p : 0 [stack (tid 17852)] 00247000-0024A000 rw-g 001F7000 : 0 [stack (tid 17852)] 0024A000-0025 rw-p 001FA000 : 0 [stack (tid 17852)] 0025-00254000 r--s : 0 0026-00261000 r--s : 0 0027-00272000 rw-p : 0 0028-0033E000 r--s 0203:7481 197032483777 /cygdrive/c/Windows/System32/locale.nls 0034-00341000 rw-p : 0 [win heap 0 default grow] 00341000-00372000 ===p 1000 : 0 [win heap 0 default grow] 0038-00381000 rw-p : 0 [win heap 2 grow] 00381000-003B2000 ===p 1000 : 0 [win heap 2 grow] 0043-0043A000 rw-p : 0 [win heap 0 default grow] 0043A000-0053 ===p A000 : 0 [win heap 0 default grow] 0053-0072B000 ===p : 0 [stack (tid 18372)] 0072B000-0072E000 rw-g 001FB000 : 0 [stack (tid 18372)] 0072E000-0073 rw-p 001FE000 : 0 [stack (tid 18372)] 0073-0092C000 ===p : 0 [stack (tid 15144)] 0092C000-0092F000 rw-g 001FC000 : 0 [stack (tid 15144)] 0092F000-0093 rw-p 001FF000 : 0 [stack (tid 15144)] 0093-00B2C000 ===p : 0 [stack (tid 8304)] 00B2C000-00B2F000 rw-g 001FC000 : 0 [stack (tid 8304)] 00B2F000-00B3 rw-p 001FF000 : 0 [stack (tid 8304)] 00B3-00D29000 ===p : 0 [stack (tid 6616)] 00D29000-00D2C000 rw-g 001F9000 : 0 [stack (tid 6616)] 00D2C000-00D3 rw-p 001FC000 : 0 [stack (tid 6616)] 00EA-00EA6000 rw-p : 0 [win heap 2 grow] 00EA6000-00EB ===p 6000 : 0 [win heap 2 grow] 7FFE-7FFE1000 r--p : 0 [shared-user-data] 7FFE1000-7FFF ===p 1000 : 0 [shared-user-data] 10040-100401000 r--p 0203:7481 25051272927416393 /usr/bin/cat.exe 100401000-100409000 r-xp 1000 0203:7481 25051272927416393 /usr/bin/cat.exe 100409000-10040A000 rw-p 9000 0203:7481 25051272927416393 /usr/bin/cat.exe 10040A000-10040F000 r--p A000 0203:7481 25051272927416393 /usr/bin/cat.exe 10040F000-100412000 rw-p F000 0203:7481 25051272927416393 /usr/bin/cat.exe 100412000-100413000 r--p 00012000 0203:7481 25051272927416393 /usr/bin/cat.exe 18001-18002 rw-s : 0 [procinfo] 18002-180029000 rw-s : 0 [cygwin-user-shared] 18003-18003A000 rw-s : 0 [cygwin-shared] 18004-180041000 r--p 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 180041000-1801E7000 r-xp 1000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 1801E7000-1801EB000 rwxp 001A7000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 1801EB000-180212000 rw-p 001AB000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 180212000-1802BA000 r--p 001D2000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 1802BA000-180303000 rw-p 0027A000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 180303000-180313000 r--p 002C3000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 180313000-18032 rw-p 002D3000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 18032-180321000 r--p 002E 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 180321000-18063 rw-p 002E1000 0203:7481 17169973579518949 /usr/bin/cygwin1.dll 3FF86-3FF861000 r--p 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF861000-3FF867000 r-xp 1000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF867000-3FF868000 rw-p 7000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF868000-3FF86D000 r--p 8000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF86D000-3FF86E000 rw-p D000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF86E000-3FF86F000 r--p E000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF86F000-3FF871000 rw-p F000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF871000-3FF873000 r--p 00011000 0203:7481 10133099161757167 /usr/bin/cygintl-8.dll 3FF88-3FF881000 r--p 0203:7481 19703248370073036 /usr/bin/cygiconv-2.dll 3FF8
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On Dec 2 16:43, René Berber wrote: > On 12/2/2015 4:15 PM, Corinna Vinschen wrote: > > > Along these lines, is anybody here still running a 64 bit Windows 10 > > which has *NOT* been updated to 1511? If so, I just need the output > > of a call to `cat /proc/self/maps' once for comparison. > > Under 64-bit Cygwin: > > [...] Thanks a lot! Does anybody have the same info for 32 bit W10 updated to 1511? I have the exact opposite info available right now :} > $ uname -a > CYGWIN_NT-10.0 T7400 2.3.1(0.291/5/3) 2015-11-14 12:44 x86_64 Cygwin > > I don't know were you can see the specific Windows version, but AFAIK it > hasn't been updated recently (the System Info only shows "Windows 10 > Pro", 64-bit). That's oh so funny: The good old system info doesn't show this anymore. But you can look into the new-style "Settings" -> System -> About. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpklkkiWm1nJ.pgp Description: PGP signature
