Re: cmake update needed
Do you have any specific questions?
2.8.9-perl-libs.patch AIUI changes PERL_POSSIBLE_LIBRARY_NAMES from
being set to "perl{PERL_VERSION_STRING} perl" only when the command
`${PERL_EXECUTABLE} -V:libperl` fails, to appending those values any
time PERL_EXECUTABLE is found. Is that command expected to fail in some
circumstances where one would be building a perl library? Or is the
problem that cmake find_library has trouble with the cyg* library prefix?
2.8.12-gui-qt4, 2.8.12-opengl, 2.8.12-ruby, and 2.8.12-tclsh look pretty
straightforward and worth upstreaming. Should I assume you have not yet
tried to do so?
#-cygwin.patch, which I had to rebase a few times to apply to the latest
release, does multiple things (good sign it should have been split into
multiple patches):
First, it disables case-insensitive matching. I see that there are some
non-default/experimental ways of running Cygwin in case sensitive mode,
but that is a runtime configuration. Most users are probably running with
case-insensitive default NTFS. If this change fixes more issues than it
causes I can take your word on it, but this would be hard to convince
upstream about. Is case sensitive matching really the right build-time
behavior to choose for Cygwin's cmake package?
Second, it corrects some /proc/cpuinfo, /proc/meminfo, etc special-casing
of Cygwin where using the same code as Linux should work. Makes sense,
I'll split this out so it can be discussed on its own w/upstream.
Lastly, it's disabling handling of Windows paths, and conversion from
Cygwin paths to Windows paths. It does look like PathCygwinToWin32 could
go away if the only place it's used in FileExists is changed to just use
access(). Upstream might find this and the change to FileIsFullPath
debatable though, since a use case for a decent number of people is
running cmake within Cygwin to drive non-Cygwin compilers. Should we
really ignore this use case?
Thanks,
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: MinGW 64 bit: -- 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." -- MinGW 32 bit: -- category: Devel requires: sdesc: "USB HID library for Win32 toolchain" ldesc: "C Library for USB/Bluetooth HID device access from Linux, Mac OS X, FreeBSD, and Windows." -- Cygwin libhidapi0 32/64 bit: -- category: Libs requires: sdesc: "USB HID library" ldesc: "C Library for USB/Bluetooth HID device access from Linux, Mac OS X, FreeBSD, and Windows." external-source: hidapi -- Cygwin libhidapi-devel 32/64 bit: -- category: Libs requires: libhidapi0 sdesc: "USB HID library" ldesc: "C Library for USB/Bluetooth HID device access from Linux, Mac OS X, FreeBSD, and Windows." external-source: hidapi -- 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 https://github.com/azru0512/cygwin/releases/download/hidapi-0.8.0-rc1.x86_64/hidapi-0.8.0-rc1-1.x86_64.tar.xz https://github.com/azru0512/cygwin/releases/download/hidapi-0.8.0-rc1.i686/hidapi-0.8.0-rc1-1.i686.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
Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes:
> ...in other words, just drop the last three lines in your setup.hint,
> and the external-source hint.
Done.
I noticed just in time that the preremove scripts can't be dash scripts
at the moment.
Here's a patch to change that and also allow ".cmd" scripts, just like
already done for postinstall scripts:
install.cc: allow .dash and .cmd extensions for preremove scripts also
Modified install.cc
diff --git a/install.cc b/install.cc
index 60c248d..653d623 100644
--- a/install.cc
+++ b/install.cc
@@ -160,10 +160,12 @@ Installer::preremoveOne (packagemeta & pkg)
Progress.SetText1 ("Running preremove script...");
Progress.SetText2 (pkg.name.c_str());
Log (LOG_PLAIN) << "Running preremove script for " << pkg.name << endLog;
- try_run_script ("/etc/preremove/", pkg.name, ".sh");
- try_run_script ("/etc/preremove/", pkg.name, ".bat");
+ const unsigned numexts = 4;
+ const char* exts[numexts] = { ".dash", ".sh", ".bat", ".cmd" };
+ for (unsigned i = 0; i < numexts; i++)
+try_run_script ("/etc/preremove/", pkg.name, exts[i]);
}
void
Installer::uninstallOne (packagemeta & pkg)
{
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
Marco Atzeri writes: > done. > You are no co-owner with Corinna Great, just in time to re-trigger the upload before the next sync. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On 2/5/2015 8:18 PM, Achim Gratz wrote: Corinna Vinschen writes: With that out of the way… can someone please hand over (co-)ownership of _autorebase in cygwin-pkg-maint and !packages to me so that I can actually upload the new package? done. You are no co-owner with Corinna Regards, Achim. Marco
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: >> The pending update is currently blocked by a duplicate python-doc >> package... > > I just had a look and there's no x86/release/python/python-doc directory. > It must have been removed in the last couple of minutes. With that out of the way… can someone please hand over (co-)ownership of _autorebase in cygwin-pkg-maint and !packages to me so that I can actually upload the new package? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
Reini Urban writes: >> I expect them to be compatible, but I haven't tested that assumption yet. > You need to keep the useint* and usemymalloc settings from 5.14.2, then > it should be ok. I'll check again but I don't think these have been altered for 5.14.4. > For the new 5.22 one you need to disable usemymalloc and remove the > "_0"/".0" suffix in > the dll and archname directory name to provide seemless upgrades to > 5.22.1 and 5.22.2 I'll get to that later, but I expect that eercise to be roughly the same as what we have to do now? Or has the build system changed that much? > later, to fix the .0 bugs. Typically a .0 perl release is of very poor > quality. I'll only put the .0 out for testing, the first non-test release will likely be .1 -- but let's see what happens. In any case this is why I wanted to have a solid 5.14.4 base in case it takes a while for things to get in order. 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: perl-5.14.4
Reini Urban writes: > Which SHA1? In the filenames of my patches? Yes. > Probably old rebased away commits in rurban/perl.git branch cygwin, > sorry. Do you need them? OK, that would explain things. I guess I can still find them by the title... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: perl-5.14.4
On 02/04/2015 11:10 PM, Achim Gratz wrote: > 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. You need to keep the useint* and usemymalloc settings from 5.14.2, then it should be ok. For the new 5.22 one you need to disable usemymalloc and remove the "_0"/".0" suffix in the dll and archname directory name to provide seemless upgrades to 5.22.1 and 5.22.2 later, to fix the .0 bugs. Typically a .0 perl release is of very poor quality. The plan sounds good.
Re: perl-5.14.4
On 02/05/2015 05:13 PM, Achim Gratz wrote: > BTW, does anyone know what repository the SHA1 in the patch files refer > to? One of them is in the official perl.git, but the rest I cannot find > in either rurban/perl.git nor the Cygports repository. > > > Regards, > Achim. Which SHA1? In the filenames of my patches? Probably old rebased away commits in rurban/perl.git branch cygwin, sorry. Do you need them?
Re: Setup patch to keep test version if test version installed
Yaakov Selkowitz writes: >> The pending update is currently blocked by a duplicate python-doc >> package... > > Yes, we know; it's fixed now. Rats, it had removed the !ready files before the transfer took place. I'll have to arm it again. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: perl-5.14.4
BTW, does anyone know what repository the SHA1 in the patch files refer to? One of them is in the official perl.git, but the rest I cannot find in either rurban/perl.git nor the Cygports repository. 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 5 16:24, Achim Gratz wrote: > Achim Gratz writes: > > Corinna Vinschen writes: > >> ...in other words, just drop the last three lines in your setup.hint, > >> and the external-source hint. > > > > Uploaded. Let's see what upset does with this. > > The pending update is currently blocked by a duplicate python-doc > package... I just had a look and there's no x86/release/python/python-doc directory. It must have been removed in the last couple of minutes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpuDqVNGZ8V6.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Thu, 2015-02-05 at 16:24 +0100, Achim Gratz wrote: > Achim Gratz writes: > > Corinna Vinschen writes: > >> ...in other words, just drop the last three lines in your setup.hint, > >> and the external-source hint. > > > > Uploaded. Let's see what upset does with this. > > The pending update is currently blocked by a duplicate python-doc > package... Yes, we know; it's fixed now. Yaakov
Re: Setup patch to keep test version if test version installed
Achim Gratz writes: > Corinna Vinschen writes: >> ...in other words, just drop the last three lines in your setup.hint, >> and the external-source hint. > > Uploaded. Let's see what upset does with this. The pending update is currently blocked by a duplicate python-doc package... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: > ...in other words, just drop the last three lines in your setup.hint, > and the external-source hint. Uploaded. Let's see what upset does with this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: cmake update needed
> On Feb 4 12:45, 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. > > Super, thanks a lot. I added you to cmake in cygwin-pkg-maint, so, > whenever you're ready, feel free to upload. > > Downside: You have to accept a goldstar ;) POW hit-and-run gold star at http://cygwin.com/goldstars/#TK
Re: Setup patch to keep test version if test version installed
On Thu, 2015-02-05 at 09:57 +0100, Corinna Vinschen wrote: > On Feb 2 10:17, Corinna Vinschen wrote: > > On Jan 30 20:13, Achim Gratz wrote: > > > Corinna Vinschen writes: > > > > Btw., when, do you think, is showtime for _autorebase 2.0? > > > > > > Sometime during the next week would be good, if not then another window > > > > I'm on vaca today, but this week sounds good to me. I will release > > 1.7.34, too, later this week. > > > > > would be two weeks later. From the responses so far I gathered that > > > Marco doesn#t think he needs to do something for Octave and R, I will > > > take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov > > > and Jason need to tell us when things are ready on their side I'd think. > > > > Well, Jason has dropped maintaiwnrship, so it's Yaakov. Yaakov? > > Yaakov, can we *please* get this done so we can upload the new > _autorebase? Don't wait for me, my queue is a bit backlogged at the moment. -- Yaakov
Re: cmake update needed
On Wed, 2015-02-04 at 22:37 -0800, Tony Kelman wrote: > > 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. With far too much time and effort expended, something I'm not eager to repeat. > > 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. As I said, I can't tell you any more which packages failed without these packages. Half of the patches should be obvious. Do you have any specific questions? -- Yaakov
Re: cmake update needed
On 2/5/2015 7:37 AM, Tony Kelman wrote: 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. yes, it took a bit of diplomacy and a lot of patience. I recommend the same for the future. 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. More easy to convince upstream if you know that also. -Tony Thanks for taking over Marco
Re: Setup patch to keep test version if test version installed
On Feb 5 10:19, Corinna Vinschen wrote: > On Feb 5 10:12, Achim Gratz wrote: > > Corinna Vinschen writes: > > > Yaakov, can we *please* get this done so we can upload the new > > > _autorebase? > > > > I guess we can do it anyway, it's not creating a new problem if these > > files are provided a few days later. Let me know when you've switched > > off the _autorebase autodep and version increment stuff and I'll upload > > the package. > > The autodep stuff is automatically removed as soon as you overwrite > _autorebase'es setup.hint file since everything is code in there: s/code/coded/ > sdesc: "Run rebaseall automatically" > #external-source: rebase > category: _PostInstallLast > requires: > noautodep: cygwin > autodep: .*/[^/]*\.(?:dll|so|oct)$ > incver_ifdep: yes ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAEgpWxX00T.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 5 10:12, Achim Gratz wrote: > Corinna Vinschen writes: > > Yaakov, can we *please* get this done so we can upload the new > > _autorebase? > > I guess we can do it anyway, it's not creating a new problem if these > files are provided a few days later. Let me know when you've switched > off the _autorebase autodep and version increment stuff and I'll upload > the package. The autodep stuff is automatically removed as soon as you overwrite _autorebase'es setup.hint file since everything is code in there: sdesc: "Run rebaseall automatically" #external-source: rebase category: _PostInstallLast requires: noautodep: cygwin autodep: .*/[^/]*\.(?:dll|so|oct)$ incver_ifdep: yes Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptNQEZCXum3.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: > Yaakov, can we *please* get this done so we can upload the new > _autorebase? I guess we can do it anyway, it's not creating a new problem if these files are provided a few days later. Let me know when you've switched off the _autorebase autodep and version increment stuff and I'll upload the package. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On Feb 2 10:17, Corinna Vinschen wrote: > On Jan 30 20:13, Achim Gratz wrote: > > Corinna Vinschen writes: > > > Btw., when, do you think, is showtime for _autorebase 2.0? > > > > Sometime during the next week would be good, if not then another window > > I'm on vaca today, but this week sounds good to me. I will release > 1.7.34, too, later this week. > > > would be two weeks later. From the responses so far I gathered that > > Marco doesn#t think he needs to do something for Octave and R, I will > > take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov > > and Jason need to tell us when things are ready on their side I'd think. > > Well, Jason has dropped maintaiwnrship, so it's Yaakov. Yaakov? Yaakov, can we *please* get this done so we can upload the new _autorebase? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPMipYSbhzW.pgp Description: PGP signature
Re: [ITP] hidapi 0.8.0-rc1
Hi Chen, On Feb 5 09:03, 陳韋任 wrote: > 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. This package is a Mingw package, not a Cygwin package. That limits its usage within the Cygwin distro. Would it be very hard to build the package as Cygwin package instead? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfdhPt5ZgOh.pgp Description: PGP signature
Re: perl-5.14.4
On Feb 4 21:41, Achim Gratz wrote: > 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? Sounds perfect to me. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpT02KLk2Wzy.pgp Description: PGP signature
Re: cmake update needed
On Feb 4 12:45, 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. Super, thanks a lot. I added you to cmake in cygwin-pkg-maint, so, whenever you're ready, feel free to upload. Downside: You have to accept a goldstar ;) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgC8MSp14VO.pgp Description: PGP signature
