64-bit: Missing perl modules

64-bit: Missing perl modules

[David Stacey]

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.

Re: 64-bit: Missing perl modules

[Achim Gratz]

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

Re: 64-bit: Missing perl modules

[David Stacey]

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.

Re: 64-bit: Missing perl modules

[Achim Gratz]

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

Re: 64-bit: Missing perl modules

[David Stacey]

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.

Re: 64-bit: Missing perl modules

[Reini Urban]

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/

Re: 64-bit: Missing perl modules

[Achim Gratz]

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

Re: 64-bit: Missing perl modules

[Reini Urban]

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/

Re: 64-bit: Missing perl modules

[Achim Gratz]

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

Re: 64-bit: Missing perl modules

[Reini Urban]

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.

Re: 64-bit: Missing perl modules

[Achim Gratz]

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

Re: 64-bit: Missing perl modules

[Reini Urban]

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.

Re: 64-bit: Missing perl modules

[Yaakov (Cygwin/X)]

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

Re: 64-bit: Missing perl modules

[Achim Gratz]

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

Re: perl-5.18.2-1 (was: 64-bit: Missing perl modules)

[Achim Gratz]

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

Re: perl-5.18.2-1

[Ken Brown]

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

Re: perl-5.18.2-1

[Yaakov (Cygwin/X)]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Yaakov (Cygwin/X)]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Yaakov Selkowitz]

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

Re: perl-5.18.2-1

[David Stacey]

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

Re: perl-5.18.2-1

[Yaakov Selkowitz]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Ken Brown]

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

Re: perl-5.18.2-1

[Corinna Vinschen]

[-- 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 --]

Re: perl-5.18.2-1

[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/

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Ken Brown]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Ken Brown]

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

Re: perl-5.18.2-1

[Achim Gratz]

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

Re: perl-5.18.2-1

[Ken Brown]

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

Re: 64-bit: Missing perl modules

[David Stacey]

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.