Re: why does setup keep trying to install non-required packages?
On Aug 11 09:41, Ken Brown wrote: On 8/11/2013 3:16 AM, Andrew Schulman wrote: Fairly often when I run setup just for updates, it selects new packages for installation that I haven't selected and that aren't required by any of my other packages. Right now setup wants to install the login package. I didn't select it, and if I unselect it the installation continues without any problem. It happened in setup-x86, and now setup-x86_64 wants to do it too. I try to keep my installation slim, so I don't want setup to add new packages that aren't required and that I didn't select. Has anyone else observed this? Know the reason? Are they new packages, and setup assumes I want all new packages? login is in the Base category and so is installed by default. It was only recently added to the 64-bit distro, but I think it's been in x86 for a long time. The files on sourceware date from 2009. As far as I know, only things in Base and Misc (and their dependencies) get installed by default. (And packages in Misc are usually there by mistake, because a maintainer forgot to provide a setup.hint.) I haven't observed any exceptions to this. Usually only Base and dependencies shoud be installed by default, not Misc. Or did I miss something? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgfZFS8srJk.pgp Description: PGP signature
Re: [RFU] libaprutil1-1.5.2-4
On Aug 11 15:11, David Rothenberger wrote:
On 8/11/2013 12:34 PM, marco atzeri wrote:
Il 8/11/2013 9:02 PM, David Rothenberger ha scritto:
D=http://home.comcast.net/~david.rothenberger/cygwin/x86_86
this is missing error 404
Sorry for the typo (x86_86 instead of x86_64).
D=http://home.comcast.net/~david.rothenberger/cygwin/x86_64
wget -x -nH --cut-dirs=3 \
${D}/libaprutil1/aprutil1/aprutil1-1.5.2-4.tar.bz2 \
${D}/libaprutil1/aprutil1/setup.hint \
^
There's still a 404 error for these two, David.
${D}/libaprutil1/libaprutil1-1.5.2-4.tar.bz2 \
${D}/libaprutil1/libaprutil1-1.5.2-4-src.tar.bz2 \
${D}/libaprutil1/libaprutil1-debuginfo/libaprutil1-debuginfo-1.5.2-4.tar.bz2
\
${D}/libaprutil1/libaprutil1-debuginfo/setup.hint \
${D}/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.5.2-4.tar.bz2 \
${D}/libaprutil1/libaprutil1-devel/setup.hint \
${D}/libaprutil1/setup.hint
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpW7iAJpPwGE.pgp
Description: PGP signature
Re: [PATCH] setup.exe SEGV on WinXP/Pro
On Aug 11 19:24, Achim Gratz wrote: Corinna Vinschen writes: Patch applied. As a follow-up on the discussion I've checked why this is a conversion operator in the first place and the answer is no particularly good reason. I propose to keep the implementation unchanged, but as a plain member function str() instead, which should be easier to grok some time later. This is the only path the conversion operator got invoked through anyway. Applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJacBM2DzBD.pgp Description: PGP signature
Re: why does setup keep trying to install non-required packages?
On 8/12/2013 5:33 AM, Corinna Vinschen wrote: On Aug 11 09:41, Ken Brown wrote: On 8/11/2013 3:16 AM, Andrew Schulman wrote: Fairly often when I run setup just for updates, it selects new packages for installation that I haven't selected and that aren't required by any of my other packages. Right now setup wants to install the login package. I didn't select it, and if I unselect it the installation continues without any problem. It happened in setup-x86, and now setup-x86_64 wants to do it too. I try to keep my installation slim, so I don't want setup to add new packages that aren't required and that I didn't select. Has anyone else observed this? Know the reason? Are they new packages, and setup assumes I want all new packages? login is in the Base category and so is installed by default. It was only recently added to the 64-bit distro, but I think it's been in x86 for a long time. The files on sourceware date from 2009. As far as I know, only things in Base and Misc (and their dependencies) get installed by default. (And packages in Misc are usually there by mistake, because a maintainer forgot to provide a setup.hint.) I haven't observed any exceptions to this. Usually only Base and dependencies shoud be installed by default, not Misc. Or did I miss something? We had problems with expat packages being installed by default because they were missing setup.hint files and therefore were put into Misc: http://cygwin.com/ml/cygwin-apps/2013-04/msg00234.html http://www.cygwin.com/ml/cygwin-apps/2013-07/msg00209.html Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Ken
Re: why does setup keep trying to install non-required packages?
On Aug 12 07:10, Ken Brown wrote: On 8/12/2013 5:33 AM, Corinna Vinschen wrote: On Aug 11 09:41, Ken Brown wrote: On 8/11/2013 3:16 AM, Andrew Schulman wrote: Fairly often when I run setup just for updates, it selects new packages for installation that I haven't selected and that aren't required by any of my other packages. Right now setup wants to install the login package. I didn't select it, and if I unselect it the installation continues without any problem. It happened in setup-x86, and now setup-x86_64 wants to do it too. I try to keep my installation slim, so I don't want setup to add new packages that aren't required and that I didn't select. Has anyone else observed this? Know the reason? Are they new packages, and setup assumes I want all new packages? login is in the Base category and so is installed by default. It was only recently added to the 64-bit distro, but I think it's been in x86 for a long time. The files on sourceware date from 2009. As far as I know, only things in Base and Misc (and their dependencies) get installed by default. (And packages in Misc are usually there by mistake, because a maintainer forgot to provide a setup.hint.) I haven't observed any exceptions to this. Usually only Base and dependencies shoud be installed by default, not Misc. Or did I miss something? We had problems with expat packages being installed by default because they were missing setup.hint files and therefore were put into Misc: http://cygwin.com/ml/cygwin-apps/2013-04/msg00234.html http://www.cygwin.com/ml/cygwin-apps/2013-07/msg00209.html Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Oh, right. The setup sources seem to prove that point, too. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNLCKR9vALl.pgp Description: PGP signature
Re: [cygport] [PATCH] Add support for VERSIONS
Hi Yaakov, Any chance to discuss this? The ideas here are not unreasonable, or, are they? On Aug 5 10:57, Corinna Vinschen wrote: On Aug 4 10:47, Achim Gratz wrote: Corinna Vinschen writes: Btw., Yaakov, thanks for the new 0.13.0 version. The only problem I still have is the duplication of the dist files into the CWD. Isn't there some switch or setting to disable this behaviour? I've just updated my rpm-style fork of cygport and I've implemented it there — you need to set NO_TOP_PKG non-null in cygport.conf. It's the first commit on top of upstream cygport master since you'll probably don't want the rest of the patch stack. I've also integrated Dave's PKG_VERSION patch (second commit up) if anybody is interested. Clone from git://repo.or.cz/cygport/rpm-style.git The rest of the branch lets you can omit the .cygport extension universally and extends version-less naming to patch files (I think Ken had requested that some time ago). It also keeps all downloads (except source VCS, I've not had time yet to look into that) in DISTDIR and uses them from there directly without copying to $top. I'll be rebasing that branch on top of cygport master to keep it current. That sounds interesting, but I'd prefer to get this functionality, at least partially, into cygport. Yaakov? Ping? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4NsTKedjZw.pgp Description: PGP signature
Re: [PATCH] libgetopt++; change DefaultFormatter to produce less line breaks in usage output
On Aug 11 21:08, Achim Gratz wrote: The default formatter splits the line 40/40, which produces several unnecessary linebreaks for setup.exe and clutters the usage output. Implement a 35/45 split by default and provide an alternative constructor that enables adjustment of these parameters if necessary. From 4989f5b105875e635b6043f0c306601ca4bec21d Mon Sep 17 00:00:00 2001 From: Achim Gratz ... Date: Sat, 10 Aug 2013 15:05:30 +0200 Subject: [PATCH] split line 35/45 by default to have less linebreaks I'm a bit puzzled. Why do I always see the mail header twice, once as mail header and once in the body when you send a patch? This is irritating. * include/getopt++/DefaultFormatter.h (DefaultFormatter): Introduce private data members and use them, adjust comment accordingly. Split the line 35/45 instead of 40/40 by default to get less linebreaks. Add default initializers for data members to the constructor. Add a second constructor that offers parameters for initialization of the private data members. (DefaultFormatter::operator ()): Remove automatic variable output and directly put the data on the output stream instead. Use private data members to construct the output rather than magic constants. Applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6f4LcrGUP4.pgp Description: PGP signature
setup: Execute postinstall batch with /d to prevent AutoRun
Hi all, I am experiencing issues with autorebase.bat during setup. The call to autorebase.bat simply fails. I use a registry key [1] to execute a batch file before opening cmd to setup my cmd environment with doskey [2]. I guess that doskey tries to access something that simply does not exist in the noninteractive shell and therefore fails. Since I could not find a way to detect a noninteractive shell in cmd I was thinking one could change the call to cmd in script.cc to include the /d parameter [3] to prevent running the AutoRun registry keys. Does that make sense? Thanks, Arlo 1: http://technet.microsoft.com/en-us/library/cc779439(v=WS.10).aspx 2: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/doskey.mspx?mfr=true 3: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true -- Arlo O'Keeffe | Skype: arlolok
Re: why does setup keep trying to install non-required packages?
On 8/11/2013 3:16 AM, Andrew Schulman wrote: Fairly often when I run setup just for updates, it selects new packages for installation that I haven't selected and that aren't required by any of my other packages. Right now setup wants to install the login package. I didn't select it, and if I unselect it the installation continues without any problem. It happened in setup-x86, and now setup-x86_64 wants to do it too. I try to keep my installation slim, so I don't want setup to add new packages that aren't required and that I didn't select. Has anyone else observed this? Know the reason? Are they new packages, and setup assumes I want all new packages? login is in the Base category and so is installed by default. It was only recently added to the 64-bit distro, but I think it's been in x86 for a long time. The files on sourceware date from 2009. As far as I know, only things in Base and Misc (and their dependencies) get installed by default. (And packages in Misc are usually there by mistake, because a maintainer forgot to provide a setup.hint.) I haven't observed any exceptions to this. OK, I see that login is in the base category - although that seems like a mistake to me, since it seems like a package that few Cygwin users will ever use. Leaving that aside, I know there are other packages that setup has tried to install, and that I don't see in the base or misc categories. Unfortunately I don't remember now what they were, but the next time it happens I'll report it here.
Re: why does setup keep trying to install non-required packages?
On Mon, Aug 12, 2013 at 01:16:33PM +0200, Corinna Vinschen wrote: On Aug 12 07:10, Ken Brown wrote: Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Oh, right. The setup sources seem to prove that point, too. You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. I assume that no one disagrees with this, right? AFAIK, any time upset has helpfully added Misc it has done nothing but cause problems. cgf
Re: why does setup keep trying to install non-required packages?
On Aug 12 11:29, Christopher Faylor wrote: On Mon, Aug 12, 2013 at 01:16:33PM +0200, Corinna Vinschen wrote: On Aug 12 07:10, Ken Brown wrote: Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Oh, right. The setup sources seem to prove that point, too. You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. I assume that no one disagrees with this, right? I don't. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpzZXDdFutXw.pgp Description: PGP signature
Re: why does setup keep trying to install non-required packages?
On 8/12/2013 11:45 AM, Corinna Vinschen wrote: On Aug 12 11:29, Christopher Faylor wrote: On Mon, Aug 12, 2013 at 01:16:33PM +0200, Corinna Vinschen wrote: On Aug 12 07:10, Ken Brown wrote: Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Oh, right. The setup sources seem to prove that point, too. You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. I assume that no one disagrees with this, right? I don't. Back in the day, Misc was used when setup.exe supported installing a directory full of random tarballs without setup.hint or setup.ini data. So, of course, if you pointed setup.exe at a directory full of random tarballs, you did so because you wanted to install them -- thus Misc was installed by default. But I don't think that (installing tarballs w/o setup.ini data) even works anymore -- and genini is easy enough to use -- so I also agree with the decision to remove Misc. -- Chuck
Re: why does setup keep trying to install non-required packages?
On Mon, Aug 12, 2013 at 12:08:44PM -0400, Charles Wilson wrote: On 8/12/2013 11:45 AM, Corinna Vinschen wrote: On Aug 12 11:29, Christopher Faylor wrote: On Mon, Aug 12, 2013 at 01:16:33PM +0200, Corinna Vinschen wrote: On Aug 12 07:10, Ken Brown wrote: Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Oh, right. The setup sources seem to prove that point, too. You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. I assume that no one disagrees with this, right? I don't. Back in the day, Misc was used when setup.exe supported installing a directory full of random tarballs without setup.hint or setup.ini data. So, of course, if you pointed setup.exe at a directory full of random tarballs, you did so because you wanted to install them -- thus Misc was installed by default. Note that I didn't say that I'd remove the capability from setup.exe. I just want to remove it from the script that generates setup.ini. I suppose someone could remove it from genini too. cgf
Re: why does setup keep trying to install non-required packages?
Christopher Faylor writes: You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. +1 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH] libgetopt++; change DefaultFormatter to produce less line breaks in usage output
Corinna Vinschen writes: I'm a bit puzzled. Why do I always see the mail header twice, once as mail header and once in the body when you send a patch? This is irritating. Sorry, I just inline the patch that 'git format-patch' produces and that is a complete email in itself. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [RFU] libaprutil1-1.5.2-4
Corinna Vinschen wrote:
On Aug 11 15:11, David Rothenberger wrote:
On 8/11/2013 12:34 PM, marco atzeri wrote:
D=http://home.comcast.net/~david.rothenberger/cygwin/x86_64 wget
-x -nH --cut-dirs=3 \
${D}/libaprutil1/aprutil1/aprutil1-1.5.2-4.tar.bz2 \
${D}/libaprutil1/aprutil1/setup.hint \
^
There's still a 404 error for these two, David.
There's no aprutil1 transition package for x86_64, so this is fine.
It's just a copy-paste error in my email. I'll be more careful next time.
--
David Rothenberger daver...@acm.org
Imitation is the sincerest form of television.
-- The New Mighty Mouse
Re: why does setup keep trying to install non-required packages?
On Mon, Aug 12, 2013 at 06:37:40PM +0200, Achim Gratz wrote: Christopher Faylor writes: You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. +1 Thanks. I have upset sort of pulled apart right now as I attempt to deal with my new upload method so it will be a while before this is implemented. cgf
Re: setup: Execute postinstall batch with /d to prevent AutoRun
On Mon, Aug 12, 2013 at 12:12:10PM -0400, Christopher Faylor wrote: On Mon, Aug 12, 2013 at 02:17:25PM +0200, Arlo O'Keeffe wrote: Hi all, I am experiencing issues with autorebase.bat during setup. The call to autorebase.bat simply fails. I use a registry key [1] to execute a batch file before opening cmd to setup my cmd environment with doskey [2]. I guess that doskey tries to access something that simply does not exist in the noninteractive shell and therefore fails. Since I could not find a way to detect a noninteractive shell in cmd I was thinking one could change the call to cmd in script.cc to include the /d parameter [3] to prevent running the AutoRun registry keys. Does that make sense? Would renaming autorebase.bat - autorebase.cmd fix this? While modifying setup to deal with .cmd files, of course. cgf
Re: setup: Execute postinstall batch with /d to prevent AutoRun
Christopher Faylor writes: Would renaming autorebase.bat - autorebase.cmd fix this? I don't think so. From the description, the AutoRun key is used whenever cmd gets started, unless the /D option is given. It seems that you would either need to change COMSPEC or start each sub-CMD with the /D switch as well if you truly wanted to skip the AutoRun key. 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
Re: [RFU] libaprutil1-1.5.2-4
On Aug 12 10:40, David Rothenberger wrote:
Corinna Vinschen wrote:
On Aug 11 15:11, David Rothenberger wrote:
On 8/11/2013 12:34 PM, marco atzeri wrote:
D=http://home.comcast.net/~david.rothenberger/cygwin/x86_64 wget
-x -nH --cut-dirs=3 \
${D}/libaprutil1/aprutil1/aprutil1-1.5.2-4.tar.bz2 \
${D}/libaprutil1/aprutil1/setup.hint \
^
There's still a 404 error for these two, David.
There's no aprutil1 transition package for x86_64, so this is fine.
It's just a copy-paste error in my email. I'll be more careful next time.
No worries. 64 bit version uploaded.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpscuPfJzKTp.pgp
Description: PGP signature
Re: Missing 64 bit packages
On 2013-08-05 04:25, Corinna Vinschen wrote: editres js185 lighttpd nspr nss perl-clone These are up now. Yaakov
Re: Missing 64 bit packages
On Aug 12 14:34, Yaakov (Cygwin/X) wrote: On 2013-08-05 04:25, Corinna Vinschen wrote: editres js185 lighttpd nspr nss perl-clone These are up now. Removed from cygwin-64bit-missing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9NAJufk3kR.pgp Description: PGP signature
Re: [RFU] Please upload: algol68g package updates
Am 11.08.2013 19:49, schrieb marco atzeri: Il 8/11/2013 7:02 PM, Thomas Wolff ha scritto: Please upload the updated packages for algol68g (both 32 and 64 bit): cd algol68g wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2 wget http://towo.net/algol68g/algol68g-2.7-0-`uname -m`.tar.bz2 Thank you Thomas Wolff you can not assume that uname -m is providing anything useful. uname -m works on every system I've tried (unlike uname -p, uname -i). Very useful (e.g. in PATH=$HOME/bin/`uname`.`uname -m`:$PATH). Moreover we are not using the architecture on the binary file. I think it is really not a good idea to have the same name for archives of different packages. No other systems I know does this. I had raised this issue well in time (http://cygwin.com/ml/cygwin-apps/2013-04/msg00319.html) with some initially positive responses (including yours) but unfortunately no further discussion. My upload request was a feable attempt to foster this discussion again... By the way, I have managed meanwhile to package algol68g completely with cygport (see my other thread which I will respond later) and will provide another upload. -- Thomas
Re: [RFU] Please upload: algol68g package updates
On 8/12/2013 5:12 PM, Thomas Wolff wrote: Am 11.08.2013 19:49, schrieb marco atzeri: Il 8/11/2013 7:02 PM, Thomas Wolff ha scritto: Please upload the updated packages for algol68g (both 32 and 64 bit): cd algol68g wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2 wget http://towo.net/algol68g/algol68g-2.7-0-`uname -m`.tar.bz2 Thank you Thomas Wolff you can not assume that uname -m is providing anything useful. uname -m works on every system I've tried (unlike uname -p, uname -i). Very useful (e.g. in PATH=$HOME/bin/`uname`.`uname -m`:$PATH). Marco didn't say that uname -m wouldn't work. He said it wouldn't provide anything useful. The person trying to carry out your upload request will be working on sourceware, where uname -m gives x86_64 regardless of the Cygwin architecture that your package is intended for. Moreover we are not using the architecture on the binary file. I think it is really not a good idea to have the same name for archives of different packages. No other systems I know does this. I had raised this issue well in time (http://cygwin.com/ml/cygwin-apps/2013-04/msg00319.html) with some initially positive responses (including yours) but unfortunately no further discussion. My upload request was a feable attempt to foster this discussion again... If you're really trying to foster a productive discussion, sending a bogus RFU doesn't seem like the best way to do it. All you accomplish is to waste the time of people like Marco who have volunteered to respond to RFUs. Ken
Re: [RFU] Please upload: algol68g package updates
On Mon, Aug 12, 2013 at 11:12:25PM +0200, Thomas Wolff wrote: Am 11.08.2013 19:49, schrieb marco atzeri: Il 8/11/2013 7:02 PM, Thomas Wolff ha scritto: Please upload the updated packages for algol68g (both 32 and 64 bit): cd algol68g wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2 wget http://towo.net/algol68g/algol68g-2.7-0-`uname -m`.tar.bz2 Thank you Thomas Wolff you can not assume that uname -m is providing anything useful. uname -m works on every system I've tried (unlike uname -p, uname -i). Very useful (e.g. in PATH=$HOME/bin/`uname`.`uname -m`:$PATH). It may be useful in your path. It is not useful when downloading since uname -m returns i686 on 32-bit Cygwin and Cygwin is currently using x86 to denote 32-bit. And, you shouldn't be inventing a convention of adding the architecture to your packages. upset won't know what to do with that. Moreover we are not using the architecture on the binary file. I think it is really not a good idea to have the same name for archives of different packages. No other systems I know does this. Just to kill two birds with one stone: http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/x86_64/os/Packages/a/abattis-cantarell-fonts-0.0.10.1-1.fc18.noarch.rpm http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/i386/os/Packages/a/abattis-cantarell-fonts-0.0.10.1-1.fc18.noarch.rpm I had raised this issue well in time (http://cygwin.com/ml/cygwin-apps/2013-04/msg00319.html) with some initially positive responses (including yours) but unfortunately no further discussion. My upload request was a feable attempt to foster this discussion again... So by asking someone to upload a package using a technique that wouldn't work, but, if it had, would have ended up not actually working with the Cygwin distribution, you hoped to win people to your side? I'm not against the idea of adding an arch keyword to package tar balls but you've chosen the wrong way to go about arguing that point. cgf
Re: Missing 64 bit packages
On 2013-08-05 04:25, Corinna Vinschen wrote: beforelight e2fsimage exif fvwm gsm libesmtp libmetalink mkcomposecache odbc-psql python-twisted sessreg snownews xcb-util-renderutil These are up now as well. grandr xfindproxy These are deprecated, and will soon be removed from i686 as well. xwinwm This too may be deprecated soon in favour of XtoW. Yaakov
[ANNOUNCEMENT] Uploads for 12 August
The following packages (and their subpackages) have been updated for both arches: * at-spi2-atk-2.8.1-1 * at-spi2-core-2.8.0-1 * atk1.0-2.8.0-1 * dconf-0.16.1-1 * font-cantarell-otf-0.0.13-1 * fontconfig-2.10.93-1 * gamin-0.1.10-14 * GConf2-3.2.6-2 * gcr-3.8.2-1 * gdk-pixbuf2.0-2.28.2-1 * glib2.0-2.36.4-1 * glib2.0-networking-2.36.2-1 * gnome-common-3.7.4-2 * gnome-icon-theme-3.8.3-1 * gnome-keyring-3.8.2-1 * gnome-themes-standard-3.8.3-1 * gobject-introspection-1.36.0-1 * graphite2-1.2.3-1 * gsettings-desktop-schemas-3.8.2-1 * gstreamer1.0-1.0.9-1 * gstreamer1.0-plugins-base-1.0.9-1 * gstreamer1.0-plugins-good-1.0.9-1 * gtk-doc-1.19-1 * gtk2.0-2.24.20-1 * gtk3-3.8.2-1 * gvfs-1.16.3-1 * harfbuzz-0.9.19-1 * libgnome-keyring-3.8.0-1 * libgsf-1.14.28-1 * libsecret1-0.15-1 * libsoup2.4-2.42.2-1 * nspr-4.9.6-1 * pango1.0-1.34.1-1 * pcre-8.33-1 * perl-Clone-0.34-1 * pixman-0.30.2-1 * python-gi-3.8.3-1 * python3-gi-3.8.3-1 * vala-0.20.1-1 * xorg-cf-files-1.0.5-2 * yelp-xsl-3.8.1-1 This update brings the GNOME components in the distro up to the latest stable release. -- Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Source a .bat file from bash
Hi Saurabh, On Fri, Aug 9, 2013 at 10:42 PM, Saurabh T wrote: Is there a way to source a .bat file from bash and have the paths and other environment variables set in it apply in cygwin? Note that to source in UNIX shell parlance means read the file and interpret it. Bash can't do that with a .bat file (it's in a different language). You could run cmd.exe to interpret the .bat file, but changes to th environment get lost when cmd.exe exits. One possibility is to run bash from the cmd.exe window after the batch has finished. some_command could be: cp $1 /tmp/bat-to-bash-$1 echo 'c:\cygwin\bin\bash.exe --login' /tmp/bat-to-bash-$1 cmd.exe /tmp/bat-to-bash-$1 (this might work, but I haven't tested it) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: redefinition of __fpending
Had a similar problem with fpending redefine while trying to compile gnu bison. May be a problem with the 1.7.23-1 release of cygwin, because when I install 1.7.22-1 everything compiles without error. -- View this message in context: http://cygwin.1069669.n5.nabble.com/redefinition-of-fpending-tp101847p101880.html Sent from the Cygwin list mailing list archive at Nabble.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: redefinition of __fpending
On Aug 11 09:20, Denis Excoffier wrote: Hello, I don't really know what is going on, but the new (since 1.7.23) __fpending() declaration in /usr/include/stdio_def.h (line 47) seems to prevent the following to compile (redefinition of __fpending, i'm using GCC-4.8.1): - m4-1.4.16 - grep-2.14 - findutils-4.5.11 These packages use fpending.c from gnulib. Big sigh. The gnulib-related configure test checks for the declaration of __fpending, but the build environment still tries to compile gnulib's fpending.c. But __fpending is defined as inline function in stdio_ext.h so the definition in fpending.c clashes with the one in stdio_ext.h. That's a bug in the gnulib build environment. The definition of __fpending should be skipped if HAVE_DECL___FPENDING is 1. The problem is that this doesn't really help us a lot since all packages with integrated gnulib are affected. I'm not sure how to fix this yet. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpexdVUDRl46.pgp Description: PGP signature
Re: : 64-bit cygwin - cannot remove group permissions from file on ntfs
On Aug 11 16:28, Luke Ordelmans wrote: Running cygwin 64-bit on Windows 8 doesn't allow me to remove group permissions from a file. On 32-bit cygwin doing the same thing works fine. Luke@Sorcerer ~/test $ uname -a CYGWIN_NT-6.2 Sorcerer 1.7.23(0.268/5/3) 2013-08-09 10:05 x86_64 Cygwin Luke@Sorcerer ~/test $ touch test Luke@Sorcerer ~/test $ chmod -c 600 test mode of `test' changed from 0660 (rw-rw) to 0600 (rw---) Luke@Sorcerer ~/test $ ls -la total 4.0K drwxrwx---+ 1 Luke None 0 Aug 11 15:40 ./ drwxrwxr-x+ 1 Luke None 0 Aug 11 15:40 ../ -rw-rw 1 Luke None 0 Aug 11 15:40 test Luke@Sorcerer ~/test $ umask 0077 Works fine for me. The only reason I can see is that the permissions and inheritance rules on the parent directory are so that the None group always has rw access, despite what you set for the file. What does `cacls .' and `cacls test' print? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpIoxtg3kG9E.pgp Description: PGP signature
Re: [64-bit] curl: fix -i option (include headers)
On 2013-08-11 23:03, Daniel Stenberg wrote:
It was however recently fixed in curl in commit bb2e0686a
(https://github.com/bagder/curl/commit/bb2e0686a) and it will be
included in the 7.32.0 release of curl that is about to get shipped
within 24 hours!
Anyway, I have attached an updated cygport file together with a patch
to fix this bug (tested with cygport --32 and cygport --64).
Thanks a lot for your report and patch!
Thanks a lot for the information and the fix, Daniel!
I've built and tested packages using the updated curl 7.32.0 source code
(with cygport --32 and cygport --64; .cygport file attached). I can
confirm that the new version works fine.
@Yaakov: Could you please upload updated packages for curl 7.32.0?
Thank you and best regards,
Andreas
NAME=curl
VERSION=7.32.0
RELEASE=1
CATEGORY=Net Web
SUMMARY=Multi-protocol file transfer tool
DESCRIPTION=curl is a command line tool and library for transferring files
with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP,
TELNET, DICT, and FILE. curl supports SSL certificates, HTTP POST, HTTP
PUT, FTP uploading, HTTP form based upload, proxies, cookies,
user+password authentication (Basic, Digest, NTLM, Negotiate...), file
transfer resume, proxy tunneling and a busload of other useful tricks.
HOMEPAGE=http://curl.haxx.se/;
SRC_URI=http://curl.haxx.se/download/${P}.tar.lzma;
PKG_NAMES=${PN} lib${PN}4 lib${PN}-devel
curl_CONTENTS=usr/bin/curl.exe usr/share/doc/ usr/share/man/man1/curl.*
libcurl4_SUMMARY=Multi-protocol file transfer library (runtime)
libcurl4_CONTENTS=usr/bin/cygcurl-4.dll
libcurl_devel_SUMMARY=Multi-protocol file transfer library (development)
libcurl_devel_CONTENTS=usr/bin/curl-config usr/include/ usr/lib/
usr/share/man/man1/curl-config.* usr/share/man/man3/
DIFF_EXCLUDES=Makefile curlbuild.h curl_config.h
# librtmp: not in Fedora due to unchallenged DMCA action
CYGCONF_ARGS=
--enable-debug --enable-optimize
--disable-hidden-symbols
--disable-ares
--enable-ldap
--disable-sspi
--with-gssapi
--without-krb4
--with-libidn
--with-libmetalink
--without-librtmp
--with-libssh2
--without-spnego
--with-ssl
--with-zlib
--with-ca-bundle=/usr/ssl/certs/ca-bundle.crt
DOCS=docs/BINDINGS docs/BUGS docs/CONTRIBUTE docs/DISTRO-DILEMMA docs/FAQ
docs/FEATURES docs/HISTORY docs/HTTP-COOKIES docs/INTERNALS
docs/KNOWN_BUGS
docs/LICENSE-MIXING docs/MAIL-ETIQUETTE docs/MANUAL docs/RESOURCES
docs/SSLCERTS docs/THANKS docs/TheArtOfHttpScripting docs/TODO
docs/VERSIONS
KEEP_LA_FILES=none
signature.asc
Description: OpenPGP digital signature
Re: hassles with cygport
On Aug 11 19:51, marco atzeri wrote:
Il 8/11/2013 7:13 PM, Thomas Wolff ha scritto:
I tried to migrate a package to using cygport. As I had announced before,
I'm using this occasion to report some of the trouble I've experienced
with it,
listing this case as a kind of log of my porting attempt (which
finally failed).
While probably most of the single problems might appear to be small and
easily solvable, the mere amount of issues and peculiarities is what
makes cygport a rather cumbersome tool for me.
[...]
rename old cygport file to new version
⇒ why is this needed? couldn't it be version-agnostic?
You could have used the old style with version number in cygport
filename or the new style with version number in the file. That seems
rather logical to me. The new style is much easier to maintain in
future.
edit cygport file to change version number of patch file, plus
rename patch file to new version
⇒ bothersome
with SRC_URI=http://.../${P}.tar.gz; trying
cygport ... almostall
⇒ *** ERROR: Cannot find source package ...
almostall does not include the download step. That's a bug in the
help output, I think.
now archive already downloaded, so cygport [almost]all not desired
⇒ look up sequence of commands (prep, compile, install, package) I
couldn't remember
almostall works fine if the source package is already available.
cygport ... prep
⇒ likely, the patch fails, of course, because sources have changed,
so why is there not a step unpack after which I would check the patch?
trying to adapt patch
⇒ searching for patched files first, somewhere among a bunch of
directories;
origsrc good guess, but tried src first anyway
⇒ bothersome
trying to remember correct tuning of diff to produce patch;
adapted patch
⇒ have to unpack again, with cygport ... prep
⇒ redundant, but well
I really don't understand your problem here. If a patch doesn't apply
to the original package, in how far is that cygport's fault? Did you
ever try to write an rpm spec file? Both, rpm spec files as well as
cygport scripts are build and packaging scripts. The package's build
problems are expected to be already solved.
need to add a parameter to the package configure script
⇒ trying to find out how to achieve this:
after some googling etc, running cygstart
/usr/share/doc/cygport/manual.html
found WAF_CONFIGURE_FLAGS for additional arguments to pass to 'waf
configure'
⇒ what is waf??? not likely to lead to success
file:///usr/share/doc/cygport-0.13.0/manual.html#robo23
waf.cygclass
[...]
DESCRIPTION
Waf is a general-purpose build system written in Python used by XMMS2,
a few GTK+ programs, and some other projects. The build system is
defined by a 'wscript' file in the top source directory and
'wscript_build' files in subdirectories, both of which are also
written in Python.
found R_CONFIGURE_ARGS for flag(s) to be passed to the configure script
used by module packages containing native code
⇒ sounds somewhat better, but what the waf are module packages
containing native code?
You should start at the top of the manual. waf, just like R, are
cygclasses to handle build environments for waf resp. R. These are not
used for default settings but only for projects using waf or R. There
are a lot of cygclasses to handle various different build environments.
What you're looking for is CYGCONF_ARGS, or the cygconf command:
found src_compile, looks more likely to be useful
⇒ however, its description is somewhat nested, so where would I insert
specific parameters or commands?
it basically appears to call cygmake (which is obviously an internal
cygport thing),
also another cygport file lists:
src_compile() {
lndirs
cd ${B}
cygmake
}
but cygmake is described Calls 'make', so where is configure invoked??
Try this:
src_compile() {
lndirs
cd ${B}
cygconf [...append configure arguments here or use CYGCONF_ARGS...]
cygmake [...append make arguments here or use MAKEOPTS...]
}
lndirs is only necessary for a project which doesn't allow to be built
outside the source tree. If you have a fairly generic autoconf based
project, you can omit src_compile entirely. For more complicated cases,
just do something along the lines of the above.
trying to take up cygport sequence:
cygport ... install
getting message
make: *** Keine Regel, um »install« zu erstellen. Schluss.
*** ERROR: make install DESTDIR failed
⇒ what is this? should I provide a DESTDIR? the manual says:
install into a DESTDIR, and run post-installation steps
this is quite unclear, what is a DESTDIR? something I need to provide
or cygport would pick?
DESTDIR is the default variable used in many projects to define
an installation directory. This is pretty common, really. E.g.
configure --prefix=/usr; make; make install DESTDIR=/tmp
will configure the project to install into /usr, but the final
`make install DESTDIR=...' will install the files under /tmp/usr
Re: [64-bit] curl: fix -i option (include headers)
On Aug 11 22:36, Andreas Winkelbauer wrote: Hi, recently I stumbled across a bug in curl for 64-bit Cygwin regarding the -i option. This bug has already been discussed in April 2013: http://cygwin.1069669.n5.nabble.com/Difference-in-32-64-bit-curl-td98083.html (I can't reply directly since I was not subscribed to this mailinglist back then.) The problem is that the current version of curl always includes the protocol headers in the output (no matter if -i or --include or --no-include are used or not). This bug breaks scripts which use curl and expect it to not include the headers in the output. After some debugging I found out that the cause of the problem is a missing cast of the third argument of my_setopt in tool_operate.c:886 (line numbers from curl 7.29.0) my_setopt(curl, CURLOPT_HEADER, config-include_headers); Here, config-include_headers is of type bool (1 byte) and my_setopt is a macro which calls curl_easy_setopt() and is defined in tool_setopt.h as follows: #define my_setopt(x,y,z) \ SETOPT_CHECK(tool_setopt(x, FALSE, config, #y, y, z)) tool_setopt() is implemented in tool_setopt.c and uses va_arg(arg, long) to get the value of its sixth argument (which is config-include_headers). However, sizeof(long) == 8, but sizeof(bool) == 1 and thus va_arg(arg, long) returns a value != 0 even if config-include_headers == 0. I am not sure why there is no problem with other boolean configuration options like CURLOPT_FAILONERROR (corresponding to -f or --fail) which are processed in exactly the same way, e.g., in tool_operate.c:930 my_setopt(curl, CURLOPT_FAILONERROR, config-failonerror); Also, there is no problem in 32-bit Cygwin and in 32/64-bit Linux. Maybe the bug is triggered by some missing or incorrect (alignment related) compiler switches? Just FYI, this is very likely a bug which is only triggered on 64 bit Cygwin due to the different way arguments are passed to functions. The 1 byte bool value is sign extended to int (4 byte) and not to long (8 byte). This doesn't matter if the arg is passed in a register since AMD64 always zero's the high 4 byte of a register when you store a 4 byte value in it. But it matters as soon as the argument is passed on the stack. The difference between Cygwin and Linux is the calling convention. Linux uses the SYSV ABI, with the first 6 args in registers before subsequent regs are spilled on the stack. Cygwin uses the MS ABI, with only the first four args in registers. So, type problems int vs. long in function args only start showing with the 7th arg on Linux, but already with the 5th arg on Cygwin. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpsTdfLctw15.pgp Description: PGP signature
bash ignoring set -f on windows
The cygwin bash is ignoring noglob on windows 7 and XP. Cygwin
details: CYGWIN_NT-6.1 1.7.17(0.262/5/3) 2012-10-19 14:39
To illustrate, here is a script which calls a java application
which I expect to have wildcards passed through as-is to the java
main String[ ]args. Source to both as follows.
#!/bin/bash
set -f
ARGS=$@
ARGSQ=$@
# Try both quoted/unquoted ARGS
echo unquoted call to TestApp
$JAVA_HOME/bin/java TestApp $ARGS
echo quoted call to TestApp
$JAVA_HOME/bin/java TestApp $ARGSQ
-
The java app is simply:
public class TestApp {
public static void main(String[] args) {
if (args.length 1) {
System.out.println(WRONG!! NO ARGS AT ALL - should be '*');
return;
}
if (args[0].equals(*)) {
System.out.println(GOT '*'!!);
} else {
System.out.println(WRONG!! got ' + args[0] + ' - should be '*');
}
}
}
From a cygwin terminal, cd to the directory containing the java
source and script. Compile the app and run as follows
$ javac TestApp.java
$ ./bash.sh ‘*’
That’s asterix in single quotes. I expect to see
GOT '*'!!
But I get
WRONG!! got 'bash.sh’ – should be ‘*’
The ‘set –f’ in the script is ignored and therefore wildcard
expansion is enabled for the java invocation. If I comment out
‘set –f’ the result is the same.
If I run the same test on a Mac the result is that with ‘set –f’
uncommented no wildcard expansion occurs and with ‘set –f’ active
expansion does occur as expected.
I am shipping a similar script with my open source app so I need
to instruct users the easiest way to fix this just for cygwin.
Is this a known problem? Can you please outline what the
issue/bug/limitation is, and the least impact fix a user can be
expected to cope with please?
The following isn't reasonable to expect from users:
- Full scale cygwin version upgrades (a few file updates are OK)
- Any requirement to build any cygwin or other software from source
- Having to set a global or environment setting which affects
software other than my app
I can live with workarounds within my own script (bash.sh above)
so long as it works in non-cygwin shells.
I’d really appreciate help on this.
thanks,
Craig
--
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: redefinition of __fpending
On Aug 12 15:26, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.08.2013 14:05, Corinna Vinschen wrote: On Aug 11 09:20, Denis Excoffier wrote: Hello, I don't really know what is going on, but the new (since 1.7.23) __fpending() declaration in /usr/include/stdio_def.h (line 47) seems to prevent the following to compile (redefinition of __fpending, i'm using GCC-4.8.1): - m4-1.4.16 - grep-2.14 - findutils-4.5.11 These packages use fpending.c from gnulib. Big sigh. The gnulib-related configure test checks for the declaration of __fpending, but the build environment still tries to compile gnulib's fpending.c. But __fpending is defined as inline function in stdio_ext.h so the definition in fpending.c clashes with the one in stdio_ext.h. That's a bug in the gnulib build environment. The definition of __fpending should be skipped if HAVE_DECL___FPENDING is 1. The problem is that this doesn't really help us a lot since all packages with integrated gnulib are affected. I'm not sure how to fix this yet. This is fixed in upstream gnulib. Oh, good to know. Obviously, that doesn't really help you much - you still need to either patch packages, or update their copies of gnulib. That's right. In theory, patching this tiny problem in the packages shouldn't be too terrible for the time being. I hope... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpZGbdy427jv.pgp Description: PGP signature
Re: [64-bit] egrep core dumps when it opens binary files
On Aug 11 15:07, Jim Burwell wrote: 64 bit egrep gets a segfault and dumps core when it opens binary files: Confirmed. This isn't exactly about binary files, but rather grep stumbles over Cygwin/Newlib's UTF-16 surrogate pair handling here. To trigger this problem, three circumstances must conincide: - you have to use a UTF-8 locale like en_US.UTF-8, - you have to use grep's -i option, - and you have to hit a file with a UTF-8 sequence which translates to a surrogate. I'm looking into a patch to handle this uncommon situation and try to send it upstream. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpy8UngDNYGl.pgp Description: PGP signature
Re: bash ignoring set -f on windows
Craig Ryan cryan.dublin at gmail.com writes: The cygwin bash is ignoring noglob on windows 7 and XP. Cygwin details: CYGWIN_NT-6.1 1.7.17(0.262/5/3) 2012-10-19 14:39 I think putting the blame on bash is premature. Try replacing the call to java with a script of your own to see what arguments it get called with, then read this: http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html especially the section Wildcard expansion behavior change on Windows platforms. Regards, Achim. -- 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: Patch for run-1.3.0-1 core dump
On 8/10/2013 1:34 PM, foo wrote: Whenever I execute run.exe, it generates run.exe.stackdump. At line 370 in run.c, run2_freeargv() tries to free newargv, and run2_freeqrgv() expects that newargv is terminated by NULL. However, in shifting newargv at line 253-256, it fails to shift NULL terminator. Therefore, run2_freeargv() frees memory illegally. The following patch is a workaround. --- run.c.old +++ run.c.new @@ -252,7 +252,7 @@ newargv = run2_dupargv (argv); /* discard newargv[0] and shift up */ free (newargv[0]); - for (newargc = 1; newargc argc; newargc++) + for (newargc = 1; newargv[newargc-1] != NULL; newargc++) newargv[newargc-1] = newargv[newargc]; newargc = argc - 1; Thanks for the bug report and the patch. I'll investigate and update the package soon. -- Chuck -- 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: Source a .bat file from bash
On Mon, Aug 12, 2013 at 4:18 AM, Csaba Raduly rcs...@gmail.com wrote: Hi Saurabh, On Fri, Aug 9, 2013 at 10:42 PM, Saurabh T wrote: Is there a way to source a .bat file from bash and have the paths and other environment variables set in it apply in cygwin? Note that to source in UNIX shell parlance means read the file and interpret it. Bash can't do that with a .bat file (it's in a different language). That is only half true. I have and a little success with bash reading a .bat file but you must obey the rules of bash syntax or overcome it and vice versa. Tedious at best. You could run cmd.exe to interpret the .bat file, but changes to th environment get lost when cmd.exe exits. One possibility is to run bash from the cmd.exe window after the batch has finished. Or just start a Cygwin shell from the .bat file. That child of the .bat file would contain the environment from the parent but the parent cannot receive the environment of the child. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Source a .bat file from bash
On Mon, Aug 12, 2013 at 10:33 AM, Earnie Boyd wrote: On Mon, Aug 12, 2013 at 4:18 AM, Csaba Raduly rcs...@.xxx wrote: Sorry, for feeding spammers. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: bash ignoring set -f on windows
I think putting the blame on bash is premature. Try replacing the call to java with a script of your own to see what arguments it get called with, How so? This works on un*x platforms so what am I missing? The script IS my own, if you execute the script as suggested what results did you get with cygwin/windows? then read this: http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html I read this, I'm not sure what it provides as a solution? Apart from the fact that I dont require java 7, what is the expected cygwin bash glob behaviour? I ran my script with \$ARGV\ as suggested and the output per my java app is 'WRONG! NO ARGS AT ALL - should be '*'. If you can illustrate how to make this work I'd like to see it because I've tried a lot of variations with cygwin without sucess and so far I can only conclude that 'set -f' is being ignored. Thanks for responding Achim but please do try the code I provided and see what results you get. Just a minor correction to my post, on Mac I said with ‘set –f’ active expansion does occur as expected, instead I meant 'with set -f removed from the script expansion does occur as expected'. cheers, craig. -- 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
core dumps, libgcc and python
Hello, I am experiencing this issue, Python core dump depending on module import http://cygwin.com/ml/cygwin/2013-06/msg00204.html and python aborts http://comments.gmane.org/gmane.os.cygwin/139622 which I suppose is caused by Crashes inside libgcc_s_dw2-1.dll http://www.mail-archive.com/gcc@gcc.gnu.org/msg68316.html Can I install a stable, old release of the related packages? I am mainly interested in Python stability, and that the scripts do not return a bad status code to the calling process; I can wait for a proper fix for other applications. Otherwise, I can attemp to build a patched version, but I suppose the toolchain also needs rebuilding and I'm not familiar with that. What is the status of the patches? Have they been approved? Thanks -- 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: : 64-bit cygwin - cannot remove group permissions from file on ntfs
On Aug 11 16:28, Luke Ordelmans wrote: Running cygwin 64-bit on Windows 8 doesn't allow me to remove group permissions from a file. On 32-bit cygwin doing the same thing works fine. Luke@Sorcerer ~/test $ uname -a CYGWIN_NT-6.2 Sorcerer 1.7.23(0.268/5/3) 2013-08-09 10:05 x86_64 Cygwin Luke@Sorcerer ~/test $ touch test Luke@Sorcerer ~/test $ chmod -c 600 test mode of `test' changed from 0660 (rw-rw) to 0600 (rw---) Luke@Sorcerer ~/test $ ls -la total 4.0K drwxrwx---+ 1 Luke None 0 Aug 11 15:40 ./ drwxrwxr-x+ 1 Luke None 0 Aug 11 15:40 ../ -rw-rw 1 Luke None 0 Aug 11 15:40 test Luke@Sorcerer ~/test $ umask 0077 Works fine for me. The only reason I can see is that the permissions and inheritance rules on the parent directory are so that the None group always has rw access, despite what you set for the file. What does `cacls .' and `cacls test' print? Corinna Spot on! Explicitly removing all rights for 'None' from the top-level d:\cygwin64 solved the problem, thanks! Luke -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: [64-bit] egrep core dumps when it opens binary files
On Aug 12 14:49, Corinna Vinschen wrote: On Aug 11 15:07, Jim Burwell wrote: 64 bit egrep gets a segfault and dumps core when it opens binary files: Confirmed. This isn't exactly about binary files, but rather grep stumbles over Cygwin/Newlib's UTF-16 surrogate pair handling here. To trigger this problem, three circumstances must conincide: - you have to use a UTF-8 locale like en_US.UTF-8, - you have to use grep's -i option, - and you have to hit a file with a UTF-8 sequence which translates to a surrogate. I'm looking into a patch to handle this uncommon situation and try to send it upstream. I added UTF-16 surrogate handling to the -i option and uploaded a grep-2.14-2 package to the 64 bit release. Please give it a tests. If it works for you, I'll send the patch upstream. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5YOrZ6JvKx.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: libaprutil1-1.5.2-4
A new version the Apache Portable Runtime utilities library is now available for download. CYGWIN CHANGES: === * x86_64: Include PostgreSQL support. * Include MySQL support. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org Imitation is the sincerest form of television. -- The New Mighty Mouse -- 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: bash ignoring set -f on windows
Craig Ryan writes: I think putting the blame on bash is premature. Try replacing the call to java with a script of your own to see what arguments it get called with, How so? This works on un*x platforms so what am I missing? You are missing that Windows is not Un*x. On Windows, each application is expected to do their own globbing (if it cares to do it at all), since cmd doesn't do that. The script IS my own, if you execute the script as suggested what results did you get with cygwin/windows? I can't run your script since you didn't say how you call it or what the version of Java is that you were using. I did point out that while you were looking at bash, you ignored the fact that Java itself would attempt to expand glob characters. But you can make a new empty directory, put these two files in there: --8---cut here---start-8--- #!/bin/bash # this is t1.sh set -f ARGS=$@ ARGQ=$@ echo noglob/unquoted/unquoted: $ARGS ./t2.sh -- $ARGS -- echo noglob/quoted/unquoted: $ARGQ ./t2.sh -- $ARGQ -- echo noglob/unquoted/quoted: $ARGS ./t2.sh -- $ARGS -- echo noglob/quoted/quoted:$ARGQ ./t2.sh -- $ARGQ -- set +f echo glob/unquoted/unquoted: $ARGS ./t2.sh -- $ARGS -- echo glob/quoted/unquoted: $ARGQ ./t2.sh -- $ARGQ -- echo glob/unquoted/quoted: $ARGS ./t2.sh -- $ARGS -- echo glob/quoted/quoted:$ARGQ ./t2.sh -- $ARGQ -- --8---cut here---end---8--- --8---cut here---start-8--- #!/bin/bash # this is t2.sh set -f echo == noglob/unquoted: $@ echo == noglob/quoted:$@ set +f echo ==glob/unquoted: $@ echo ==glob/quoted:$@ --8---cut here---end---8--- make them both executable and then run t1.sh. This should produce the following output: --8---cut here---start-8--- $ ./t1.sh * noglob/unquoted/unquoted: * == noglob/unquoted: -- * -- == noglob/quoted:-- * -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- * -- noglob/quoted/unquoted: * == noglob/unquoted: -- * -- == noglob/quoted:-- * -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- * -- noglob/unquoted/quoted: * == noglob/unquoted: -- * -- == noglob/quoted:-- * -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- * -- noglob/quoted/quoted:* == noglob/unquoted: -- * -- == noglob/quoted:-- * -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- * -- glob/unquoted/unquoted: t1.sh t2.sh == noglob/unquoted: -- t1.sh t2.sh -- == noglob/quoted:-- t1.sh t2.sh -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- t1.sh t2.sh -- glob/quoted/unquoted: t1.sh t2.sh == noglob/unquoted: -- t1.sh t2.sh -- == noglob/quoted:-- t1.sh t2.sh -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- t1.sh t2.sh -- glob/unquoted/quoted: * == noglob/unquoted: -- * -- == noglob/quoted:-- * -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- * -- glob/quoted/quoted:* == noglob/unquoted: -- * -- == noglob/quoted:-- * -- ==glob/unquoted: -- t1.sh t2.sh -- ==glob/quoted:-- * -- --8---cut here---end---8--- I read this, I'm not sure what it provides as a solution? Apart from the fact that I dont require java 7, what is the expected cygwin bash glob behaviour? Maybe the above example convinces you that bash does respect the noglob switch, even on Cygwin. What Java does when it gets a command line with a globbing character is a different matter. It seems that it expects the glob character inside quotes or even quoted quotes, depending on version. Note that the outermost quotes will be removed by bash before Java gets to see it, so you will have to do something like \$@\ or even \\\$@\\\ to get this construct onto the commandline of Java unharmed. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: git-svn died of signal 6
Christian Franke wrote: Christian Franke wrote: Christian Franke wrote: Pawel Jasinski wrote: hi, after recent update I noticed a problem with 'git svn' first, it was complaining about 'address already taken' After restart and rebaseall I am getting: $ git svn rebase Current branch master is up to date. error: git-svn died of signal 6 I can confirm this: $ git svn fetch error: git-svn died of signal 6 This results in a perl.exe.stackdump file in cwd. Workaround: use cygwin to 1.7.18 (instead of 1.7.20) This also worked for me. With 1.7.18 the error message is not printed but an empty perl.exe.stackdump file is created. Problem does no longer occur with Cygwin 1.7.21. ... but reappears in 1.7.22 and .23. Christian -- 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: [ANNOUNCEMENT] Updated: vim-7.3.1152-1
Hi Yaakov, I'm wondering that noone mentioned it before, but maybe everyone is using ~/.vimrc or they were not as puzzled as me and tried to find out what went wrong. After updating to your latest vim build 1152, vim started to behave really unexpected, no syntax coloring, only one undo step and doing undo again did a redo, ... In the meantime I found out that your 7.3-virc.patch is the culprit, it replaces # define SYS_VIMRC_FILE $VIM/vimrc by # ifdef FEAT_NORMAL # define SYS_VIMRC_FILE /etc/vimrc # else # define SYS_VIMRC_FILE /etc/virc # endif which changes system vimrc file from /etc/vim/vimrc to /etc/vimrc for normal vim usage. This way no options are set and vim starts its strange behaviour. I guess the new block of code should probably more likely be # ifdef FEAT_NORMAL # define SYS_VIMRC_FILE $VIM/vimrc # else # define SYS_VIMRC_FILE $VIM/virc # endif or at most # ifdef FEAT_NORMAL # define SYS_VIMRC_FILE $VIM/vimrc # else # define SYS_VIMRC_FILE /etc/virc # endif Regards Björn Am 11.06.2013 00:47, schrieb Yaakov (Cygwin/X): The following packages have been updated for the Cygwin distribution: *** vim-7.3.1152-1 *** vim-common-7.3.1152-1 *** vim-minimal-7.3.1152-1 *** xxd-7.3.1152-1 *** gvim-7.3.1152-1 Vim is an advanced text editor that seeks to provide the power of the de-facto Unix editor 'Vi', with a more complete feature set and a choice of terminal and GTK+ interfaces. This is an update to last week's upstream patchset, with the following packaging changes: * The 'vi' binary now uses ~/.virc and /etc/virc instead of vimrc to avoid errors with configuration options not supported by 'vi'. * gvim on x86_64 uses the GTK+ interface. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: automake1.9-1.9.6-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.9, and contains the latest version of the automake 1.9 series, automake-1.9.6. This cygwin package, automake1.9, can be installed without conflict alongside the existing automake1.14 ... automake1.10, automake1.8 ... automake1.4 cygwin packages. CHANGES SINCE 1.9.6-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite results = cyg32| 7 of 560 tests failed cyg32| (8 tests were not run) cyg64| 7 of 560 tests failed cyg64| (8 tests were not run) === Testsuite Details: = both| FAIL: compile_f90_c_cxx.test both| FAIL: compile_f_c_cxx.test both| FAIL: flibs.test Looks like a bug in the test. It expects a copy of config.guess/config.sub in the testing directory, but never copies it there nor runs automake with --add-missing. both| FAIL: pr401.test This new test (and its corresponding fix) is backported from am1.10 -- but the new .test file created by the patch is not executable. A simple chmod +x command before re- running the test fixes it. both| FAIL: instsh.test both| FAIL: location.test both| FAIL: warnopts.test All of these appear to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. While technically these 7 failures are regressions from the previous am1.9 release: 0 of 545 tests failed They all appear to be related to platform updates (e.g. perl), or otherwise do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: automake1.8-1.8.5-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.8, and contains the latest version of the automake 1.8 series, automake-1.8.5. This cygwin package, automake1.8, can be installed without conflict alongside the existing automake1.14 ... automake1.9, automake1.7 ... automake1.4 cygwin packages. CHANGES SINCE 1.8.5-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite results = cyg32| 34 of 525 tests failed cyg32| (5 tests were not run) cyg64| 34 of 525 tests failed cyg64| (5 tests were not run) === Testsuite Details: = both| FAIL: compile_f_c_cxx.test both| FAIL: flibs.test Looks like a bug in the test. It expects a copy of config.guess/config.sub in the testing directory, but never copies it there nor runs automake with --add-missing. both| FAIL: instsh.test both| FAIL: location.test both| FAIL: warnopts.test All of these appear to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: depcomp4.test both| FAIL: ldadd.test both| FAIL: ldflags.test both| FAIL: libobj13.test both| FAIL: libtool.test both| FAIL: libtool2.test both| FAIL: libtool3.test both| FAIL: libtool5.test both| FAIL: libtool6.test both| FAIL: libtool7.test both| FAIL: listval.test both| FAIL: ltcond.test both| FAIL: ltcond2.test both| FAIL: ltconv.test both| FAIL: ltdeps.test both| FAIL: ltlibobjs.test both| FAIL: ltlibsrc.test both| FAIL: nobase.test both| FAIL: pr72.test both| FAIL: pr211.test both| FAIL: pr300-ltlib.test both| FAIL: pr307.test both| FAIL: reqd2.test both| FAIL: stdlib2.test both| FAIL: subobj9.test both| FAIL: suffix2.test both| FAIL: suffix5.test both| FAIL: suffix8.test both| FAIL: suffix10.test Each of these depend on internal details of (old) libtool, but we use a newer version and these tests have not been updated to match. While technically, these 34 failures are regressions from the previous am1.8 release: All 510 tests behaved as expected, (3 expected failures) They all appear to be related to platform updates (perl, libtool, etc) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: automake1.7-1.7.9-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.7, and contains the latest version of the automake 1.7 series, automake-1.7.9. This cygwin package, automake1.7, can be installed without conflict alongside the existing automake1.14 ... automake1.8, automake1.6 ... automake1.4 cygwin packages. CHANGES SINCE 1.7.9-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite results = cyg32| 36 of 460 tests failed cyg32| (4 tests were not run) cyg64| 36 of 460 tests failed cyg64| (4 tests were not run) === Testsuite Details: = both| FAIL: compile_f_c_cxx.test both| FAIL: flibs.test Looks like a bug in the test. It expects a copy of config.guess/config.sub in the testing directory, but never copies it there nor runs automake with --add-missing. both| FAIL: instsh.test both| FAIL: warnopts.test All of these appear to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: depcomp4.test both| FAIL: ldadd.test both| FAIL: ldflags.test both| FAIL: libobj13.test both| FAIL: libtool.test both| FAIL: libtool2.test both| FAIL: libtool3.test both| FAIL: libtool5.test both| FAIL: libtool6.test both| FAIL: listval.test both| FAIL: ltcond.test both| FAIL: ltcond2.test both| FAIL: ltconv.test both| FAIL: ltdeps.test both| FAIL: ltlibobjs.test both| FAIL: nobase.test both| FAIL: pr72.test both| FAIL: pr211.test both| FAIL: pr300-ltlib.test both| FAIL: pr307.test both| FAIL: reqd2.test both| FAIL: stdlib2.test both| FAIL: subobj9.test both| FAIL: suffix2.test both| FAIL: suffix5.test both| FAIL: suffix8.test both| FAIL: suffix10.test Each of these depend on internal details of (old) libtool, but we use a newer version and these tests have not been updated to match. both| FAIL: txinfo3.test both| FAIL: txinfo13.test both| FAIL: txinfo16.test both| FAIL: txinfo18.test both| FAIL: txinfo22.test In each case, texi2dvi reports a failure because the *output* .dvi file does not exist. However, whatever the cause of these errors they do not represent true regressions because in the previous release of am1.7 these tests were skipped. While technically, these 36 failures are regressions from the previous am1.7 release: 0 of 451 tests failed They all appear to be related to platform updates (perl, libtool, etc) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: automake1.6-1.6.3-12
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.6, and contains the latest version of the automake 1.6 series, automake-1.6.3. This cygwin package, automake1.6, can be installed without conflict alongside the existing automake1.14 ... automake1.7, automake1.5, and automake1.4 cygwin packages. CHANGES SINCE 1.6.3-11 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite Results == cyg32| 19 of 388 tests failed cyg64| 19 of 388 tests failed == Testsuite Details: == both| FAIL: gettext.test both| FAIL: gettext2.test Newer gettext expects AM_PROG_MKDIR_P but this version of automake does not define it both| FAIL: installsh.test This appears to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: ldflags.test both| FAIL: libtool.test both| FAIL: libtool2.test both| FAIL: libtool3.test both| FAIL: listval.test both| FAIL: ltdeps.test both| FAIL: ltlibobjs.test both| FAIL: nobase.test both| FAIL: pr72.test both| FAIL: pr211.test both| FAIL: pr300-ltlib.test both| FAIL: pr307.test both| FAIL: required2.test both| FAIL: subdircond.test both| FAIL: subobj9.test both| FAIL: suffix2.test This version of automake does not understand new libtool's multi-m4 file structure, and so unexpected warnings are emitted. While technically, these 19 failures are regressions from the previous am1.6 release: 0 of 370 tests failed They all appear to be related to platform updates (perl, libtool, gettext) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: automake1.5-1.5-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.5, and contains the latest version of the automake 1.5 series, automake-1.5. This cygwin package, automake1.5, can be installed without conflict alongside the existing automake1.14 ... automake1.6, and automake1.4 cygwin packages. CHANGES SINCE 1.5-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite Results == cyg32| 4 of 324 tests failed cyg64| 4 of 324 tests failed == Testsuite Details: == both| FAIL: installsh.test This appears to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: listval.test both| FAIL: subdircond.test both| FAIL: suffix2.test This version of automake does not understand new libtool's multi-m4 file structure, and so unexpected warnings are emitted. These errors all appear to be related to platform updates (perl, libtool) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: automake1.4-1.4p6-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.4, and contains the latest version of the automake 1.4 series, automake-1.4p6. This cygwin package, automake1.4, can be installed without conflict alongside the existing automake1.14 ... automake1.5 cygwin packages. CHANGES SINCE 1.4p6-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite Results == cyg32| 1 of 194 tests failed cyg64| 1 of 194 tests failed == Testsuite Details: == both| FAIL: installsh.test This appears to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: libaprutil1-1.5.2-4
A new version the Apache Portable Runtime utilities library is now available for download. CYGWIN CHANGES: === * x86_64: Include PostgreSQL support. * Include MySQL support. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org Imitation is the sincerest form of television. -- The New Mighty Mouse
Updated: automake1.9-1.9.6-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.9, and contains the latest version of the automake 1.9 series, automake-1.9.6. This cygwin package, automake1.9, can be installed without conflict alongside the existing automake1.14 ... automake1.10, automake1.8 ... automake1.4 cygwin packages. CHANGES SINCE 1.9.6-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite results = cyg32| 7 of 560 tests failed cyg32| (8 tests were not run) cyg64| 7 of 560 tests failed cyg64| (8 tests were not run) === Testsuite Details: = both| FAIL: compile_f90_c_cxx.test both| FAIL: compile_f_c_cxx.test both| FAIL: flibs.test Looks like a bug in the test. It expects a copy of config.guess/config.sub in the testing directory, but never copies it there nor runs automake with --add-missing. both| FAIL: pr401.test This new test (and its corresponding fix) is backported from am1.10 -- but the new .test file created by the patch is not executable. A simple chmod +x command before re- running the test fixes it. both| FAIL: instsh.test both| FAIL: location.test both| FAIL: warnopts.test All of these appear to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. While technically these 7 failures are regressions from the previous am1.9 release: 0 of 545 tests failed They all appear to be related to platform updates (e.g. perl), or otherwise do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: automake1.8-1.8.5-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.8, and contains the latest version of the automake 1.8 series, automake-1.8.5. This cygwin package, automake1.8, can be installed without conflict alongside the existing automake1.14 ... automake1.9, automake1.7 ... automake1.4 cygwin packages. CHANGES SINCE 1.8.5-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite results = cyg32| 34 of 525 tests failed cyg32| (5 tests were not run) cyg64| 34 of 525 tests failed cyg64| (5 tests were not run) === Testsuite Details: = both| FAIL: compile_f_c_cxx.test both| FAIL: flibs.test Looks like a bug in the test. It expects a copy of config.guess/config.sub in the testing directory, but never copies it there nor runs automake with --add-missing. both| FAIL: instsh.test both| FAIL: location.test both| FAIL: warnopts.test All of these appear to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: depcomp4.test both| FAIL: ldadd.test both| FAIL: ldflags.test both| FAIL: libobj13.test both| FAIL: libtool.test both| FAIL: libtool2.test both| FAIL: libtool3.test both| FAIL: libtool5.test both| FAIL: libtool6.test both| FAIL: libtool7.test both| FAIL: listval.test both| FAIL: ltcond.test both| FAIL: ltcond2.test both| FAIL: ltconv.test both| FAIL: ltdeps.test both| FAIL: ltlibobjs.test both| FAIL: ltlibsrc.test both| FAIL: nobase.test both| FAIL: pr72.test both| FAIL: pr211.test both| FAIL: pr300-ltlib.test both| FAIL: pr307.test both| FAIL: reqd2.test both| FAIL: stdlib2.test both| FAIL: subobj9.test both| FAIL: suffix2.test both| FAIL: suffix5.test both| FAIL: suffix8.test both| FAIL: suffix10.test Each of these depend on internal details of (old) libtool, but we use a newer version and these tests have not been updated to match. While technically, these 34 failures are regressions from the previous am1.8 release: All 510 tests behaved as expected, (3 expected failures) They all appear to be related to platform updates (perl, libtool, etc) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: automake1.7-1.7.9-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.7, and contains the latest version of the automake 1.7 series, automake-1.7.9. This cygwin package, automake1.7, can be installed without conflict alongside the existing automake1.14 ... automake1.8, automake1.6 ... automake1.4 cygwin packages. CHANGES SINCE 1.7.9-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite results = cyg32| 36 of 460 tests failed cyg32| (4 tests were not run) cyg64| 36 of 460 tests failed cyg64| (4 tests were not run) === Testsuite Details: = both| FAIL: compile_f_c_cxx.test both| FAIL: flibs.test Looks like a bug in the test. It expects a copy of config.guess/config.sub in the testing directory, but never copies it there nor runs automake with --add-missing. both| FAIL: instsh.test both| FAIL: warnopts.test All of these appear to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: depcomp4.test both| FAIL: ldadd.test both| FAIL: ldflags.test both| FAIL: libobj13.test both| FAIL: libtool.test both| FAIL: libtool2.test both| FAIL: libtool3.test both| FAIL: libtool5.test both| FAIL: libtool6.test both| FAIL: listval.test both| FAIL: ltcond.test both| FAIL: ltcond2.test both| FAIL: ltconv.test both| FAIL: ltdeps.test both| FAIL: ltlibobjs.test both| FAIL: nobase.test both| FAIL: pr72.test both| FAIL: pr211.test both| FAIL: pr300-ltlib.test both| FAIL: pr307.test both| FAIL: reqd2.test both| FAIL: stdlib2.test both| FAIL: subobj9.test both| FAIL: suffix2.test both| FAIL: suffix5.test both| FAIL: suffix8.test both| FAIL: suffix10.test Each of these depend on internal details of (old) libtool, but we use a newer version and these tests have not been updated to match. both| FAIL: txinfo3.test both| FAIL: txinfo13.test both| FAIL: txinfo16.test both| FAIL: txinfo18.test both| FAIL: txinfo22.test In each case, texi2dvi reports a failure because the *output* .dvi file does not exist. However, whatever the cause of these errors they do not represent true regressions because in the previous release of am1.7 these tests were skipped. While technically, these 36 failures are regressions from the previous am1.7 release: 0 of 451 tests failed They all appear to be related to platform updates (perl, libtool, etc) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: automake1.6-1.6.3-12
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.6, and contains the latest version of the automake 1.6 series, automake-1.6.3. This cygwin package, automake1.6, can be installed without conflict alongside the existing automake1.14 ... automake1.7, automake1.5, and automake1.4 cygwin packages. CHANGES SINCE 1.6.3-11 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite Results == cyg32| 19 of 388 tests failed cyg64| 19 of 388 tests failed == Testsuite Details: == both| FAIL: gettext.test both| FAIL: gettext2.test Newer gettext expects AM_PROG_MKDIR_P but this version of automake does not define it both| FAIL: installsh.test This appears to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: ldflags.test both| FAIL: libtool.test both| FAIL: libtool2.test both| FAIL: libtool3.test both| FAIL: listval.test both| FAIL: ltdeps.test both| FAIL: ltlibobjs.test both| FAIL: nobase.test both| FAIL: pr72.test both| FAIL: pr211.test both| FAIL: pr300-ltlib.test both| FAIL: pr307.test both| FAIL: required2.test both| FAIL: subdircond.test both| FAIL: subobj9.test both| FAIL: suffix2.test This version of automake does not understand new libtool's multi-m4 file structure, and so unexpected warnings are emitted. While technically, these 19 failures are regressions from the previous am1.6 release: 0 of 370 tests failed They all appear to be related to platform updates (perl, libtool, gettext) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: automake1.5-1.5-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.5, and contains the latest version of the automake 1.5 series, automake-1.5. This cygwin package, automake1.5, can be installed without conflict alongside the existing automake1.14 ... automake1.6, and automake1.4 cygwin packages. CHANGES SINCE 1.5-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite Results == cyg32| 4 of 324 tests failed cyg64| 4 of 324 tests failed == Testsuite Details: == both| FAIL: installsh.test This appears to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. both| FAIL: listval.test both| FAIL: subdircond.test both| FAIL: suffix2.test This version of automake does not understand new libtool's multi-m4 file structure, and so unexpected warnings are emitted. These errors all appear to be related to platform updates (perl, libtool) and do not actually represent regressions in automake itself, so to speak. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: automake1.4-1.4p6-11
Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.4, and contains the latest version of the automake 1.4 series, automake-1.4p6. This cygwin package, automake1.4, can be installed without conflict alongside the existing automake1.14 ... automake1.5 cygwin packages. CHANGES SINCE 1.4p6-10 == * Rely on cygport to autogenerate setup.hints * Update config.sub/config.guess to latest standard (supports cygwin64) * Use 'alternatives' only for documentation; rely on wrapper to handle the tools themselves. * First cygwin64 release Testsuite Results == cyg32| 1 of 194 tests failed cyg64| 1 of 194 tests failed == Testsuite Details: == both| FAIL: installsh.test This appears to be due to a warning issued by new perl when parsing Wrap.pm: Useless use of /d modifier in transliteration operator at .../lib/Automake/Wrap.pm line 60. This messes up the expected stderr output. -- Charles Wilson volunteer automake maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
