Front page | perl.perl5.porters |
Postings from July 2009
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. 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 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. Other than the late date, is there a reason to not incorporate this? 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. FWIW, I'm doing this work now. JoshThread Previous | Thread Next