Re: cygcheck failing to find file

2018-02-20 Thread Fergus Daly 
>> Cygcheck is a native Windows executable .. ..
>> I pushed a fix and uploaded new developer snapshots to
>> https://cygwin.de/snapshots/
>> Please give them a try.

I tried your link above but got "HTTP 404 Not found".
Just in case this was your intention I tried the latest cygwin1.dll
snapshot from
https://cygwin.com/snapshots/
being 20180216 but still got
> $ cygcheck /d/src/sc.exe
> cygcheck: could not find '/d/src/sc.exe'

I just tried the 20180220 snapshot; but still get
> $ cygcheck /d/src/sc.exe
> cygcheck: could not find '/d/src/sc.exe'

Fergus

--
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: Advice needed on ffcall packaging

2018-02-20 Thread Brian Inglis 
On 2018-02-20 11:41, Yaakov Selkowitz wrote:
> NAME=ffcall
> ...
> PKG_NAMES="libffcall0 libffcall-devel"
> libffcall0_CONTENTS=...
> libffcall_devel_OBSOLETES="ffcall"
> libffcall_devel_CONTENTS=...

Does this generate the ("virtual") package setup entry for:

@ ffcall
...
category: _obsolete
requires: libffcall-devel
...

and does this need need to be kept in .cygport for future releases?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

[ANNOUNCEMENT] mesa 17.3.5-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* dri-drivers-17.3.5-1
* libglapi0-17.3.5-1
* libGL1-17.3.5-1
* libGL-devel-17.3.5-1
* libOSMesa8-17.3.5-1
* libOSMesa-devel-17.3.5-1
* libEGL1-17.3.5-1
* libEGL-devel-17.3.5-1
* libGLESv2_2-17.3.5-1
* libGLESv2-devel-17.3.5-1
* windowsdriproto-17.3.5-1

Mesa is an open-source implementation of the OpenGL, OpenGL ES, and EGL 
specifications for rendering interactive 3D graphics.

Complete documentation on OpenGL usage and configuration can be found here:

http://x.cygwin.com/docs/ug/using-glx.html

This is an update to the latest stable release:

https://www.mesa3d.org/relnotes/17.3.4.html
https://www.mesa3d.org/relnotes/17.3.5.html

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

mesa 17.3.5-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* dri-drivers-17.3.5-1
* libglapi0-17.3.5-1
* libGL1-17.3.5-1
* libGL-devel-17.3.5-1
* libOSMesa8-17.3.5-1
* libOSMesa-devel-17.3.5-1
* libEGL1-17.3.5-1
* libEGL-devel-17.3.5-1
* libGLESv2_2-17.3.5-1
* libGLESv2-devel-17.3.5-1
* windowsdriproto-17.3.5-1

Mesa is an open-source implementation of the OpenGL, OpenGL ES, and EGL 
specifications for rendering interactive 3D graphics.

Complete documentation on OpenGL usage and configuration can be found here:

http://x.cygwin.com/docs/ug/using-glx.html

This is an update to the latest stable release:

https://www.mesa3d.org/relnotes/17.3.4.html
https://www.mesa3d.org/relnotes/17.3.5.html

--
Yaakov

[ANNOUNCEMENT] zziplib 0.13.68-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* zziplib-0.13.68-1
* libzzip0.13-0.13.68-1
* libzzip-devel-0.13.68-1

The zziplib library is intentionally lightweight, it offers the ability to 
easily extract data from files archived in a single zip file. Applications 
can bundle files into a single zip archive and access them. The 
implementation is based only on the (free) subset of compression with the 
zlib algorithm which is actually used by the zip/unzip tools.

This is an update to the latest release, which includes CVE fixes:

https://sourceforge.net/projects/zziplib/files/zziplib13/0.13.68/

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

zziplib 0.13.68-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* zziplib-0.13.68-1
* libzzip0.13-0.13.68-1
* libzzip-devel-0.13.68-1

The zziplib library is intentionally lightweight, it offers the ability to 
easily extract data from files archived in a single zip file. Applications 
can bundle files into a single zip archive and access them. The 
implementation is based only on the (free) subset of compression with the 
zlib algorithm which is actually used by the zip/unzip tools.

This is an update to the latest release, which includes CVE fixes:

https://sourceforge.net/projects/zziplib/files/zziplib13/0.13.68/

--
Yaakov

[ANNOUNCEMENT] Updated X.Org components

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* bdftopcf-1.1-1
* libXcursor1-1.1.15-1
* libXcursor-devel-1.1.15-1
* libXfont1-1.5.4-1
* libXfont-devel-1.5.4-1
* libXfont2_2-2.0.3-1
* libXfont2-devel-2.0.3-1
* libXRes1-1.2.0-1
* libXRes-devel-1.2.0-1
* xfs-1.2.0-1
* xkeyboard-config-2.23.1-1
* xkeyboard-config-devel-2.23.1-1
* xorgproto-2018.3-1

This includes the latest updates to a few X.Org components, including a
CVE fix in libXfont (of which there are no longer any consumers) and
libXfont2.

https://lists.x.org/archives/xorg-announce/2017-October/002812.html
https://lists.x.org/archives/xorg-announce/2017-November/002821.html
https://lists.x.org/archives/xorg-announce/2017-November/002823.html
https://lists.x.org/archives/xorg-announce/2017-November/002824.html
https://lists.x.org/archives/xorg-announce/2017-November/002826.html
https://lists.x.org/archives/xorg-announce/2018-February/002833.html
https://lists.x.org/archives/xorg-announce/2018-February/002835.html
https://lists.x.org/archives/xorg-announce/2018-February/002836.html
https://lists.x.org/archives/xorg-announce/2018-February/002839.html

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

Updated X.Org components

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* bdftopcf-1.1-1
* libXcursor1-1.1.15-1
* libXcursor-devel-1.1.15-1
* libXfont1-1.5.4-1
* libXfont-devel-1.5.4-1
* libXfont2_2-2.0.3-1
* libXfont2-devel-2.0.3-1
* libXRes1-1.2.0-1
* libXRes-devel-1.2.0-1
* xfs-1.2.0-1
* xkeyboard-config-2.23.1-1
* xkeyboard-config-devel-2.23.1-1
* xorgproto-2018.3-1

This includes the latest updates to a few X.Org components, including a
CVE fix in libXfont (of which there are no longer any consumers) and
libXfont2.

https://lists.x.org/archives/xorg-announce/2017-October/002812.html
https://lists.x.org/archives/xorg-announce/2017-November/002821.html
https://lists.x.org/archives/xorg-announce/2017-November/002823.html
https://lists.x.org/archives/xorg-announce/2017-November/002824.html
https://lists.x.org/archives/xorg-announce/2017-November/002826.html
https://lists.x.org/archives/xorg-announce/2018-February/002833.html
https://lists.x.org/archives/xorg-announce/2018-February/002835.html
https://lists.x.org/archives/xorg-announce/2018-February/002836.html
https://lists.x.org/archives/xorg-announce/2018-February/002839.html

-- 
Yaakov

MinGW GNOME 3.26 libraries

2018-02-20 Thread Yaakov Selkowitz 
The following packages has been uploaded to the Cygwin distribution:

* mingw64-i686-adwaita-icon-theme-3.26.1-1
* mingw64-i686-atk1.0-2.26.1-1
* mingw64-i686-gdk-pixbuf2.0-2.36.11-1
* mingw64-i686-gdl3-3.26.0-1
* mingw64-i686-glib2.0-2.54.3-1
* mingw64-i686-glib2.0-networking-2.54.1-1
* mingw64-i686-glibmm2.4-2.54.1-1
* mingw64-i686-goffice0.10-0.10.38-1
* mingw64-i686-gtk3-3.22.28-1
* mingw64-i686-gtkmm3.0-3.22.2-1
* mingw64-i686-gtksourceview3.0-3.24.6-1
* mingw64-i686-json-glib1.0-1.4.2-1
* mingw64-i686-libgee0.8-0.20.1-1
* mingw64-i686-libgsf1-1.14.42-1
* mingw64-i686-librest0.7-0.8.1-1
* mingw64-i686-librsvg2-2.40.20-1
* mingw64-i686-libsoup2.4-2.60.3-1
* mingw64-i686-pango1.0-1.40.14-1
* mingw64-x86_64-adwaita-icon-theme-3.26.1-1
* mingw64-x86_64-atk1.0-2.26.1-1
* mingw64-x86_64-gdk-pixbuf2.0-2.36.11-1
* mingw64-x86_64-gdl3-3.26.0-1
* mingw64-x86_64-glib2.0-2.54.3-1
* mingw64-x86_64-glib2.0-networking-2.54.1-1
* mingw64-x86_64-glibmm2.4-2.54.1-1
* mingw64-x86_64-goffice0.10-0.10.38-1
* mingw64-x86_64-gtk3-3.22.28-1
* mingw64-x86_64-gtkmm3.0-3.22.2-1
* mingw64-x86_64-gtksourceview3.0-3.24.6-1
* mingw64-x86_64-json-glib1.0-1.4.2-1
* mingw64-x86_64-libgee0.8-0.20.1-1
* mingw64-x86_64-libgsf1-1.14.42-1
* mingw64-x86_64-librest0.7-0.8.1-1
* mingw64-x86_64-librsvg2-2.40.20-1
* mingw64-x86_64-libsoup2.4-2.60.3-1
* mingw64-x86_64-pango1.0-1.40.14-1

This updates the GTK+/GNOME libraries for the MinGW-w64 cross-compiler
toolchains to the 3.26 stable release.

-- 
Yaakov

[ANNOUNCEMENT] MinGW GNOME 3.26 libraries

2018-02-20 Thread Yaakov Selkowitz 
The following packages has been uploaded to the Cygwin distribution:

* mingw64-i686-adwaita-icon-theme-3.26.1-1
* mingw64-i686-atk1.0-2.26.1-1
* mingw64-i686-gdk-pixbuf2.0-2.36.11-1
* mingw64-i686-gdl3-3.26.0-1
* mingw64-i686-glib2.0-2.54.3-1
* mingw64-i686-glib2.0-networking-2.54.1-1
* mingw64-i686-glibmm2.4-2.54.1-1
* mingw64-i686-goffice0.10-0.10.38-1
* mingw64-i686-gtk3-3.22.28-1
* mingw64-i686-gtkmm3.0-3.22.2-1
* mingw64-i686-gtksourceview3.0-3.24.6-1
* mingw64-i686-json-glib1.0-1.4.2-1
* mingw64-i686-libgee0.8-0.20.1-1
* mingw64-i686-libgsf1-1.14.42-1
* mingw64-i686-librest0.7-0.8.1-1
* mingw64-i686-librsvg2-2.40.20-1
* mingw64-i686-libsoup2.4-2.60.3-1
* mingw64-i686-pango1.0-1.40.14-1
* mingw64-x86_64-adwaita-icon-theme-3.26.1-1
* mingw64-x86_64-atk1.0-2.26.1-1
* mingw64-x86_64-gdk-pixbuf2.0-2.36.11-1
* mingw64-x86_64-gdl3-3.26.0-1
* mingw64-x86_64-glib2.0-2.54.3-1
* mingw64-x86_64-glib2.0-networking-2.54.1-1
* mingw64-x86_64-glibmm2.4-2.54.1-1
* mingw64-x86_64-goffice0.10-0.10.38-1
* mingw64-x86_64-gtk3-3.22.28-1
* mingw64-x86_64-gtkmm3.0-3.22.2-1
* mingw64-x86_64-gtksourceview3.0-3.24.6-1
* mingw64-x86_64-json-glib1.0-1.4.2-1
* mingw64-x86_64-libgee0.8-0.20.1-1
* mingw64-x86_64-libgsf1-1.14.42-1
* mingw64-x86_64-librest0.7-0.8.1-1
* mingw64-x86_64-librsvg2-2.40.20-1
* mingw64-x86_64-libsoup2.4-2.60.3-1
* mingw64-x86_64-pango1.0-1.40.14-1

This updates the GTK+/GNOME libraries for the MinGW-w64 cross-compiler
toolchains to the 3.26 stable release.

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

GNOME 3.26.2

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* adwaita-icon-theme-3.26.1-1
* adwaita-icon-theme-devel-3.26.1-1
* anjuta-3.26.0-1
* anjuta-extras-3.26.0-1
* at-spi2-core-2.26.2-1
* baobab-3.26.1-1
* corebird-1.7.3-1
* dconf-0.26.1-1
* dconf-editor-3.26.2-1
* dconf-service-0.26.1-1
* d-feet-0.3.13-1
* eog-3.26.2-1
* eog-devel-3.26.2-1
* eog-doc-3.26.2-1
* eog-plugins-3.26.2-1
* evince-3.26.0-1
* evolution-3.20.5-2
* evolution-data-server-3.20.6-2
* evolution-devel-3.20.5-2
* evolution-doc-3.20.5-2
* evolution-ews-3.20.5-2
* file-roller-3.26.2-1
* five-or-more-3.26.0-1
* folks-0.11.4-1
* four-in-a-row-3.22.2-1
* frogr-1.4-1
* gdk-pixbuf2.0-svg-2.40.20-1
* gdk-pixbuf-thumbnailer-2.36.11-1
* gegl0.3-0.3.28-1
* girepository-Anjuta3.0-3.26.0-1
* girepository-Atk1.0-2.26.1-1
* girepository-Atspi2.0-2.26.2-1
* girepository-cairo1.0-1.54.1-1
* girepository-Champlain0.12-0.12.16-1
* girepository-EDataServer1.2-3.20.6-2
* girepository-Evince3.0-3.26.0-1
* girepository-Folks0.6-0.11.4-1
* girepository-GData0.0-0.17.9-1
* girepository-GdkPixbuf2.0-2.36.11-1
* girepository-Gdl3-3.26.0-1
* girepository-Gee0.8-0.20.1-1
* girepository-Gegl0.3-0.3.28-1
* girepository-GExiv2_0.10-0.10.8-1
* girepository-Ggit1.0-0.26.2-1
* girepository-GIRepository2.0-1.54.1-1
* girepository-Gkbd3.0-3.26.0-1
* girepository-GLib2.0-1.54.1-1
* girepository-GMime3.0-3.0.5-1
* girepository-GnomeDesktop3.0-3.26.2-1
* girepository-Goa1.0-3.22.6-2
* girepository-GOffice0.10-0.10.38-1
* girepository-Gom1.0-0.3.3-1
* girepository-GPaste1.0-3.26.0-1
* girepository-Grl0.3-0.3.4-1
* girepository-Grss0.7-0.7.0-1
* girepository-Gsf1-1.14.42-1
* girepository-Gspell1-1.6.1-1
* girepository-Gtk2.0-2.24.32-1
* girepository-Gtk3.0-3.22.28-1
* girepository-GtkChamplain0.12-0.12.16-1
* girepository-GtkSource3.0-3.24.6-1
* girepository-Gucharmap2.90-10.0.3-1
* girepository-GWeather3.0-3.26.1-1
* girepository-Json1.0-1.4.2-1
* girepository-MediaArt2.0-1.9.4-1
* girepository-Pango1.0-1.40.14-1
* girepository-Peas1.0-1.22.0-1
* girepository-Rest0.7-0.8.1-1
* girepository-Rsvg2.0-2.40.20-1
* girepository-Soup2.4-2.60.3-1
* girepository-SoupGNOME2.4-2.60.3-1
* girepository-Tepl3-3.0.0-1
* girepository-TotemPlParser1.0-3.26.0-1
* girepository-Tracker2.0-2.0.3-1
* girepository-Vte2.91-0.50.2-1
* girepository-x11-1.54.1-1
* girepository-Zpj0.0-0.0.3-1
* gitg-3.26.0-1
* glade-3.20.3-1
* glade-devel-3.20.3-1
* glade-doc-3.20.3-1
* glade-gtksourceview-3.24.6-1
* glade-libgweather3-3.26.1-1
* glade-libpeas-1.22.0-1
* glade-python-3.20.3-1
* glade-vte2.91-0.50.2-1
* glib2.0-networking-2.54.1-1
* glib2.0-openssl-2.50.6-1
* gnome2048-3.26.1-1
* gnome-applets-3.26.0-1
* gnome-backgrounds-3.26.2-1
* gnome-calculator-3.26.0-1
* gnome-calendar-3.26.3-1
* gnome-chess-3.26.0-1
* gnome-clocks-3.26.1-1
* gnome-code-assistance-3.16.1-4
* gnome-contacts-3.26.1-1
* gnome-control-center-3.26.2-1
* gnome-desktop-3.26.2-1
* gnome-devel-docs-3.26.0-1
* gnome-dictionary-3.26.1-1
* gnome-directory-thumbnailer-0.1.10-1
* gnome-flashback-3.26.0-1
* gnome-font-viewer-3.26.0-1
* gnome-getting-started-docs-3.26.2-1
* gnome-klotski-3.22.2-1
* gnome-mines-3.26.0-1
* gnome-online-accounts-3.22.6-2
* gnome-online-miners-3.26.0-1
* gnome-panel-3.26.0-1
* gnome-panel-devel-3.26.0-1
* gnome-recipes-2.0.2-1
* gnome-robots-3.22.2-1
* gnome-screenshot-3.26.0-1
* gnome-session-3.26.1-1
* gnome-settings-daemon-3.26.2-1
* gnome-settings-daemon-devel-3.26.2-1
* gnome-sudoku-3.26.0-1
* gnome-taquin-3.26.1-1
* gnome-terminal-3.26.2-1
* gnome-todo-3.26.2-1
* gnome-tweak-tool-3.26.4-1
* gnome-user-docs-3.26.2.1-1
* gnumeric-1.12.38-1
* gnumeric-devel-1.12.38-1
* gnumeric-gdaif-1.12.38-1
* gnumeric-perl-1.12.38-1
* gnumeric-psiconv-1.12.38-1
* gnumeric-python-1.12.38-1
* gobject-introspection-1.54.1-1
* gpaste-client-3.26.0-1
* gpaste-daemon-3.26.0-1
* gpaste-ui-3.26.0-1
* grilo0.3-0.3.4-1
* grilo0.3-plugins-0.3.5-1
* gsf-office-thumbnailer-1.14.42-1
* gspell-1.6.1-1
* gtk2.0-atk-bridge-2.26.1-1
* gtk2.0-demo-2.24.32-1
* gtk2.0-engines-pixmap-2.24.32-1
* gtk2.0-gail-2.24.32-1
* gtk3-demo-3.22.28-1
* gtk-doc-1.26-1
* gtk-update-icon-cache-3.22.28-1
* gucharmap-10.0.3-1
* gvfs-1.34.2-1
* gvfs-devel-1.34.2-1
* gvfs-goa-1.34.2-1
* hitori-3.22.4-1
* iagno-3.26.1-1
* json-glib1.0-1.4.2-1
* krb5-auth-dialog-3.26.1-1
* latexila-3.26.1-1
* libanjuta3_0-3.26.0-1
* libanjuta3-devel-3.26.0-1
* libanjuta3-doc-3.26.0-1
* libatk1.0_0-2.26.1-1
* libatk1.0-devel-2.26.1-1
* libatk1.0-doc-2.26.1-1
* libatk-bridge2.0_0-2.26.1-1
* libatk-bridge2.0-devel-2.26.1-1
* libatspi0-2.26.2-1
* libatspi-devel-2.26.2-1
* libatspi-doc-2.26.2-1
* libbabl0.1_0-0.1.42-1
* libbabl-devel-0.1.42-1
* libcamel1.2_57-3.20.6-2
* libchamplain0.12_0-0.12.16-1
* libchamplain0.12-devel-0.12.16-1
* libchamplain0.12-doc-0.12.16-1
* libchamplain-gtk0.12_0-0.12.16-1
* libchamplain-gtk0.12-devel-0.12.16-1
* libchamplain-gtk0.12-doc-0.12.16-1
* libdconf1-0.26.1-1
* libdconf-devel-0.26.1-1
* libdconf-doc-0.26.1-1
* libebackend1.2_10-3.20.6-2
*

[ANNOUNCEMENT] GNOME 3.26.2

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* adwaita-icon-theme-3.26.1-1
* adwaita-icon-theme-devel-3.26.1-1
* anjuta-3.26.0-1
* anjuta-extras-3.26.0-1
* at-spi2-core-2.26.2-1
* baobab-3.26.1-1
* corebird-1.7.3-1
* dconf-0.26.1-1
* dconf-editor-3.26.2-1
* dconf-service-0.26.1-1
* d-feet-0.3.13-1
* eog-3.26.2-1
* eog-devel-3.26.2-1
* eog-doc-3.26.2-1
* eog-plugins-3.26.2-1
* evince-3.26.0-1
* evolution-3.20.5-2
* evolution-data-server-3.20.6-2
* evolution-devel-3.20.5-2
* evolution-doc-3.20.5-2
* evolution-ews-3.20.5-2
* file-roller-3.26.2-1
* five-or-more-3.26.0-1
* folks-0.11.4-1
* four-in-a-row-3.22.2-1
* frogr-1.4-1
* gdk-pixbuf2.0-svg-2.40.20-1
* gdk-pixbuf-thumbnailer-2.36.11-1
* gegl0.3-0.3.28-1
* girepository-Anjuta3.0-3.26.0-1
* girepository-Atk1.0-2.26.1-1
* girepository-Atspi2.0-2.26.2-1
* girepository-cairo1.0-1.54.1-1
* girepository-Champlain0.12-0.12.16-1
* girepository-EDataServer1.2-3.20.6-2
* girepository-Evince3.0-3.26.0-1
* girepository-Folks0.6-0.11.4-1
* girepository-GData0.0-0.17.9-1
* girepository-GdkPixbuf2.0-2.36.11-1
* girepository-Gdl3-3.26.0-1
* girepository-Gee0.8-0.20.1-1
* girepository-Gegl0.3-0.3.28-1
* girepository-GExiv2_0.10-0.10.8-1
* girepository-Ggit1.0-0.26.2-1
* girepository-GIRepository2.0-1.54.1-1
* girepository-Gkbd3.0-3.26.0-1
* girepository-GLib2.0-1.54.1-1
* girepository-GMime3.0-3.0.5-1
* girepository-GnomeDesktop3.0-3.26.2-1
* girepository-Goa1.0-3.22.6-2
* girepository-GOffice0.10-0.10.38-1
* girepository-Gom1.0-0.3.3-1
* girepository-GPaste1.0-3.26.0-1
* girepository-Grl0.3-0.3.4-1
* girepository-Grss0.7-0.7.0-1
* girepository-Gsf1-1.14.42-1
* girepository-Gspell1-1.6.1-1
* girepository-Gtk2.0-2.24.32-1
* girepository-Gtk3.0-3.22.28-1
* girepository-GtkChamplain0.12-0.12.16-1
* girepository-GtkSource3.0-3.24.6-1
* girepository-Gucharmap2.90-10.0.3-1
* girepository-GWeather3.0-3.26.1-1
* girepository-Json1.0-1.4.2-1
* girepository-MediaArt2.0-1.9.4-1
* girepository-Pango1.0-1.40.14-1
* girepository-Peas1.0-1.22.0-1
* girepository-Rest0.7-0.8.1-1
* girepository-Rsvg2.0-2.40.20-1
* girepository-Soup2.4-2.60.3-1
* girepository-SoupGNOME2.4-2.60.3-1
* girepository-Tepl3-3.0.0-1
* girepository-TotemPlParser1.0-3.26.0-1
* girepository-Tracker2.0-2.0.3-1
* girepository-Vte2.91-0.50.2-1
* girepository-x11-1.54.1-1
* girepository-Zpj0.0-0.0.3-1
* gitg-3.26.0-1
* glade-3.20.3-1
* glade-devel-3.20.3-1
* glade-doc-3.20.3-1
* glade-gtksourceview-3.24.6-1
* glade-libgweather3-3.26.1-1
* glade-libpeas-1.22.0-1
* glade-python-3.20.3-1
* glade-vte2.91-0.50.2-1
* glib2.0-networking-2.54.1-1
* glib2.0-openssl-2.50.6-1
* gnome2048-3.26.1-1
* gnome-applets-3.26.0-1
* gnome-backgrounds-3.26.2-1
* gnome-calculator-3.26.0-1
* gnome-calendar-3.26.3-1
* gnome-chess-3.26.0-1
* gnome-clocks-3.26.1-1
* gnome-code-assistance-3.16.1-4
* gnome-contacts-3.26.1-1
* gnome-control-center-3.26.2-1
* gnome-desktop-3.26.2-1
* gnome-devel-docs-3.26.0-1
* gnome-dictionary-3.26.1-1
* gnome-directory-thumbnailer-0.1.10-1
* gnome-flashback-3.26.0-1
* gnome-font-viewer-3.26.0-1
* gnome-getting-started-docs-3.26.2-1
* gnome-klotski-3.22.2-1
* gnome-mines-3.26.0-1
* gnome-online-accounts-3.22.6-2
* gnome-online-miners-3.26.0-1
* gnome-panel-3.26.0-1
* gnome-panel-devel-3.26.0-1
* gnome-recipes-2.0.2-1
* gnome-robots-3.22.2-1
* gnome-screenshot-3.26.0-1
* gnome-session-3.26.1-1
* gnome-settings-daemon-3.26.2-1
* gnome-settings-daemon-devel-3.26.2-1
* gnome-sudoku-3.26.0-1
* gnome-taquin-3.26.1-1
* gnome-terminal-3.26.2-1
* gnome-todo-3.26.2-1
* gnome-tweak-tool-3.26.4-1
* gnome-user-docs-3.26.2.1-1
* gnumeric-1.12.38-1
* gnumeric-devel-1.12.38-1
* gnumeric-gdaif-1.12.38-1
* gnumeric-perl-1.12.38-1
* gnumeric-psiconv-1.12.38-1
* gnumeric-python-1.12.38-1
* gobject-introspection-1.54.1-1
* gpaste-client-3.26.0-1
* gpaste-daemon-3.26.0-1
* gpaste-ui-3.26.0-1
* grilo0.3-0.3.4-1
* grilo0.3-plugins-0.3.5-1
* gsf-office-thumbnailer-1.14.42-1
* gspell-1.6.1-1
* gtk2.0-atk-bridge-2.26.1-1
* gtk2.0-demo-2.24.32-1
* gtk2.0-engines-pixmap-2.24.32-1
* gtk2.0-gail-2.24.32-1
* gtk3-demo-3.22.28-1
* gtk-doc-1.26-1
* gtk-update-icon-cache-3.22.28-1
* gucharmap-10.0.3-1
* gvfs-1.34.2-1
* gvfs-devel-1.34.2-1
* gvfs-goa-1.34.2-1
* hitori-3.22.4-1
* iagno-3.26.1-1
* json-glib1.0-1.4.2-1
* krb5-auth-dialog-3.26.1-1
* latexila-3.26.1-1
* libanjuta3_0-3.26.0-1
* libanjuta3-devel-3.26.0-1
* libanjuta3-doc-3.26.0-1
* libatk1.0_0-2.26.1-1
* libatk1.0-devel-2.26.1-1
* libatk1.0-doc-2.26.1-1
* libatk-bridge2.0_0-2.26.1-1
* libatk-bridge2.0-devel-2.26.1-1
* libatspi0-2.26.2-1
* libatspi-devel-2.26.2-1
* libatspi-doc-2.26.2-1
* libbabl0.1_0-0.1.42-1
* libbabl-devel-0.1.42-1
* libcamel1.2_57-3.20.6-2
* libchamplain0.12_0-0.12.16-1
* libchamplain0.12-devel-0.12.16-1
* libchamplain0.12-doc-0.12.16-1
* libchamplain-gtk0.12_0-0.12.16-1
* libchamplain-gtk0.12-devel-0.12.16-1
* libchamplain-gtk0.12-doc-0.12.16-1
* libdconf1-0.26.1-1
* libdconf-devel-0.26.1-1
* libdconf-doc-0.26.1-1
* libebackend1.2_10-3.20.6-2
*

[ANNOUNCEMENT] libical 2.0.0-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libical2-2.0.0-1
* libical-devel-2.0.0-1

Libical is an Open Source implementation of the IETF's iCalendar 
Calendaring and Scheduling protocols. (RFC 2445, 2446, and 2447). It parses 
iCal components and provides a C API for manipulating the component 
properties, parameters, and subcomponents.

This update is API compatible but not ABI compatible with 1.0:

https://github.com/libical/libical/releases/tag/v2.0.0

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

[ANNOUNCEMENT] uchardet 0.0.6-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* uchardet-0.0.6-1
* libuchardet0-0.0.6-1
* libuchardet-devel-0.0.6-1

uchardet is an encoding detector library, which takes a sequence of bytes 
in an unknown character encoding without any additional information, and 
attempts to determine the encoding of the text.

This has been added as a new dependency of GNOME latexila 3.26.

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

libical 2.0.0-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libical2-2.0.0-1
* libical-devel-2.0.0-1

Libical is an Open Source implementation of the IETF's iCalendar 
Calendaring and Scheduling protocols. (RFC 2445, 2446, and 2447). It parses 
iCal components and provides a C API for manipulating the component 
properties, parameters, and subcomponents.

This update is API compatible but not ABI compatible with 1.0:

https://github.com/libical/libical/releases/tag/v2.0.0

--
Yaakov

uchardet 0.0.6-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* uchardet-0.0.6-1
* libuchardet0-0.0.6-1
* libuchardet-devel-0.0.6-1

uchardet is an encoding detector library, which takes a sequence of bytes 
in an unknown character encoding without any additional information, and 
attempts to determine the encoding of the text.

This has been added as a new dependency of GNOME latexila 3.26.

--
Yaakov

[ANNOUNCEMENT] fontconfig 2.12.6-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* fontconfig-2.12.6-1
* fontconfig-doc-2.12.6-1
* libfontconfig1-2.12.6-1
* libfontconfig-common-2.12.6-1
* libfontconfig-devel-2.12.6-1
* mingw64-i686-fontconfig-2.12.6-1
* mingw64-x86_64-fontconfig-2.12.6-1

Fontconfig is a library designed to provide system-wide font configuration, 
customization and application access.

This is an update to the latest stable release.  The perpetual postinstall 
script has been optimized.

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

[ANNOUNCEMENT] cairo 1.14.12-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libcairo2-1.14.12-1
* libcairo-devel-1.14.12-1
* libcairo-doc-1.14.12-1
* mingw64-i686-cairo-1.14.12-1
* mingw64-x86_64-cairo-1.14.12-1

Cairo is a 2D graphics library with support for multiple output devices. 
Currently supported output targets include the X Window System (via both 
Xlib and XCB), quartz, win32, and image buffers, as well as PDF, PostScript, 
and SVG file output.

This is an update to the latest stable release:

https://www.cairographics.org/news/cairo-1.14.12/

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

fontconfig 2.12.6-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* fontconfig-2.12.6-1
* fontconfig-doc-2.12.6-1
* libfontconfig1-2.12.6-1
* libfontconfig-common-2.12.6-1
* libfontconfig-devel-2.12.6-1
* mingw64-i686-fontconfig-2.12.6-1
* mingw64-x86_64-fontconfig-2.12.6-1

Fontconfig is a library designed to provide system-wide font configuration, 
customization and application access.

This is an update to the latest stable release.  The perpetual postinstall 
script has been optimized.

--
Yaakov

cairo 1.14.12-1

2018-02-20 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libcairo2-1.14.12-1
* libcairo-devel-1.14.12-1
* libcairo-doc-1.14.12-1
* mingw64-i686-cairo-1.14.12-1
* mingw64-x86_64-cairo-1.14.12-1

Cairo is a 2D graphics library with support for multiple output devices. 
Currently supported output targets include the X Window System (via both 
Xlib and XCB), quartz, win32, and image buffers, as well as PDF, PostScript, 
and SVG file output.

This is an update to the latest stable release:

https://www.cairographics.org/news/cairo-1.14.12/

--
Yaakov

Re: setup 2.888 crashes on --prune-install

2018-02-20 Thread Andrew Schulman 
> Andrew Schulman writes:
> > When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown
> > below, it crashes. An error dialog pops up saying "setup-x86.exe has
> > stopped working". No other debug information appears on the console - the
> > whole session is shown below.
> 
> That option, as I originally implemented it, should actually leave your
> system exactly with those packages requested, without diving into
> dependencies.  In other words, that list should be self-contained, like
> you'd get from copying an existing installation from a different
> machine.  From what you were saying I guess that you rather want to use
> --delete-orphans.

Thanks. Yes, --delete-orphans is what I wanted.

And sadly I just found out that pdftk is gone :(

Andrew

Re: Advice needed on ffcall packaging

2018-02-20 Thread Ken Brown 

On 2/20/2018 1:41 PM, Yaakov Selkowitz wrote:

On 2018-02-20 09:47, Ken Brown wrote:

A few years ago I adopted ffcall (32-bit only) in order to keep it from
disappearing from the distro:

The latest upstream release builds on 64-bit Cygwin, so I'd like to
update the package, and I'd like to find a sensible way of breaking it
up into subpackages.  Here are the relevant facts:

1. Cygwin's existing (32-bit) ffcall is really a devel package: It
consists of headers, four (static) libs, and documentation.  There are
no subpackages and no shared libs.

2. The build of the current release produces the same four static libs,
plus shared versions of the first three, plus a new lib, both static and
shared (libffcall.a and cygffcall-0.dll).

If I were starting from scratch, I would have three packages: ffcall,
libffcall0, and libffcall-devel.  ffcall would be source only;
libffcall0 would contain the shared libs *.dll; and libffcall-devel
would contain the headers, the import libs *.dll.a, and the one static
lib for which there is no shared version.  I wouldn't ship the other
static libs unless I discover later that they're needed for some reason.

But I'm not starting from scratch, and users of the existing ffcall will
need the new libffcall-devel.


NAME=ffcall
...
PKG_NAMES="libffcall0 libffcall-devel"
libffcall0_CONTENTS=...
libffcall_devel_OBSOLETES="ffcall"
libffcall_devel_CONTENTS=...


Thanks!  It would never have occurred to me that a package could be 
obsoleted by one of its subpackages.


Ken

Re: setup 2.888 crashes on --prune-install

2018-02-20 Thread Achim Gratz 
Andrew Schulman writes:
> When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown
> below, it crashes. An error dialog pops up saying "setup-x86.exe has
> stopped working". No other debug information appears on the console - the
> whole session is shown below.

That option, as I originally implemented it, should actually leave your
system exactly with those packages requested, without diving into
dependencies.  In other words, that list should be self-contained, like
you'd get from copying an existing installation from a different
machine.  From what you were saying I guess that you rather want to use
--delete-orphans.


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: Advice needed on ffcall packaging

2018-02-20 Thread Yaakov Selkowitz 
On 2018-02-20 09:47, Ken Brown wrote:
> A few years ago I adopted ffcall (32-bit only) in order to keep it from
> disappearing from the distro:
> 
> The latest upstream release builds on 64-bit Cygwin, so I'd like to
> update the package, and I'd like to find a sensible way of breaking it
> up into subpackages.  Here are the relevant facts:
> 
> 1. Cygwin's existing (32-bit) ffcall is really a devel package: It
> consists of headers, four (static) libs, and documentation.  There are
> no subpackages and no shared libs.
> 
> 2. The build of the current release produces the same four static libs,
> plus shared versions of the first three, plus a new lib, both static and
> shared (libffcall.a and cygffcall-0.dll).
> 
> If I were starting from scratch, I would have three packages: ffcall,
> libffcall0, and libffcall-devel.  ffcall would be source only;
> libffcall0 would contain the shared libs *.dll; and libffcall-devel
> would contain the headers, the import libs *.dll.a, and the one static
> lib for which there is no shared version.  I wouldn't ship the other
> static libs unless I discover later that they're needed for some reason.
> 
> But I'm not starting from scratch, and users of the existing ffcall will
> need the new libffcall-devel.

NAME=ffcall
...
PKG_NAMES="libffcall0 libffcall-devel"
libffcall0_CONTENTS=...
libffcall_devel_OBSOLETES="ffcall"
libffcall_devel_CONTENTS=...

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

setup 2.888 crashes on --prune-install

2018-02-20 Thread Andrew Schulman 
When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown
below, it crashes. An error dialog pops up saying "setup-x86.exe has
stopped working". No other debug information appears on the console - the
whole session is shown below.

When I run the same command without --prune-install, it completes normally.

Poor setup seems to be having trouble solving all of the dependencies. Not
surprising, as my installation is old and crufty. Of course that's what I
was hoping --prune-install would help to dig me out of.

Andrew

c:\Users\x\Downloads\utilities\cygwin32>setup-x86.exe --no-shortcuts
--quiet-mode --prune-install --packages
atool,autoconf,automake,autossh,bc,bind-utils,byacc,bzr,curl,cygport,discus,dos2unix,doxygen,emacs,file,fish,flexdll,gcc-core,gcc-g++,gettext-devel,git,gnupg2,gsl-devel,help2man,lftp,libargp,libargp-devel,libcrypt-devel,libgd-devel,libiconv,libintl-devel,libncurses-devel,libneon-devel,libpcre2-devel,libpng-devel,libreadline-devel,libwrap-devel,libX11-devel,links,lndir,m4,make,multitail,ncurses,nosleep,ocaml,ocaml-camlp4,openssh,openssl-devel,orpie,p7zip,par2,patch,patchutils,pdftk,perl,pinentry,pinfo,pkg-config,procps-ng,psmisc,readline,rebase,robodoc,rsync,screen,sitecopy,sng,socat,stow,stunnel,time,tree,unison2.27,unison2.32,unison2.40,unison2.45,unison2.48,unison2.49,unison2.51,util-linux,wget,zip,

Starting cygwin install, version 2.888
User has backup/restore rights
Current Directory: C:\Users\x\Downloads\utilities\cygwin32
Could not open service McShield for query, start and stop. McAfee may not
be installed, or we don't have access.
root: C:\cygwin32 system
Selected local directory: C:\Users\x\Downloads\utilities\cygwin32
net: Direct
site: http://mirrors.xmission.com/cygwin/
solving: 699 tasks, update: no, use test packages: no
Augmented Transaction List:
   0   erase_update-info-dir 03000-1
   1   erase   aria2 1.32.0-1
   2   eraseautomake 10-1
   3   erase automake1.4 1.4p6-11
   4   erase automake1.5 1.5-11
   5   erase automake1.6 1.6.3-12
   6   erase automake1.7 1.7.9-11
   7   erase automake1.8 1.8.5-11
   8   erase  bind-utils 9.11.2-2.P1
   9   erasecompface 1.5.2-12
  10   erasecurl 7.56.1-1
  11   erase cvs 1.11.23-2
  12   erasediffstat 1.61-1
  13   erase doxygen 1.8.14-2
  14   erase   emacs 25.3-1
  15   erase  fontconfig 2.12.4-1
  16   erase gcc-g++ 6.4.0-5
  17   erase   gettext-devel 0.19.8.1-2
  18   erase   ghostscript-fonts-std 20170801-4
  19   erase   gnupg 1.4.22-1
  20   erasegraphviz 2.40.1-3
  21   erase gsl 2.3-2
  22   erase   gsl-devel 2.3-2
  23   erase   inetutils 1.9.1-2
  24   erase  ipcalc 0.41-1
  25   erase libEGL1 17.3.3-1
  26   erase  libGL1 17.3.3-1
  27   eraselibXpm-devel 3.5.12-1
  28   eraselibbind9_140 9.10.4-4.P4
  29   erase libclang3.8 3.8.1-1
  30   erase libclang4.0 4.0.1-1
  31   eraselibcord1 7.6.4-1
  32   erase libdialog13 1.3-2.20160828
  33   erase   libdns166 9.11.0-3.P5
  34   erase libfontconfig-devel 2.12.4-1
  35   erase   libgccpp1 7.6.4-1
  36   erase   libgcj-common 5.4.0-1
  37   erase libgd-devel 2.2.5-1
  38   erase libgnutls28 3.3.27-1
  39   erase libgsl0 1.16-2
  40   erase  libguile17 1.8.8-3
  41   eraselibicu56 56.1-1
  42   eraselibicu57 57.1-1
  43   eraselibicu59 59.1-1
  44   erase   libirs141 9.10.4-4.P4
  45   erase

Re: Advice needed on ffcall packaging

2018-02-20 Thread Marco Atzeri 

On 20/02/2018 16:47, Ken Brown wrote:
A few years ago I adopted ffcall (32-bit only) in order to keep it from 
disappearing from the distro:


   https://sourceware.org/ml/cygwin-apps/2015-07/msg00092.html





But I'm not starting from scratch, and users of the existing ffcall will 
need the new libffcall-devel.  I can think of two possibilities for 
handling this:


A) Pretend that I'm starting from scratch, and deal with the fallout. 
There probably won't be any, since ffcall is not currently required by 
any other package.  As far as I know, its only use is that it's a build 
requirement for clisp, which I maintain.


B) Make three packages as above, with the source-only package being 
called libffcall instead of ffcall.  (libffcall is the upstream name 
anyway.)  I could then make libffcall-devel obsolete ffcall.






Maybe this is much ado about nothing, but I'd appreciate advice.

Ken


Both are fine.
B is more in line with current trend in package name but it is
just personal taste.

Regards
Marco

[newlib-cygwin] Cygwin: net.cc: drop redundant declarations

2018-02-20 Thread Corinna Vinschen 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=dff3bc9a86c5d07f97dd62dd3279124b4b576296

commit dff3bc9a86c5d07f97dd62dd3279124b4b576296
Author: Corinna Vinschen 
Date:   Tue Feb 20 18:14:57 2018 +0100

Cygwin: net.cc: drop redundant declarations

Replace cygwin_inet_aton call with cygwin_inet_pton

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/net.cc | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index dc81fb7..0d85332 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -59,11 +59,8 @@ extern "C"
 {
   int h_errno;
 
-  int __stdcall rcmd (char **ahost, unsigned short inport, char *locuser,
- char *remuser, char *cmd, SOCKET * fd2p);
   int sscanf (const char *, const char *, ...);
   int cygwin_inet_pton(int, const char *, void *);
-  int cygwin_inet_aton(const char *, struct in_addr *);
   const char *cygwin_inet_ntop (int, const void *, char *, socklen_t);
   int dn_length1(const unsigned char *, const unsigned char *,
 const unsigned char *);
@@ -1792,7 +1789,7 @@ get_ipv4fromreg (struct ifall *ifp, const char *name, 
DWORD idx)
{ \
  char t[64]; \
  sys_wcstombs (t, 64, (u)); \
- cygwin_inet_aton (t, (a)); \
+ cygwin_inet_pton (AF_INET, t, (a)); \
}
   /* If DHCP is used, we have only one address. */
   if (dhcp)

[newlib-cygwin] Cygwin: set/getsockopt: Move implementation into fhandler_socket class

2018-02-20 Thread Corinna Vinschen 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ea1e5318d5479ca841beab601a4c3dd7cce627ad

commit ea1e5318d5479ca841beab601a4c3dd7cce627ad
Author: Corinna Vinschen 
Date:   Tue Feb 20 18:01:40 2018 +0100

Cygwin: set/getsockopt: Move implementation into fhandler_socket class

This requires to export find_winsock_errno from net.cc.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/cygerrno.h |   1 +
 winsup/cygwin/fhandler.h |   4 +
 winsup/cygwin/fhandler_socket.cc | 330 +
 winsup/cygwin/net.cc | 347 ++-
 4 files changed, 348 insertions(+), 334 deletions(-)

diff --git a/winsup/cygwin/cygerrno.h b/winsup/cygwin/cygerrno.h
index afcae4c..009ae63 100644
--- a/winsup/cygwin/cygerrno.h
+++ b/winsup/cygwin/cygerrno.h
@@ -41,6 +41,7 @@ __set_errno (const char *fn, int ln, int val)
 }
 #define set_errno(val) __set_errno (__PRETTY_FUNCTION__, __LINE__, (val))
 
+int find_winsock_errno (DWORD why);
 void __reg2 __set_winsock_errno (const char *fn, int ln);
 #define set_winsock_errno() __set_winsock_errno (__FUNCTION__, __LINE__)
 
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index ab6fb6e..ce9d924 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -590,6 +590,10 @@ class fhandler_socket: public fhandler_base
   int getpeereid (pid_t *pid, uid_t *euid, gid_t *egid);
   int socketpair (int af, int type, int protocol, int flags,
  fhandler_socket *fh_out);
+  int setsockopt (int level, int optname, const void *optval,
+ __socklen_t optlen);
+  int getsockopt (int level, int optname, const void *optval,
+ __socklen_t *optlen);
 
   int open (int flags, mode_t mode = 0);
   void __reg3 read (void *ptr, size_t& len);
diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc
index a7c702e..26d4716 100644
--- a/winsup/cygwin/fhandler_socket.cc
+++ b/winsup/cygwin/fhandler_socket.cc
@@ -2685,3 +2685,333 @@ fhandler_socket::getpeereid (pid_t *pid, uid_t *euid, 
gid_t *egid)
   __endtry
   return -1;
 }
+
+static int
+convert_ws1_ip_optname (int optname)
+{
+  static int ws2_optname[] =
+  {
+0,
+IP_OPTIONS,
+IP_MULTICAST_IF,
+IP_MULTICAST_TTL,
+IP_MULTICAST_LOOP,
+IP_ADD_MEMBERSHIP,
+IP_DROP_MEMBERSHIP,
+IP_TTL,
+IP_TOS,
+IP_DONTFRAGMENT
+  };
+  return (optname < 1 || optname > _WS1_IP_DONTFRAGMENT)
+? optname
+: ws2_optname[optname];
+}
+
+int
+fhandler_socket::setsockopt (int level, int optname, const void *optval,
+socklen_t optlen)
+{
+  bool ignore = false;
+  int ret = -1;
+
+  /* Preprocessing setsockopt.  Set ignore to true if setsockopt call should
+ get skipped entirely. */
+  switch (level)
+{
+case SOL_SOCKET:
+  switch (optname)
+   {
+   case SO_PEERCRED:
+ /* Switch off the AF_LOCAL handshake and thus SO_PEERCRED handling
+for AF_LOCAL/SOCK_STREAM sockets.  This allows to handle special
+situations in which connect is called before a listening socket
+accepts connections.
+FIXME: In the long run we should find a more generic solution
+which doesn't require a blocking handshake in accept/connect
+to exchange SO_PEERCRED credentials. */
+ if (optval || optlen)
+   set_errno (EINVAL);
+ else
+   ret = af_local_set_no_getpeereid ();
+ return ret;
+
+   case SO_REUSEADDR:
+ /* Per POSIX we must not be able to reuse a complete duplicate of a
+local TCP address (same IP, same port), even if SO_REUSEADDR has
+been set.  This behaviour is maintained in WinSock for backward
+compatibility, while the WinSock standard behaviour of stream
+socket binding is equivalent to the POSIX behaviour as if
+SO_REUSEADDR has been set.  The SO_EXCLUSIVEADDRUSE option has
+been added to allow an application to request POSIX standard
+behaviour in the non-SO_REUSEADDR case.
+
+To emulate POSIX socket binding behaviour, note that SO_REUSEADDR
+has been set but don't call setsockopt.  Instead
+fhandler_socket::bind sets SO_EXCLUSIVEADDRUSE if the application
+did not set SO_REUSEADDR. */
+ if (optlen < (socklen_t) sizeof (int))
+   {
+ set_errno (EINVAL);
+ return ret;
+   }
+ if (get_socket_type () == SOCK_STREAM)
+   ignore = true;
+ break;
+
+   case SO_RCVTIMEO:
+   case SO_SNDTIMEO:
+ if (optlen < (socklen_t) sizeof (struct timeval))
+   {
+ set_errno (EINVAL);
+ return ret;
+   }
+ if (timeval_to_ms ((struct timeval *) optval,
+

[newlib-cygwin] Cygwin: clean error mapping

2018-02-20 Thread Corinna Vinschen 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=044ab77dcc59ec7eea0e3880d47c22f5f62cc502

commit 044ab77dcc59ec7eea0e3880d47c22f5f62cc502
Author: Corinna Vinschen 
Date:   Tue Feb 20 17:59:45 2018 +0100

Cygwin: clean error mapping

- Move definition of windows to POSIX error mapping struct into
  cygerrno.h
- Move declaration of winsock errno functions to cygerrno.h
- Input to error mapping functions is DWORD

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/cygerrno.h | 10 ++
 winsup/cygwin/errno.cc   |  7 +--
 winsup/cygwin/net.cc | 21 +++--
 winsup/cygwin/winsup.h   |  3 ---
 4 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/winsup/cygwin/cygerrno.h b/winsup/cygwin/cygerrno.h
index ce33d97..afcae4c 100644
--- a/winsup/cygwin/cygerrno.h
+++ b/winsup/cygwin/cygerrno.h
@@ -11,6 +11,13 @@ details. */
 #include 
 #include "regparm.h"
 
+struct errmap_t
+{
+  DWORD w;  /* windows version of error */
+  const char *s;/* text of windows version */
+  int e;/* errno version of error */
+};
+
 void __reg3 seterrno_from_win_error (const char *file, int line, DWORD code);
 void __reg3 seterrno_from_nt_status (const char *file, int line, NTSTATUS 
status);
 int __reg2 geterrno_from_win_error (DWORD code = GetLastError (), int deferrno 
= 13 /*EACCESS*/);
@@ -34,6 +41,9 @@ __set_errno (const char *fn, int ln, int val)
 }
 #define set_errno(val) __set_errno (__PRETTY_FUNCTION__, __LINE__, (val))
 
+void __reg2 __set_winsock_errno (const char *fn, int ln);
+#define set_winsock_errno() __set_winsock_errno (__FUNCTION__, __LINE__)
+
 #define get_errno()  (errno)
 extern "C" void __stdcall set_sig_errno (int e);
 
diff --git a/winsup/cygwin/errno.cc b/winsup/cygwin/errno.cc
index 9168e9b..4203265 100644
--- a/winsup/cygwin/errno.cc
+++ b/winsup/cygwin/errno.cc
@@ -31,12 +31,7 @@ details. */
 
 #define X(w, e) {ERROR_##w, #w, e}
 
-static const struct
-{
-  DWORD w;  /* windows version of error */
-  const char *s;/* text of windows version */
-  int e;/* errno version of error */
-} errmap[] =
+static const errmap_t errmap[] =
 {
   /* FIXME: Some of these choices are arbitrary! */
   X (ACCESS_DENIED,EACCES),
diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index d0e4d3b..7d73790 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -150,14 +150,7 @@ inet_makeaddr (int net, int lna)
   return in;
 }
 
-struct tl
-{
-  int w;
-  const char *s;
-  int e;
-};
-
-static const struct tl errmap[] = {
+static const errmap_t wsock_errmap[] = {
   {WSA_INVALID_HANDLE, "WSA_INVALID_HANDLE", EBADF},
   {WSA_NOT_ENOUGH_MEMORY, "WSA_NOT_ENOUGH_MEMORY", ENOMEM},
   {WSA_INVALID_PARAMETER, "WSA_INVALID_PARAMETER", EINVAL},
@@ -206,11 +199,11 @@ static const struct tl errmap[] = {
 };
 
 static int
-find_winsock_errno (int why)
+find_winsock_errno (DWORD why)
 {
-  for (int i = 0; errmap[i].s != NULL; ++i)
-if (why == errmap[i].w)
-  return errmap[i].e;
+  for (int i = 0; wsock_errmap[i].s != NULL; ++i)
+if (why == wsock_errmap[i].w)
+  return wsock_errmap[i].e;
 
   return EPERM;
 }
@@ -229,7 +222,7 @@ __set_winsock_errno (const char *fn, int ln)
  * Since the member `s' isn't used for debug output we can use it
  * for the error text returned by herror and hstrerror.
  */
-static const struct tl host_errmap[] = {
+static const errmap_t host_errmap[] = {
   {WSAHOST_NOT_FOUND, "Unknown host", HOST_NOT_FOUND},
   {WSATRY_AGAIN, "Host name lookup failure", TRY_AGAIN},
   {WSANO_RECOVERY, "Unknown server error", NO_RECOVERY},
@@ -242,7 +235,7 @@ set_host_errno ()
 {
   int i;
 
-  int why = WSAGetLastError ();
+  DWORD why = WSAGetLastError ();
 
   for (i = 0; host_errmap[i].w != 0; ++i)
 if (why == host_errmap[i].w)
diff --git a/winsup/cygwin/winsup.h b/winsup/cygwin/winsup.h
index 1b3fbfe..d2b3718 100644
--- a/winsup/cygwin/winsup.h
+++ b/winsup/cygwin/winsup.h
@@ -212,9 +212,6 @@ bool timeval_to_ms (const struct timeval *, DWORD &);
 void __stdcall set_console_title (char *);
 void init_console_handler (bool);
 
-void __reg2 __set_winsock_errno (const char *fn, int ln);
-#define set_winsock_errno() __set_winsock_errno (__FUNCTION__, __LINE__)
-
 extern bool wsock_started;
 
 /* Printf type functions */

Re: "ls" doesn't show postscript files any longer

2018-02-20 Thread Siegmar Gross 

Hi Henri, hi Marco,

I can see my postscript file again with cygwin1-20180216.dll.

hermes temp 10 uname -a
CYGWIN_NT-6.1 hermes 2.10.1(0.325/5/3)  x86_64 Cygwin
hermes temp 11 ls -l
total 328
-rwxrwx---+ 1 SYSTEM   SYSTEM  10896 Feb 20 16:37 MpCmdRun.log
-rwxrwx---+ 1 fd1026_2 None   322294 Feb 20 16:39 chap4.ps
hermes temp 12 getfacl chap4.ps
# file: chap4.ps
# owner: fd1026_2
# group: None
user::rwx
group::---
group:root:rwx
group:Authentifizierte Benutzer:rwx
group:SYSTEM:rwx
group:Benutzer:r-x
mask:rwx
other:---

hermes temp 13

Thank you very much for your help.

Siegmar

Am 19.02.2018 um 23:34 schrieb Houder:

On Mon, 19 Feb 2018 12:24:24, Siegmar Gross wrote:

Hi,

I'm using Cygwin on top of Windows 7 (all updates installed).
"ls" doesn't show postscript files any longer after upgrading
all installed Cygwin packages to the latest versions. I create
the postscript file with MS Word 2003 using the "HP Color LJ
4550 PS" driver and printing to a file. In the past these files
were visible.

hermes temp 10 uname -a
CYGWIN_NT-6.1 hermes 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
hermes temp 11 ls
MpCmdRun.log
hermes temp 12 ls *.ps
ls: No match.
hermes temp 13 ls chap4.ps
chap4.ps
hermes temp 14 file chap4.ps
chap4.ps: PJL encapsulated PostScript document text
hermes temp 15

Does anybody know why I don't see the existing file any longer?


Siegmar,

Please, do as suggested by Marco Atzeri.

  - stop everything "Cygwin" related, and
  - replace the cygwin1.dll by the one you will find here

 https://cygwin.com/snapshots/

Download https://cygwin.com/snapshots/x86_64/cygwin1-20180216.dll.xz and
extract the cygwin1.dll.

As verification of what Marco believes to be the culprit, I "printed" to a file
from Word 2007.

This file proved to be "invisible" for ls (but not to the cmd's dir command).

The Windows Explorer shows that the file has the T attribute ... You may use
properties > details to verify if the same is true for chap4.ps

After replacing the cygwin1.dll with the latest version, the file "reappeared"
again to ls.

Please, report back here (using BOTTOM-posting - as I do here).

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



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

Advice needed on ffcall packaging

2018-02-20 Thread Ken Brown 
A few years ago I adopted ffcall (32-bit only) in order to keep it from 
disappearing from the distro:


  https://sourceware.org/ml/cygwin-apps/2015-07/msg00092.html

The latest upstream release builds on 64-bit Cygwin, so I'd like to 
update the package, and I'd like to find a sensible way of breaking it 
up into subpackages.  Here are the relevant facts:


1. Cygwin's existing (32-bit) ffcall is really a devel package: It 
consists of headers, four (static) libs, and documentation.  There are 
no subpackages and no shared libs.  The static libs are


  usr/lib/libavcall.a
  usr/lib/libcallback.a
  usr/lib/libtrampoline.a
  usr/lib/libvacall.a

2. The build of the current release produces the same four static libs, 
plus shared versions of the first three, plus a new lib, both static and 
shared (libffcall.a and cygffcall-0.dll).


If I were starting from scratch, I would have three packages: ffcall, 
libffcall0, and libffcall-devel.  ffcall would be source only; 
libffcall0 would contain the shared libs *.dll; and libffcall-devel 
would contain the headers, the import libs *.dll.a, and the one static 
lib for which there is no shared version.  I wouldn't ship the other 
static libs unless I discover later that they're needed for some reason.


But I'm not starting from scratch, and users of the existing ffcall will 
need the new libffcall-devel.  I can think of two possibilities for 
handling this:


A) Pretend that I'm starting from scratch, and deal with the fallout. 
There probably won't be any, since ffcall is not currently required by 
any other package.  As far as I know, its only use is that it's a build 
requirement for clisp, which I maintain.


B) Make three packages as above, with the source-only package being 
called libffcall instead of ffcall.  (libffcall is the upstream name 
anyway.)  I could then make libffcall-devel obsolete ffcall.


For the record, here's what Fedora does: Until a few months ago, there 
was only one package, ffcall, which contained everything.  At that time 
they created two subpackages, ffcall-devel and ffcall-static. 
ffcall-devel corresponds to my proposed libffcall-devel; ffcall-static 
contains all the static libs; and plain ffcall more-or-less corresponds 
to my proposed libffcall0.  This doesn't make a lot of sense to me.


Maybe this is much ado about nothing, but I'd appreciate advice.

Ken

[ANNOUNCEMENT] Updated: Git v2.16.2-1

2018-02-20 Thread Adam Dinwoodie 
Version 2.16.2-1 of Git has been uploaded and should be coming soon to a
mirror near you. This update includes the following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

This is an update to the latest upstream release.

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/gitster/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

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

Updated: Git v2.16.2-1

2018-02-20 Thread Adam Dinwoodie 
Version 2.16.2-1 of Git has been uploaded and should be coming soon to a
mirror near you. This update includes the following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

This is an update to the latest upstream release.

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/gitster/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

Re: Regression in latest snapshot (x86 arch)?

2018-02-20 Thread Corinna Vinschen 
On Feb 20 15:24, Houder wrote:
> On 2018-02-20 12:25, Houder wrote:
> > L.S.,
> > 
> > As far as I can tell, the latest snapshot (2018-02-16) has a problem in
> > case
> > of the x86 arch.
> 
> @@ uname -a
> CYGWIN_NT-6.1-WOW Seven 2.10.1(0.325/5/3)  i686 Cygwin
> @@ strings /usr/bin/cygwin1.dll | grep -m1 -E
> '/vinschen/|/corinna/|/cygheap\.cc'
> /ext/build/mknetrel/src/cygwin-snapshot-20180220-1/winsup/cygwin/cygheap.cc
> 
> 
> @@ touch aap
> @@ stat aap
>   File: aap
>   Size: 0   Blocks: 0  IO Block: 65536  regular empty
> file
> Device: 33d91880h/869865600dInode: 14355223812272521  Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/   Henri)   Gid: (  513/None)
> Access: 2018-02-20 15:20:50.817305500 +0100
> Modify: 2018-02-20 15:20:50.817305500 +0100
> Change: 2018-02-20 15:20:50.817305500 +0100
>  Birth: 2018-02-20 15:19:08.949126600 +0100
> @@ cp -p .bashrc noot
> @@ stat noot
>   File: noot
>   Size: 8309Blocks: 12 IO Block: 65536  regular file
> Device: 33d91880h/869865600dInode: 9007199254770065  Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   Henri)   Gid: (  513/None)
> Access: 2018-01-24 15:27:52.646229400 +0100
> Modify: 2018-01-24 15:27:52.646229400 +0100
> Change: 2018-02-20 15:21:04.217729000 +0100
>  Birth: 2018-02-20 15:21:04.217729000 +0100
> 
> Corinna, thank you!

You're welcome, but please give me at least the time to announce the new
snapshot ;)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Regression in latest snapshot (x86 arch)?

2018-02-20 Thread Corinna Vinschen 
On Feb 20 12:25, Houder wrote:
> L.S.,
> 
> As far as I can tell, the latest snapshot (2018-02-16) has a problem in case
> of the x86 arch.
> 
> I noticed it when I applied "cp -p" to cygwin1.dll
> 
> @@ stat cygwin1.dll
>   File: cygwin1.dll
>   Size: 3003413 Blocks: 2936   IO Block: 65536  regular file
> Device: 33d91880h/869865600dInode: 15762598695825794  Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   Henri)   Gid: (  513/None)
> Access: 1970-01-01 01:01:39.427244800 +0100
> Modify: 1970-01-01 01:00:54.998366800 +0100
> Change: 2018-02-20 11:41:41.747593600 +0100
>  Birth: 2018-02-20 10:49:55.031336800 +0100

Thanks for the info.  I applied a fix and uploaded new developer
snapshots to https://cygwin.com/snapshots/  Please try.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Regression in latest snapshot (x86 arch)?

2018-02-20 Thread Houder 

On 2018-02-20 12:25, Houder wrote:

L.S.,

As far as I can tell, the latest snapshot (2018-02-16) has a problem in 
case

of the x86 arch.


@@ uname -a
CYGWIN_NT-6.1-WOW Seven 2.10.1(0.325/5/3)  i686 Cygwin
@@ strings /usr/bin/cygwin1.dll | grep -m1 -E 
'/vinschen/|/corinna/|/cygheap\.cc'

/ext/build/mknetrel/src/cygwin-snapshot-20180220-1/winsup/cygwin/cygheap.cc


@@ touch aap
@@ stat aap
  File: aap
  Size: 0   Blocks: 0  IO Block: 65536  regular 
empty file

Device: 33d91880h/869865600dInode: 14355223812272521  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   Henri)   Gid: (  513/None)
Access: 2018-02-20 15:20:50.817305500 +0100
Modify: 2018-02-20 15:20:50.817305500 +0100
Change: 2018-02-20 15:20:50.817305500 +0100
 Birth: 2018-02-20 15:19:08.949126600 +0100
@@ cp -p .bashrc noot
@@ stat noot
  File: noot
  Size: 8309Blocks: 12 IO Block: 65536  regular file
Device: 33d91880h/869865600dInode: 9007199254770065  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   Henri)   Gid: (  513/None)
Access: 2018-01-24 15:27:52.646229400 +0100
Modify: 2018-01-24 15:27:52.646229400 +0100
Change: 2018-02-20 15:21:04.217729000 +0100
 Birth: 2018-02-20 15:21:04.217729000 +0100

Corinna, 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

[newlib-cygwin] Cygwin: Make sure fraction of seconds constants enforce 64 bit computation

2018-02-20 Thread Corinna Vinschen 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=0a3f4e6087e0e44fd36ca2d88f619fae2dfaa02c

commit 0a3f4e6087e0e44fd36ca2d88f619fae2dfaa02c
Author: Corinna Vinschen 
Date:   Tue Feb 20 15:05:23 2018 +0100

Cygwin: Make sure fraction of seconds constants enforce 64 bit computation

Dropping the 'LL' specifier leads to 32 bit truncation during timestamp
computation.  Revert it.  Exempt MSPERSEC which is used for 32 bit values.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/hires.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/hires.h b/winsup/cygwin/hires.h
index a28efcd..5c75cf6 100644
--- a/winsup/cygwin/hires.h
+++ b/winsup/cygwin/hires.h
@@ -30,13 +30,13 @@ details. */
 /* 100ns difference between Windows and UNIX timebase. */
 #define FACTOR (0x19db1ded53e8000LL)
 /* # of nanosecs per second. */
-#define NSPERSEC (10)
+#define NSPERSEC (10LL)
 /* # of 100ns intervals per second. */
-#define NS100PERSEC (1000)
+#define NS100PERSEC (1000LL)
 /* # of microsecs per second. */
-#define USPERSEC (100)
+#define USPERSEC (100LL)
 /* # of millisecs per second. */
-#define MSPERSEC (1000)
+#define MSPERSEC (1000L)
 
 class hires_base
 {

Updated: setup (2.888)

2018-02-20 Thread Jon Turney 


A new version of Setup, release 2.888, has been uploaded to

  https://cygwin.com/setup-x86.exe (32 bit version)
  https://cygwin.com/setup-x86_64.exe  (64 bit version)

Changes compared to 2.884:

User visible changes:
- In the package chooser, 'Current' is replaced by 'Best' (to more 
accurately summarize what it does)
- Add 'Sync' as a choice, (which sets all packages to the version 
available from the package repository, downgrading if necessary, 
equivalent to the existing --force-current command line option).
- These are modified by a 'Test' check-box, which allows test packages 
to be used.
- The "prereq" page showing dependencies which will be added is replaced 
by "problems" page showing problems found by the dependency solver, with 
default solutions.

- A "confirm" page is added showing all the changes which will be made.

Internal changes:
- Uses the libsolv dependency solver, rather than a home-made one.
- Add support for 'depends2: package (relation version) [...]', in a 
version section in setup.ini

- Add support for 'obsoletes:' in setup.ini, likewise
- Add support for 'replace-versions:' in a package section setup.ini, to 
indicate problematic versions.


Other:
- Query the user for action to take if a corrupt local file is found
- Validate package hash after download
- Any MessageBox shown during setup.ini parsing is now modal

A big 'thank you' to Ken Brown for all his work on this.

Please send bug reports, as usual, to the public mailing list cygwin AT
cygwin DOT com.

[ANNOUNCEMENT] Updated: setup (2.888)

2018-02-20 Thread Jon Turney 


A new version of Setup, release 2.888, has been uploaded to

  https://cygwin.com/setup-x86.exe (32 bit version)
  https://cygwin.com/setup-x86_64.exe  (64 bit version)

Changes compared to 2.884:

User visible changes:
- In the package chooser, 'Current' is replaced by 'Best' (to more 
accurately summarize what it does)
- Add 'Sync' as a choice, (which sets all packages to the version 
available from the package repository, downgrading if necessary, 
equivalent to the existing --force-current command line option).
- These are modified by a 'Test' check-box, which allows test packages 
to be used.
- The "prereq" page showing dependencies which will be added is replaced 
by "problems" page showing problems found by the dependency solver, with 
default solutions.

- A "confirm" page is added showing all the changes which will be made.

Internal changes:
- Uses the libsolv dependency solver, rather than a home-made one.
- Add support for 'depends2: package (relation version) [...]', in a 
version section in setup.ini

- Add support for 'obsoletes:' in setup.ini, likewise
- Add support for 'replace-versions:' in a package section setup.ini, to 
indicate problematic versions.


Other:
- Query the user for action to take if a corrupt local file is found
- Validate package hash after download
- Any MessageBox shown during setup.ini parsing is now modal

A big 'thank you' to Ken Brown for all his work on this.

Please send bug reports, as usual, to the public mailing list cygwin AT
cygwin DOT com.

--
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 2.887 release candidate - please test

2018-02-20 Thread Jon Turney 

On 07/02/2018 11:51, Jon Turney wrote:

On 07/02/2018 11:38, David Balažic wrote:

On 7 February 2018 at 01:49, Steven Penny wrote:

On Tue, 6 Feb 2018 15:04:49, Jon Turney wrote:
- 'Current' is replaced by 'Best' (which is slightly different in ways

it's difficult to summarize briefly) and 'Sync' (which exposes the
--force-current (distupgrade) option through the UI).


i get the desire for one word labels - but im not sure how good
"sync" is. its not clear in the GUI what it does, and frankly, even
reading your description doesnt clear up for me what it does. i
guess i would need to run "--help" and see what "--force-current"
does to figure it out. that just seems like more work than it
should be.

This could be improved by having a tooltip on the GUI item, 
explaining in a sentence or two, what it does.


There already is a tooltip:

"Sets all packages to the version available from the package 
respository, downgrading if necessary."


For the record, the changes in 2.888 are to fix a typo in this tooltip, 
and to avoid a crash when installing a source package.


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

Regression in latest snapshot (x86 arch)?

2018-02-20 Thread Houder 

L.S.,

As far as I can tell, the latest snapshot (2018-02-16) has a problem in 
case

of the x86 arch.

I noticed it when I applied "cp -p" to cygwin1.dll

@@ stat cygwin1.dll
  File: cygwin1.dll
  Size: 3003413 Blocks: 2936   IO Block: 65536  regular file
Device: 33d91880h/869865600dInode: 15762598695825794  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   Henri)   Gid: (  513/None)
Access: 1970-01-01 01:01:39.427244800 +0100
Modify: 1970-01-01 01:00:54.998366800 +0100
Change: 2018-02-20 11:41:41.747593600 +0100
 Birth: 2018-02-20 10:49:55.031336800 +0100

For some reason 'access time' and 'modify time' default to 1970-01-01. I 
do

not notice this for the x86_64 arch.

Anybody NOT experiencing this "regression?"

Henri

@@ uname -a
CYGWIN_NT-6.1-WOW Seven 2.10.1(0.325/5/3)  i686 Cygwin
@@ strings /usr/bin/cygwin1.dll | grep -m1 -E 
'/vinschen/|/corinna/|/cygheap\.cc'

/ext/build/mknetrel/src/cygwin-snapshot-20180216-1/winsup/cygwin/cygheap.cc

@@ pwd
/home/Henri
@@ rm aap noot
@@ touch aap
@@ stat aap
  File: aap
  Size: 0   Blocks: 0  IO Block: 65536  regular 
empty file

Device: 33d91880h/869865600dInode: 5629499534242193  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   Henri)   Gid: (  513/None)
Access: 1970-01-01 00:58:52.-659927900 +0100
Modify: 1970-01-01 00:58:52.-659927900 +0100
Change: 2018-02-20 12:19:28.967976100 +0100
 Birth: 2018-02-20 12:19:28.967976100 +0100

@@ cp -p .bashrc noot
@@ stat noot
  File: noot
  Size: 8309Blocks: 12 IO Block: 65536  regular file
Device: 33d91880h/869865600dInode: 20829148276589133  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   Henri)   Gid: (  513/None)
Access: 1970-01-01 00:57:45.-158186600 +0100
Modify: 1970-01-01 00:57:45.-158186600 +0100
Change: 2018-02-20 12:01:52.670520600 +0100
 Birth: 2017-05-24 19:42:17.311494900 +0200

@@ stat .bashrc
  File: .bashrc
  Size: 8309Blocks: 12 IO Block: 65536  regular file
Device: 33d91880h/869865600dInode: 37717646879229026  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   Henri)   Gid: (  513/None)
Access: 2018-01-24 15:27:52.646229400 +0100
Modify: 2018-01-24 15:27:52.646229400 +0100
Change: 2018-01-24 15:27:52.677429500 +0100
 Birth: 2016-07-19 14:31:42.953010600 +0200

=

--
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: Atomic mmap replacement

2018-02-20 Thread Corinna Vinschen 
On Feb 19 20:03, John Hood wrote:
> 
> 
> On 02/19/2018 12:19, Corinna Vinschen wrote:
> > On second thought, we *could* do this, if the pages have been mmapped
> > before(*).  Unfortunately this would require a *major* revamp of the
> > page handling in mmap.  We would have to keep the mapping of every
> > single 64K page separate.
> > 
> > I.e., requesting a file mapping of 256K at offset 0 on the POSIX level
> > would have to be handled as four Windows file mappings under the hood:
> > 
> > 1. a 64K file mapping at offset 0
> > 2. a 64K file mapping at offset 65536
> > 3. a 64K file mapping at offset 131072
> > 4. a 64K file mapping at offset 196608
> > 
> > A request to mmap another 64K page to the third mapping in this example
> > could then be done by unmapping the third mapping and replace it with
> > the requested mapping.
> > 
> > I'm not sure this is feasible.  It would complicate and slow down the
> > code especially for big mappings; one call to NtCreateSection and one to
> > NtMapViewOfSection per 64K page, plus the overhead of making sure that
> > all mappings are in the right, sequential order in memory.  Plus the
> > overhead of having to remap a lot more mappings in forked children.  The
> > "Cygwin is slow" meme would get another interesting facet :}
> > 
> I work on an app that does something like this (but for other reasons, and
> it'll never be ported to Cygwin).
> 
> I'm also dubious, but I'll point out that it'd probably be reasonable to do
> this only on regions that are mapped PROT_NONE initially, other regions
> could work as they do now.

As far as I'm concerned, the problem is that we collect special cases
which raise the number of lines of code, getting more complicated and
less well debuggable, but still only work in some cases.

Assuming we'd do this at all, doing this per page *all* the time would
certainly lead to simpler code.  The big change affects the bookkeeping
code in the first place.  Right now we have a list of files (anonympous
mappings are one file) with a list of mappings per file attached.  In
theory, to support scenarios like this, the bookkeeping structure should
be changed to a hash or list of per-page structs.  So we would look at
maps starting at the page address, rather than starting at the file
descriptor the map is attached to.

I'm not opposed to change Cygwin's mmap this way, but it's a lt of
work and there's so much to do in so limited a time...

If somebody would like to take a stab at this, I'd be pretty excited.
Fortunately the mmap code is collected in a single source file
winsup/cygwin/mmap.cc, so you only need limited insight in the Cygwin
code.  Help from my side is guaranteed.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Atomic mmap replacement

2018-02-20 Thread Corinna Vinschen 
On Feb 19 17:33, Ken Brown wrote:
> On 2/19/2018 12:19 PM, Corinna Vinschen wrote:
> In the meantime, the problem was solved on the emacs side by doing what you
> suggested in your previous email:
> 
> > - unmap the old mapping
> > - remap the unaffected parts as separate anonymous mapping
> > - map the affected parts for the requested file mapping
> 
> But in the emacs application it's simpler, because there are no unaffected
> parts, so step 2 can be skipped.

Thanks, that's obviously the simpler approach :)

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature