* 64-bit: Missing perl modules @ 2014-04-05 21:42 David Stacey 2014-04-06 6:32 ` Achim Gratz 0 siblings, 1 reply; 37+ messages in thread From: David Stacey @ 2014-04-05 21:42 UTC (permalink / raw) To: cygwin-apps 32-bit Cygwin has a 'perl_vendor' package, which contains a number of perl modules that are not present in 64-bit Cygwin. Specifically, I am interested in the following perl modules: Devel::Symdump Pod::Coverage Test::Pod Test::Pod::Coverage These are all available in the 'perl_vendor' package in 32-bit Cygwin, but missing from 64-bit. Reini: I am aware that you maintain these modules in the 32-bit distribution through the 'perl_vendor' package. I don't want to tread on any toes, and I don't know what plans you have for 'perl_vendor'. However, I would like to see these modules in 64-bit Cygwin, and would be happy to maintain them myself if you would prefer not to do so. Please let me know how you would like to proceed. If you were happy for me to maintain these perl modules then I can send an ITP for four separate packages. These would be in 64-bit Cygwin only (unless 'perl_vendor' was to become obsolete). Obviously, I would be equally happy for you to provide a 64-bit 'perl_vendor' if you thought that was the right thing to do. Cheers, Dave. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-05 21:42 64-bit: Missing perl modules David Stacey @ 2014-04-06 6:32 ` Achim Gratz 2014-04-06 15:37 ` David Stacey 0 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-04-06 6:32 UTC (permalink / raw) To: cygwin-apps David Stacey writes: > Reini: I am aware that you maintain these modules in the 32-bit > distribution through the 'perl_vendor' package. I don't want to tread > on any toes, and I don't know what plans you have for > 'perl_vendor'. You might want to check the archives for an earlier discussion about perl_vendor. https://sourceware.org/ml/cygwin-apps/2012-08/msg00006.html TL;DR: I'm locally keeping perl_vendor as an "umbrella" package that just provides dependencies and package each Perl dstribution separately. I've progressed to have two more of these umbrella packages, specifically one that collects all the Perl distributions I only need to build other distributions with (that are not already in perl_vendor) and another that collects all the distributions for our data analysis. The dependencies among these packages never reference the umbrella packages, so they are strictly for convenience of installing a bunch of Perl distributions via a single package. The cygport files for each Perl distribution are auto-generated (while using some changes to cygport that Yaakov hasn't accepted upstream). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-06 6:32 ` Achim Gratz @ 2014-04-06 15:37 ` David Stacey 2014-04-06 16:38 ` Achim Gratz 0 siblings, 1 reply; 37+ messages in thread From: David Stacey @ 2014-04-06 15:37 UTC (permalink / raw) To: cygwin-apps On 06/04/14 07:32, Achim Gratz wrote: > David Stacey writes: >> Reini: I am aware that you maintain these modules in the 32-bit >> distribution through the 'perl_vendor' package. I don't want to tread >> on any toes, and I don't know what plans you have for >> 'perl_vendor'. > You might want to check the archives for an earlier discussion about > perl_vendor. > > https://sourceware.org/ml/cygwin-apps/2012-08/msg00006.html Thank you for your reply. Yes, I was aware of that discussion. I'm not talking about breaking up 'perl_vendor' for 32-bit Cygwin (although IMHO that would be a good thing in the long term). I'd just like to see the perl modules I mentioned adding to 64-bit Cygwin - and I'm happy to maintain those packages myself if no-one else want to claim ownership. Dave. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-06 15:37 ` David Stacey @ 2014-04-06 16:38 ` Achim Gratz 2014-04-06 18:59 ` David Stacey 0 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-04-06 16:38 UTC (permalink / raw) To: cygwin-apps David Stacey writes: > Thank you for your reply. Yes, I was aware of that discussion. I'm not > talking about breaking up 'perl_vendor' for 32-bit Cygwin (although > IMHO that would be a good thing in the long term). I'd just like to > see the perl modules I mentioned adding to 64-bit Cygwin - and I'm > happy to maintain those packages myself if no-one else want to claim > ownership. I don't see why it should be a good idea to have different packaging for the two architectures, so I still think this issue needs to be decided. Anyway, here's what I have: --8<---------------cut here---------------start------------->8--- wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/x86_64/release" ${wget}/perl-Devel-Symdump/perl-Devel-Symdump-2.11-2-src.tar.xz ${wget}/perl-Devel-Symdump/perl-Devel-Symdump-2.11-2.tar.xz ${wget}/perl-Devel-Symdump/setup.hint ${wget}/perl-Test-Pod-Coverage/perl-Test-Pod-Coverage-1.08-4-src.tar.xz ${wget}/perl-Test-Pod-Coverage/perl-Test-Pod-Coverage-1.08-4.tar.xz ${wget}/perl-Test-Pod-Coverage/setup.hint ${wget}/perl-Test-Pod/perl-Test-Pod-1.48-2.tar.xz ${wget}/perl-Test-Pod/perl-Test-Pod-1.48-2-src.tar.xz ${wget}/perl-Test-Pod/setup.hint ${wget}/perl-Pod-Coverage/perl-Pod-Coverage-0.23-2.tar.xz ${wget}/perl-Pod-Coverage/perl-Pod-Coverage-0.23-2-src.tar.xz ${wget}/perl-Pod-Coverage/setup.hint --8<---------------cut here---------------end--------------->8--- The last communication from Reini was that he was getting ready for a new Perl release and I think we should wait for how he wants to handle perl_vendor for that release. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-06 16:38 ` Achim Gratz @ 2014-04-06 18:59 ` David Stacey 2014-04-07 18:54 ` Reini Urban 0 siblings, 1 reply; 37+ messages in thread From: David Stacey @ 2014-04-06 18:59 UTC (permalink / raw) To: cygwin-apps On 06/04/14 17:38, Achim Gratz wrote: > David Stacey writes: >> Thank you for your reply. Yes, I was aware of that discussion. I'm not >> talking about breaking up 'perl_vendor' for 32-bit Cygwin (although >> IMHO that would be a good thing in the long term). I'd just like to >> see the perl modules I mentioned adding to 64-bit Cygwin - and I'm >> happy to maintain those packages myself if no-one else want to claim >> ownership. > I don't see why it should be a good idea to have different packaging for > the two architectures, so I still think this issue needs to be decided. Agreed. Hopefully the different collections of perl modules that are available in the two architectures can be unified with the next perl release. > Anyway, here's what I have: Yes, those are more or less identical to the packages that I prepared - I could have done with those links a few days ago :-) It's rather nice (albeit inefficient) to have two people trying to do the same thing - so often in open source programmes no-one has the time! You've obviously put some thought and effort into this, so I'm happy to step back and let you (or Reini) to maintain these perl modules. The important thing is that they end up in 64-bit Cygwin at some point. Thankfully, cygport makes most perl modules absurdly easy to maintain. So if you need someone to adopt a few if and when 'perl_vendor' gets split up then please let me know. Dave. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-06 18:59 ` David Stacey @ 2014-04-07 18:54 ` Reini Urban 2014-04-07 19:30 ` Achim Gratz 2014-04-08 16:20 ` 64-bit: Missing perl modules David Stacey 0 siblings, 2 replies; 37+ messages in thread From: Reini Urban @ 2014-04-07 18:54 UTC (permalink / raw) To: cygwin-apps On Sun, Apr 6, 2014 at 1:59 PM, David Stacey wrote: > On 06/04/14 17:38, Achim Gratz wrote: >> >> David Stacey writes: >>> >>> Thank you for your reply. Yes, I was aware of that discussion. I'm not >>> talking about breaking up 'perl_vendor' for 32-bit Cygwin (although >>> IMHO that would be a good thing in the long term). I'd just like to >>> see the perl modules I mentioned adding to 64-bit Cygwin - and I'm >>> happy to maintain those packages myself if no-one else want to claim >>> ownership. >> >> I don't see why it should be a good idea to have different packaging for >> the two architectures, so I still think this issue needs to be decided. > > > Agreed. Hopefully the different collections of perl modules that are > available in the two architectures can be unified with the next perl > release. > > >> Anyway, here's what I have: > > > Yes, those are more or less identical to the packages that I prepared - I > could have done with those links a few days ago :-) It's rather nice (albeit > inefficient) to have two people trying to do the same thing - so often in > open source programmes no-one has the time! You've obviously put some > thought and effort into this, so I'm happy to step back and let you (or > Reini) to maintain these perl modules. The important thing is that they end > up in 64-bit Cygwin at some point. > > Thankfully, cygport makes most perl modules absurdly easy to maintain. So if > you need someone to adopt a few if and when 'perl_vendor' gets split up then > please let me know. > > Dave. The new 5.18.2 package will be unified for 32bit and 64bit, yes. perl_vendor will probably stay as is, as it is the easiest for the user and the maintainer. I still need to rebase all most-used XS modules esp. on 32bit perl to make sense and avoid dll base collisions on forks, which happens with CPAN, a basic bootstrap problem. My cygwin-specific rebase framework for CPAN modules still needs some love, esp. on 32bit. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-07 18:54 ` Reini Urban @ 2014-04-07 19:30 ` Achim Gratz 2014-04-07 21:31 ` Reini Urban 2014-04-08 16:20 ` 64-bit: Missing perl modules David Stacey 1 sibling, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-04-07 19:30 UTC (permalink / raw) To: cygwin-apps Reini Urban writes: > The new 5.18.2 package will be unified for 32bit and 64bit, yes. Looking forward to it… > perl_vendor will probably stay as is, as it is the easiest for the > user and the maintainer. I beg to differ. It would be vastly easier for everyone if perl_vendor simply depended on those packages that are now hidden inside it. Let me know what's inside the new perl_vendor and I'll help to produce those single distribution packages. > I still need to rebase all most-used XS modules esp. on 32bit perl to > make sense and avoid dll base collisions on forks, which happens with > CPAN, a basic bootstrap problem. I've not been doing that for more than two years now and have actually backed out the respective changes in MakeMaker, IIRC. As long as I'm using cygport I'm not running into problems (except for PDL since this produces several DLL that initially occupy the same address space, which is easily taken care of with an ephemeral rebase before testing). > My cygwin-specific rebase framework for CPAN modules still needs some > love, esp. on 32bit. I'm doing incremental auto-rebase on install, YMMV. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-07 19:30 ` Achim Gratz @ 2014-04-07 21:31 ` Reini Urban 2014-04-08 18:02 ` Achim Gratz 0 siblings, 1 reply; 37+ messages in thread From: Reini Urban @ 2014-04-07 21:31 UTC (permalink / raw) To: cygwin-apps On Mon, Apr 7, 2014 at 2:29 PM, Achim Gratz wrote: > Reini Urban writes: >> The new 5.18.2 package will be unified for 32bit and 64bit, yes. > > Looking forward to it... > >> perl_vendor will probably stay as is, as it is the easiest for the >> user and the maintainer. > > I beg to differ. It would be vastly easier for everyone if perl_vendor > simply depended on those packages that are now hidden inside it. Let me > know what's inside the new perl_vendor and I'll help to produce those > single distribution packages. Nope. >> I still need to rebase all most-used XS modules esp. on 32bit perl to >> make sense and avoid dll base collisions on forks, which happens with >> CPAN, a basic bootstrap problem. > > I've not been doing that for more than two years now and have actually > backed out the respective changes in MakeMaker, IIRC. As long as I'm > using cygport I'm not running into problems (except for PDL since this > produces several DLL that initially occupy the same address space, which > is easily taken care of with an ephemeral rebase before testing). You can do individual perlrebase or wait for the full autorebase for every XS installation. With individual split perl_vendor packages the user needs to wait for every single rebase update. With the combined perl_vendor I'll do it as part of the build step and the user only needs to wait for one rebase run. >> My cygwin-specific rebase framework for CPAN modules still needs some >> love, esp. on 32bit. > > I'm doing incremental auto-rebase on install, YMMV. Sure, that's automatic of you care to package everything. But updates come every week, not every two years. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-07 21:31 ` Reini Urban @ 2014-04-08 18:02 ` Achim Gratz 2014-04-08 20:52 ` Reini Urban 0 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-04-08 18:02 UTC (permalink / raw) To: cygwin-apps Reini Urban writes: > Nope. Care to explain? > You can do individual perlrebase or wait for the full autorebase for > every XS installation. Or do an ephemeral rebase that is taking the rebase map of the rest of the system correctly into account. > With individual split perl_vendor packages the user needs to wait for > every single rebase update. No. You can run the incremental rebase directly if you wish and as long as the rest of the system had been rebased correctly it will only touch the new stuff. > With the combined perl_vendor I'll do it as part of the build step and > the user only needs to wait for one rebase run. You wouldn't need a special perlrebase for that, that's the whole point. > Sure, that's automatic of you care to package everything. > But updates come every week, not every two years. In my case I have to package things anyway since I need to distribute the to a bunch of machines that have no outward connection. Besides the need for an internal CPAN mirror, I'd generally not trust a random user to run a CPAN update and make a judgment of whether or not everything worked as expected. Packaging some 300 Perl distributions really is less work than any of the alternatives and keeping things up-to-date isn't all that time-consuming so far. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-08 18:02 ` Achim Gratz @ 2014-04-08 20:52 ` Reini Urban 2014-04-08 21:27 ` Achim Gratz ` (2 more replies) 0 siblings, 3 replies; 37+ messages in thread From: Reini Urban @ 2014-04-08 20:52 UTC (permalink / raw) To: cygwin-apps On Tue, Apr 8, 2014 at 1:01 PM, Achim Gratz wrote: > Reini Urban writes: >> Nope. > > Care to explain? Already did. It's vastly easier to keep perl_vendor than to split it up. For all parties. >> You can do individual perlrebase or wait for the full autorebase for >> every XS installation. > > Or do an ephemeral rebase that is taking the rebase map of the rest of > the system correctly into account. Only if you register each and every user module with the system. But we don't want that. I know that you want to cygport every single perl module, but this is a very extreme position. >> With individual split perl_vendor packages the user needs to wait for >> every single rebase update. > > No. You can run the incremental rebase directly if you wish and as long > as the rest of the system had been rebased correctly it will only touch > the new stuff. > >> With the combined perl_vendor I'll do it as part of the build step and >> the user only needs to wait for one rebase run. > > You wouldn't need a special perlrebase for that, that's the whole point. True. With proper EUMM and MB integration we would need no perlrebase. But MB is a mess. And Module::Install even more. And I wonder what will come up next. MB::Lite is already in the works just to bypass GNU make. >> Sure, that's automatic of you care to package everything. >> But updates come every week, not every two years. > > In my case I have to package things anyway since I need to distribute > the to a bunch of machines that have no outward connection. Besides the > need for an internal CPAN mirror, I'd generally not trust a random user > to run a CPAN update and make a judgment of whether or not everything > worked as expected. Packaging some 300 Perl distributions really is > less work than any of the alternatives and keeping things up-to-date > isn't all that time-consuming so far. Fair enough. But then I would keep them uptodate with a simple cpan or rsync, which is better than setup.exe. No need to stop all services. I maintain about 40 VM's this way, cross-version and platform. cpan ensures proper testing and with CPAN::Reporter being integrated the authors even get feedback. strawberry perl does the same. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-08 20:52 ` Reini Urban @ 2014-04-08 21:27 ` Achim Gratz 2014-04-09 14:13 ` Reini Urban 2014-04-09 5:20 ` Yaakov (Cygwin/X) 2014-05-02 8:22 ` perl-5.18.2-1 (was: 64-bit: Missing perl modules) Achim Gratz 2 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-04-08 21:27 UTC (permalink / raw) To: cygwin-apps Reini Urban writes: > Already did. It's vastly easier to keep perl_vendor than to split it up. > For all parties. Then consider me not a party. For me keeping perl_vendor an opaque bundle is making things more difficult. I could special-case it into all the dependecy tests, but seeing that unbundling it is actually easier, I don't see why I should. This unbundling lets me update individual distributions from perl_vendor independently, which has been quite useful. >>> You can do individual perlrebase or wait for the full autorebase for >>> every XS installation. >> >> Or do an ephemeral rebase that is taking the rebase map of the rest of >> the system correctly into account. > > Only if you register each and every user module with the system. > But we don't want that. Wait, weren't we talking about vendor-perl, possibly site-perl? These two locations are already "registered with the system". The only head-scratcher for me are always inline modules compiled on the fly and stuffed into private directories. Rebase doesn't provide for any private libraries and really it can't since this is a system-wide issue. > I know that you want to cygport every single perl module, but this is a very > extreme position. Again, as long as CPAN or cpanm or whatever honors @INC, the next incremental rebase keeps things in order. The same for ruby and octave. I've explained why I package all distributions and why opaque bundles are unhelpful, but this has nothing whatsoever to do with the need for rebasing. > True. With proper EUMM and MB integration we would need no perlrebase. > But MB is a mess. And Module::Install even more. And I wonder what will > come up next. MB::Lite is already in the works just to bypass GNU make. We'll see how this works. Today I've dealt with that bright idea to "protect" the UNTAINT test in Inline. That really doesn't work that way in Cygwin and I'm still not sure what it is supposed to protect me from (ending up with an empty path). > Fair enough. But then I would keep them uptodate with a simple cpan or > rsync, which is better than setup.exe. No can do, even if it was better. > No need to stop all services. Really, there's a lot more stuff our IT does that stops services than a Cygwin update. > cpan ensures proper testing and with CPAN::Reporter being integrated > the authors even get feedback. Again, not something that I can do and not the point of our discussion, which was the opaque bundling within perl_vendor. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-08 21:27 ` Achim Gratz @ 2014-04-09 14:13 ` Reini Urban 0 siblings, 0 replies; 37+ messages in thread From: Reini Urban @ 2014-04-09 14:13 UTC (permalink / raw) To: cygwin-apps On Tue, Apr 8, 2014 at 4:27 PM, Achim Gratz wrote: > Reini Urban writes: >> Only if you register each and every user module with the system. >> But we don't want that. > > Wait, weren't we talking about vendor-perl, possibly site-perl? These > two locations are already "registered with the system". The only > head-scratcher for me are always inline modules compiled on the fly and > stuffed into private directories. Rebase doesn't provide for any > private libraries and really it can't since this is a system-wide issue. So why are you discussing this with me that long when you have no idea how the systems works, and how it should work? FYI: vendor-perl is provided by perl_vendor and pre-rebased, and then post-rebased by setup. site-perl is populated by cpan and rebased with EUMM hooks and perlrebase. Without proper rebasing of all dll's perl will not be able to fork or call itself, and it does it very often. The most prominent case being EUMM and CPAN. This is only an issue for 32 bit, 64 bit has a much friendlier address space. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-08 20:52 ` Reini Urban 2014-04-08 21:27 ` Achim Gratz @ 2014-04-09 5:20 ` Yaakov (Cygwin/X) 2014-04-09 18:02 ` Achim Gratz 2014-05-02 8:22 ` perl-5.18.2-1 (was: 64-bit: Missing perl modules) Achim Gratz 2 siblings, 1 reply; 37+ messages in thread From: Yaakov (Cygwin/X) @ 2014-04-09 5:20 UTC (permalink / raw) To: cygwin-apps On 2014-04-08 15:52, Reini Urban wrote: > On Tue, Apr 8, 2014 at 1:01 PM, Achim Gratz wrote: >> Reini Urban writes: >>> Nope. >> >> Care to explain? > > Already did. It's vastly easier to keep perl_vendor than to split it up. > For all parties. Obviously, it's not, because perl_vendor hasn't been updated for almost two years. That is evidence enough to me that having to rebuild perl core and dozens of extra modules just to update or add a single CPAN module isn't feasible. >>> You can do individual perlrebase or wait for the full autorebase for >>> every XS installation. >> >> Or do an ephemeral rebase that is taking the rebase map of the rest of >> the system correctly into account. > > Only if you register each and every user module with the system. > But we don't want that. Yes, we do want to have packages for all Perl modules required by other packages. Telling users "oh, if you want to make this Cygwin package work, go install the modules from CPAN" is not a viable solution. > I know that you want to cygport every single perl module, but this is a very > extreme position. No, it's not. We're not talking about all of CPAN here, just those modules which are needed by other packages; even with the typical recursiveness of CPAN dependencies, it's not all that many packages. >>> With the combined perl_vendor I'll do it as part of the build step and >>> the user only needs to wait for one rebase run. >> >> You wouldn't need a special perlrebase for that, that's the whole point. > > True. With proper EUMM and MB integration we would need no perlrebase. > But MB is a mess. And Module::Install even more. And I wonder what will > come up next. MB::Lite is already in the works just to bypass GNU make. That's not what he meant. With _autorebase, there is no need for special rebasing of perl modules shipped in vendor_perl by the distro (or Ports), they will be rebased by setup during postinstall. As for those installed into site_perl, I think it would be an improvement to make rebaseall specifically look for those, knowing that they won't be registered otherwise. (Same could be said for Python's easy_install, Ruby's gem, R's CMD INSTALL, and PHP's pecl, except that not all of those have a site/vendor split.) >>> Sure, that's automatic of you care to package everything. >>> But updates come every week, not every two years. >> >> In my case I have to package things anyway since I need to distribute >> the to a bunch of machines that have no outward connection. Besides the >> need for an internal CPAN mirror, I'd generally not trust a random user >> to run a CPAN update and make a judgment of whether or not everything >> worked as expected. Packaging some 300 Perl distributions really is >> less work than any of the alternatives and keeping things up-to-date >> isn't all that time-consuming so far. +1 > Fair enough. But then I would keep them uptodate with a simple cpan or > rsync, which is better than setup.exe. > No need to stop all services. > I maintain about 40 VM's this way, cross-version and platform. > > cpan ensures proper testing and with CPAN::Reporter being integrated > the authors even get feedback. > strawberry perl does the same. But that's not how Linux distributions manage Perl modules, and that's the issue here. Yaakov ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-09 5:20 ` Yaakov (Cygwin/X) @ 2014-04-09 18:02 ` Achim Gratz 0 siblings, 0 replies; 37+ messages in thread From: Achim Gratz @ 2014-04-09 18:02 UTC (permalink / raw) To: cygwin-apps Yaakov (Cygwin/X) writes: > Yes, we do want to have packages for all Perl modules required by > other packages. Telling users "oh, if you want to make this Cygwin > package work, go install the modules from CPAN" is not a viable > solution. Thanks, Yaakov. The packaging issue introduced by the opaque bundling of perl_vendor is the only point of the discussion that I care enough about to continue. In the hope that helps things along, please forget all the other remarks that do not pertain to this issue or move them to another thread or private discussion. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 (was: 64-bit: Missing perl modules) 2014-04-08 20:52 ` Reini Urban 2014-04-08 21:27 ` Achim Gratz 2014-04-09 5:20 ` Yaakov (Cygwin/X) @ 2014-05-02 8:22 ` Achim Gratz 2014-05-03 2:06 ` perl-5.18.2-1 Ken Brown ` (2 more replies) 2 siblings, 3 replies; 37+ messages in thread From: Achim Gratz @ 2014-05-02 8:22 UTC (permalink / raw) To: cygwin-apps Reini Urban writes: > It's vastly easier to keep perl_vendor than to split it up. I've been looking at the test package for the upcoming 5.18.2 release announced in http://cygwin.com/ml/cygwin-announce/2014-04/msg00038.html and I'd like to contest that assertion again. TL;DR: I still propose to keep each Perl distribution as a separate package (yes, I'm willing to ITP them) and move perl_vendor to an umbrella package that simply bundles those individual packages plus perhaps a README. Long version: First off, there is a flurry of changes in the content of perl_vendor that you didn't list in the announcement. This is exactly my gripe with opaque bundling: anyone who's been relying on perl_vendor to deliver a certain set of Perl distributions will suddenly find that some have been removed and others have been added and the only way to find that out is to look into the source archive. This also means you're going to have a package conflict if any of those distributions are packaged (either locally or in cygports) or some of your intended changes become hidden behind things in site_perl (which may or may not be the latest version or missing some of the patches you applied to vendor_perl). Secondly, some of the distributions you've removed from perl_vendor are actually run-time requirements of the modules that are in (plus a few new ones that weren't in the old perl_vendor). Packaging errors on the Perl side are a possibility (although usually these are missing dependencies, not additional ones), but barring that there's 25 more distributions that need to be delivered with perl_vendor: --8<---------------cut here---------------start------------->8--- perl-Sub-Install perl-Data-OptList perl-Encode-Locale perl-HTTP-Date perl-IO-HTML perl-LWP-MediaTypes perl-HTTP-Message perl-Sub-Exporter perl-Data-Dump perl-File-Listing perl-HTTP-Cookies perl-HTTP-Daemon perl-HTTP-Negotiate perl-Net-HTTP perl-WWW-RobotRules perl-File-Which perl-MRO-Compat perl-Capture-Tiny perl-Compress-Raw-Zlib perl-Data-Section perl-Devel-Autoflush perl-Digest-HMAC perl-Mozilla-CA perl-Text-Template perl-YAML-Syck --8<---------------cut here---------------end--------------->8--- Then there's 19 more distributions needed for building (those do not need to be in perl_vendor), bringing the total for a successful build from scratch to 125 distributions: --8<---------------cut here---------------start------------->8--- perl-Sub-Uplevel perl-Inline-Files perl-Params-Util perl-Parse-RecDescent perl-Sub-Install perl-Test-Warn perl-common-sense perl-Data-OptList perl-Encode-Locale perl-HTTP-Date perl-IO-HTML perl-Inline perl-LWP-MediaTypes perl-Types-Serialiser perl-URI perl-Capture-Tiny perl-Class-XSAccessor perl-Data-UUID perl-HTML-Tagset perl-HTTP-Message perl-IO-Tty perl-IPC-Run3 perl-JSON-XS perl-Number-Compare perl-Probe-Perl perl-Sub-Exporter perl-Text-Glob perl-Try-Tiny perl-CPAN-DistnameInfo perl-Data-Dump perl-Data-GUID perl-File-Find-Object perl-File-Find-Rule perl-File-Listing perl-HTML-Parser perl-HTTP-Cookies perl-HTTP-Daemon perl-HTTP-Negotiate perl-IO-Prompt-Tiny perl-IPC-Run perl-JSON perl-Net-HTTP perl-Test-Fatal perl-Test-Script perl-WWW-RobotRules perl-Archive-Zip perl-Compress-Bzip2 perl-Data-Compare perl-Devel-Symdump perl-File-Find-Object-Rule perl-File-Which perl-IO-CaptureOutput perl-IO-Socket-IP perl-MRO-Compat perl-Metabase-Fact perl-Module-Signature perl-Net-SSLeay perl-Test-FailWarnings perl-Test-Tester perl-Test-Without-Module perl-XML-NamespaceSupport perl-XML-SAX-Base perl-YAML-LibYAML perl-libwww-perl perl-CPAN-Checksums perl-CPAN-Testers-Report perl-Compress-Raw-Bzip2 perl-Compress-Raw-Zlib perl-Config-Tiny perl-Data-Section perl-Devel-Autoflush perl-Digest-HMAC perl-Expect perl-File-Copy-Recursive perl-File-HomeDir perl-File-Remove perl-File-chmod perl-File-pushd perl-IO-Socket-SSL perl-Metabase-Client-Simple perl-Mozilla-CA perl-PAR-Dist perl-Pod-Coverage perl-Socket6 perl-TermReadKey perl-Test-NoWarnings perl-Test-Reporter perl-Test-Requires perl-Test-TrailingSpace perl-Text-Template perl-XML-SAX perl-YAML perl-YAML-Syck perl-B-Generate perl-CPAN perl-CPAN-Inject perl-CPAN-Reporter perl-Config-Perl-V perl-Data-Alias perl-Digest-SHA perl-ExtUtils-CBuilder perl-ExtUtils-ParseXS perl-File-Temp perl-IO-Compress perl-IO-Socket-INET6 perl-IO-String perl-LWP-Protocol-https perl-Module-Build perl-Module-ScanDeps perl-Net-DNS perl-Net-IP perl-Net-Telnet perl-PadWalker perl-Pod-Escapes perl-Pod-Simple perl-Proc-ProcessTable perl-Software-License perl-Tee perl-Term-ReadLine-Gnu perl-Term-ReadLine-Perl perl-Test-Pod perl-Test-Pod-Coverage perl-Test-Reporter-Transport-Metabase perl-XML-LibXML perl-XML-Parser --8<---------------cut here---------------end--------------->8--- If you build and install these in this order, then you can bootstrap perl_vendor without using CPAN or cpanminus in about an hour or two. The dependency walker that produces the above output also produces the necessary cygport files, which only seldomly need some manual edits (mainly for setting test options). At the moment I just build from the command line, but putting this into a Makefile is certainly possible. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-02 8:22 ` perl-5.18.2-1 (was: 64-bit: Missing perl modules) Achim Gratz @ 2014-05-03 2:06 ` Ken Brown 2014-05-04 5:51 ` perl-5.18.2-1 Yaakov (Cygwin/X) 2014-05-04 7:29 ` perl-5.18.2-1 Achim Gratz 2014-05-04 17:20 ` perl-5.18.2-1 Achim Gratz 2 siblings, 1 reply; 37+ messages in thread From: Ken Brown @ 2014-05-03 2:06 UTC (permalink / raw) To: cygwin-apps On 5/2/2014 4:21 AM, Achim Gratz wrote: > Reini Urban writes: >> It's vastly easier to keep perl_vendor than to split it up. > > I've been looking at the test package for the upcoming 5.18.2 release > announced in http://cygwin.com/ml/cygwin-announce/2014-04/msg00038.html > and I'd like to contest that assertion again. > > TL;DR: I still propose to keep each Perl distribution as a separate > package (yes, I'm willing to ITP them) +1 > and move perl_vendor to an > umbrella package that simply bundles those individual packages plus > perhaps a README. I'm not even sure that such an umbrella is needed. Maintainers of packages that rely on Perl modules can simply use cygport to determine which perl-* packages are required. I don't see the need for a perl_vendor package that brings in some arbitrarily chosen collection of Perl modules. Reini, I know you think it's more work to split up perl_vendor than to keep it as is, but Achim has offered to do the work. And it would make things much easier for those of us who maintain packages that require Perl modules. With the current bundling, we have to check for each required module whether or not it's included in perl_vendor. I just did this for biber, and it's very tedious. I hope you'll reconsider. Ken ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-03 2:06 ` perl-5.18.2-1 Ken Brown @ 2014-05-04 5:51 ` Yaakov (Cygwin/X) 0 siblings, 0 replies; 37+ messages in thread From: Yaakov (Cygwin/X) @ 2014-05-04 5:51 UTC (permalink / raw) To: cygwin-apps On 2014-05-02 21:05, Ken Brown wrote: > On 5/2/2014 4:21 AM, Achim Gratz wrote: >> Reini Urban writes: >>> It's vastly easier to keep perl_vendor than to split it up. >> >> I've been looking at the test package for the upcoming 5.18.2 release >> announced in http://cygwin.com/ml/cygwin-announce/2014-04/msg00038.html >> and I'd like to contest that assertion again. >> >> TL;DR: I still propose to keep each Perl distribution as a separate >> package (yes, I'm willing to ITP them) and move perl_vendor to an >> umbrella package that simply bundles those individual packages plus >> perhaps a README. > > I'm not even sure that such an umbrella is needed. Maintainers of > packages that rely on Perl modules can simply use cygport to determine > which perl-* packages are required. I don't see the need for a > perl_vendor package that brings in some arbitrarily chosen collection of > Perl modules. > > Reini, I know you think it's more work to split up perl_vendor than to > keep it as is, but Achim has offered to do the work. And it would make > things much easier for those of us who maintain packages that require > Perl modules. With the current bundling, we have to check for each > required module whether or not it's included in perl_vendor. I just did > this for biber, and it's very tedious. I hope you'll reconsider. +1, and I'm willing to help with some of the modules as well. Yaakov ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-02 8:22 ` perl-5.18.2-1 (was: 64-bit: Missing perl modules) Achim Gratz 2014-05-03 2:06 ` perl-5.18.2-1 Ken Brown @ 2014-05-04 7:29 ` Achim Gratz 2014-05-04 8:24 ` perl-5.18.2-1 Yaakov (Cygwin/X) 2014-05-11 19:05 ` perl-5.18.2-1 Achim Gratz 2014-05-04 17:20 ` perl-5.18.2-1 Achim Gratz 2 siblings, 2 replies; 37+ messages in thread From: Achim Gratz @ 2014-05-04 7:29 UTC (permalink / raw) To: cygwin-apps Achim Gratz writes: > First off, there is a flurry of changes in the content of perl_vendor > that you didn't list in the announcement. This is exactly my gripe with > opaque bundling: anyone who's been relying on perl_vendor to deliver a > certain set of Perl distributions will suddenly find that some have been > removed and others have been added and the only way to find that out is > to look into the source archive. The residual changes would be a removal of Crypt-SSLeay and IPC-Cmd, while IPC-Run, Test-NoWarnings and Test-Tester would still be supplied by the build dependencies. Unless someone has a strong opinion that these two should be dropped, I'd continue to have them available. Going forward I think this should provide a smooth transition: 1) ITA perl_vendor and provide an umbrella plus all dependencies for perl-5.14.2. I'd use current versions for these, not the original ones from perl_vendor. 2) The re-builds and additional distributions for perl-5.18 will be provided as test versions. 3) Coinciding with the perl-5.18.2 release, move everything from test to current. 4) Optional: obsolete the perl_vendor umbrella package. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-04 7:29 ` perl-5.18.2-1 Achim Gratz @ 2014-05-04 8:24 ` Yaakov (Cygwin/X) 2014-05-04 9:36 ` perl-5.18.2-1 Achim Gratz 2014-05-11 19:05 ` perl-5.18.2-1 Achim Gratz 1 sibling, 1 reply; 37+ messages in thread From: Yaakov (Cygwin/X) @ 2014-05-04 8:24 UTC (permalink / raw) To: cygwin-apps On 2014-05-04 02:29, Achim Gratz wrote: > Achim Gratz writes: >> First off, there is a flurry of changes in the content of perl_vendor >> that you didn't list in the announcement. This is exactly my gripe with >> opaque bundling: anyone who's been relying on perl_vendor to deliver a >> certain set of Perl distributions will suddenly find that some have been >> removed and others have been added and the only way to find that out is >> to look into the source archive. > > The residual changes would be a removal of Crypt-SSLeay and IPC-Cmd, > while IPC-Run, Test-NoWarnings and Test-Tester would still be supplied > by the build dependencies. Unless someone has a strong opinion that > these two should be dropped, I'd continue to have them available. I have a few packages in Ports that require Crypt::SSLeay. Yaakov ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-04 8:24 ` perl-5.18.2-1 Yaakov (Cygwin/X) @ 2014-05-04 9:36 ` Achim Gratz 0 siblings, 0 replies; 37+ messages in thread From: Achim Gratz @ 2014-05-04 9:36 UTC (permalink / raw) To: cygwin-apps Yaakov (Cygwin/X) writes: > I have a few packages in Ports that require Crypt::SSLeay. I'll keep it, then. IPC::Run, too – I don't remember this module ever making any trouble. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-04 7:29 ` perl-5.18.2-1 Achim Gratz 2014-05-04 8:24 ` perl-5.18.2-1 Yaakov (Cygwin/X) @ 2014-05-11 19:05 ` Achim Gratz 2014-08-15 20:38 ` perl-5.18.2-1 Achim Gratz 1 sibling, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-05-11 19:05 UTC (permalink / raw) To: cygwin-apps Achim Gratz writes: > 1) ITA perl_vendor and provide an umbrella plus all dependencies for > perl-5.14.2. I'd use current versions for these, not the original ones > from perl_vendor. If you want to test this, please use http://cygwin.stromeko.net as your only or additional download site in setup.exe (you must use the -X option since the setup.ini isn't signed). This should result in an update of perl_vendor on x86 to -6, emptying the package and pulling in the individual distribution packages as dependencies. For x86_64 there's also a perl_vendor package just to more easily install all packages if you want to try that, otherwise setup should offer updates for any packages that you've already installed as dependencies for other stuff. The test packages for 5.18 will probably be put into a different directory on the same server next weekend or so. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-11 19:05 ` perl-5.18.2-1 Achim Gratz @ 2014-08-15 20:38 ` Achim Gratz 2014-08-15 21:15 ` perl-5.18.2-1 Yaakov Selkowitz 0 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-08-15 20:38 UTC (permalink / raw) To: cygwin-apps Achim Gratz writes: > Achim Gratz writes: >> 1) ITA perl_vendor and provide an umbrella plus all dependencies for >> perl-5.14.2. I'd use current versions for these, not the original ones >> from perl_vendor. > > If you want to test this, please use http://cygwin.stromeko.net as your > only or additional download site in setup.exe (you must use the -X > option since the setup.ini isn't signed). This should result in an > update of perl_vendor on x86 to -6, emptying the package and pulling in > the individual distribution packages as dependencies. Looking at my server logs there hasn't been a single access to this. Is there still interest in getting this done? 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-08-15 20:38 ` perl-5.18.2-1 Achim Gratz @ 2014-08-15 21:15 ` Yaakov Selkowitz 2014-08-15 22:01 ` perl-5.18.2-1 David Stacey 2014-08-16 7:05 ` perl-5.18.2-1 Achim Gratz 0 siblings, 2 replies; 37+ messages in thread From: Yaakov Selkowitz @ 2014-08-15 21:15 UTC (permalink / raw) To: cygwin-apps On Fri, 2014-08-15 at 22:38 +0200, Achim Gratz wrote: > Achim Gratz writes: > > Achim Gratz writes: > >> 1) ITA perl_vendor and provide an umbrella plus all dependencies for > >> perl-5.14.2. I'd use current versions for these, not the original ones > >> from perl_vendor. > > > > If you want to test this, please use http://cygwin.stromeko.net as your > > only or additional download site in setup.exe (you must use the -X > > option since the setup.ini isn't signed). This should result in an > > update of perl_vendor on x86 to -6, emptying the package and pulling in > > the individual distribution packages as dependencies. > > Looking at my server logs there hasn't been a single access to this. Is > there still interest in getting this done? Thanks for the reminder. Where did we leave off wrt breaking out perl_vendor? Yaakov ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-08-15 21:15 ` perl-5.18.2-1 Yaakov Selkowitz @ 2014-08-15 22:01 ` David Stacey 2014-08-15 22:17 ` perl-5.18.2-1 Yaakov Selkowitz 2014-08-16 7:00 ` perl-5.18.2-1 Achim Gratz 2014-08-16 7:05 ` perl-5.18.2-1 Achim Gratz 1 sibling, 2 replies; 37+ messages in thread From: David Stacey @ 2014-08-15 22:01 UTC (permalink / raw) To: cygwin-apps On 15/08/14 22:15, Yaakov Selkowitz wrote: > Where did we leave off wrt breaking out > perl_vendor? Back in April, Reini expressed a desire to keep perl_vendor, claiming that it is the easiest solution for both user and maintainer [1]. Whilst there are some of us who might question this, Reini has vastly more knowledge and experience of perl than I ever will have. So when Reini states that there are good reasons why perl_vendor should stay, I am prepared to respect his judgement. As our perl maintainer wishes to keep perl_vendor, any discussion to the contrary seems somewhat academic. Dave. [1] https://cygwin.com/ml/cygwin-apps/2014-04/msg00015.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-08-15 22:01 ` perl-5.18.2-1 David Stacey @ 2014-08-15 22:17 ` Yaakov Selkowitz 2014-08-16 7:00 ` perl-5.18.2-1 Achim Gratz 1 sibling, 0 replies; 37+ messages in thread From: Yaakov Selkowitz @ 2014-08-15 22:17 UTC (permalink / raw) To: cygwin-apps On Fri, 2014-08-15 at 23:00 +0100, David Stacey wrote: > On 15/08/14 22:15, Yaakov Selkowitz wrote: > > Where did we leave off wrt breaking out > > perl_vendor? > > Back in April, Reini expressed a desire to keep perl_vendor, claiming > that it is the easiest solution for both user and maintainer [1]. > > Whilst there are some of us who might question this, Reini has vastly > more knowledge and experience of perl than I ever will have. So when > Reini states that there are good reasons why perl_vendor should stay, I > am prepared to respect his judgement. > > As our perl maintainer wishes to keep perl_vendor, any discussion to the > contrary seems somewhat academic. The problem is that is seems to have remained academic; four months later, and we still don't have a replacement for perl_vendor. Reini, where are you holding with this? It's fine if you don't want to maintain all the perl module packages separately, there are those who are willing to help. Yaakov ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-08-15 22:01 ` perl-5.18.2-1 David Stacey 2014-08-15 22:17 ` perl-5.18.2-1 Yaakov Selkowitz @ 2014-08-16 7:00 ` Achim Gratz 1 sibling, 0 replies; 37+ messages in thread From: Achim Gratz @ 2014-08-16 7:00 UTC (permalink / raw) To: cygwin-apps David Stacey writes: > Back in April, Reini expressed a desire to keep perl_vendor, claiming > that it is the easiest solution for both user and maintainer [1]. Well, I have been keeping a large local installation of Perl modules and without perl_vendor dissolved I can't maintain that. Some of the extra modules require newer versions of what is in perl_vendor. Now, for my local installation I create my own setup.ini files and I can simply patch things up whichever way I want, but that was a lot of effort to get there. That same problem is encountered by everyone else who tries to do something similar and the solution Reini suggests is that they install all their stuff via CPAN (which goes into site_perl and thus overrides vendor_perl). Guess what, I did exactly that at the beginning, but there were for instance problems with LWP that couldn't be resolved unless I removed it from vendor_perl. Also, I now have to install on machines that don't have access to CPAN (and I have only remote access to) so I must package the modules (which puts them into vendor_perl by default). Again, Reini suggests I mirror CPAN, but that is even more impractical. Even if I did, each update would consist of multiple steps, each of which could fail. > Whilst there are some of us who might question this, Reini has vastly > more knowledge and experience of perl than I ever will have. So when > Reini states that there are good reasons why perl_vendor should stay, > I am prepared to respect his judgement. I don't dispute that it might be good reasons for him. But I continue to say that for certain use cases (as the outlined above) this is a show stopper and requires a lot of effort to undo, which a lot of users would simply be unable to do and a bunch of others wouldn't have the time to spend on. I've already offered to do what's necessary since I already spent most of the work to make it happen. You can try out if it works for you (in a test installation if you want) by doing that 32bit install I pointed you at. We could then make an informed discussion on the way forward. > As our perl maintainer wishes to keep perl_vendor, any discussion to > the contrary seems somewhat academic. I respectfully disagree. The problems with that approach are real and just declaring that "nobody does this" is not going to make them go away. Anybody should be able to package any Perl distribution for Cygwin via cygport without having to dive into exactly how perl_vendor has been built. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-08-15 21:15 ` perl-5.18.2-1 Yaakov Selkowitz 2014-08-15 22:01 ` perl-5.18.2-1 David Stacey @ 2014-08-16 7:05 ` Achim Gratz 2014-10-28 16:41 ` perl-5.18.2-1 Ken Brown 1 sibling, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-08-16 7:05 UTC (permalink / raw) To: cygwin-apps Yaakov Selkowitz writes: > Thanks for the reminder. Where did we leave off wrt breaking out > perl_vendor? I've offered a practical way to do this for everyone to test on a 32bit install. If that works and is agreeable, I've also offered to ITA/ITP the packages in question plus any other Perl distributions that maintainers want to be taken off their hands. That's the way I've been running my own installations for about two years now and I haven't been looking back. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-08-16 7:05 ` perl-5.18.2-1 Achim Gratz @ 2014-10-28 16:41 ` Ken Brown 2014-10-29 11:17 ` perl-5.18.2-1 Corinna Vinschen 0 siblings, 1 reply; 37+ messages in thread From: Ken Brown @ 2014-10-28 16:41 UTC (permalink / raw) To: cygwin-apps On 8/16/2014 3:04 AM, Achim Gratz wrote: > Yaakov Selkowitz writes: >> Thanks for the reminder. Where did we leave off wrt breaking out >> perl_vendor? > > I've offered a practical way to do this for everyone to test on a 32bit > install. If that works and is agreeable, I've also offered to ITA/ITP > the packages in question plus any other Perl distributions that > maintainers want to be taken off their hands. That's the way I've been > running my own installations for about two years now and I haven't been > looking back. Another two months have passed and there's still no response from Reini, nor do we have a release of perl-5.18 on x86_64. Can someone suggest a way to move forward? Is Reini still with us? Ken ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-10-28 16:41 ` perl-5.18.2-1 Ken Brown @ 2014-10-29 11:17 ` Corinna Vinschen 2014-10-30 8:00 ` perl-5.18.2-1 Reini Urban 0 siblings, 1 reply; 37+ messages in thread From: Corinna Vinschen @ 2014-10-29 11:17 UTC (permalink / raw) To: cygwin-apps; +Cc: Reini Urban [-- Attachment #1: Type: text/plain, Size: 1211 bytes --] On Oct 28 12:41, Ken Brown wrote: > On 8/16/2014 3:04 AM, Achim Gratz wrote: > >Yaakov Selkowitz writes: > >>Thanks for the reminder. Where did we leave off wrt breaking out > >>perl_vendor? > > > >I've offered a practical way to do this for everyone to test on a 32bit > >install. If that works and is agreeable, I've also offered to ITA/ITP > >the packages in question plus any other Perl distributions that > >maintainers want to be taken off their hands. That's the way I've been > >running my own installations for about two years now and I haven't been > >looking back. > > Another two months have passed and there's still no response from Reini, nor > do we have a release of perl-5.18 on x86_64. Can someone suggest a way to > move forward? Is Reini still with us? Reini? Ping? Your last reply to the issue is from Aprl 9th, and you never replied to the problems outlined by Yaakov the same day. Thanks, Corinna P.S: If Reini doesn't reply within the next two or three weeks, I'd say perl is up for grabs. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-10-29 11:17 ` perl-5.18.2-1 Corinna Vinschen @ 2014-10-30 8:00 ` Reini Urban 2014-10-30 16:58 ` perl-5.18.2-1 Achim Gratz 0 siblings, 1 reply; 37+ messages in thread From: Reini Urban @ 2014-10-30 8:00 UTC (permalink / raw) To: cygwin-apps, Reini Urban 2014-10-29 12:17 GMT+01:00 Corinna Vinschen <corinna-cygwin@cygwin.com>: > On Oct 28 12:41, Ken Brown wrote: >> On 8/16/2014 3:04 AM, Achim Gratz wrote: >> >Yaakov Selkowitz writes: >> >>Thanks for the reminder. Where did we leave off wrt breaking out >> >>perl_vendor? >> > >> >I've offered a practical way to do this for everyone to test on a 32bit >> >install. If that works and is agreeable, I've also offered to ITA/ITP >> >the packages in question plus any other Perl distributions that >> >maintainers want to be taken off their hands. That's the way I've been >> >running my own installations for about two years now and I haven't been >> >looking back. This way was not practical. You cannot ensure a proper rebased initial set this way, hence 32bit rebase error will be more likely. I didn't make progress in the autorebaser for cpan installs. >> Another two months have passed and there's still no response from Reini, nor >> do we have a release of perl-5.18 on x86_64. Can someone suggest a way to >> move forward? Is Reini still with us? > > Reini? Ping? Your last reply to the issue is from Aprl 9th, and you > never replied to the problems outlined by Yaakov the same day. I'm reading but I cannot work on it, since my machines are still on the ship from the US to Europe. > P.S: If Reini doesn't reply within the next two or three weeks, I'd say > perl is up for grabs. But I'm fine if Achim takes it, since he caused too many troubles in his x86_64 packaging changes for the 32bit port, which I didn't want to follow. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-10-30 8:00 ` perl-5.18.2-1 Reini Urban @ 2014-10-30 16:58 ` Achim Gratz 2014-11-03 22:09 ` perl-5.18.2-1 Ken Brown 0 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-10-30 16:58 UTC (permalink / raw) To: cygwin-apps Reini Urban writes: > This way was not practical. You cannot ensure a proper rebased initial > set this way, hence 32bit rebase error will be more likely. > I didn't make progress in the autorebaser for cpan installs. I have a working incremental autorebase that can handle site_perl just fine. If that's the only problem you have we can work it out, I suppose. > But I'm fine if Achim takes it, since he caused too many troubles in > his x86_64 packaging changes for the 32bit port, which I didn't want > to follow. Huh? I've got nothing to do with any current Perl packages in either the 32bit or x86_64 releases. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-10-30 16:58 ` perl-5.18.2-1 Achim Gratz @ 2014-11-03 22:09 ` Ken Brown 2014-11-04 16:25 ` perl-5.18.2-1 Achim Gratz 0 siblings, 1 reply; 37+ messages in thread From: Ken Brown @ 2014-11-03 22:09 UTC (permalink / raw) To: cygwin-apps On 10/30/2014 12:58 PM, Achim Gratz wrote: > Reini Urban writes: >> This way was not practical. You cannot ensure a proper rebased initial >> set this way, hence 32bit rebase error will be more likely. >> I didn't make progress in the autorebaser for cpan installs. > > I have a working incremental autorebase that can handle site_perl just > fine. If that's the only problem you have we can work it out, I > suppose. > >> But I'm fine if Achim takes it, since he caused too many troubles in >> his x86_64 packaging changes for the 32bit port, which I didn't want >> to follow. > > Huh? I've got nothing to do with any current Perl packages in either > the 32bit or x86_64 releases. I think Reini is talking about the changes introduced by Yaakov and subsequently followed by others (including me). But as long as you're getting the credit anyway, are you willing to adopt perl? We seem to be at an impasse otherwise. Ken ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-11-03 22:09 ` perl-5.18.2-1 Ken Brown @ 2014-11-04 16:25 ` Achim Gratz 2014-11-10 21:30 ` perl-5.18.2-1 Ken Brown 0 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-11-04 16:25 UTC (permalink / raw) To: cygwin-apps Ken Brown writes: > I think Reini is talking about the changes introduced by Yaakov and > subsequently followed by others (including me). But as long as you're > getting the credit anyway, are you willing to adopt perl? We seem to > be at an impasse otherwise. The last time Reini talked about the 64bit version of Perl he mentioned he was chasing a serious bug (I don't remember what it was and it may already be moot). I can try to build Perl starting from his 32bit packge, but I would really like to start from where Reini left off for 64bit if that's possible. I probably can't test the result as thouroughly as Reini would have done. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-11-04 16:25 ` perl-5.18.2-1 Achim Gratz @ 2014-11-10 21:30 ` Ken Brown 0 siblings, 0 replies; 37+ messages in thread From: Ken Brown @ 2014-11-10 21:30 UTC (permalink / raw) To: cygwin-apps On 11/4/2014 11:25 AM, Achim Gratz wrote: > Ken Brown writes: >> I think Reini is talking about the changes introduced by Yaakov and >> subsequently followed by others (including me). But as long as you're >> getting the credit anyway, are you willing to adopt perl? We seem to >> be at an impasse otherwise. > > The last time Reini talked about the 64bit version of Perl he mentioned > he was chasing a serious bug (I don't remember what it was and it may > already be moot). I can try to build Perl starting from his 32bit > packge, but I would really like to start from where Reini left off for > 64bit if that's possible. I probably can't test the result as > thouroughly as Reini would have done. I searched the archives, and I found the following two messages from Reini https://sourceware.org/ml/cygwin-apps/2014-03/msg00010.html https://sourceware.org/ml/cygwin/2014-05/msg00511.html in which he mentioned problems with sockets. He didn't specify how serious the problems were. Reini, can you give Achim whatever information he needs in order to continue from where you left off? Ken ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-02 8:22 ` perl-5.18.2-1 (was: 64-bit: Missing perl modules) Achim Gratz 2014-05-03 2:06 ` perl-5.18.2-1 Ken Brown 2014-05-04 7:29 ` perl-5.18.2-1 Achim Gratz @ 2014-05-04 17:20 ` Achim Gratz 2014-05-04 17:59 ` perl-5.18.2-1 Ken Brown 2 siblings, 1 reply; 37+ messages in thread From: Achim Gratz @ 2014-05-04 17:20 UTC (permalink / raw) To: cygwin-apps The follwing Perl distribution packages are build or runtime requirements for perl_vendor but currently not maintained by me, so I would ITA them if perl_vendor gets dissolved into individual packages: perl-archive-zip Yaakov Selkowitz perl-capture-tiny Ken Brown perl-clone Yaakov Selkowitz perl-data-compare Ken Brown perl-date-simple Ken Brown perl-digest-hmac Yaakov Selkowitz perl-encode-locale Yaakov Selkowitz perl-file-find-rule Ken Brown perl-file-listing Yaakov Selkowitz perl-html-parser Yaakov Selkowitz perl-html-tagset Yaakov Selkowitz perl-http-cookies Yaakov Selkowitz perl-http-daemon Yaakov Selkowitz perl-http-date Yaakov Selkowitz perl-http-message Yaakov Selkowitz perl-http-negotiate Yaakov Selkowitz perl-io-html Ken Brown perl-io-socket-ssl Yaakov Selkowitz perl-io-tty Reini Urban perl-ipc-run3 Ken Brown perl-lwp-mediatypes Yaakov Selkowitz perl-lwp-protocol-https Ken Brown perl-module-scandeps Yaakov Selkowitz perl-mozilla-ca Ken Brown perl-net-http Yaakov Selkowitz perl-net-ssleay Yaakov Selkowitz perl-number-compare Ken Brown perl-par-dist Yaakov Selkowitz perl-params-util Yaakov Selkowitz perl-proc-processtable Yaakov Selkowitz perl-term-readkey Yaakov Selkowitz perl-term-readline-gnu Yaakov Selkowitz perl-text-glob Ken Brown perl-uri Yaakov Selkowitz perl-www-robotrules Yaakov Selkowitz perl-xml-libxml Yaakov Selkowitz perl-xml-namespacesupport Yaakov Selkowitz perl-xml-parser Yaakov Selkowitz perl-xml-sax Yaakov Selkowitz perl-xml-sax-base Yaakov Selkowitz perl-xml-simple Yaakov Selkowitz perl-yaml Yaakov Selkowitz Eric Blake has asked to be relieved of the responsibility for his single Perl package: perl-error Eric Blake If there are other perl distribution packages that you want me to take ownership of, please let me know. I've been building most of the remaining packages locally anyway, so it wouldn't be much additional work. 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: perl-5.18.2-1 2014-05-04 17:20 ` perl-5.18.2-1 Achim Gratz @ 2014-05-04 17:59 ` Ken Brown 0 siblings, 0 replies; 37+ messages in thread From: Ken Brown @ 2014-05-04 17:59 UTC (permalink / raw) To: cygwin-apps On 5/4/2014 1:20 PM, Achim Gratz wrote: > > The follwing Perl distribution packages are build or runtime > requirements for perl_vendor but currently not maintained by me, so I > would ITA them if perl_vendor gets dissolved into individual packages: > > perl-archive-zip Yaakov Selkowitz > perl-capture-tiny Ken Brown > perl-clone Yaakov Selkowitz > perl-data-compare Ken Brown > perl-date-simple Ken Brown > perl-digest-hmac Yaakov Selkowitz > perl-encode-locale Yaakov Selkowitz > perl-file-find-rule Ken Brown > perl-file-listing Yaakov Selkowitz > perl-html-parser Yaakov Selkowitz > perl-html-tagset Yaakov Selkowitz > perl-http-cookies Yaakov Selkowitz > perl-http-daemon Yaakov Selkowitz > perl-http-date Yaakov Selkowitz > perl-http-message Yaakov Selkowitz > perl-http-negotiate Yaakov Selkowitz > perl-io-html Ken Brown > perl-io-socket-ssl Yaakov Selkowitz > perl-io-tty Reini Urban > perl-ipc-run3 Ken Brown > perl-lwp-mediatypes Yaakov Selkowitz > perl-lwp-protocol-https Ken Brown > perl-module-scandeps Yaakov Selkowitz > perl-mozilla-ca Ken Brown > perl-net-http Yaakov Selkowitz > perl-net-ssleay Yaakov Selkowitz > perl-number-compare Ken Brown > perl-par-dist Yaakov Selkowitz > perl-params-util Yaakov Selkowitz > perl-proc-processtable Yaakov Selkowitz > perl-term-readkey Yaakov Selkowitz > perl-term-readline-gnu Yaakov Selkowitz > perl-text-glob Ken Brown > perl-uri Yaakov Selkowitz > perl-www-robotrules Yaakov Selkowitz > perl-xml-libxml Yaakov Selkowitz > perl-xml-namespacesupport Yaakov Selkowitz > perl-xml-parser Yaakov Selkowitz > perl-xml-sax Yaakov Selkowitz > perl-xml-sax-base Yaakov Selkowitz > perl-xml-simple Yaakov Selkowitz > perl-yaml Yaakov Selkowitz You're welcome to take mine (which currently exist only on x86_64). I only packaged them because they were build or runtime requirements of biber. Ken ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 64-bit: Missing perl modules 2014-04-07 18:54 ` Reini Urban 2014-04-07 19:30 ` Achim Gratz @ 2014-04-08 16:20 ` David Stacey 1 sibling, 0 replies; 37+ messages in thread From: David Stacey @ 2014-04-08 16:20 UTC (permalink / raw) To: cygwin-apps On 07/04/14 19:54, Reini Urban wrote: > The new 5.18.2 package will be unified for 32bit and 64bit, yes. > > perl_vendor will probably stay as is, as it is the easiest for the > user and the maintainer. Thank you for your reply. I'm pleased that there is a way forward to get these perl modules into 64-bit Cygwin, and I look forward to seeing 'perl_vendor' in our 64-bit land. Thanks again, Dave. ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2014-11-10 21:30 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-05 21:42 64-bit: Missing perl modules David Stacey 2014-04-06 6:32 ` Achim Gratz 2014-04-06 15:37 ` David Stacey 2014-04-06 16:38 ` Achim Gratz 2014-04-06 18:59 ` David Stacey 2014-04-07 18:54 ` Reini Urban 2014-04-07 19:30 ` Achim Gratz 2014-04-07 21:31 ` Reini Urban 2014-04-08 18:02 ` Achim Gratz 2014-04-08 20:52 ` Reini Urban 2014-04-08 21:27 ` Achim Gratz 2014-04-09 14:13 ` Reini Urban 2014-04-09 5:20 ` Yaakov (Cygwin/X) 2014-04-09 18:02 ` Achim Gratz 2014-05-02 8:22 ` perl-5.18.2-1 (was: 64-bit: Missing perl modules) Achim Gratz 2014-05-03 2:06 ` perl-5.18.2-1 Ken Brown 2014-05-04 5:51 ` perl-5.18.2-1 Yaakov (Cygwin/X) 2014-05-04 7:29 ` perl-5.18.2-1 Achim Gratz 2014-05-04 8:24 ` perl-5.18.2-1 Yaakov (Cygwin/X) 2014-05-04 9:36 ` perl-5.18.2-1 Achim Gratz 2014-05-11 19:05 ` perl-5.18.2-1 Achim Gratz 2014-08-15 20:38 ` perl-5.18.2-1 Achim Gratz 2014-08-15 21:15 ` perl-5.18.2-1 Yaakov Selkowitz 2014-08-15 22:01 ` perl-5.18.2-1 David Stacey 2014-08-15 22:17 ` perl-5.18.2-1 Yaakov Selkowitz 2014-08-16 7:00 ` perl-5.18.2-1 Achim Gratz 2014-08-16 7:05 ` perl-5.18.2-1 Achim Gratz 2014-10-28 16:41 ` perl-5.18.2-1 Ken Brown 2014-10-29 11:17 ` perl-5.18.2-1 Corinna Vinschen 2014-10-30 8:00 ` perl-5.18.2-1 Reini Urban 2014-10-30 16:58 ` perl-5.18.2-1 Achim Gratz 2014-11-03 22:09 ` perl-5.18.2-1 Ken Brown 2014-11-04 16:25 ` perl-5.18.2-1 Achim Gratz 2014-11-10 21:30 ` perl-5.18.2-1 Ken Brown 2014-05-04 17:20 ` perl-5.18.2-1 Achim Gratz 2014-05-04 17:59 ` perl-5.18.2-1 Ken Brown 2014-04-08 16:20 ` 64-bit: Missing perl modules David Stacey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).