Re: Backpan mirror?
Hi Dave, You should be able to get backpan.cpantesters.org. Doug fixed the rsync problem at the weekend. Thanks, barbie. -- Birmingham.pm - http://birmingham.pm.org CPAN Testers - http://cpantesters.org YAPC Surveys - http://yapc-surveys.org Perl Jam - http://perljam.info On Tue, Sep 15, 2015 at 5:34 PM, David Cantrell <da...@cantrell.org.uk> wrote: > On Tue, Sep 15, 2015 at 12:24:47PM -0400, David Golden wrote: > > > Ah, right. It's private. > > > > I suggest you email the Perl NOC and ask for private rsync access. I > think > > supporting CPXXXAN makes a good case for it. > > Will do - thanks. > > -- > David Cantrell | Reality Engineer, Ministry of Information > > Immigration: making Britain great since AD43 >
Re: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN
On Thu, Apr 15, 2010 at 08:56:04AM -0600, Curtis Jewell wrote: wrote: On Thu, Apr 15, 2010 at 10:14 AM, Tim Bunce tim.bu...@pobox.com wrote: On Wed, Apr 14, 2010 at 09:59:32PM -0400, Jesse Vincent wrote: Forcing an extension makes all sorts of tools that previously just worked with a tarball suddenly start to fail. We've dealt with it in the past. However, I'm inclined to think that going that way means an entirely new client that is designed for .cpan files. This is more akin to PPM, except non binary. The question in my mind is what this gains us beyond double-clickability for Windows. (Which is a non-trivial benefit -- e.g. see a *.cpan distribution on a web page, click it to install in Strawberry Perl). It might let us rethink some of the painful conventions of distribution tarballs today. (Idea suddenly came to mind. If not workable, just take apart and reassemble until it does work.) Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated by PAUSE once the tarball is uploaded, with whatever information is required (a reference to the tarball, what version of perl is required, etc.) in order, when that file is passed to a CPAN client, to download and install the tarball. This is essentially how PPM works. The PPD file points to a tarball, via an extension to the OSD file format. It would be easier to generate an installation configuration file, supported by a new installer that can cope with the double-click install of several OSes these days, than changing the package archive format. Changing PAUSE/CPAN to require a new package archive is likely to have a detrimental effect on Perl as a whole, as older installers will then be unable to install anything new. Upgrading is not always easy for some organisations (I know of one still using 5.6.1!). Mind you, if it means adding even more files to the filesystem, we come back to the discussion about rsync :( Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: Trimming the CPAN - Automatic Purging
On Thu, Mar 25, 2010 at 11:12:32AM +, Tim Bunce wrote: Currently on PAUSE you have to explicitly delete old uploads. Which often is a good thing. While BACKPAN exists, it isn't somewhere that many go to look for old distributions. For me and probably others, BACKPAN only distributions are ones that have been specifically marked by the maintainers as obsolete, badly broken or similar. Automatic deletes from CPAN would change that. There are many distributions on CPAN that older versions work on a particular perl/os, but more recent ones don't. Latest isn't necessarily the greatest. If you are going to perform this then it should really feed off the CPAN Testers to know if a specific release has been marked as being the latest working release for a particular perl/os. I would also suggest extending the timeframe considerably to perhaps 3 or maybe 5 years. Lastly I would also personnally be annoyed if only the latest versions were available, as I often make great use of the diff tool on search.cpan.org. Having only the latest version renders that great tool redundant :( Files selected in this way would be scheduled to be deleted in a month and an email would be sent to the authors, just as if they'd selected the files for deletion via PAUSE. There are already many authors who have non-responding email addresses (I will get around to publicising that list at some point), so some will likely disappear down a blackhole. What if you're about to delete a set of distributions that should really be kept available? No one would be listening to know that it should still be kept. I would prefer a suggestion email to authors to delete, rather than an email telling them that their distributions will be deleted unless they do something. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: Trimming the CPAN - Automatic Purging
On Thu, Mar 25, 2010 at 02:08:45PM -0700, Geoffrey Broadwell wrote: Forgive a lurker, but wasn't that the point of this: http://search.cpan.org/~andk/File-Rsync-Mirror-Recent-0.0.7/ When I saw that announced, I remember thinking Yay, large archive rsync problem solved! Did it not work out? It currently supports all the fast CPAN mirrors. The CPAN Testers mirror is currently 10 seconds behind PAUSE :) Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: optional_features key names
On Wed, Dec 16, 2009 at 10:54:47AM -0500, David Golden wrote: On Wed, Dec 16, 2009 at 9:01 AM, Barbie bar...@missbarbell.co.uk wrote: On Tue, Dec 15, 2009 at 02:32:42PM +, Zefram wrote: David Golden wrote: Right now, the draft says an identifier and that term could be defined further. I take identifier, without further explanation, to mean /[A-Za-z_][0-9A-Za-z_]*/. Not anything involving \w, note. I would prefer to keep it simple like this too. If I created an Identifier type with that specification, would that suffice? Works for me :) Does anyone want to bikeshed the name or regex before I add it? A #8a2be2 one will do nicely thanks ;) Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
optional_features key names
Hi All, While reviewing a fix to my Test-(CPAN|JSON|YAML)-Meta distributions, regarding optional_features, it was questioned what the key name in each map should be. Below is an excerpt of a discussion between Kevin Ryde and myself, via the RT#52685 [1] [1] http://rt.cpan.org/Public/Bug/Display.html?id=52685 From: Kevin Ryde via RT bug-test-yaml-m...@rt.cpan.org Barbie via RT bug-test-yaml-m...@rt.cpan.org writes: Although not explicitly stated in the current specifications (v1.0 - v1.4), the convention has been to precede user defined keys with [xX]_. That doesn't sound right for the optional features names. The effect would be that anything is allowed in lower case, but if you want upper case you must write x_. That x_ bit is for extensions to maps with spec-defined keys isn't it? In the optional features names there isn't anything spec-defined, it's all user-defined names, and you're free to write anything, isn't it? Either way it would help for the spec to say something there, as I can't imagine I'll be the last to wonder what it is or isn't supposed to be. as defined in the current blead version of v2.0 of the specification: Sounds a bit dangerous to enforce future spec against META.yml's which only declare themselves as 1.4 or whatever. But my reading of that x_ would be that in 1.4 no unknown keys are allowed (toplevel, requires maps, etc), but 2.0 allows unknown keys if they begin x_, ie. a loosening ... - End forwarded message - Although the convention for the X_ naming is only stated in v2.0, it has been discussed before and been considered acceptable. However, I think Kevin makes a good point as to whether this should be backported. Thoughts welcome. Kevin also makes a good point regarding what characters should be allowable in an optional feature key name. Currently there is no specific mention of how optional features should be named (lower case? preceding X_? any value in the character class \w?). What would be the recommended naming convention for optional features? Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: CMSP 03. Deprecate YAML Tiny dialect for JSON
On Fri, Oct 09, 2009 at 09:38:45AM -0400, David Golden wrote: On Fri, Oct 9, 2009 at 8:11 AM, Ricardo Signes perl.cpanw...@rjbs.manxome.org wrote: * David Golden xda...@gmail.com [2009-10-09T07:42:35] 03. Deprecate YAML Tiny dialect for JSON Strongly agree. * I would like one violation of the JSON spec: allow Javascript-style comments. My one beef with the JSON spec. Elliot Strongly disagree. We don't want to have our own dialect. I agree with Rick. Sorry to be late to get myself together with following up on these, but better late than never hopefully :) I see 01, 02 and 03 all part of the same discussion really. There seems little point in discussing YAML if we think moving to JSON is the better option. I'm with the strongly agree camp on the first part of above :) (and with the no new dialect on the second part) However, we don't want to suddenly make the whole of CPAN invalid. Thankfully as Parse::CPAN::Meta appears to support both, I think we have that covered. I'm happy to support JSON in core, but would rather we do it visiably rather than under the covers as per the M::B example David mentioned in an earlier post. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: CMSP 10. Add a free-text prerequisite field
On Fri, Oct 09, 2009 at 08:19:29AM -0400, Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:47:00] 10. Add a free-text prerequisite field Strongly oppose. The META file is meant to tell machines about dists. This will not be useful. Agreed. This kind of information should be in the README, as it's just informative, and not something that we should expect CPAN/PLUS to parse and understand. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: CMSP 11. OS/arch/platform-specific requirements
On Fri, Oct 09, 2009 at 11:52:50AM -0400, David Golden wrote: On Fri, Oct 9, 2009 at 7:47 AM, David Golden xda...@gmail.com wrote: 11. OS/arch/platform-specific requirements Proposal: I would like to see a way to specify OS-specific requirements. One option might be to use Devel::CheckOS, which already seems to have a comprehensive list of supported OS names, and have a hash like: Opposed. This would need a total rethink of prerequisites (e.g. can 'optional features' have os-specific requirements? Madness). That is probably not going to happen until 3.0. Also opposed. Any OS list will change over time, and what may not work in a current OS, may be supported in a future version. I see this being better left to the Makefile.PL or Build.PL if the author feels stronglky enough to exclude certain OSes, etc. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: CMSP 19. Make repository resource a hash
On Sat, Oct 31, 2009 at 03:45:31PM -0400, David Golden wrote: On Sat, Oct 31, 2009 at 2:05 PM, Barbie bar...@missbarbell.co.uk wrote: Agreed on both counts. type as proposed can be easily derived from the URLs from the examples. Is there a use case for its use? Both Subversion, and Git repositories can use http://; URLs, so there needs to disambiguate them. No. I meant type not format. In the example given, the URL was http://github.com and the type was github. It seemed a bit redundant to explicitly say what public website repository is being used, when it was in the domain part of the URL. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
Re: ENOMAIL
On Sun, Oct 11, 2009 at 02:35:56PM -0700, Ask Bjørn Hansen wrote: On Oct 11, 2009, at 13:08, Barbie wrote: Anyone any idea why I'm not getting mail to this list? Have I been blocked? Nothing in my spam traps and the last mail i got was Aug 26. I note that there has been a flurry of CMSP items in the web archives, but I'm not going to both cut-n-pasting replies to into emails :( Your mail server are receiving and accepting the mails. I sent you a sample log entry off-list. Thanks Ask. Very strange. I'll have to hassle my ISP to see what's going on. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
ENOMAIL
Anyone any idea why I'm not getting mail to this list? Have I been blocked? Nothing in my spam traps and the last mail i got was Aug 26. I note that there has been a flurry of CMSP items in the web archives, but I'm not going to both cut-n-pasting replies to into emails :( Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org
