Front page | perl.perl5.porters |
Postings from July 2009
On Sat, Jul 25, 2009 at 04:45:52PM -0700, Joshua ben Jore wrote: > On Sat, Jul 25, 2009 at 4:13 AM, Dave Mitchell<davem@iabyn.com> wrote: > > Is anyone aware of any issues that would stop me releasing 5.10.1-RC1? > > I'm aware of version.pm, and my intention for the 5.10.0 regression bugs > > is to go with whatever gets fixed in the next day or two, then list > > the remaining significant one in the "Known bugs" section of perldelta. > > I would very much like to ASCII-ify > lib/Parse/CPAN/Meta/t/data/utf_16_le_bom.yml prior to the final cut. > This apparently won't stop a real Debian packager but I'm the only one > my $work has got. I've gotten far enough with this to think the fix > ought to go into Parse::CPAN::Meta in Adam's SVN repo at > http://svn.ali.as/cpan. I've been letting this slip off the top of my > stack but I guess that's not a good idea right now. Sorry. Well, I loosely followed the earlier thread, but not too closely. Is the issue that something in the debian packaging system somewhere can't cope with binary files in source code (which sounds strange)? > For lack of anything smarter, I'd like to push uupacktool.pl into the > Parse-CPAN-Meta CPAN module and use the documented procedure in > pod/perlrepository.pod for "binary files." Parse-CPAN-Meta as a > dual-use module then just takes on the technical debt of having a > /copy/ of the packer tool. Annoying but not harbl. I can't see any reason to change Parse-CPAN-Meta. The technique described in perlrepository.pod is something that is done in core, not in the distro. Ie in core we just replace utf_16_le_bom.yml with utf_16_le_bom.yml.packed, and everything just magically works. But: I thought that outcome of the earlier thread was that banning binary files in the perl core was obsolete, and we should start dismantling the .packed stuff; so I'm not keen on adding to it now. > I notice that the CPAN version of Parse-CPAN-Meta is not integrated. I > assume patching this issue involves a linear sequence from the CPAN > version forward and applying the fix to core means upgrading from > 1.38, past CPAN @ 1.39, to the currently fictional 1.40. Um, core and blead are at 1.39, and have been since June. > Other than the late date, is there a reason to not incorporate this? I think that's a pretty good reason all by itself! > If this isn't applied, work's .deb build process originally based on > 5.10.0 will break. From prior emails about dpkg-source, the fix for my > site appears to require incorporating some "testing" or "unstable" > changes from Debian into Ubuntu. Kind of a PITA but not ultimately > unsolvable. Well, is the issue something that will affect all or many debian users, or just your site? -- But Pity stayed his hand. "It's a pity I've run out of bullets", he thought. -- "Bored of the Rings"Thread Previous | Thread Next