Re: Setup patch to keep test version if test version installed
Hi Ken, On Feb 3 16:50, Ken Brown wrote: On 2/3/2015 10:27 AM, Corinna Vinschen wrote: On Feb 3 08:04, Ken Brown wrote: On 2/3/2015 6:33 AM, Corinna Vinschen wrote: Hey guys, On Jan 28 21:23, Corinna Vinschen wrote: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe [...] Did you test this version? Is it ok to become the release version of setup? It works fine for me. Nice. Are you a potential user of the -m option? No, so I couldn't test that. But it seems that others have tested it by now. Right, and thus I released this version :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjq5hmKQAF_.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Try this: Works a treat, please install. 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: Setup patch to keep test version if test version installed
On Feb 3 22:27, Corinna Vinschen wrote: On Feb 3 22:04, Corinna Vinschen wrote: On Feb 3 21:37, Achim Gratz wrote: I'm not sure we're talking about the same thing. I've recently added code to print an error message along with the parameter usage when a wrong option or other non-parseable stuff was given instead of simply exiting with no indication other than the non-zero exit code. The changes you've just installed look good to me, but they don't touch the exit path in question: [...] I guess with those changes one could now use Log (LOG_TIMESTAMP) instead of cerr in that place and hopefully the output would appear again? I was pretty certain I tested that in both mintty and CMD, but maybe not... I was referring explicitely to the CMD prompt being too early. I didn't test the situation when specifying a wrong option, sorry. The point in the file where this occurs is somewhat early. At this point the log stuff isn't initialized and AttachConsole hasn't been called. I'll look into that, maybe it can be fixed easily. Try this: On second thought, this is still unclean. What bugs me is that the behaviour of LogFile::exit is not easier conditionalized. I'm going to change LogFile::exit to something like this: LogFile::exit (int exit_code, bool show_end_of_install_msg) This allows to separate printing the Ending cygwin install message from the exit_code and so we can exit with a non-zero exit code *and* skip showing the message. Hang on for a bit... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgplex3psDuyR.pgp Description: PGP signature
Re: perl-5.14.4
David Stacey writes: On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Do you expect the XS modules built against 5.14.2 to be compatible with 5.14.4, or would you like them rebuilt? I expect them to be compatible, but I haven't tested that assumption yet. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: cmake update needed
Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. I have some builds of latest 3.1.1 sitting around that I can send to the list later today. Note that I have temporarily removed all of the patches from cygwin-ports since none of them were necessary to build, or changed the results of any of cmake's unit tests. I'll definitely put any of them back if I can get a reproducible test case report, to pursue with upstream for adding new cases to their unit tests. -Tony
perl-5.14.4
As I said in another thread I intend to skip directly to version 5.22 shortly after it becomes available in May (assuming the release schedule is still holds). While looking into some of the test fails on 5.18.4 I've moved back to 5.14.4 for comparison (the fail turned out to be a combination of new optimizations in gcc-4.9 and undefined behaviour in Perl code). The fix in this case was to add a compiler flag (-fwrapv) that disables those optimizations and I'm now back to having roughly the same test fails as the old 5.14.2 from Reini: Failed 9 tests out of 2048, 99.56% okay. ../cpan/Win32/t/GetShortPathName.t -- returns a long path name when called from mintty ../cpan/Win32/t/Names.t -- this old version of Win32 does not know about Windows 8.1 ../cpan/Win32/t/Unicode.t -- ANSI path functions do not return the expected results ../dist/Net-Ping/t/510_ping_udp.t -- same as 5.14.2 ../ext/XS-APItest/t/call_checker.t -- same as 5.14.2 ../lib/File/stat.t -- works if test is not run as Administrator (but then other tests fail) op/filetest.t -- works if test is not run as Administrator (but then other tests fail) porting/exec-bit.t -- global.sym has exec bit set, but not registered as such porting/regen.t -- also something to do with global.sym I'll probably keep the Win32 and other bundled CPAN modules as released with 5.14 and provide the latest versions as unbundled perl-* packages so that Module::CoreList doesn't lie to the user. So, it looks like I'm ready to bring Perl on both 32bit and 64bit to the same (final 5.14.4) version plus I can already do the packaging changes planned for the 5.22 release (dissolution of perl_vendor and creation of perl_base as a minimal install variant) for both architectures. I hope that this would enable a much smoother transition when that version gets released since the dependencies of those packages relying on Perl should be fixable until then. If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]
On 2/3/2015 4:17 AM, Corinna Vinschen wrote: On Feb 2 10:46, Ken Brown wrote: I've now begun working on the 64-bit build. I found a few minor things I had to change, and the build was pretty far along, when I apparently hit a gcc bug: [...] Oh, that's too bad. I hope somebody from the gcc folks take a look. I've submitted the report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 Ken
Re: perl-5.14.4
On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Do you expect the XS modules built against 5.14.2 to be compatible with 5.14.4, or would you like them rebuilt? Dave.
Re: cmake update needed
Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread Yes, those took a while, but they were resolved eventually. All these patches are the result of years of real-world usage of cmake, and there will likely be more patches required in the future. I can't tell you off the top of my head which packages require each of these changes, but I can tell you why they are necessary (and a few of them should be quite obvious). That would help. Someone else is welcome to maintain the package without asking any questions, but if I'm going to do it I'd like to know what those patches are for. I have your git history, but your commit messages are not particularly enlightening. I'm asking for failure cases, links to bug reports or previous postings, or similar. I don't think that's an unreasonable request, is it? I'll put the patches back and rebuild, but I'd like to understand them first. -Tony
Re: cmake update needed
By “adopt,” you are offering to participate in the package contribution system, which involves a bit more than just putting tarballs in a shared Dropbox folder: https://cygwin.com/setup.html I'm aware, thanks, I already maintain 4 other packages. I'm putting these up for review of the packaging, as is customary. -Tony
Re: cmake update needed
Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. Sure. Were the reasons for them ever written down? If I'm going to maintain the package, I do not want to carry local patches forever. CMake's test suite is very extensive, if it's missing use cases that are specific to Cygwin then I'm sure upstream would be willing to add add more tests to catch them in the future. I'm willing to pursue upstreaming the patches wherever possible, but need test cases to do so. I've made this request once or twice before and it was ignored. -Tony
Re: cmake update needed
On Wed, 2015-02-04 at 12:45 -0800, Tony Kelman wrote: Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. I have some builds of latest 3.1.1 sitting around that I can send to the list later today. Note that I have temporarily removed all of the patches from cygwin-ports since none of them were necessary to build, or changed the results of any of cmake's unit tests. I'll definitely put any of them back if I can get a reproducible test case report, to pursue with upstream for adding new cases to their unit tests. Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. -- Yaakov
Re: cmake update needed
Happy to adopt it. I have some builds of latest 3.1.1 sitting around
that I can send to the list later today. Note that I have temporarily
removed all of the patches from cygwin-ports since none of them were
necessary to build, or changed the results of any of cmake's unit
tests. I'll definitely put any of them back if I can get a
reproducible test case report, to pursue with upstream for adding new
cases to their unit tests.
BASEURL=https://dl.dropboxusercontent.com/u/8244638/cygwin-cmake
wget --no-check-certificate --no-host-directories \
--force-directories --cut-dirs=2 \
${BASEURL}/i686/cmake-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-3.1.1-1-src.tar.xz \
${BASEURL}/i686/setup.hint \
${BASEURL}/i686/cmake-debuginfo/cmake-debuginfo-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-debuginfo/setup.hint \
${BASEURL}/i686/cmake-doc/cmake-doc-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-doc/setup.hint \
${BASEURL}/i686/cmake-gui/cmake-gui-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-gui/setup.hint \
${BASEURL}/i686/emacs-cmake/emacs-cmake-3.1.1-1.tar.xz \
${BASEURL}/i686/emacs-cmake/setup.hint \
${BASEURL}/x86_64/cmake-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-3.1.1-1-src.tar.xz \
${BASEURL}/x86_64/setup.hint \
${BASEURL}/x86_64/cmake-debuginfo/cmake-debuginfo-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-debuginfo/setup.hint \
${BASEURL}/x86_64/cmake-doc/cmake-doc-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-doc/setup.hint \
${BASEURL}/x86_64/cmake-gui/cmake-gui-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-gui/setup.hint \
${BASEURL}/x86_64/emacs-cmake/emacs-cmake-3.1.1-1.tar.xz \
${BASEURL}/x86_64/emacs-cmake/setup.hint
-Tony
[ITP] hidapi 0.8.0-rc1
Dear all, I would like to package hidapi and propose it for inclusion in Cygwin. hidapi is a multi-platform library which allows an application to interface with USB and Bluetooth HID-Class devices on Windows, Linux, and Mac OS X. hidapi has been included in many Linux distributions. My proposed setup.hint: category: Devel requires: sdesc: USB HID library for Win64 toolchain ldesc: C Library for USB/Bluetooth HID device access from Linux, Mac OS X, FreeBSD, and Windows. The package build successfully and everything works for me. The package files are available for inspection from: https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.x86_64/setup.hint https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.x86_64/mingw64-x86_64-hidapi-0.8.0-rc1-1-src.tar.xz https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.x86_64/mingw64-x86_64-hidapi-0.8.0-rc1-1.tar.xz https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.x86_64/setup-debuginfo.hint https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.x86_64/mingw64-x86_64-hidapi-debuginfo-0.8.0-rc1-1.tar.xz https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.i686/setup.hint https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.i686/mingw64-i686-hidapi-0.8.0-rc1-1-src.tar.xz https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.i686/mingw64-i686-hidapi-0.8.0-rc1-1.tar.xz https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.i686/setup-debuginfo.hint https://github.com/azru0512/cygwin/releases/download/mingw-hidapi-0.8.0-rc1.i686/mingw64-i686-hidapi-debuginfo-0.8.0-rc1-1.tar.xz Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: I just applied a bigger patch, which not only changed exit, but the way how the actual LogFile instance gets accessed in general. I removed the variable theLog entirely and now, rather than [...] Please give it a try. For your convenience I created test releases again: Built and tested OK. 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: Setup patch to keep test version if test version installed
On Feb 4 12:19, Achim Gratz wrote: Corinna Vinschen writes: I just applied a bigger patch, which not only changed exit, but the way how the actual LogFile instance gets accessed in general. I removed the variable theLog entirely and now, rather than [...] Please give it a try. For your convenience I created test releases again: Built and tested OK. Thanks for testing! I'm not going to upload this for the public yet. I'm just uploading cygwin 1.7.34, that's enough to choke on for the next couple of days :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7QZdA56zNm.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 4 10:01, Corinna Vinschen wrote: On Feb 3 22:27, Corinna Vinschen wrote: On Feb 3 22:04, Corinna Vinschen wrote: On Feb 3 21:37, Achim Gratz wrote: I'm not sure we're talking about the same thing. I've recently added code to print an error message along with the parameter usage when a wrong option or other non-parseable stuff was given instead of simply exiting with no indication other than the non-zero exit code. The changes you've just installed look good to me, but they don't touch the exit path in question: [...] I guess with those changes one could now use Log (LOG_TIMESTAMP) instead of cerr in that place and hopefully the output would appear again? I was pretty certain I tested that in both mintty and CMD, but maybe not... I was referring explicitely to the CMD prompt being too early. I didn't test the situation when specifying a wrong option, sorry. The point in the file where this occurs is somewhat early. At this point the log stuff isn't initialized and AttachConsole hasn't been called. I'll look into that, maybe it can be fixed easily. Try this: On second thought, this is still unclean. What bugs me is that the behaviour of LogFile::exit is not easier conditionalized. I'm going to change LogFile::exit to something like this: LogFile::exit (int exit_code, bool show_end_of_install_msg) This allows to separate printing the Ending cygwin install message from the exit_code and so we can exit with a non-zero exit code *and* skip showing the message. Hang on for a bit... I just applied a bigger patch, which not only changed exit, but the way how the actual LogFile instance gets accessed in general. I removed the variable theLog entirely and now, rather than LogSingleton::GetInstance ().exit (1); or extern LogFile *theLog; theLog-exit (1); you can simply use the macro Logger: Logger ().exit (1); I also moved the global variable exit_msg into the LogFile class as static, protected variable, and now you access it via Logger ().setExitMsg (42); Logger ().getExitMsg (); This is much cleaner IMHO. Please give it a try. For your convenience I created test releases again: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPc4F71xI80.pgp Description: PGP signature
cmake update needed
Hi, I am starting to find programs with CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 2.8.10 or higher is required. You are running version 2.8.9 no problem (yet) on 64 bit but on 32bit yes. 2.8.9 package was released 2.5 years ago, and the 64bit version is due to Yaakov. Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Regards Marco
Re: cmake update needed
On Feb 4, 2015, at 3:40 PM, Tony Kelman t...@kelman.net wrote: Happy to adopt it. BASEURL=https://dl.dropboxusercontent.com/u/8244638/cygwin-cmake By “adopt,” you are offering to participate in the package contribution system, which involves a bit more than just putting tarballs in a shared Dropbox folder: https://cygwin.com/setup.html
Re: cmake update needed
On Wed, 2015-02-04 at 16:08 -0800, Tony Kelman wrote: Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. Sure. Were the reasons for them ever written down? If I'm going to maintain the package, I do not want to carry local patches forever. Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread CMake's test suite is very extensive, if it's missing use cases that are specific to Cygwin then I'm sure upstream would be willing to add add more tests to catch them in the future. I'm willing to pursue upstreaming the patches wherever possible, but need test cases to do so. I've made this request once or twice before and it was ignored. All these patches are the result of years of real-world usage of cmake, and there will likely be more patches required in the future. I can't tell you off the top of my head which packages require each of these changes, but I can tell you why they are necessary (and a few of them should be quite obvious). -- Yaakov
