Re: setup -g ???
On 14/03/2018 15:26, David Allsopp wrote: [reformatted for top-posting] Lee wrote: -- Forwarded message -- From: Jon Turney Date: Fri, 3 Nov 2017 15:26:27 + Subject: Re: Problem running the latest python2-2.7.14-1 under AppVeyor To: The Cygwin Mailing List On 03/11/2017 14:45, Vadim Zeitlin wrote: Our build has started on AppVeyor, a continuous integration provider, started failing since a couple of days as a makefile command running a Python script started failing with exit code 127 without any more information. This is a strange situation as I can't reproduce the problem locally, but something definitely seems to be wrong with this package on the AppVeyor machine as Python just doesn't seem to be executable, e.g. the output of these commands in our batch file driving the build: Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's setup. Due to setup terribleness, without this flag, it will install the requested packages, and any missing dependencies of them, but not upgrade any of the dependencies which are already installed to the current (and perhaps needed) version... See also [1]. [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html Should we still be using the -g (--upgrade-also) flag on setup? I believe so (or at least hope so). I think it's the case that setup should now know to upgrade a dependency if you install a new package which requires a newer version of it, but I hope that's not become the same as setup effectively acting with --upgrade-also every time you run it (that would be a real nuisance, unless the entire Cygwin package universe is going to be recompiled on every new Cygwin release). This is basically correct. setup is now capable of being told about dependencies where upgrading an already installed package is required, but this information isn't currently collected (For example, some packages now exist (e.g. vim [1]), which were built with gcc 6.4.0-5 and cygport 0.31.0-1. These packages almost certainly use ssp/fortify functions in the cygwin DLL, and so require a cygwin package >=2.10.0-1 (technically, the requirement is cygwin API >=0.320), but the dependency recorded is only on the cygwin package at any version) That's something someone could usefully work on, if they were so inclined. So, yes, if you are using --packages, you should continue to use -g (unless you know what you are doing and/or like to live dangerously) [1] https://cygwin.com/ml/cygwin/2018-03/msg00176.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: setup -g ???
Lee wrote: > On 3/18/18, David Allsopp wrote: > > Lee wrote: > >> On 3/14/18, David Allsopp wrote: > >> > [reformatted for top-posting] > >> > > >> > Lee wrote: > >> >> > -- Forwarded message -- > >> >> > From: Jon Turney > >> >> > Date: Fri, 3 Nov 2017 15:26:27 + > >> >> > Subject: Re: Problem running the latest python2-2.7.14-1 under > >> >> > AppVeyor > >> >> > To: The Cygwin Mailing List > >> >> > > >> >> > On 03/11/2017 14:45, Vadim Zeitlin wrote: > >> >> > > Our build has started on AppVeyor, a continuous integration > >> >> > > provider, started failing since a couple of days as a makefile > >> >> > > command running a Python script started failing with exit code > >> >> > > 127 without any more information. This is a strange situation > >> >> > > as I can't reproduce the problem locally, but something > >> >> > > definitely seems to be wrong with this package on the AppVeyor > >> >> > > machine as Python just doesn't seem to be executable, e.g. the > >> >> > > output of these commands in our batch file > >> >> > driving the build: > >> >> > > >> >> > Perhaps you need to provide the -g (--upgrade-also) flag to > >> >> > cygwin's setup. > >> >> > > >> >> > Due to setup terribleness, without this flag, it will install > >> >> > the requested packages, and any missing dependencies of them, > >> >> > but not upgrade any of the dependencies which are already > >> >> > installed to the current (and perhaps needed) version... > >> >> > > >> >> > See also [1]. > >> >> > > >> >> > [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html > >> >> > >> >> Should we still be using the -g (--upgrade-also) flag on setup? > >> > > >> > I believe so (or at least hope so). > >> > >> So if I run setup and it says there are no pending updates it might > >> be lying to me? > >> > >> I need to run setup -g and only then if there are no pending updates > >> do I know that my cygwin installation is up to date? > > > > No - the original question here was about running setup with a command > > line and the --packages argument. If you run setup interactively (with > > no arguments), you should be told if any packages need upgrading, just > > as before, without needing -g. > > When I saw the msg about > > Perhaps you need to provide the -g (--upgrade-also) flag > I tried running setup & got a short list of updates. Applied the > updates and ran setup again.. and had no pending updates listed as > expected. Then I ran setup -g and a few libXXX things were listed as > pending :( > > Maybe I got lucky & the lib showed up at the mirror I was > using just after running setup the second time?? dunno, but > unless/until I can duplicate setup not showing any pending updates & > setup -g saying there are pending updates, maybe we should just write it > off as a one time occurrence. It's possible that it was simply a mirror update - there are two ways to tell, if you see it again (or if you can remember what the actual packages were and the date you did it). One is to look in the history of this mailing list and see if there was an announce of a package update on or around the time you did the update. The other is to browse a mirror directly (e.g. https://mirrorservice.org/sites/sourceware.org/pub/cygwin/) and look at the timestamps of the files for the new package which appeared. The third way, if it really worries you, is to use a private mirror (either via rsync or using Cygwin setup's "Download" option - though over the years I've found the latter remarkably unreliable) which allows completely repeatable installations. HTH, David
Re: setup -g ???
On 3/18/18, David Allsopp wrote: > Lee wrote: >> On 3/14/18, David Allsopp wrote: >> > [reformatted for top-posting] >> > >> > Lee wrote: >> >> > -- Forwarded message -- >> >> > From: Jon Turney >> >> > Date: Fri, 3 Nov 2017 15:26:27 + >> >> > Subject: Re: Problem running the latest python2-2.7.14-1 under >> >> > AppVeyor >> >> > To: The Cygwin Mailing List >> >> > >> >> > On 03/11/2017 14:45, Vadim Zeitlin wrote: >> >> > > Our build has started on AppVeyor, a continuous integration >> >> > > provider, started failing since a couple of days as a makefile >> >> > > command running a Python script started failing with exit code >> >> > > 127 without any more information. This is a strange situation as >> >> > > I can't reproduce the problem locally, but something definitely >> >> > > seems to be wrong with this package on the AppVeyor machine as >> >> > > Python just doesn't seem to be executable, e.g. the output of >> >> > > these commands in our batch file >> >> > driving the build: >> >> > >> >> > Perhaps you need to provide the -g (--upgrade-also) flag to >> >> > cygwin's setup. >> >> > >> >> > Due to setup terribleness, without this flag, it will install the >> >> > requested packages, and any missing dependencies of them, but not >> >> > upgrade any of the dependencies which are already installed to the >> >> > current (and perhaps needed) version... >> >> > >> >> > See also [1]. >> >> > >> >> > [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html >> >> >> >> Should we still be using the -g (--upgrade-also) flag on setup? >> > >> > I believe so (or at least hope so). >> >> So if I run setup and it says there are no pending updates it might be >> lying to me? >> >> I need to run setup -g and only then if there are no pending updates do >> I know that my cygwin installation is up to date? > > No - the original question here was about running setup with a command line > and the --packages argument. If you run setup interactively (with no > arguments), you should be told if any packages need upgrading, just as > before, without needing -g. When I saw the msg about > Perhaps you need to provide the -g (--upgrade-also) flag I tried running setup & got a short list of updates. Applied the updates and ran setup again.. and had no pending updates listed as expected. Then I ran setup -g and a few libXXX things were listed as pending :( Maybe I got lucky & the lib showed up at the mirror I was using just after running setup the second time?? dunno, but unless/until I can duplicate setup not showing any pending updates & setup -g saying there are pending updates, maybe we should just write it off as a one time occurrence. Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: setup -g ???
Lee wrote: > On 3/14/18, David Allsopp wrote: > > [reformatted for top-posting] > > > > Lee wrote: > >> > -- Forwarded message -- > >> > From: Jon Turney > >> > Date: Fri, 3 Nov 2017 15:26:27 + > >> > Subject: Re: Problem running the latest python2-2.7.14-1 under > >> > AppVeyor > >> > To: The Cygwin Mailing List > >> > > >> > On 03/11/2017 14:45, Vadim Zeitlin wrote: > >> > > Our build has started on AppVeyor, a continuous integration > >> > > provider, started failing since a couple of days as a makefile > >> > > command running a Python script started failing with exit code > >> > > 127 without any more information. This is a strange situation as > >> > > I can't reproduce the problem locally, but something definitely > >> > > seems to be wrong with this package on the AppVeyor machine as > >> > > Python just doesn't seem to be executable, e.g. the output of > >> > > these commands in our batch file > >> > driving the build: > >> > > >> > Perhaps you need to provide the -g (--upgrade-also) flag to > >> > cygwin's setup. > >> > > >> > Due to setup terribleness, without this flag, it will install the > >> > requested packages, and any missing dependencies of them, but not > >> > upgrade any of the dependencies which are already installed to the > >> > current (and perhaps needed) version... > >> > > >> > See also [1]. > >> > > >> > [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html > >> > >> Should we still be using the -g (--upgrade-also) flag on setup? > > > > I believe so (or at least hope so). > > So if I run setup and it says there are no pending updates it might be > lying to me? > > I need to run setup -g and only then if there are no pending updates do > I know that my cygwin installation is up to date? No - the original question here was about running setup with a command line and the --packages argument. If you run setup interactively (with no arguments), you should be told if any packages need upgrading, just as before, without needing -g. My assumption is that the new dependency solver means that installing a package with --packages should install that and upgrade *only* required dependencies, not the entire system. The OP's issue here with AppVeyor is one I see too, because the AppVeyor team are relatively slow to update the Cygwin installation in their images (that's their call, of course). However, I workaround that using a script which installs required packages and then tests a known command from the package with --version - if I get a non-zero exit code, then I know that the package probably depends on a newer Cygwin DLL and the whole system needs upgrading. For example, quoting https://ci.appveyor.com/project/dra27/opam/build/1.0.210/job/21p7e382hp3q9lh7#L11: > Cygwin package patch will be installed > Cygwin package unzip will be installed > Cygwin package vim will be installed > Cygwin package flexdll will be installed << at this point, the script will have run setup with --packages=patch,unzip,vim,flexdll >> > Cygwin Package Information > Package Version > curl 7.56.1-1 > cygwin 2.9.0-3 > diffutils3.5-2 > flexdll 0.35-2 > gcc-g++ 6.4.0-4 > make 4.2.1-2 > patch2.7.4-1 > tar 1.29-1 > unzip6.0-17 > vim 8.0.1567-1 > Cygwin package upgrade required - please go and drink coffee << at this point, the script runs setup a second time with --upgrade-also >> > Cygwin Package Information > Package Version > curl 7.56.1-1 > cygwin 2.10.0-1 > diffutils3.5-2 > flexdll 0.35-2 > gcc-g++ 6.4.0-5 > make 4.2.1-2 > patch2.7.4-1 > tar 1.29-1 > unzip6.0-17 > vim 8.0.1567-1 This build was on March 11th, and the problem package was Vim - the patch, unzip and flexdll packages hadn't been recompiled against Cygwin 2.10 and so could be installed without a full package upgrade. You can see from my message about coffee why I'd care if -g had become the default, because it takes ages to run (obviously), and I don't want my CI slowed down unnecessarily... David
Re: setup -g ???
On 3/14/18, David Allsopp wrote: > [reformatted for top-posting] > > Lee wrote: >> > -- Forwarded message -- >> > From: Jon Turney >> > Date: Fri, 3 Nov 2017 15:26:27 + >> > Subject: Re: Problem running the latest python2-2.7.14-1 under AppVeyor >> > To: The Cygwin Mailing List >> > >> > On 03/11/2017 14:45, Vadim Zeitlin wrote: >> > > Our build has started on AppVeyor, a continuous integration provider, >> > > started failing since a couple of days as a makefile command running >> > > a >> > > Python script started failing with exit code 127 without any more >> > > information. This is a strange situation as I can't reproduce the >> > > problem locally, but something definitely seems to be wrong with this >> > > package on the AppVeyor machine as Python just doesn't seem to be >> > > executable, e.g. the output of these commands in our batch file >> > driving the build: >> > >> > Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's >> > setup. >> > >> > Due to setup terribleness, without this flag, it will install the >> > requested packages, and any missing dependencies of them, but not >> > upgrade any of the dependencies which are already installed to the >> > current (and perhaps needed) version... >> > >> > See also [1]. >> > >> > [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html >> >> Should we still be using the -g (--upgrade-also) flag on setup? > > I believe so (or at least hope so). So if I run setup and it says there are no pending updates it might be lying to me? I need to run setup -g and only then if there are no pending updates do I know that my cygwin installation is up to date? Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: setup -g ???
[reformatted for top-posting] Lee wrote: > > -- Forwarded message -- > > From: Jon Turney > > Date: Fri, 3 Nov 2017 15:26:27 + > > Subject: Re: Problem running the latest python2-2.7.14-1 under AppVeyor > > To: The Cygwin Mailing List > > > > On 03/11/2017 14:45, Vadim Zeitlin wrote: > > > Our build has started on AppVeyor, a continuous integration provider, > > > started failing since a couple of days as a makefile command running a > > > Python script started failing with exit code 127 without any more > > > information. This is a strange situation as I can't reproduce the > > > problem locally, but something definitely seems to be wrong with this > > > package on the AppVeyor machine as Python just doesn't seem to be > > > executable, e.g. the output of these commands in our batch file > > driving the build: > > > > Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's > > setup. > > > > Due to setup terribleness, without this flag, it will install the > > requested packages, and any missing dependencies of them, but not > > upgrade any of the dependencies which are already installed to the > > current (and perhaps needed) version... > > > > See also [1]. > > > > [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html > > Should we still be using the -g (--upgrade-also) flag on setup? I believe so (or at least hope so). I think it's the case that setup should now know to upgrade a dependency if you install a new package which requires a newer version of it, but I hope that's not become the same as setup effectively acting with --upgrade-also every time you run it (that would be a real nuisance, unless the entire Cygwin package universe is going to be recompiled on every new Cygwin release). David -- 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