rpmconf-like tool for Cygwin

2020-04-07 Thread Yaakov Selkowitz
I put together an initial draft of a tool meant to fill the role of rpmconf on RPM-based systems: https://github.com/yselkowitz/cygetcconf It definitely needs more work (and maybe a better name) before inclusion anywhere, but in the spirit of "early and often", it's a start. HTH, -- Yaakov

Re: Missing new.h and broken comdef.h in cygwin32-w32api-headers (and the mingw header packages too)

2020-04-07 Thread Csaba Ráduly via Cygwin
On 07/04/2020 15:29, Hans de Ruiter via Cygwin wrote: Hi Hans, I've been trying to compile something that uses comutil.h, which in turn includes comip.h and comdef.h (amongst others). First, I get a missing header error: /usr/include/w32api/comip.h:21:10: fatal error: new.h: No such file or

Re: segfault on 32bit

2020-04-07 Thread Csaba Ráduly via Cygwin
On 07/04/2020 19:33, Marco Atzeri via Cygwin wrote: while trying to build the 32bit version on python, I hit this never seen before issue: checking for %zd printf() format support... make: *** No targets specified and no makefile found.  Stop. *** ERROR: make failed   4 [main] sh 18479

Re: cygport patches for consideration

2020-04-07 Thread Achim Gratz
Yaakov Selkowitz writes: >> I guess I can change my cygport generator instead to use >> CPAN_DIR when needed, but haven't got around doing so. > > Depending on its size, it would be nice to get this generator into > cygport's tools, and could possibly be used as the basis for other such >

Re: cygport patches for consideration

2020-04-07 Thread Yaakov Selkowitz
On Tue, 2020-04-07 at 18:52 +0200, Achim Gratz wrote: > Yaakov Selkowitz writes: > > > support subdirectories in CPAN download URL > > > > There is no need for two variables to do the same thing. I like > > Reini's idea but let's call it CPAN_SUBDIR instead. What about the > > attached

Re: Using ARM GNU GCC with Cygwin

2020-04-07 Thread Ben
Thanks for everyone's comments... I ended up getting the stock arm-gcc working just find if I got rid of absolute paths and just worked with relatives. I'm amused. :D Cygwin saves me once again from working in the DOS prompt environment. :P  -Ben -- Ben Kamen - O.D.T., S.P.

segfault on 32bit

2020-04-07 Thread Marco Atzeri via Cygwin
while trying to build the 32bit version on python, I hit this never seen before issue: checking for %zd printf() format support... make: *** No targets specified and no makefile found. Stop. *** ERROR: make failed 4 [main] sh 18479 D:\cygwin32\bin\sh.exe: *** fatal error in forked

Re: EXTERNAL: open descriptor to named pipes sometimes fail

2020-04-07 Thread Wells, Roger K. via Cygwin
On 4/7/20 11:10 AM, Kristian Ivarsson via Cygwin wrote: Opening a (second) descriptor for (blocking) write sometimes fail The provided test case sometimes succeed, but quite often fail with ENOENT (in various indexes) I haven't dug deeper to find the underlaying cause yet Have anyone

Re: cygport patches for consideration

2020-04-07 Thread Jon Turney
On 07/04/2020 17:52, Achim Gratz wrote: Yaakov Selkowitz writes: Automatically create a test release if the release string starts with a literal "0" Nak. There is not necessarily any correlation between a -0.* release and whether it should be test or not. Then there ought to be. :-)

[ANNOUNCEMENT] Updated: libao-1.2.0-2

2020-04-07 Thread David Rothenberger
CYGWIN NEWS: === Make packaging for i686 match the packaging for x86_64 by moving all the documentation to the libao package and making the libao4 and libao-devel packages depend on it. Move the man page from libao-devel to libao, since it describes libao.conf. DESCRIPTION:

[ANNOUNCEMENT] Updated libftdi1-1.4-2 for x86 and x86_64

2020-04-07 Thread Åke Rehnman via Cygwin-announce
Versions 1.4-2 of   libftdi1   libftdi1-devel   libftdi1-debuginfo   libftdi1-doc   python27-ftdi1   python36-ftdi1 for x86 and x86_64 are available in the Cygwin distribution. Version 1.4-2 is identical to 1.4-1. CHANGES Latest upstream release DESCRIPTION libFTDI is an open source

Updated libftdi1-1.4-2 for x86 and x86_64

2020-04-07 Thread Åke Rehnman via Cygwin-announce
Versions 1.4-2 of   libftdi1   libftdi1-devel   libftdi1-debuginfo   libftdi1-doc   python27-ftdi1   python36-ftdi1 for x86 and x86_64 are available in the Cygwin distribution. Version 1.4-2 is identical to 1.4-1. CHANGES Latest upstream release DESCRIPTION libFTDI is an open source

Updated: libao-1.2.0-2

2020-04-07 Thread David Rothenberger
CYGWIN NEWS: === Make packaging for i686 match the packaging for x86_64 by moving all the documentation to the libao package and making the libao4 and libao-devel packages depend on it. Move the man page from libao-devel to libao, since it describes libao.conf. DESCRIPTION:

Re: open descriptor to named pipes sometimes fail

2020-04-07 Thread Ken Brown via Cygwin
On 4/7/2020 11:10 AM, Kristian Ivarsson via Cygwin wrote: Opening a (second) descriptor for (blocking) write sometimes fail The provided test case sometimes succeed, but quite often fail with ENOENT (in various indexes) I haven't dug deeper to find the underlaying cause yet Have anyone

Re: Trouble uploading package

2020-04-07 Thread Åke Rehnman via Cygwin
On 2020-04-07 17:25, Jon Turney wrote: On 07/04/2020 16:03, Åke Rehnman via Cygwin wrote: Hello all, I tripped on the finish line... ERROR: install packages from source package 'libftdi1' have non-unique current versions 1.3-1 (python3-ftdi1), 1.4-1 (2 others) ERROR: error while validating

Re: calm: cygwin package upload report for David Rothenberger

2020-04-07 Thread David Rothenberger
On 4/7/2020 8:07 AM, Jon Turney wrote: On 07/04/2020 01:41, cygwin-no-re...@cygwin.com wrote: WARNING: package 'libao' version '1.2.0-1' has empty install tar file, but it's not in the _obsolete category It looks like this package is empty on x86, but contains documentation on x86_64. I

Re: Trouble uploading package

2020-04-07 Thread Jon Turney
On 07/04/2020 16:03, Åke Rehnman via Cygwin wrote: Hello all, I tripped on the finish line... ERROR: install packages from source package 'libftdi1' have non-unique current versions 1.3-1 (python3-ftdi1), 1.4-1 (2 others) ERROR: error while validating merged x86_64 packages for Ake Rehnman

open descriptor to named pipes sometimes fail

2020-04-07 Thread Kristian Ivarsson via Cygwin
Opening a (second) descriptor for (blocking) write sometimes fail The provided test case sometimes succeed, but quite often fail with ENOENT (in various indexes) I haven't dug deeper to find the underlaying cause yet Have anyone experienced this before ? Kristian #include #include #include

Re: calm: cygwin package upload report for David Rothenberger

2020-04-07 Thread Jon Turney
On 07/04/2020 01:41, cygwin-no-re...@cygwin.com wrote: WARNING: package 'libao' version '1.2.0-1' has empty install tar file, but it's not in the _obsolete category It looks like this package is empty on x86, but contains documentation on x86_64. I guess this is perhaps because some tool

Trouble uploading package

2020-04-07 Thread Åke Rehnman via Cygwin
Hello all, I tripped on the finish line... ERROR: install packages from source package 'libftdi1' have non-unique current versions 1.3-1 (python3-ftdi1), 1.4-1 (2 others) ERROR: error while validating merged x86_64 packages for Ake Rehnman I get this report: WARNING: copying

[ANNOUNCEMENT] X.Org X11 package refresh

2020-04-07 Thread Jon Turney
The following packages have been uploaded to the Cygwin distribution: * fonttosfnt-1.1.0-1 * libX11-1.6.9-1 * libXpm-3.5.13-1 * libXrender-0.9.10-1 * libxcb-1.14-1 * luit-20190106-1 * rgb-1.0.6-1 * xcb-proto-1.14-1 * xcb-util-0.4.0-1 * xcb-util-image-0.4.0-1 * xcb-util-keysyms-0.4.0-1 *

[ANNOUNCEMENT] Updated: libao-1.2.0-1

2020-04-07 Thread David Rothenberger
NEWS: = Update to upstream 1.2.0. Drop support for nas/libaudio. Replace ESD with PulseAudio. DESCRIPTION: Libao is a cross-platform audio library that allows programs to output audio using a simple API on a wide variety of platforms. It currently supports: * Null output

X.Org X11 package refresh

2020-04-07 Thread Jon Turney
The following packages have been uploaded to the Cygwin distribution: * fonttosfnt-1.1.0-1 * libX11-1.6.9-1 * libXpm-3.5.13-1 * libXrender-0.9.10-1 * libxcb-1.14-1 * luit-20190106-1 * rgb-1.0.6-1 * xcb-proto-1.14-1 * xcb-util-0.4.0-1 * xcb-util-image-0.4.0-1 * xcb-util-keysyms-0.4.0-1 *

Updated: libao-1.2.0-1

2020-04-07 Thread David Rothenberger
NEWS: = Update to upstream 1.2.0. Drop support for nas/libaudio. Replace ESD with PulseAudio. DESCRIPTION: Libao is a cross-platform audio library that allows programs to output audio using a simple API on a wide variety of platforms. It currently supports: * Null output

Missing new.h and broken comdef.h in cygwin32-w32api-headers (and the mingw header packages too)

2020-04-07 Thread Hans de Ruiter via Cygwin
I've been trying to compile something that uses comutil.h, which in turn includes comip.h and comdef.h (amongst others). First, I get a missing header error: /usr/include/w32api/comip.h:21:10: fatal error: new.h: No such file or directory So, I copy new.h from the mingw headers (I'm using

[ANNOUNCEMENT] Updated: qpdf-10.0.0-1

2020-04-07 Thread Marco Atzeri via Cygwin-announce
Versions 10.0.0-1 of qpdf libqpdf28 API Bump libqpdf-devel are available in the Cygwin distribution: CHANGES Latest upstream release DESCRIPTION QPDF is a command-line program that does structural, content-preserving transformations on PDF files. It also provides

Updated: qpdf-10.0.0-1

2020-04-07 Thread Marco Atzeri via Cygwin-announce
Versions 10.0.0-1 of qpdf libqpdf28 API Bump libqpdf-devel are available in the Cygwin distribution: CHANGES Latest upstream release DESCRIPTION QPDF is a command-line program that does structural, content-preserving transformations on PDF files. It also provides

Re: Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)]

2020-04-07 Thread JonY via Cygwin
On 4/7/20 12:57 AM, Yaakov Selkowitz wrote: > On Mon, 2020-04-06 at 23:55 +, JonY via Cygwin wrote: >> On 4/6/20 10:07 AM, Jan Nijtmans via Cygwin wrote: >>> Ping. >>> >>> Would it be possible to release a version of mingw64-i686-binutils with the >>> same patch as done for