Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

[Marco Atzeri]

On 11/05/2016 00:11, Yaakov Selkowitz wrote:

Package Maintainers,

cygport 0.22.0 is on its way to the mirrors.  With this release, and
thanks to Jon Turney's continuing work on calm (the replacement for
upset which generates setup.ini), packages marked ARCH=noarch will be
uploaded once under the /noarch/release hierarchy instead of into each
of /x86/release and /x86_64/release.  This change is intended to save
disk space and bandwidth for both sourceware and our mirrors.

A package should be marked ARCH=noarch IF AND ONLY IF *all* subpackages
thereof do not contain anything compiled with the *native* gcc, and the
file contents are (or can be) 100% identical for x86 and x86_64.
Examples include, but are not limited to, packages which contain only:






Please do not hesitate to ask if you have any questions.

TIA,


So at this stage not the documentation subpackages, but only if all
subpackages are in this category. correct ?

Not so sure if this case fit in your request;
all the language files for tesseract

tesseract-ocr-deu
tesseract-ocr-eng
tesseract-ocr-fra
tesseract-ocr-ita
tesseract-ocr-nld
tesseract-ocr-por
tesseract-ocr-spa
tesseract-ocr-vie
tesseract-training-core
tesseract-training-deu
tesseract-training-eng
tesseract-training-fra
tesseract-training-ita
tesseract-training-nld
tesseract-training-por
tesseract-training-spa
tesseract-training-vie

that are in the same tree of tesseract-ocr but
they have independent minimalist setup.hint hand made.

eg: tesseract-training-eng

$ cat setup.hint
sdesc: "English language files for training tesseract-ocr"
category: Text
requires: tesseract-training-util

Re: [ITP] python-configobj 5.0.6 (4.7.2 is in Cygwin Ports)

[Mike DePaulo]

Feedback?

On Fri, May 6, 2016 at 9:15 AM, Mike DePaulo  wrote:
> This package is currently in Cygwin Ports at version 4.7.2-2, as well
> as in major distros like Fedora & Debian.
>
> The 5.0.x series has a new upstream. They also removed the PKG-INFO file.
>
> It is a dependency of package terminator, which is currently in an ITP
> state from Cygwin Ports also.
>
> https://github.com/mikedep333/python-configobj-cygport
> 
> category: Python
> requires: python python-six
> sdesc: "Python module for handling config files"
> ldesc: "ConfigObj is a simple but powerful config file reader and writer:
> an ini file round tripper. Its main feature is that it is very easy to use,
> with a straightforward programmer's interface and a simple syntax for config
> files."

cygport 0.22.0-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* cygport-0.22.0-1

cygport is the standard method for building and maintaining packages for 
the Cygwin distribution.

ATTENTION MAINTAINERS: please see the following important message regarding
ARCH=noarch packages with this release:

https://cygwin.com/ml/cygwin-apps/2016-05/msg00024.html


Jon Turney (2):
  pkg_pkg: avoid having cygwin-debuginfo requires: itself
  Propagate exit status

Ken Brown (4):
  prep_texlive: drop preparation for fc-cache calls
  texlive: update for tlmgr
  texlive: include collection .tlpobj for tlmgr
  texlive: trigger running of mktexlsr after package removal

Yaakov Selkowitz (7):
  Update DESCRIPTION
  autotools: really do not assume presence of autopoint
  postinst: use perpetual postinstalls for icon theme caches
  postinst: accept RESTRICT=postinst-info
  upload: support single noarch directory
  Update gnuconfig
  Bump version to 0.22.0

[ANNOUNCEMENT] cygport 0.22.0-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* cygport-0.22.0-1

cygport is the standard method for building and maintaining packages for 
the Cygwin distribution.

ATTENTION MAINTAINERS: please see the following important message regarding
ARCH=noarch packages with this release:

https://cygwin.com/ml/cygwin-apps/2016-05/msg00024.html


Jon Turney (2):
  pkg_pkg: avoid having cygwin-debuginfo requires: itself
  Propagate exit status

Ken Brown (4):
  prep_texlive: drop preparation for fc-cache calls
  texlive: update for tlmgr
  texlive: include collection .tlpobj for tlmgr
  texlive: trigger running of mktexlsr after package removal

Yaakov Selkowitz (7):
  Update DESCRIPTION
  autotools: really do not assume presence of autopoint
  postinst: use perpetual postinstalls for icon theme caches
  postinst: accept RESTRICT=postinst-info
  upload: support single noarch directory
  Update gnuconfig
  Bump version to 0.22.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

[ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

[Yaakov Selkowitz]

Package Maintainers,

cygport 0.22.0 is on its way to the mirrors.  With this release, and 
thanks to Jon Turney's continuing work on calm (the replacement for 
upset which generates setup.ini), packages marked ARCH=noarch will be 
uploaded once under the /noarch/release hierarchy instead of into each 
of /x86/release and /x86_64/release.  This change is intended to save 
disk space and bandwidth for both sourceware and our mirrors.


A package should be marked ARCH=noarch IF AND ONLY IF *all* subpackages 
thereof do not contain anything compiled with the *native* gcc, and the 
file contents are (or can be) 100% identical for x86 and x86_64. 
Examples include, but are not limited to, packages which contain only:


* documentation;
* scripts;
* fonts;
* icon themes;
* other runtime data;
* C/C++ headers without a library;
* libraries for cross-compiler toolchains.
* pure Lua/Perl/Python/Ruby/Tcl modules without C/C++ bindings.

Once you have upgraded to cygport 0.22.0, maintainers MUST email a list 
of their package(s) which qualify as noarch AND are already marked 
ARCH=noarch or will be with the next release.  (Note that inheriting 
cross.cygclass implies ARCH=noarch.)  A new release is NOT necessary 
just to add ARCH=noarch to the .cygport, just that it should be added 
locally so as to be included in the next release.  We will then move 
these packages into /noarch/release on sourceware and acknowledge such, 
at which point you are clear to upload future releases.


Please do not hesitate to ask if you have any questions.

TIA,
--
Yaakov

mesa 11.2.2-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* mesa-11.2.2-1
* dri-drivers-11.2.2-1
* libglapi0-11.2.2-1
* libGL1-11.2.2-1
* libGL-devel-11.2.2-1
* libOSMesa8-11.2.2-1
* libOSMesa-devel-11.2.2-1
* libEGL1-11.2.2-1
* libEGL-devel-11.2.2-1
* libGLESv2_2-11.2.2-1
* libGLESv2-devel-11.2.2-1
* windowsdriproto-11.2.2-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 upstream release:

http://mesa3d.org/relnotes/11.2.2.html

--
Yaakov

[ANNOUNCEMENT] mesa 11.2.2-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* mesa-11.2.2-1
* dri-drivers-11.2.2-1
* libglapi0-11.2.2-1
* libGL1-11.2.2-1
* libGL-devel-11.2.2-1
* libOSMesa8-11.2.2-1
* libOSMesa-devel-11.2.2-1
* libEGL1-11.2.2-1
* libEGL-devel-11.2.2-1
* libGLESv2_2-11.2.2-1
* libGLESv2-devel-11.2.2-1
* windowsdriproto-11.2.2-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 upstream release:

http://mesa3d.org/relnotes/11.2.2.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

[ANNOUNCEMENT] s2tc 1.0-1.20151227gitf6ec862

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* s2tc-1.0-1.20151227gitf6ec862
* libtxc_dxtn-1.0-1.20151227gitf6ec862
* libtxc_dxtn-devel-1.0-1.20151227gitf6ec862

S2TC (Super Simple Texture Compression) is a patent-free texture 
compression algorithm designed to be compatible with existing S3TC 
decompressors. Also included is a libtxc_dxtn replacement that uses S2TC to 
compress and decompress textures, which can be directly used by Mesa/DRI.

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

s2tc 1.0-1.20151227gitf6ec862

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* s2tc-1.0-1.20151227gitf6ec862
* libtxc_dxtn-1.0-1.20151227gitf6ec862
* libtxc_dxtn-devel-1.0-1.20151227gitf6ec862

S2TC (Super Simple Texture Compression) is a patent-free texture 
compression algorithm designed to be compatible with existing S3TC 
decompressors. Also included is a libtxc_dxtn replacement that uses S2TC to 
compress and decompress textures, which can be directly used by Mesa/DRI.

--
Yaakov

[ANNOUNCEMENT] nfs-server 2.3-6

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* nfs-server-2.3-6

This project is a true NFS version 2 server implementation, with all 
functionality occurring in user-space.  Note that this protocol version is 
deprecated and support thereof has been removed from some recent systems 
(e.g. RHEL 7 and current Fedora releases).

This release has been ported to libtirpc and is built for the first time 
for x86_64.  The service installation script has been updated for rpcbind 
in place of the deprecated portmap (sunrpc, x86 only).

--
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] unfs3 0.9.22-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* unfs3-0.9.22-1

UNFS3 is a user-space implementation of the NFS version 3 server 
specification. It provides a daemon for the MOUNT and NFS protocols, which 
are used by NFS clients for accessing files on the server.

This is an initial release for a protocol version which is still supported 
by modern systems.

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

nfs-server 2.3-6

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* nfs-server-2.3-6

This project is a true NFS version 2 server implementation, with all 
functionality occurring in user-space.  Note that this protocol version is 
deprecated and support thereof has been removed from some recent systems 
(e.g. RHEL 7 and current Fedora releases).

This release has been ported to libtirpc and is built for the first time 
for x86_64.  The service installation script has been updated for rpcbind 
in place of the deprecated portmap (sunrpc, x86 only).

--
Yaakov

unfs3 0.9.22-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* unfs3-0.9.22-1

UNFS3 is a user-space implementation of the NFS version 3 server 
specification. It provides a daemon for the MOUNT and NFS protocols, which 
are used by NFS clients for accessing files on the server.

This is an initial release for a protocol version which is still supported 
by modern systems.

--
Yaakov

[ANNOUNCEMENT] w3m 0.5.3-3

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* w3m-0.5.3-3

w3m is a text-based web browser as well as a pager like 'more' or 'less'. 
With w3m you can browse web pages through a terminal emulator window 
(xterm, rxvt, etc.). Moreover, w3m can be used as a text formatting tool 
which typesets HTML into plain text.

This release adds the latest patchset from Fedora.

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

w3m 0.5.3-3

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* w3m-0.5.3-3

w3m is a text-based web browser as well as a pager like 'more' or 'less'. 
With w3m you can browse web pages through a terminal emulator window 
(xterm, rxvt, etc.). Moreover, w3m can be used as a text formatting tool 
which typesets HTML into plain text.

This release adds the latest patchset from Fedora.

--
Yaakov

iso-codes 3.68-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* iso-codes-3.68-1
* iso-codes-devel-3.68-1

This package aims to provide the list of the ISO country, language,
and currency names and their translations in one place.

This is an update to the latest upstream release:

http://anonscm.debian.org/cgit/pkg-isocodes/iso-codes.git/tree/ChangeLog

--
Yaakov

[ANNOUNCEMENT] iso-codes 3.68-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* iso-codes-3.68-1
* iso-codes-devel-3.68-1

This package aims to provide the list of the ISO country, language,
and currency names and their translations in one place.

This is an update to the latest upstream release:

http://anonscm.debian.org/cgit/pkg-isocodes/iso-codes.git/tree/ChangeLog

--
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] dblatex 0.3.7-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* dblatex-0.3.7-1

dblatex is a program that transforms your SGML/XML DocBook documents to 
DVI, PostScript or PDF by translating them into pure LaTeX as a first 
process.  MathML 2.0 markups are supported, too.

This is an update to the latest upstream release:

https://sourceforge.net/projects/dblatex/files/dblatex/dblatex-0.3.5/
https://sourceforge.net/projects/dblatex/files/dblatex/dblatex-0.3.6/
https://sourceforge.net/projects/dblatex/files/dblatex/dblatex-0.3.7/

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

dblatex 0.3.7-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* dblatex-0.3.7-1

dblatex is a program that transforms your SGML/XML DocBook documents to 
DVI, PostScript or PDF by translating them into pure LaTeX as a first 
process.  MathML 2.0 markups are supported, too.

This is an update to the latest upstream release:

https://sourceforge.net/projects/dblatex/files/dblatex/dblatex-0.3.5/
https://sourceforge.net/projects/dblatex/files/dblatex/dblatex-0.3.6/
https://sourceforge.net/projects/dblatex/files/dblatex/dblatex-0.3.7/

--
Yaakov

[ANNOUNCEMENT] dateutils 0.3.5-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* dateutils-0.3.5-1

Dateutils are a bunch of tools that revolve around fiddling with dates and 
times in the command line with a strong focus on use cases that arise when 
dealing with large amounts of financial data.

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

dateutils 0.3.5-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* dateutils-0.3.5-1

Dateutils are a bunch of tools that revolve around fiddling with dates and 
times in the command line with a strong focus on use cases that arise when 
dealing with large amounts of financial data.

--
Yaakov

[ANNOUNCEMENT] datefudge 1.21-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* datefudge-1.21-1

This program (and preload library) fakes the system date so that programs 
think the wall clock is ... different. The faking is not complete; 
timestamp on files are not affected in any way. This package is useful if 
you want to test the date handling of your programs without changing the 
system clock.

This is an update to the latest upstream 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

[ANNOUNCEMENT] python-dbus 1.2.4-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* python-dbus-1.2.4-1
* python-dbus-devel-1.2.4-1
* python3-dbus-1.2.4-1

D-Bus is a message bus system, a simple way for applications to talk to one 
another.  D-Bus supplies both a system daemon (for events such as 'new 
hardware device added' or 'printer queue changed') and a per-login-session 
daemon (for general IPC needs among user applications). Also, the message 
bus is built on top of a general one-to-one message passing framework, 
which can be used by any two apps to communicate directly (without going 
through the message bus daemon).

This is an update to the latest release of the Python bindings:

https://lists.freedesktop.org/archives/dbus/2016-February/016851.html
https://lists.freedesktop.org/archives/dbus/2016-March/016852.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

[ANNOUNCEMENT] dbus-glib 0.106-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* libdbus-glib_1_2-0.106-1
* libdbus-glib_1-devel-0.106-1
* dbus-bash-completion-0.106-1
* mingw64-i686-dbus-glib-0.106-1
* mingw64-x86_64-dbus-glib-0.106-1

D-Bus is a message bus system, a simple way for applications to talk to one 
another. D-Bus supplies both a system daemon (for events such as 'new 
hardware device added' or 'printer queue changed') and a 
per-user-login-session daemon (for general IPC needs among user 
applications). Also, the message bus is built on top of a general 
one-to-one message passing framework, which can be used by any two apps to 
communicate directly (without going through the message bus daemon).

This is an update to the latest upstream release:

https://lists.freedesktop.org/archives/dbus/2016-January/016846.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

[ANNOUNCEMENT] dbus 1.10.8-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* dbus-1.10.8-1
* dbus-doc-1.10.8-1
* dbus-x11-1.10.8-1
* libdbus1_3-1.10.8-1
* libdbus1-devel-1.10.8-1
* mingw64-i686-dbus-1.10.8-1
* mingw64-x86_64-dbus-1.10.8-1

D-BUS is a message bus system, a simple way for applications to talk to one 
another.  D-BUS supplies both a system daemon (for events such as 'new 
hardware device added' or 'printer queue changed') and a per-login-session 
daemon (for general IPC needs among user applications). Also, the message 
bus is built on top of a general one-to-one message passing framework, 
which can be used by any two apps to communicate directly (without going 
through the message bus daemon).

This is an update to the latest upstream release branch:

https://lists.freedesktop.org/archives/dbus/2015-August/016769.html
https://lists.freedesktop.org/archives/dbus/2015-October/016827.html
https://lists.freedesktop.org/archives/dbus/2015-November/016828.html
https://lists.freedesktop.org/archives/dbus/2015-December/016831.html
https://lists.freedesktop.org/archives/dbus/2016-March/016853.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

dbus 1.10.8-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* dbus-1.10.8-1
* dbus-doc-1.10.8-1
* dbus-x11-1.10.8-1
* libdbus1_3-1.10.8-1
* libdbus1-devel-1.10.8-1
* mingw64-i686-dbus-1.10.8-1
* mingw64-x86_64-dbus-1.10.8-1

D-BUS is a message bus system, a simple way for applications to talk to one 
another.  D-BUS supplies both a system daemon (for events such as 'new 
hardware device added' or 'printer queue changed') and a per-login-session 
daemon (for general IPC needs among user applications). Also, the message 
bus is built on top of a general one-to-one message passing framework, 
which can be used by any two apps to communicate directly (without going 
through the message bus daemon).

This is an update to the latest upstream release branch:

https://lists.freedesktop.org/archives/dbus/2015-August/016769.html
https://lists.freedesktop.org/archives/dbus/2015-October/016827.html
https://lists.freedesktop.org/archives/dbus/2015-November/016828.html
https://lists.freedesktop.org/archives/dbus/2015-December/016831.html
https://lists.freedesktop.org/archives/dbus/2016-March/016853.html

--
Yaakov

byacc 20160324-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* byacc-20160324-1

Berkeley Yacc is an LALR(1) parser generator.  Berkeley Yacc has been made 
as compatible as possible with AT Yacc.  Berkeley Yacc can accept any 
input specification that conforms to the AT Yacc documentation.

This is an update to the latest upstream release.

--
Yaakov

[ANNOUNCEMENT] byacc 20160324-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* byacc-20160324-1

Berkeley Yacc is an LALR(1) parser generator.  Berkeley Yacc has been made 
as compatible as possible with AT Yacc.  Berkeley Yacc can accept any 
input specification that conforms to the AT Yacc documentation.

This is an update to the latest upstream 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

[ANNOUNCEMENT] autoconf-archive 2016.03.20-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* autoconf-archive-2016.03.20-1

The GNU Autoconf Archive is a collection of more than 450 macros for GNU 
Autoconf that have been contributed as free software by friendly supporters 
of the cause from all over the Internet.

This is an update to the latest upstream 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

[ANNOUNCEMENT] ascii 3.15-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* ascii-3.15-1

The ascii utility provides easy conversion between various byte 
representations and the ASCII character table. It knows about a wide 
variety of hex, binary, octal, Teletype mnemonic, ISO/ECMA code point, 
slang names, XML entity names, and other representations. Given any one on 
the command line, it will try to display all others. Called with no 
arguments it displays a handy small ASCII chart.

This is an update to the latest upstream 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

autoconf-archive 2016.03.20-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* autoconf-archive-2016.03.20-1

The GNU Autoconf Archive is a collection of more than 450 macros for GNU 
Autoconf that have been contributed as free software by friendly supporters 
of the cause from all over the Internet.

This is an update to the latest upstream release.

--
Yaakov

ascii 3.15-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* ascii-3.15-1

The ascii utility provides easy conversion between various byte 
representations and the ASCII character table. It knows about a wide 
variety of hex, binary, octal, Teletype mnemonic, ISO/ECMA code point, 
slang names, XML entity names, and other representations. Given any one on 
the command line, it will try to display all others. Called with no 
arguments it displays a handy small ASCII chart.

This is an update to the latest upstream release.

--
Yaakov

aria2 1.22.0-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* aria2-1.22.0-1

aria2 is a lightweight multi-protocol & multi-source, cross platform 
download utility operated in command-line. It supports HTTP/HTTPS, FTP, 
BitTorrent and Metalink. You can manipulate aria2 via XML-RPC interface.

This is an update to the latest upstream release.

--
Yaakov

[ANNOUNCEMENT] aria2 1.22.0-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* aria2-1.22.0-1

aria2 is a lightweight multi-protocol & multi-source, cross platform 
download utility operated in command-line. It supports HTTP/HTTPS, FTP, 
BitTorrent and Metalink. You can manipulate aria2 via XML-RPC interface.

This is an update to the latest upstream 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

add fish to /etc/shells (base-files)

[Andrew Schulman]

Achim, can you please add /bin/fish and /usr/bin/fish to /etc/shells in
base-files?

Thank you,
Andrew


--
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: Formatting command line arguments when starting a Cygwin process from a native process

[David Allsopp]

Aaron Digulla wrote:
> David Allsopp wrote:
> > Aaron Digulla wrote:
> > >
> > > Am Samstag, 07. Mai 2016 09:45 CEST, "David Allsopp"
> > > schrieb:
> > >
> > >
> > > > > Then all you need is a rudimentary quoting.
> > > >
> > > > Yes, but the question still remains what that rudimentary quoting
> > > > is -
> > > i.e.
> > > > I can see how to quote spaces which appear in elements of argv,
> > > > but I cannot see how to quote double quotes!
> > >
> > > This should help:
> > > https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/0
> > > 4/23/e veryone-quotes-command-line-arguments-the-wrong-way/
> >
> > This provides documentation for how Microsoft implementations do it, not
> how Cygwin does it. The Cygwin DLL is responsible for determining how a
> Cygwin process gets argc and argv from GetCommandLineW.
> 
> That's correct but I read your question as "how do I start executables
> linked against Cygwin from another Windows process"

That's the correct reading of my question!

> To do that, you need to convert the argument list/array into the stupid
> Windows format because that's what the Cygwin process will expect.

This is not correct - both by reading the code and by testing. If you put this 
into the program caller.c I posted previously in thread which is intended to 
start with argv[1] being the literal string a\\b (i.e. 4 characters)

commandLine = "callee \"ab\"";

and then if callee.c is compiled with i686-w64-mingw32-gcc (Microsoft-world - 
escaping rules according to MSDN):

$ ./caller
argc = 2
argv[0] = callee
argv[1] = a\\b

with argv[1] correctly given in Microsoft's escaping. But if you compile 
callee.c with gcc (Cygwin-world), you get:

$ ./caller
argc = 2
argv[0] = callee
argv[1] = a\b

With the Cygwin DLL applying its interpretation of the escaping (treating \\ 
within a quoted parameter as an escaped single backslash), and quite clearly 
not MSDN's (treating \\ as two backslash characters because it's no followed by 
a double-quote). As an aside, if you have CYGWIN=noglob, you will actually get 
the same output as the native Windows case with two backslashes (more evidence, 
if you still need it, about how my question is everything to do with the Cygwin 
DLL, and nothing to do with MSDN and Microsoft's escaping rules).

There's also the small matter of Cygwin's @file trick for reading command line 
arguments from files (i.e. an extra escaping rule not indicated in MSDN because 
it's not part of Windows) - this time have commandLine = "@test", run echo 
foo>test and this time with a Microsoft-compiled callee, you'll get argv[1] = 
@test and with a Cygwin-compiled one, you'll get argv[1] = foo

> > > My line of thought is that Cygwin can't get anything which Windows
> > > can't send it. So the first step to solve this mess is to make sure
> > > the arguments which you send to CreateProcess() are correct.
> > >
> > > The next step would be to write a small C utility which dumps it's
> 
> > > arguments, so you can properly debug all kinds of characters.
> >
> > See later email, but IMHO the conversion is something Cygwin should have
> precisely documented, not determined by brittle experimentation.
> 
> Ah... no. You're mixing two or three things. Let me enumerate:
> 
> 1. You have to give your OS (Windows or Unix) the information which
> process you want to start and which arguments to pass. Unix has two ways
> (string array and single string), Windows has only single string.

Which system call in Unix allows you to start a process by giving a single 
string instead of an array of arguments (or a series of parameters)?

> 2. The OS will put the information into a structure of some kind and pass
> that to the new process.
> 3. If you have a shell (CMD.exe, bash, etc), they will take the structure
> and parse it according to some rules. They will then convert the result
> again into an OS call.
> 4. The C runtime of your executable will know where to get the OS
> structure and how to turn the structure into char ** argv.
> Where is Cygwin in all this? It's part of step #3. Cygwin emulates exec()
> and similar Unix OS functions which an emulated shell like BASH will use.
> Which means Cygwin code in the DLL is irrelevant if you don't have a Unix
> shell somewhere in your process chain.

No, Cygwin is loosely part of step #3 and definitely the whole of #4. If you 
invoke a Cygwin process from a native process, the Cygwin DLL does the work of 
#4, not the C runtime. Step #3 is entirely irrelevant to my problem because 
there is no shell involved.

> If you just want to execute a Cygwin process (= Windows process which
> includes the Cygwin.dll), you need to know #1, #2 and #4.

Indeed - which basically was my original question. Precisely how Cygwin deals 
with the conversion in Step 4.


David


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  

Re: Possible issue with newest version of git (v 2.8) under Cygwin

[andrew stern]

>I'm not sure I understand what you're seeing: if your repository is already 
>set up with core.filemode set to false, Git won't check the executable flag on 
>the files.  What leads you to think the speed slow-down is related to 
>>checking whether the file is executable?

>If setting cygexec makes a noticable speed difference even with core.filemode 
>false, I can only conclude the problem is somewhere below Git and related to 
>how the Cygwin DLL provides file access.

>FWIW, having just checked the Cygwin user guide's fstab instructions[0], the 
>noacl setting should be ignored on NFS filesystems; if you're seeing that make 
>a difference, that looks like a bug.

I tried a clone and pull both with the noacl and without the noacl. In
my experiment without the noacl it was much faster when doing pulls
after someone else checked in changes.  I located on the web a
reference to noacl being slow when doing a stat under cygwin and
figured if I prevent reading each file it might be faster so I went to
my noacl directory and did a pull of their changes after adding the
cygexec flag after the noacl flag.  Instead of being tens of minutes
it was just a bit over a minute and a half.  Although the repository
is on a NFS drive the local file system is NTFS and I see it spending
lots of time doing the update on the merge even though it is just a
couple of files that have changed.  I'm still trying to figure out
what exactly is going on and how best to deal with the permissioning
issue that we are now experiencing.  After discussions we would rather
have it slow then have bad permission problems but I'd rather not have
either issue.

If I leave off the noacl and do a clone followed by a push and pull we
end up with the following error in the Windows security tab:
  The permissions on file.cpp are incorrectly ordered, which may cause
some entries to be ineffective.

It also leaves the permissions looking like this

DenyNULL SID   Special
not Inherited
AllowUser  Special
 not Inherited
Denydev group   Traverse folder...
 not Inherited
DenyAuthenticated Users   Traverse folder...
not Inherited
DenySYSTEM   Traverse folder...
  not Inherited
DenyAdministrators for machine  Traverse folder...
not Inherited
DenyUsers for machine   Traverse folder...
 not Inherited
Allowdev group   Read & execute
   not Inherited
AllowAuthenticated Users   Read, Write & execute  not Inherited
AllowSYSTEM   Read, Write & execute
not Inherited
AllowAdministrators for machine  Read, Write & execute  not Inherited
AllowUsers for machine  Read & execute
not Inherited
AllowEveryone   Read
 not Inherited

--
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: Formatting command line arguments when starting a Cygwin process from a native process

[Aaron Digulla]

Am Montag, 09. Mai 2016 17:19 CEST, David Allsopp  schrieb:

> Aaron Digulla wrote:
> >
> > Am Samstag, 07. Mai 2016 09:45 CEST, "David Allsopp" 
> > schrieb:
> >
> >
> > > > Then all you need is a rudimentary quoting.
> > >
> > > Yes, but the question still remains what that rudimentary quoting is -
> > i.e.
> > > I can see how to quote spaces which appear in elements of argv, but I
> > > cannot see how to quote double quotes!
> >
> > This should help:
> > https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e
> > veryone-quotes-command-line-arguments-the-wrong-way/
>
> This provides documentation for how Microsoft implementations do it, not how 
> Cygwin does it. The Cygwin DLL is responsible for determining how a Cygwin 
> process gets argc and argv from GetCommandLineW.

That's correct but I read your question as "how do I start executables linked 
against Cygwin from another Windows process"

To do that, you need to convert the argument list/array into the stupid Windows 
format because that's what the Cygwin process will expect.

> > My line of thought is that Cygwin can't get anything which Windows can't
> > send it. So the first step to solve this mess is to make sure the
> > arguments which you send to CreateProcess() are correct.
> >
> > The next step would be to write a small C utility which dumps it's

> > arguments, so you can properly debug all kinds of characters.
>
> See later email, but IMHO the conversion is something Cygwin should have 
> precisely documented, not determined by brittle experimentation.

Ah... no. You're mixing two or three things. Let me enumerate:

1. You have to give your OS (Windows or Unix) the information which process you 
want to start and which arguments to pass. Unix has two ways (string array and 
single string), Windows has only single string.
2. The OS will put the information into a structure of some kind and pass that 
to the new process.
3. If you have a shell (CMD.exe, bash, etc), they will take the structure and 
parse it according to some rules. They will then convert the result again into 
an OS call.
4. The C runtime of your executable will know where to get the OS structure and 
how to turn the structure into char ** argv.

Where is Cygwin in all this? It's part of step #3. Cygwin emulates exec() and 
similar Unix OS functions which an emulated shell like BASH will use. Which 
means Cygwin code in the DLL is irrelevant if you don't have a Unix shell 
somewhere in your process chain.

If you just want to execute a Cygwin process (= Windows process which includes 
the Cygwin.dll), you need to know #1, #2 and #4.


> > PS: I always point people to string list/array type methods to create
> > processes which fix all the problems with spaces and odd characters
> > (quotes, umlauts, etc). It seems that Windows doesn't have such a method
> > to create processes. Which kind of makes sense; Windows is very, very
> > mouse centered.
>
> I fail to see the connection with mice! What Windows (NT) does have is a 
> legacy where the decision on how to convert a command line to a list/array of 
> arguments is determined per-process (and so not the responsibility of command 
> line shells) vs Unix which puts the burden of converting a single command 
> line to the array on the shell instead. Nominally, the Windows way is more 
> flexible, though I don't think that flexibility is actually useful 
> (especially if you look at the comments in the command line -> argv 
> conversion in Microsoft's C Runtime library!).

Using single strings to run commands causes all kinds or problems. It's a 
brittle API, which you should avoid. It kind of feels more simple but it's the 
"too simple" kind which Einstein mentioned ("You should make things as simple 
as possible. But not more simle.")

Think of it that way: Your executable gets the arguments as a string array. On 
the parent process side, Unix allows you to create a process with an array of 
strings. That's a natural API which doesn't need any kind of conversion (maybe 
you need to copy the strings but that's it).

If you convert from and to a single string all the time, you need a way to 
quote and escape. So this is more error prone than the plain array solution.

And lastly: If everyone would always use arrays, we wouldn't have this long, 
tedious discussion.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://blog.pdark.de/


--
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: Possible issue with newest version of git (v 2.8) under Cygwin

[Adam Dinwoodie]

On Tue, May 10, 2016 at 09:15:48AM -0400, andrew stern wrote:
> >I suspect this isn't a problem with the Git upgrade but with recent
> >changes that have been being made to how the core Cygwin dll handles
> >permissions.
> 
> >That being said, can you try running `git config core.filemode false` in
> >the repository, re-enabling noacl, and see if that has things running at
> >something more like normal speed?  That disables Git's checks on file
> >permissions, so it should isolate whether the slow-down is specifically
> >Git checking permissions or if merely accessing files is the problem.
> 
> >(With core.filemode disabled, you'll need to use `git update-index` to
> >add/remove the executable flag on files in the Git repository; see `git
> >help update-index` for details on how that works.  To undo the config
> >change, use `git config core.filemode true`.)
> 
> This repository is created with the filemode=false after I finish
> cloning from the repository using cygwin.
> I've decided to try cygexec on the fstab to see if it helps and it
> does seem much faster.
> I don't know if this is the correct way to speed it up again but the
> speed slow down does seem related to reading each file and determining
> if it is executable.
> The new line is:
> none /cygdrive cygdrive binary,posix=0,user,noacl,cygexec 0 0

I'm not sure I understand what you're seeing: if your repository is
already set up with core.filemode set to false, Git won't check the
executable flag on the files.  What leads you to think the speed
slow-down is related to checking whether the file is executable?

If setting cygexec makes a noticable speed difference even with
core.filemode false, I can only conclude the problem is somewhere below
Git and related to how the Cygwin DLL provides file access.

FWIW, having just checked the Cygwin user guide's fstab instructions[0],
the noacl setting should be ignored on NFS filesystems; if you're seeing
that make a difference, that looks like a bug.

[0]: https://cygwin.com/cygwin-ug-net/using.html#mount-table

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

Re: Possible issue with newest version of git (v 2.8) under Cygwin

[andrew stern]

>I suspect this isn't a problem with the Git upgrade but with recent
>changes that have been being made to how the core Cygwin dll handles
>permissions.

>That being said, can you try running `git config core.filemode false` in
>the repository, re-enabling noacl, and see if that has things running at
>something more like normal speed?  That disables Git's checks on file
>permissions, so it should isolate whether the slow-down is specifically
>Git checking permissions or if merely accessing files is the problem.

>(With core.filemode disabled, you'll need to use `git update-index` to
>add/remove the executable flag on files in the Git repository; see `git
>help update-index` for details on how that works.  To undo the config
>change, use `git config core.filemode true`.)

This repository is created with the filemode=false after I finish
cloning from the repository using cygwin.
I've decided to try cygexec on the fstab to see if it helps and it
does seem much faster.
I don't know if this is the correct way to speed it up again but the
speed slow down does seem related to reading each file and determining
if it is executable.
The new line is:
none /cygdrive cygdrive binary,posix=0,user,noacl,cygexec 0 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: Possible issue with newest version of git (v 2.8) under Cygwin

[Adam Dinwoodie]

On Mon, May 09, 2016 at 03:59:39PM -0400, andrew stern wrote:
> If I change my fstab back so that it does not include the noacl option
> on the line the merge is much faster:
> 
> 15:51:22.288607 git.c:350   trace: built-in: git 'merge'
> 'FETCH_HEAD' Updating 154cf50..a0f35eb
> Fast-forward
> 15:55:18.347594 run-command.c:336   trace: run_command: 'gc' '--auto'
> 
> So it is clear that my fix for the Windows permissions is causing the
> merge to take a very long time.
> 
> 
> On 9 May 2016 at 14:34, andrew stern <> wrote:
> > Recently I upgraded to version 2.8.0 of git on cygwin.  I’m running
> > under Windows 2008 R2.  Before this upgrade we were able to share a
> > NFS drive as a main repository.  After the upgrade the permissions
> > were changed so that only a single person had write access to the
> > repository on a shared NFS drive.  When the push is done to the NFS
> > drive these permissions cause deny write access to the other users of
> > the repository so we couldn’t update the sha1 of the head reference.
> > An example of the incorrect permissions are:
> >
> >
> > Allow User Specialnot
> > inherited  This folder only
> > Allow dev  Specialnot
> > inherited This folder only
> > Allow Everyone Read & execute not
> > inherited  This folder, subfolders and
> > Allow Administators for machineSpecialnot
> > inherited  This folder only
> > Allow SYSTEM   Specialnot
> > inherited  This folder only
> > Allow Users for machineSpecialnot
> > inherited  This folder only
> > Allow CREATOR OWNERSpecialnot
> > inherited Subfolders and files only
> > Allow CREATOR GROUPSpecialnot
> > inherited Subfolders and files only
> >
> > But the Windows permissions should have been inherited only.  Also not
> > the group dev is not in the list.  The permissions after a push showed
> > dev on the shared NFS drive along with errors that the permissions
> > were out of order.
> >
> > Allow Administators   Full Control   D:\  This folder,
> > subfolders and
> > Allow SYSTEM  Full Control   D:\  This folder,
> > subfolders and
> > Allow UserSpecialD:\  This folder only
> > Allow CREATOR OWNER   SpecialD:\  Subfolders
> > and files only
> > Allow User on Machine Read & execute D:\  This folder,
> > subfolders and
> > Allow User on Machine SpecialD:\  This folder,
> > subfolders
> >
> >
> > After searching through new groups and the web it was decided to add
> > noacl to the fstab for the cygwin mount:
> >
> > none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
> >
> > Now we are finding that the git merge onto our local drive after a
> > fetch from the NFS shared repository is taking a very long time.
> > (shown with >> in front on below line)
> >
> > $ git pull origin MCSTRATEGY_4_4
> > 13:01:16.587064 git.c:351   trace: built-in: git 'pull'
> > 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.752064 run-command.c:336   trace: run_command: 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.790064 exec_cmd.c:120  trace: exec: 'git' 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.821064 git.c:351   trace: built-in: git 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:17.069064 run-command.c:336   trace: run_command:
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 13:01:17.136064 run-command.c:195   trace: exec: '/bin/sh' '-c'
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 13:01:18.084064 run-command.c:336   trace: run_command: 'rev-list'
> > '--objects' '--stdin' '--not' '--all' '--quiet'
> > 13:01:18.229064 run-command.c:336   trace: run_command: 'rev-list'
> > '--objects' '--stdin' '--not' '--all'
> > 13:01:18.284064 exec_cmd.c:120  trace: exec: 'git' 'rev-list'
> > '--objects' '--stdin' '--not' '--all'
> > 13:01:18.314064 git.c:351   trace: built-in: git
> > 'rev-list' '--objects' '--stdin' '--not' '--all'
> > From /cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.
> >  * branchMCSTRATEGY_4_4 -> FETCH_HEAD
> > 13:01:18.367064 run-command.c:952   run_processes_parallel:
> > preparing to run up to 1 tasks
> > 13:01:18.373064 run-command.c:984   run_processes_parallel: done
> > 13:01:18.375064 run-command.c:336   trace: run_command: 'gc' '--auto'
> > 13:01:18.410064 exec_cmd.c:120  trace: exec: 'git' 'gc' '--auto'
> > 13:01:18.440064 git.c:351   trace: built-in: 

Re: timestamp 1462839105 iso-codes missing under release/

[Marco Atzeri]

On 10/05/2016 13:03, fer...@bonhard.uklinux.net wrote:

The latest setup.ini refers to new updates under release/iso-codes
but the files and the entire subdirectory including [o\prev] files
is missing on at least 3 mirrors that I tried.Fergus



 They're in noarch/release now.


Thank you.
Must have missed this: but I've just looked at another mirror and it looks
as though noarch/ is either superseding or mimicking x86/ as the home
location for release/. Will setup.ini move from x86/ to noarch/ ?
Interesting and important for those of us who maintain local [unofficial]
mirrors.
Oh yes: why the change?
Fergus



x86 and x86_64 are sharing ~ 30% of package that are not
processor dependent.
Plus all the source packages.

The target is to relief the mirrors and disks
of the duplications.
It will take some time to arrive there.

Regards
Marco



--
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: timestamp 1462839105 iso-codes missing under release/

[fer...@bonhard.uklinux.net]

>> The latest setup.ini refers to new updates under release/iso-codes
>> but the files and the entire subdirectory including [o\prev] files
>> is missing on at least 3 mirrors that I tried.Fergus

>  They're in noarch/release now.

Thank you.
Must have missed this: but I've just looked at another mirror and it looks
as though noarch/ is either superseding or mimicking x86/ as the home
location for release/. Will setup.ini move from x86/ to noarch/ ?
Interesting and important for those of us who maintain local [unofficial]
mirrors.
Oh yes: why the change?
Fergus


mail2web.com ? Enhanced email for the mobile individual based on Microsoft?
Exchange - http://link.mail2web.com/Personal/EnhancedEmail



--
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: timestamp 1462839105 iso-codes missing under release/

[Achim Gratz]

Fergus writes:
> The latest setup.ini refers to new updates under release/iso-codes but
> the files and the entire subdirectory including [orev] files is
> missing on at least 3 mirrors that I tried. 

They're in noarch/release now.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: Dedup x86/x86_64 --> noarch

[Andrew Schulman]

> Andrew Schulman writes:
> > I feel as though I've once again missed some important discussion about 
> > package
> > maintenance.  Your question implies that we can now upload packages with 
> > arch
> > "noarch".  Is that true?
> 
> Meanwhile it has become true, although Jon and Yaakov are still in the
> early stages of adding support for that.  But my posting really was
> meant as a demonstration that there are substantial gains to be had from
> going to this layout and that therefore it'd be worthwile adding
> official support for it.
> 
> > I remember a discussion of this question a year or two ago, where IIRC the
> > result was that we wouldn't have any "noarch" packages.  Did that change?  
> > If
> > so, I seem to have missed the discussion here.  It should be worth a 
> > "HEADSUP".
> 
> Yes, this needs to be announced soonish (Yaakov?) as otherwise some
> folks will be a bit surprised to see their mirror scripts not working
> anymore.
> 
> > If this is what's happened, we need to update https://cygwin.com/setup.html 
> > with
> > the new information (the page is overdue for an overhaul anyway). In 
> > particular
> > I wonder if cygport is ready to handle the change.
> 
> AFAIK, not quite yet.

OK, thanks!
Andrew

timestamp 1462839105 iso-codes missing under release/

[Fergus]

The latest setup.ini refers to new updates under release/iso-codes but the 
files and the entire subdirectory including [orev] files is missing on at least 
3 mirrors that I tried. 
Fergus‎
Sent from my BlackBerry 10 smartphone.‎

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