Re: Preserving git history across repositories
On Sun, Dec 22, 2013 at 09:51:23AM -0500, James E Keenan wrote: > Is it possible to preserve the commit history of a tree of files as > it moves out of one repository and into another? This is a bit fiddly but it's quite doable. The steps look something like this: - create your new repository, cloned from the 'perl' repository. - find the files/directories you care about. Delete EVERYTHING else -- not just 'git rm -r', but actually wipe out knowledge of those files' existence from the history. One guide to this is here: https://help.github.com/articles/remove-sensitive-data -- and now that you know the name of the git commands to use, you should be able to find lots of other documents describing variants to this technique. - now you should be left with just the one tree in the repo, including all commits in the history: ext/Pod-Html. Now you can move it to its new location using a normal 'git mv', and continue with development. (FWIW, I'd suggest doing only minimal changes at this point - rename the code to live under lib/, add a Makefile.PL, META.* and Changes, and then immediately releasing to the CPAN, to mark its move out of core -- and then continue with cleaning up the code in subsequent releases.) Thanks for taking this on -- it looks like Pod-Html has wanted a caretaker for quite some time!
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
On Sun, Jun 01, 2014 at 08:40:14PM +0200, Jens Rehsack wrote: > > Let me rephrase: making available a "XS-only" choice, when both PP ans XS > > are > > available is a mistake. Not just making the choice is a mistake, > > *presenting it* is a mistake in its own right. > > You should explain why that should be a mistake when presenting a "PP-only" > choice is not a mistake. That doesn't make any sense to me. There exists installations that can run PP dists, but not XS dists. There is no such thing as an installation that *cannot* run a PP implementation. The "give me only the PP version, even if XS is available and installable on my system" choice is useful when preparing a fatpacked installation. I do not see any gain in specifying "give me XS or give me death". Not every dist is XS-based, so is not going to work out in most cases, anyway. I'm wondering why it isn't always possible to split a dist into two implementations, one PP and the other with XS optimizations. If the dist simply cannot be implemented using pure Perl (Moose, for example), then surely the right thing to is simply refuse to install on PP systems? Can you clarify what the usecases are here? That is, /achieve?
Re: All tickets at rt.cpan.org for ExtUtils-Manifest are closable
On Fri, Aug 01, 2014 at 06:50:46PM -0400, James E Keenan wrote: > I see from http://search.cpan.org/dist/ExtUtils-Manifest/ that you > are the most recent releasor of ExtUtils-Manifest. This module is maintained by the Perl Toolchain Gang, and its repository for the CPAN distribution lives at https://github.com/Perl-Toolchain-Gang/ExtUtils-Manifest. > I have reviewed all remaining New or Open tickets for this distro at > https://rt.cpan.org//Dist/Display.html?Queue=ExtUtils-Manifest. > Those that, IMHO, warrant action have been transferred to > rt.perl.org (since P5P is now, FBOW, the primary maintainer of this > distro). Some don't warrant further action. I fear that moving the tickets into the main perl5 queue will lead to lessened visibilty, except to the core porters who are usually occupied with matters in core rather than supporting modules. I would be happy to create github issues for them for tracking. Is there an easy way of searching for these tickets in the perl5 queue?
Re: File::ShareDir - Outstanding modernization
I am not opposed in principle to redesigning File::ShareDir, but I want to be *very* clear about the proposed design changes, impact on various parts of the toolchain, and back-compatibility concerns before anything moves beyond the design phase. This code sits at the very heart of the cpan, called directly by ExtUtils::MakeMaker. On Tue, May 5, 2015 at 6:14 AM, Olivier Mengué wrote: > Hi, > > Is it really necessary to introduce those new features (bloat?) in the > existing File::ShareDir ? > > Why not just fork and keep the original File::ShareDir light? > What problems would be solved if the new features you plan were added to > the existing File::ShareDir? Which existing application would benefit from > these change just by upgrading to that new File::ShareDir, without using > the new APIs? > > Olivier. > > 2015-05-04 16:34 GMT+02:00 Jens Rehsack : > >> Hi, >> >> initially planned being one big topic for my QAH attendance, but Murphy >> decided to keep me busy otherwise (broken car, for everyone who didn't >> recognize on QAH...). >> >> Well - things are settling meanwhile and I have a few moments to think >> about the tasks I missed to finish in Berlin. One is File::ShareDir. >> >> The intension is to let File::ShareDir get closer to File::ConfigDir >> (and later let File::ConfigDir steal some features from File::ShareDir). >> >> The longterm goal is having it behave a bit more like "share" is intended >> (read until end of mail - don't scream here). There is no plan to break >> backwards compatibility (and if it happens on accident, the intension is >> to fix it and hopefully detect before it happens). >> >> Back to ideas for File::ShareDir: >> >> 1) analogous to File::ConfigDir have a bunch of share-dir prefixes >>including existing prefixes (core_share_dir, site_share_dir, >>vendor_share_dir, ...) and new ones (system_share_dir, >> machine_share_dir, >>here_share_dir, ...). >>==> here is can be sane to have plugins like >> https://metacpan.org/release/File-ConfigDir-Plack >>for $ENV based locations (eg. FOO_BASE) or framework related >> extension. >> 2) Upon the prefixes, the dist_dir(), module_dir() will calculate the >>Full Qualified Share Dir as requested. It'll very likely to have other >>preferences is prefix picking for legacy API and new API (-> 3) >> 3) introduce better accessors (dist_share_dir, module_share_dir, >> app_share_dir, >>dist_config_dir, module_config_dir, ...). >> >> The goal is allow a module access share-dirs from different applications >> (eg. templates to process) or let applications rely on different immutable >> files from several distributions (think LaTeX as an example). >> >> Cheers >> -- >> Jens Rehsack - rehs...@gmail.com >> >> >
Re: Possible bug in Test::Builder, fix is easy, but might break things
> The problem is that parent_todo is not considered when setting the OK's in the details in subtests. That means if a subtest ok fails, and the parent is in todo, the 'ok' and 'actual_ok' are both set to false. Why is this a bug? After all, it's only the top level of TAP that ever matters when it comes to the overall test pass/failure, and a subtest's pass or fail status will be adjusted accordingly for the parent TODO at the *parent's* level. TODOs don't need to propagate downward to all contained subtests. Further, if we required that TODO state must propagate down to all contained subtests, that means that subtests must always be aware of that upper state -- which rules out any use of separate processes to to create the subtest results, which is conceptually possible (something else, thinking that it is a top-level test, can provide us the TAP, and then we nest it as a subtest into another test -- and this should be possible both with TAP strings and with an event streamer). On Mon, Dec 21, 2015 at 4:04 PM, Chad Granum wrote: > Test::Builder appends all Ok's to a structure it can return via > $tb->details. These Ok's have the fields 'ok' and 'actual_ok'. 'actual_ok' > is the true/false value passed to $tb->ok, 'ok' is adjusted to be true if > the test was run under TODO. > > > https://metacpan.org/source/EXODIST/Test-Simple-1.001014/lib/Test/Builder.pm#L845 > > The bug is in subtest handling. When you start a subtest you essentially > create a new Test::Builder singleton, and the TODO state is clear int he > new one, but it has a field 'parent_TODO' that gets set. This is used to > ensure that failures in a subtest when the parent has TODO set do not count > as actual failures. > > The problem is that parent_todo is not considered when setting the OK's in > the details in subtests. That means if a subtest ok fails, and the parent > is in todo, the 'ok' and 'actual_ok' are both set to false. > > The fix is easy, just change line 845 to look at parent_TODO. However this > breaks Test::ClassMoose because it uses details to verify its results. > https://metacpan.org/source/DROLSKY/Test-Class-Moose-0.67/t/basic.t#L55 > > I spoke with autarch about this test since he is the current maintainer. > He agrees with me that 'ok' should be true in that test, and that this is > probably a bug. > > I have not yet figured out what else this may break on cpan, I will try to > do that tomorrow. > > *What I am looking for from cpan-workers:* > > 1) Do you think this is actually a bug, or does it work as you think it > should? > 2) Even if we all agree it is a bug, can we fix it, or do we need to > preserve it to avoid breaking things? > > -Chad > > > > >
Re: CPAN River - water quality metric
> I think “has a META.yml or META.json” is worth keeping in I'm surprised this one is being discussed at all. IMO, not having a META file should disqualify the distribution from being considered at all. At Berlin last year we talked about making it mandatory, and held off "for now" so the outliers could be fixed. Having META should be non-negotiable for a well-formed CPAN distribution. On Thu, Dec 24, 2015 at 1:10 AM, Neil Bowers wrote: > > CPANdeps (http://deps.cpantesters.org) has been providing useful > > information on water quality. It might be enough to make a better or > > opinionated presentation of it for the upriver authors. IMHO META > > files and min version specification depends more on when a > > distribution is released and don't well fit for water quality metrics. > > I’m not convinced on min version either, but am leaning towards including > it, if we can come up with a definition that’s practical and useful. > > I think “has a META.yml or META.json” is worth keeping in, as there are a > number of benefits to having one, and I suspect there’s at least some > correlation between dists that don’t have a META file and dists that > haven’t listed all prereqs (eg in the Makefile.PL). > > That said, I’m really just experimenting here, trying to find things that > are useful indicators for whether a dist is good to rely on. > > Neil > >
Re: Should Test2 maintain $! and $@?
> Test2, the dist, is just internals. It provides no tools. It does not
have ok(), is(), etc.
Um, so... what *is* Test2 then? (And the second question would be: and what
does it have to do with Test::More?) Without context, your first question
is equivalent to "should Foo::Bar maintain $! and $@?".
On Mon, Jan 11, 2016 at 7:14 PM, Chad Granum wrote:
> Some things I forgot to mention:
>
> Test2, the dist, is just internals. It provides no tools. It does not have
> ok(), is(), etc. What I am talking about is not thr simple task of putting
> local $! In some exports. This is localizing $! Around any call to use,
> require, open, close, etc. Anything that can alter a handle, write a file,
> etc.
>
> The reason for these extreme measures is because that is what
> Test::Builder does. Test::More does not localize $! In ok() and is(), it
> instead has protections scattered about its internals.
>
> So my proposal is not to write tools that modify $!, it is to spare the
> internals from all these hurdles and let the tools do the $! Protection if
> they need it.
>
> Now, lots of things depend on Test::Builder jumping through these hoops,
> so I will ensure Test::Builder still protects $!.
>
> The question is, do I accomplish this by wrapping everything that
> canchange $! In all the Test2 internals, or do I do it by having
> Test::Builder protect them when it calls out to Test2? The latter option
> would reduce the complexity of Test2, but not break things.
>
> As for tools, yes, preserving $! Is a valuable behavior, but I think it
> belongs at the tool level, not the internals.
>
> That said, it just occured to me that this can possibly be accomplished by
> having a context store $! And $@ when it is obtained, then restore them
> when it is released, which would avoid needing to use local everywhere, and
> still preserve them for all tools automatically...
> On Jan 11, 2016 4:53 PM, "Chad Granum" wrote:
>
>> Test::More/Test::Builder work VERY hard to ensure nothing inside them
>> alters $! or $@. This is for thing like this:
>>
>> ok(do_something_scary());
>>> is($!, 0, "expected $! val");
>>> is($@, undef, '$@ not changed');
>>
>>
>> Without Test::More/Builder being careful to support this, the second 2
>> assertions could fail because something inside ok() modifies $! or $@.
>>
>> *I cannot change Test::Builder/More* they must continue to protect $!
>> and $@, otherwise things break (I have a few downstream samples to show
>> that it does).
>>
>> However. It is easy enough to have Test::Builder/More protect $! and $@
>> without requiring Test2 to do so.
>>
>> Since Test2 is new, and nothing depends on any of its behaviors yet, I am
>> considering having Test2 not care about modifying $! and $@. So far I have
>> been taking care to preserve $! and $@, but it does add significant
>> complexity (and minor, but noticeable slowdown) to Test2.
>>
>> *Reasons for dropping this promise from Test2:*
>>
>>- Simplifies code
>>- $! and $@ are altered by many many things, adding { local ... }
>>around all of them is a pain
>>- Sometimes internals you don't expect to set $! will
>>- Perl itself documents that you cannot depend on $! and $@ being
>>unchanged past the immediate line after you set it.
>>- Test::Builder will continue to protect $! and $@, so nothing will
>>break
>>- Test2 is new, nothing depends on it preserving these
>>
>> *Reasons not to drop it:*
>>
>>- It is helpful to people who might not realize $! and $@ are often
>>altered unexpectedly.
>>
>> I am asking for input in case I missed any reasons/arguments for either
>> side. In either case backwards compatibility will be preserved.
>>
>> -Chad
>>
>>
>>
Re: Thoughts on Kik and NPM and implications for CPAN
Should an author be able to delete a currently-indexed distribution on the CPAN? Yes, without reservation or exception. Open source is free, and that freedom includes removing my consent for my name to be attached to a publication at any time. However, we (the CPAN community) can do a lot of things after that to mitigate any damage. I wholeheartedly agree with transferring namespace permissions to something that the PAUSE admins control, so any random joe cannot claim the namespace and upload whatever he likes into it (this is an attack vector we must keep closed). We also need to be able to act quickly to publish something in its place so installations pulling directly from the CPAN do not break. I would suggest an email alert go out to the modules@ list (or another list, should this prove too noisy) providing notification that an indexed module is being deleted and de-indexed.
Re: Thoughts on Kik and NPM and implications for CPAN
Done: https://github.com/andk/pause/issues/204 On Wed, Mar 23, 2016 at 10:57 AM, David Golden wrote: > On Wed, Mar 23, 2016 at 1:39 PM, Karen Etheridge wrote: > >> I would suggest an email alert go out to the modules@ list (or another >> list, should this prove too noisy) providing notification that an indexed >> module is being deleted and de-indexed. > > > Excellent suggestion! I think modules@ is the right list and suspect the > frequency is rare. (Maybe Andreas has statistics on it?) > > Could you please open a PAUSE ticket for that idea? > > > -- > David Golden Twitter/IRC/Github: @xdg >
Re: Passing some torches
I believe Leon Timmermans is already established as a maintainer of Module::Build, so things should be fine there. Since I'm already a release wrangler on YAML-Tiny, upon which CPAN-Meta-YAML is based, I'm happy to coordinate its releases as well. I'm happy to take on Perl-OSType too since it is indeed quite straightforward (along with whoever else in the gang is interested). I won't object to additional comaint bits on any of the other distributions you listed (the more the merrier, for redundancy) but cannot make any promises as to bandwidth for processing its outstanding issues. On Sun, Apr 3, 2016 at 3:32 AM, David Golden wrote: > Many of you may have noticed that over the last year, I've been stepping > back from active toolchain development. While I will continue supporting > certain areas (META related stuff) and hope to step up my efforts in other, > neglected areas (CPAN Testers), there are several modules where it no > longer makes sense for me to be co-maintainer. > > I am the sole "active" co-maintainer on the following distributions; for > redundancy, I suggest a new co-maintainer should be found as backup: > > * CPAN > * File-Temp > * Module-Build > * File-chdir > > The following distributions I plan to step away from, but have other > co-maintainers already: > > * ExtUtils-CBuilder > * ExtUtils-Install > * Module-CoreList > * Module-Metadata > > I am -- and will remain -- primary maintainer of the following, but there > are no co-maintainers; I'd like someone(s) to volunteer to be my backup > (the work should be trivial): > > * Perl-OSType > * CPAN-Meta-YAML > > Regards, > David > > -- > David Golden Twitter/IRC/Github: @xdg >
Re: Renaming the "QA Hackathon"?
When I saw this thread title I thought it was going to be discussing the "QA" part of it, and I thought "yeah, right on!".. I totally agree with Neil's points about what we do not being a "hackathon" though. ..And I also like the idea of changing the QA bit to Infrastructure. Perl Infrastructure gets a vote from me. On Sat, Apr 9, 2016 at 8:50 AM, Kent Fredric wrote: > On 10 April 2016 at 03:45, David Golden wrote: > > Perl Toolchain Summit > > > Because "Toolchain" is not really a word that necessarily makes sense > outside Perl, you can use "Infrastructure" or even "Critical > Infrastructure" in its stead. ( I personally like Critical, its a > very spicy word, and accurately reflects the propensity of this sphere > of things to either go pear shaped or steal your SAN Cookies ) > > Also, depending on how many words you want to spend, throwing "Annual" > in there might help give some context to how frequently these things > happen. > > The narrative you want to be carrying in your words is: > > "Every year, we get all our brightest in one place and discuss and > work on the most pressing and important problems that affect the the > broadest number of concerns in the Perl+CPAN ecosystem" > > -- > Kent > > KENTNL - https://metacpan.org/author/KENTNL >
Unresponsive cpan mirror: cpan-sj.viaverio.com
Hi toolchainers, I'm not sure who maintains the list of cpan mirrors, but cpan-sj.viaverio.com is now unresponsive, and should be removed from the list that CPAN.pm uses (and any other cpan clients). - Karen Etheridge (et...@cpan.org)
Re: Unresponsive cpan mirror: cpan-sj.viaverio.com
Is there not an official, centralized, list of mirrors? I suppose whoever maintains that list did not find out about the retiring of the various mirrors and send out the updates! http://grep.cpan.me/?q=cpan-sj.viaverio.com What other mirrors should be removed? On Tue, Jun 14, 2016 at 11:11 PM, Henk P. Penning wrote: > On Tue, 14 Jun 2016, Karen Etheridge wrote: > > Date: Tue, 14 Jun 2016 20:48:35 +0200 >> From: Karen Etheridge >> To: cpan-workers >> Subject: Unresponsive cpan mirror: cpan-sj.viaverio.com >> >> Hi toolchainers, >> >> I'm not sure who maintains the list of cpan mirrors, but >> cpan-sj.viaverio.com is now unresponsive, and should be removed from the >> list that CPAN.pm uses (and any other cpan clients). >> > > Mirror "cpan-sj.viaverio.com" was retired on 2016-02-19, > on request by the owner. > > Searching on search.cpan.org for cpan-sj.viaverio.com yields : > > http://search.cpan.org/~marcel/CPAN-Command-1.100840/lib/CPAN/Command.pm > > ... don't know why > > http://search.cpan.org/~rjbs/perl-5.24.0/pod/perlmodlib.PL > > contains refs to mirrors that were retired 5 years ago. > > - Karen Etheridge (et...@cpan.org) >> > > Groeten, > > HPP > > _ > Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_ > Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \ > Budapestlaan 6, 3584CD Utrecht, NLF +31 30 253 4553 \_/ \_/ > http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/ >
Re: YAML (maybe other modules) might need CPAN smoking
There should be -TRIAL releases of anything this far upriver, at the very least. On Tue, Jul 5, 2016 at 5:34 AM, Sawyer X wrote: > YAML.pm. > > It isn't tool chain, but it is relatively upriver, so I thought this > group would be interested. Additionally this idea can extend to > non-core toolchain tools. > > On Tue, Jul 5, 2016 at 2:18 PM, David Golden > wrote: > > YAML or YAML::Tiny? Only the latter is tool chain. > > > > On Jul 5, 2016 8:14 AM, "Sawyer X" wrote: > >> > >> YAML broke some stuff. > >> > >> I'm beginning to think that YAML is one of the modules that could > >> really use a CPAN smoke of its own. I think the more upriver the > >> module, the more this becomes relevant. > >> > >> Thoughts? >
Re: No . in @INC breaks CPAN
> In this case, adding '.' to the distribution's Makefile.PL made no
difference. I had to add "use lib ('.');" to Auxiliary.pm to enable it to
locate 'eligible_chars', after which 'make test' PASSed.
> Based on this example and several other failures, my hunch is that many
of the failures which we'll see on CPAN are failures of *tests* rather than
failures of the modules themselves.
I would agree. I'd also encourage authors to not add "use lib '.';" to
their tests to fix these issues, but rather move the test modules to t/lib
and instead "use lib 't/lib'".
On Mon, Nov 14, 2016 at 10:56 AM, James E Keenan wrote:
>
> On 11/14/2016 09:11 AM, Todd Rinaldo wrote:
> > Howdy,
> >
> > I've done a write up of a recent change to blead perl. In the future it
> will no longer be possible to count on . being in @INC. This will break
> many of the existing CPAN installs.
> >
> > It was suggested I send the RFC here:
> >
> > http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removin
> g-from-inc-is-about-to-break-cpan.html
> >
> > In Perl 5.26, it will no longer be a safe assumption to assume . is in
> @INC. This is a good move towards a more secure Perl, but will break the
> installation of many CPAN modules. For those of you wondering why this was
> done, see this post for more information.
> >
> > Many CPAN modules try to do things like: use inc::Module::Install; This
> depends on . being in @INC. If you invoke Makefile.PL without it, the
> script will not even run.
> >
>
> Here is a use case which I found very soon after building a perl at blead
> with the new option and then installing App::cpanminus against that perl.
>
> #
> Summary of my perl5 (revision 5 version 25 subversion 7) configuration:
> Commit id: dd4f16e4ff71ea6d0422d277f00fe430e1d93938
> [snip]
> config_args='-des -Dusedevel -Uversiononly
> -Dprefix=/home/jkeenan/testing/nodot -Dman1dir=none -Dman3dir=none
> -Ddefault_inc_excludes_dot'
> [snip]
> @INC:
> lib
> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux
> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7
> /home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux
> /home/jkeenan/testing/nodot/lib/perl5/5.25.7
> #
>
> I used ./bin/cpanm to install one of my CPAN distros that has a
> second-level dependency on another one of those distros,
> Perl-StringIdentifier.
>
> #
> Building and testing String-PerlIdentifier-0.05 ... FAIL
> ! Installing String::PerlIdentifier failed. See
> /home/jkeenan/.cpanm/work/1479138905.14485/build.log for details. Retry
> with --force to force install it.
> #
>
> Let's inspect that build log.
>
> #
> PERL_DL_NONLAZY=1 "/home/jkeenan/testing/nodot/bin/perl"
> "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef
> *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
> Can't locate t/eligible_chars in @INC (@INC contains: t/
> /home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/lib
> /home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/arch
> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux
> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7
> /home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux
> /home/jkeenan/testing/nodot/lib/perl5/5.25.7) at t/Auxiliary.pm line 14.
> Compilation failed in require at t/01_basic.t line 8.
> BEGIN failed--compilation aborted at t/01_basic.t line 8.
> # Looks like your test exited with 2 just after 1.
> t/01_basic.t ..
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 40/41 subtests
> #
>
> Here's what that distro has in/under its 't/' directory.
>
> #
> $ ls t |cat
> 01_basic.t
> 02_specified.t
> 03_min.t
> 04_max.t
> 05_default.t
> 06_no_scores.t
> Auxiliary.pm
> eligible_chars
> #
>
> #
> $ head t/01_basic.t
> # t/01_basic.t - four basic tests
> use Test::More tests => 41;
> use strict;
> use warnings;
>
> BEGIN { use_ok( 'String::PerlIdentifier' ); }
> use lib ("t/");
> use Auxiliary qw{ _first_and_subsequent };
>
> four_basic_tests() for (1..10);
> #
> $ head -15 t/Auxiliary.pm
> package Auxiliary;
> use strict;
> use warnings;
> our ($VERSION, @ISA, @EXPORT_OK);
> $VERSION = '0.05';
> require Exporter;
> @ISA = qw(Exporter);
> @EXPORT_OK = qw(
> _first_and_subsequent
> );
> *ok = *Test::More::ok;
> use lib ('.');
>
> our (%eligibles, %chars);
> require "t/eligible_chars";
> #
>
> The test file attempts to load Auxiliary.pm, which is located in the same
> directory as the test file. Auxiliary.pm in turn 'require's a plain-text
> file, 'eligible_chars', which is also located in t/. That 'require' fails.
>
> In this case, adding '.' to the distribution's Makefile.PL made no
> difference. I had to add "use lib ('.');" to Auxiliary.pm to enable it to
> locate 'eligible_chars', after which 'make test' PASSed.
>
> Based on this example and several other failures, my hunch is that many of
> the failures which we'll
Re: File::Copy::Recursive broken on FreeBSD and other OSes; working on replacement
A new File::Copy::Recursive has been released -- has the threat now passed? On Wed, Apr 18, 2018 at 7:25 PM, James E Keenan wrote: > This message is intended for people working on the Perl toolchain and, in > particular, for attendees at the Perl Toolchain Summit starting tomorrow in > Oslo. > > The test-against-dev work I have been conducting for several months has > identified at least one CPAN distro, high up in the toolchain, which is > broken on non-Linux operating systems. The reasons for this breakage are > sub-optimal code in modules or test suites, not "Blead Breaks CPAN." Such > breakage prevents the distro from being installed and means that its > revdeps are never reached during the following cases: > > * Installation via 'cpan' shell: Distro fails and is graded as FAIL and > reported to metabase. Assuming on 'force install' is attempted on distro, > revdep is graded as DISCARD and no report is sent to metabase or to > revdep's maintainers. > > * Installation via 'cpanm': Distro fails and is graded as FAIL. Revdep > is not attempted and is not graded anywhere. You have to examine build.log > for messages reporting "Bailing out " No report is sent to metabase or > to maintainers. > > * Because test-against-dev relies on 'cpanm', if a distro in, say, the top > 1000 of the CPAN river fails, its revdeps are never reached, meaning their > code does not get exercised against the latest monthly development release. > > The CPAN distro of greatest concern right now is File-Copy-Recursive( > http://search.cpan.org/~dmuey/File-Copy-Recursive-0.40/), currently > ranked about #128 in the CPAN river. On FreeBSD (and perhaps other OSes), > FCR's current version (0.40 as of Apr 17 2018) has an unfixed bug ( > https://rt.cpan.org/Ticket/Display.html?id=123964) leading to test > failures and failure to install. Unless a user chooses to '--force' > install FCR, that prevents its revdeps from being installed in an automated > manner or tested against dev/blead. > > Over 6000 CPAN distributions have direct or indirect dependencies on FCR, > including CPAN-Reporter, Test-File-ShareDir, DateTime, Dist-Zilla and > Catalyst-Devel. So thousands of CPAN distros cannot be installed on > FreeBSD and other systems. > > The author of FCR is aware of the bug ticket and Tom Hukins provided a > patch which I have tested successfully on FreeBSD. But the patch has not > been applied as of yesterday. As we are now in the countdown to > perl-5.28.0, we really need to be able to assess the impact of release > candidates on CPAN -- and not just on Linux. > > Earlier this week I wanted to resume sending CPANtesters reports from > FreeBSD-11.1. I tried to install CPAN-Reporter but could not, due to the > bug in its dependency, FCR. To address that I have uploaded to CPAN a new > CPAN distro, File-Copy-Recursive-Reduced (FCR2), which provides > stripped-down versions of 2 FCR subroutines, fcopy() and dircopy(), which > are used in the CPAN-Reporter test suite. I then branched CPAN-Reporter to > create a version which uses the FCR2 versions of these functions rather > than FCR. That makes CPAN-Reporter installable again. I have therefore > filed: > > https://github.com/cpan-testers/CPAN-Reporter/issues/88 > and > https://github.com/cpan-testers/CPAN-Reporter/pull/90 (a better p.r. than > my earlier /89) > > I hope that during the PTS you can review and apply this p.r. and upload a > new version of CPAN-Reporter. This will once again permit automated > installation on FreeBSD and other non-Linux operating systems. It will > also help us to assess perl-5.28's possible impact on that distro and its > revdeps. > > Thank you very much. > Jim Keenan >
Re: Move dev release tarballs to GitHub?
On Sun, Apr 10, 2022 at 6:43 AM Ricardo Signes < perl.cpanw...@rjbs.manxome.org> wrote: > Looking good. "plenv install" finds the file at metacpan, which, it > appears, is actually a backpan mirror. This suggests that we can safely > delete these old dev versions. > Running: perlbrew install -j 9 --as 11.4 5.11.4 -D man1dir=none -D man3dir=none Fetching perl 5.11.4 as /Volumes/amaretto/Users/ether/perl5/perlbrew/dists/perl-5.11.4.tar.bz2 Download https://www.cpan.org/authors/id/R/RJ/RJBS/perl-5.11.4.tar.bz2 to /Volumes/amaretto/Users/ether/perl5/perlbrew/dists/perl-5.11.4.tar.bz2 ERROR: Failed to download https://www.cpan.org/authors/id/R/RJ/RJBS/perl-5.11.4.tar.bz2 ERROR: Failed to execute the command curl --silent --location --fail -o /Volumes/amaretto/Users/ether/perl5/perlbrew/dists/perl-5.11.4.tar.bz2 https://www.cpan.org/authors/id/R/RJ/RJBS/perl-5.11.4.tar.bz2
Re: Increasing podlators Perl dependency to 5.12
On Sat, Mar 16, 2024 at 6:22 PM Russ Allbery wrote: > I wanted to provide some advance notice that I plan to increase the > minimum Perl dependency for podlators (Pod::Man and Pod::Text) to 5.12 > from 5.10 in the next release. > Sounds good to me; I appreciate the heads up! It's worth noting that at last year's Perl Toolchain Summit (PTS) there was a consensus agreement to raise the maximum-minimum required Perl version to 5.16 (that is, critical toolchain modules MAY raise their minimum version requirements to as high as 5.16, but will not do so arbitrarily), and this value will be raised to 5.20 after the release of Perl 5.40 a few months from now. (ref: https://rjbs.cloud/blog/2023/05/pts-2023-lyon-amendment-2-5/ ) ...My goal is to eventually get to at least Perl 5.24 so that I can use > postfix dereferencing. > For the 'postderef' feature (and for sub signatures too, my other favourite and oft-used feature), 5.20 should be sufficient for most things; you may want to consider stopping there for a bit.
