Re: Toolchain issues
> On Thu, 29 Apr 2010 08:42:28 +0200, "H.Merijn Brand" > said: >For some reasons I need Date-Manip-5.xx instead of the parallel >developed version -6.xx. By time-stamp, -5.xx may even be newer >cpan SBECK/Date-Manip-5.56.tar.gz >works fine, but if you do that again, it will INSTALL the same >module again, and again and again, whereas >cpan Date::Manip >will see that the latest version is already installed. As I have >that specific notation as part of a long list of module arguments, >stored in a file that is restarted after build fixes, it will indeed >build and re-install Date::Manip-5.xx time after time again CPAN documentation: Specifying a distro with the install command (or on the cpan commandline) always tries to install, that's indeed documented behaviour, so no bug here. (I suppose you know that, just stating it for further clarification). CPAN News: SBECK/Date-Manip-6.10.tar.gz is out. Works with 5.12. But still DateTime::Format::DateManip fails tests with that. Workaround 1: If you enable distroprefs and write a distroprefs file with "goto", then you can write "install Date::Manip" again. Something like (off the top of my head) match: distribution: "SBECK/Date-Manip-6.10.tar.gz" goto: "SBECK/Date-Manip-5.56.tar.gz" Workaround 2: https://rt.cpan.org/Ticket/Display.html?id=55771 There is a patch. Distroprefs can apply patches too, but a bit work involved, let me know if you want help. Workaround 3: Install DT:F:DM with force. Distroprefs can specifify testing strategy too, let me know if you want help. HTH, -- andreas
Re: What's the common denominator in these NYTProf failures?
> On Wed, 28 Jan 2009 13:50:05 +, Tim Bunce said: > I'm strugling to find a common denominator in these test results: > http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Devel-NYTProf+2.07_94 > It would be wonderful if there was some tool that would analyse the > perl -V output and help identify the combinations of settings associated > with failures - assuming there is a pattern. The tool exists: CPAN::Testers::ParseReport comes with the program ctgetreports. Pay attention to the --solve parameter. Unfortunately, in your case no findings except what David Golden already mentioned: Regression 'meta:from' Name Theta StdErr T-stat [0='const'] 1. 0.1574 6.35 [...] [2='eq_bin...@cpan.org'] -0.9412 0.1619 -5.81 which tells us that normally the tests succeed but if the tester is bin...@cpan.org, there is only 6% PASS. Indeed, bingos reported one PASS: 3151674 -- andreas
Re: Fwd: [rt.cpan.org #40976] New files installed without user-write permission
> On Mon, 17 Nov 2008 01:34:09 +0100, demerphq <[EMAIL PROTECTED]> said: > Can anyone help me out with this? Is this EUI's fault or something > else? Is anything to do with this permission issue that we have been > discussing? For the record: Unix has three types of permissions, "user", "group", and "other". This ticket seems to complain about "user" permissions. Last week's long winded permission debate was about "other" permissions, so two different things. I seem to recall that in the MakeMaker community the consensus always was that installing writable is a nono. That would allow to reject the ticket. But what the last sentence is probably saying is that 1.44 was broken and nobody detected it. That would mean, tests and/or specs are missing. In any case, rest assured, that PAUSE has not changed and has not altered any bit of the distribution. -- andreas
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
>>>>> On Wed, 12 Nov 2008 20:44:45 -0800, Michael G Schwern <[EMAIL PROTECTED]> >>>>> said: > Andreas J. Koenig wrote: >>>>>>> On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern <[EMAIL >>>>>>> PROTECTED]> said: >> >> > Now that the CPAN shells and archiving modules are handling it at their >> > end, I >> > think the PAUSE filter should be removed. It's not PAUSE's job to be the >> > code >> > police. >> >> It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell >> and archiving module involved. > What I was expressing is that the CPAN shell can do I know very well what the cpan shell can do, but it cannot replace tar. > the twiddling to strip > flags at the point of extraction, rather than PAUSE stopping it at the gate. > Archive::Tar already does this (see $Archive::Tar::INSECURE_EXTRACT_MODE). > The important distinction being that it's done under the user's control and > not by PAUSE fiat. I don't care what the users do under their control. I care that they do not get hosed by the perl community. > PAUSE shouldn't be playing security nanny or any other nanny. PAUSE is innocent and shall remain so. But when the perl community does not enough to protect the innocent user from stupid packaging some sort of action is required. We can find alternative ways of dealing with it but we are responsible for avoiding harm to the innocent. > It's not even necessary or effective. Because there's already a perfectly > sensible and universal way to avoid this problem and that's to set your umask > to something sensible. Then no matter what the archive's internal > permissions > are set to they'll be stripped when it's extracted. Hear, hear. I tell you again, I don't care what the users do under their control. I care that they do not get hosed by the perl community. > Most systems already do this by default, because it's good security > practice. If you don't have a umask set, that's a basic > vulnerability *at the user's end*. No amount of hand-holding from > CPAN will protect the user without a umask. Some other system will > ship a world writable file or a setuid executable or something. > Then you're hosed all over again. You are not well informed. # umask 002 # tar xzf /home/ftp/pub/PAUSE/authors/id/Y/YV/YVES/ExtUtils-Install-1.51.tar.gz # ls -la ExtUtils-Install-1.51 total 1104 drwxrwxrwx 4 544 5134096 Nov 12 20:02 ./ drwxrwxrwt 10110 root root 1073152 Nov 13 08:24 ../ -rwxrwxrwx 1 544 5131765 Mar 3 2008 Build.PL* -rwxrwxrwx 1 544 5138911 Nov 12 19:58 Changes* -rwxrwxrwx 1 544 513 197 Sep 10 2007 INSTALL.SKIP* -rwxrwxrwx 1 544 513 446 Nov 5 21:51 MANIFEST* -rwxrwxrwx 1 544 513 458 Sep 10 2007 MANIFEST.SKIP* -rwxrwxrwx 1 544 513 743 Nov 12 20:02 META.yml* -rwxrwxrwx 1 544 5132506 Mar 3 2008 Makefile.PL* -rwxrwxrwx 1 544 5131282 Sep 10 2007 README* drwxrwxrwx 3 544 5134096 Nov 12 20:01 lib/ drwxrwxrwx 3 544 5134096 Nov 12 20:01 t/ > We are trying to fix a basic, wide-spread, user-end security hole, one that > is > not at all specific to Perl, at too high a level and too specific a system. It's not wide spread, it's only coming frrom a handful of Windows users and we have to react some way or another. Doing nothing is not an option. > It's like plugging one hole in a screen door. Pfff, there's no arguing about the minitude of the achievement per se. I'm much more annoyed by your intervention than I'm already annoyed by the mere fact that we have to fritter away our time with such a stupidity. -- andreas
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
> On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern <[EMAIL PROTECTED]> > said: > Now that the CPAN shells and archiving modules are handling it at their end, I > think the PAUSE filter should be removed. It's not PAUSE's job to be the code > police. It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell and archiving module involved. -- andreas
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
> On Wed, 12 Nov 2008 14:51:26 -0600, Jonathan Rockway <[EMAIL PROTECTED]> > said: > I agree with demerphq here, why can't PAUSE just fix this? It didn't come up in the hasty discussion about this problem, it didn't occur to me for a moment. And to nobody else. And the number of victims seemed to be low. I'm watching the number of rejects every day and I have counted 50 since Sep 23rd, so exactly one per day on average. I will probably take the time implement the suggestion, but can't promise it at the moment. > It won't > break signatures (since they sign file content, not file metadata), and > it won't break the CHECKSUMS file (since that could be generated after > the tarball is fixed). It seems you're right. > It could be weird if what you upload to CPAN isn't what you > download... but it fixes a security problem, and it doesn't require > authors to know that this problem exists. Abstraction++ (demerphq,jrockway)++ -- andreas
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
> On Tue, 30 Sep 2008 17:11:00 -0500, Jonathan Rockway <[EMAIL PROTECTED]> > said: >> Anyway, I think the average CPAN author doesn't >> really know or care about that, sadly. >> See also > FWIW, this is true. I have never thought about it. > Personally, I am confused as to why users have programs that do whatever > an input file from the Internet tells them to do. If you don't want > your tar command to create world-writable files, you should probably > tell your tar command to not create world-writable files... right? That > is much easier than convincing every person on the Internet to do what > you want. It is also easier than convincing every CPAN author to > upgrade MakeMaker. Not true. The tools we are advocating must simply work. If they would leave all decisions to the end user we would have no CPAN. MakeMaker has always done the right thing, no need to upgrade. There was a bug to squash and not to paint over it or bathe in ignorance. Did you even notice the bug in the noise? -- andreas
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
> On Tue, 23 Sep 2008 11:40:09 +0200, "Jos I. Boumans" <[EMAIL PROTECTED]> > said: >> And so I have implemented it now. If it breaks too much in too short >> time, we could probably revert it, but first I'd like to see how bad >> we really do. > I agree to this (first) solution; this will give us a good idea about > the > scope of the problem. I have watched the indexer for a week now. The scope is more than two uploads per day. These uploads got an email about world writable files or directories. I looked up their CPAN directories right now and based on the findings I have added the third column. 23-Sep SEMUELF/Data-ParseBinary-0.07.tar.gzfixed 26-Sep GFUJI/warnings-unused-0.02.tar.gz not fixed 26-Sep STEFFENW/DBD-PO-0.10.tar.gz not fixed 26-Sep STEFFENW/Bundle-DBD-PO-0.10.tar.gz not fixed 26-Sep AJDIXON/daemonise-1.0.tar.gznot fixed 26-Sep RPHANEY/openStatisticalServices-0.015.tar.gzfixed 26-Sep RPHANEY/openStatisticalServices-0.018.tar.gzfixed 27-Sep COSIMO/Imager-SkinDetector-0.01.tar.gz fixed 27-Sep FAYLAND/Pod-From-GoogleWiki-0.06.tar.gz fixed 28-Sep DANNY/Rose-DBx-Object-Renderer-0.34.tar.gz not fixed 28-Sep MTHURN/WWW-Search-Ebay-2.244.tar.gz fixed 28-Sep JSTROM/Tk-TextVi-0.014.tar.gz not fixed 28-Sep JSTROM/Tk-TextVi-0.0141.tar.gz not fixed 29-Sep MATTN/Net-Kotonoha-0.07.tar.gz fixed 29-Sep MTHURN/WWW-Search-Ebay-Europe-2.002.tar.gz fixed 29-Sep ANGERSTEI/Net-Ping-Network-1.57.tar.gz not fixed 29-Sep RPHANEY/openStatisticalServices-0.019.tar.gzfixed Congratulations to all authors who managed to fix their distros. I *you* are among them, please spread the word how you did it. I expect that the third column is already wrong when you read this. Good night, -- andreas
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
> On Mon, 22 Sep 2008 16:00:41 -0400, "David Golden" <[EMAIL PROTECTED]> > said: > Problem 1: race condition between unarchiving and execution if > Makefile.PL or Build.PL is world writable (ditto test files as well) > (a) Have CPAN and CPANPLUS refuse to run 'perl *.PL' if the PL in > question is world writable. What you say below. > (b) Have CPAN and CPANPLUS not preserve mode permissions even for > root; that's "--no-same-permissions") for tar or $Archive::Tar::CHMOD > = 0 for Archive::Tar. I presume there's a comparable thing for zip > archives. That leaves it up to the users umask setting. I have no experience how much it would break. > (c) Both > (d) Something else I lean toward PAUSE not indexing them thus pulling the plug as early as possible. > (e) Ignore it Even if the communitiy tends to believe this to be irrelevant, I'd say Shlomi is right. There's nothing that allows us to ignore security relevant issues. We have to be paranoid, period. > Personally, I lean towards (b) as that seems relatively sane and > minimally disruptive. > For (a), I worry about edge cases for operating systems that don't > have unixish permissions. E.g. on Win32, an administrative always has > write-permission, even on files set to be read-only. A less > aggressive option than (a) is just to issue warnings about > world-writable files. Sounds good. > For completeness, there's a possible problem 2: An insecure umask can > lead to world-writable files, including not only the unarchived files, > but also Makefile (or Build) and some files in blib [1]: > (a) Ignore this -- insecure umask isn't Perl's problem to worry about > (b) Set an appropriate umask before generating Makefile, Build or > copying things to blib. > For this one, I lean towards (a). So do I. Apart from that, I wonder if and how 'make dist' could let world readable files escape. Or were they built without 'make dist'? There was umask setting code in MakeMaker since the early days. If it isn't anymore, this should be fixed, and if you agree with me, it must be fixed RSN, given PAUSE would refuse to index distros with world readable files. -- andreas
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
>>>>> On Mon, 22 Sep 2008 22:37:55 +0200, [EMAIL PROTECTED] (Andreas J. Koenig) >>>>> said: >> (d) Something else > I lean toward PAUSE not indexing them thus pulling the plug as early > as possible. And so I have implemented it now. If it breaks too much in too short time, we could probably revert it, but first I'd like to see how bad we really do. -- andreas
Re: use Test::More no_plan => $plan;
>>>>> On Tue, 9 Sep 2008 12:51:02 +0200, Aristotle Pagaltzis <[EMAIL >>>>> PROTECTED]> said: > * Andreas J. Koenig <[EMAIL PROTECTED]> [2008-09-09 11:25]: >> It's definitely the 'I broke CPAN' level. My smoker has 260 >> fails more than usually. > Due to this particular issue? I have not checked but I have no doubt. There was nothing spectacular else afaics. > Anyway, the biggest “I broke CPAN” > event I remember involved failures cascading to some 15× as many > distributions – literally more than half of the CPAN. This one > isn’t nearly as bad, even if it’s more than bad enough. Good > thing it’s a dev release, eh? Absolutely! I wish I had expressed my gratitude for getting dev releases again. Thank you, Schwern, sorry for being grumpy this morning. -- andreas
Re: use Test::More no_plan => $plan;
> On Tue, 09 Sep 2008 05:03:25 -0700, Michael G Schwern <[EMAIL PROTECTED]> > said: > I've uploaded a new alpha to deal with this. It still breaks Sub::Uplevel. Sub::Uplevel has lots of dependencies. I won't smoke a Test-Simple that breaks Sub-Uplevel. Or if the fault is on Sub-Uplevel, please let David Golden know. I'm pretty sure I have reported this recently. Have I not? -- andreas
Re: use Test::More no_plan => $plan;
> On Tue, 9 Sep 2008 09:00:54 +0200, Aristotle Pagaltzis <[EMAIL > PROTECTED]> said: > * Michael G Schwern <[EMAIL PROTECTED]> [2008-09-09 08:15]: >> I was surprised to get a few hundred results > Note that CodeSearch indexes tarballs, so there are likely to be > a lot of dupes. But even so, a cautious estimate would still put > that at at least several dozen unique hits, so it’s not quite an > “I broke CPAN”-level problem, but it’s still significant. It's definitely the 'I broke CPAN' level. My smoker has 260 fails more than usually. -- andreas
Re: Module::Build 0.2809 release coming, should we test it?
>>>>> On Mon, 8 Sep 2008 16:36:00 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said: > # from Andreas J. Koenig > # on Monday 08 September 2008 15:16: >> Since yesterday I have downloaded and analysed ~56000 testreports from >> cpantesters and found ~135 distros that have been tested by both MB >> 0.2808 and 0.2808_03. There is only one result (Test-Group-0.12) that >> looks bad but it turns out to be due to broken Test::More 0.81_01. All >> others suggest that _03 is doing well. > Umm... okay. > 1. I see a lot of m/0.2808_03 +FAIL/ in there. OK, I walk you through them. First off, there are ten cases in the file I sent you. B-Generate-1.130.2808 FAIL 5 B-Generate-1.130.2808 PASS 6 B-Generate-1.130.2808_03 FAIL 1 So the above is a case where it's impossible to judge without looking at the report but at the same time we cannot have any expectations about a single event when the previous outcome was diverse. Let's call it a case DUNNO. CGI-Application-Plugin-ValidateRM-2.2 0.2808 FAIL 18 CGI-Application-Plugin-ValidateRM-2.2 0.2808_03 FAIL 2 Seems like the exact right behaviour. Let's call it a case OK. Devel-LeakTrace-0.05 0.2808 FAIL 43 Devel-LeakTrace-0.05 0.2808 PASS 6 Devel-LeakTrace-0.05 0.2808_03 FAIL 1 It's a DUNNO but likelihood is high that we need not look closer on this one. HTTP-Proxy-0.230.2808 FAIL 8 HTTP-Proxy-0.230.2808 PASS 5 HTTP-Proxy-0.230.2808_03 FAIL 6 HTTP-Proxy-0.230.2808_03 PASS 1 Although it's a DUNNO, the distribution between fail and pass is quite good. Math-BaseCalc-1.0120.2808 FAIL 9 Math-BaseCalc-1.0120.2808 PASS 9 Math-BaseCalc-1.0120.2808_03 FAIL 1 A DUNNO. Metaweb-0.05 0.2808 FAIL 14 Metaweb-0.05 0.2808 PASS 10 Metaweb-0.05 0.2808_03 FAIL 1 DUNNO Parse-BACKPAN-Packages-0.330.2808 FAIL 18 Parse-BACKPAN-Packages-0.330.2808 PASS 8 Parse-BACKPAN-Packages-0.330.2808_03 FAIL 1 DUNNO Template-Plugin-Class-0.13 0.2808 FAIL 6 Template-Plugin-Class-0.13 0.2808 PASS 55 Template-Plugin-Class-0.13 0.2808_03 FAIL 1 DUNNO Test-Group-0.120.2808 PASS 47 Test-Group-0.120.2808_03 FAIL 1 A WHOAA THERE, that seems to indicate that something's wrong. But as I explained in the previous mail, this is due to Test-Simple dev release. Test-JSON-0.06 0.2808 FAIL 15 Test-JSON-0.06 0.2808 PASS 44 Test-JSON-0.06 0.2808_03 FAIL 1 A DUNNO again. So to sum up, we have found that two of the ten support the view that _03 is doing fine, one appears to be against but is proved wrong, so seven remaining are simply DUNNOs that we can ignore because they do not indicate that we have to doubt. > Did you chase-down several of those? No. > Are you saying that having > "some fail" on 0.2808 implies that "some fail" on 0.2808_03 means > no regression, or did you manage to somehow correlate the > 0.2808_03 fails to the same machines sending 0.2808 fails? As explained above, I used judgement. If somebody with strong statistics fu can measure the trustworthyness of the data in fovor of a releasse, please speak up. > 2. Where are these reports coming from? I have said it, I have (well, CPAN::Testers::ParseReport has) downloaded 56000 reports from http://www.nntp.perl.org/group/perl.cpan.testers/ > Again, the subject of false > fails: I would hate for testers to be pummelling other authors with > alpha M::B errors while the M::B maintainers are left blissfully > ignorant. Toolchain maintainers will probably want to use ctgetreports which comes with CPAN::Testers::ParseReport. If dev releases pummel other authors it's a call for better tests. If your tests are good, then release early, release often and watch the results on cpantesters. The point of cpantesters for toolchain modules: they may not only watch their own but all test results where they might be involved. -- andreas
Re: Module::Build 0.2809 release coming, should we test it?
> On Fri, 5 Sep 2008 16:48:37 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said: > http://scratchcomputing.com/tmp/generated_by.module_build.list Since yesterday I have downloaded and analysed ~56000 testreports from cpantesters and found ~135 distros that have been tested by both MB 0.2808 and 0.2808_03. There is only one result (Test-Group-0.12) that looks bad but it turns out to be due to broken Test::More 0.81_01. All others suggest that _03 is doing well. -- andreas count-for-ewilhelm.pl.out.condensed Description: Binary data
Re: [ANNOUNCE] Test::More 0.81_01
> On Sat, 06 Sep 2008 15:47:58 -0700, Michael G Schwern <[EMAIL PROTECTED]> > said: > http://test-more.googlecode.com/files/Test-Simple-0.81_01.tar.gz This version breaks the test for DAGOLDEN/Sub-Uplevel-0.1901.tar.gz t/05_honor_prior_override # Failed test 'use Sub::Uplevel;' # at t/05_honor_prior_override.t line 50. # Tried to use 'Sub::Uplevel'. # Error: Global symbol "$VERSION" requires explicit package name at /home/sand/.cpan/build/Sub-Uplevel-0.1901-NZoOq2/blib/lib/Sub/Uplevel.pm line 5. # Global symbol "@ISA" requires explicit package name at /home/sand/.cpan/build/Sub-Uplevel-0.1901-NZoOq2/blib/lib/Sub/Uplevel.pm line 15. # Global symbol "@EXPORT" requires explicit package name at /home/sand/.cpan/build/Sub-Uplevel-0.1901-NZoOq2/blib/lib/Sub/Uplevel.pm line 16. # BEGIN not safe after errors--compilation aborted at /home/sand/.cpan/build/Sub-Uplevel-0.1901-NZoOq2/blib/lib/Sub/Uplevel.pm line 85. # Compilation failed in require at (eval 4) line 2. # BEGIN failed--compilation aborted at (eval 4) line 2. Number found where operator expected at t/05_honor_prior_override.t line 65, near "uplevel 1" (Do you need to predeclare uplevel?) Name "main::uplevel" used only once: possible typo at t/05_honor_prior_override.t line 65. # Failed test 'caller from uplevel subroutine calls custom routine' # at t/05_honor_prior_override.t line 81. # got: 'CODE(0x87b820)' # expected: 'niam' # Looks like you failed 2 tests of 7. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/7 subtests -- andreas
Re: passing the baton onwards
>>>>> On Fri, 05 Sep 2008 17:15:04 -0700, brian d foy <[EMAIL PROTECTED]> said:
> In article <[EMAIL PROTECTED]>, (Andreas J. Koenig)
> <[EMAIL PROTECTED]> wrote:
>> >>>>> On Fri, 05 Sep 2008 10:54:40 -0700, brian d foy <[EMAIL PROTECTED]>
>> >>>>> said:
>>
>> > Or, Andreas could change PAUSE, which is a bit more involved :)
>>
>> Do you not know the abandoned flag? Or not considering it appropriate?
> *I* know about it, but you also have to register the module, don't you?
Yes, but this is probably a good thing.
> Beyond that, is there a way for everyone to see the list of those
> modules?
Currently you'd need to write a few lines of code to get at the list,
like, say:
% perl -e '
use CPAN;
for $m (CPAN::Shell->expand("Module","/./")){
next unless $m->dslip_status->{S} eq "a";
print $m->id, "\n";
}
'
CPAN: Term::ANSIColor loaded ok (v1.10)
CPAN: Storable loaded ok (v2.15)
Going to read /home/sand/.cpan/Metadata
Database was generated on Sat, 06 Sep 2008 05:03:24 GMT
CPAN: YAML::Syck loaded ok (v0.71)
Going to read /home/sand/.cpan/build/
DONE
Found 320 old builds, restored the state of none
Agent
Algorithm::ScheduledPath
Apache::Sandwich
Be::Query
Business::OnlinePayment::InternetSecure
Crypt::RC6
Crypt::Serpent
Lingua::EL::Poly2Mono
Math::Brent
Module::MakefilePL::Parse
Mozilla::Backup
Parallel::Performing
R3
Tamino
WWW::BF2Player
WWW::BF2S
WWW::GameMonitor
Win32::Share
> That's what I meant about you changing pause, much like you
> did for 06.perms.
Anybody can set up a website to publish this list. It should probably
also on PAUSE. Yes, will do, that way it is always uptodate.
> It would also be nice to see that bit set somewhere like CPAN Search,
> maybe with a button that says "I want to take over maintenance".
I hope Graham listens:)
--
andreas
Re: passing the baton onwards
> On Fri, 05 Sep 2008 10:54:40 -0700, brian d foy <[EMAIL PROTECTED]> said: > Or, Andreas could change PAUSE, which is a bit more involved :) Do you not know the abandoned flag? Or not considering it appropriate? On the Edit Module Metadata page the DSLIP status has under Support Level: developer mailing-list comp.lang.perl.* none abandoned unknown -- andreas
Re: imaginary Makefile.PL (and scripts)
> On Wed, 3 Sep 2008 13:24:34 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said: > That is different than a tarball though. Does the script installation > have to be given up in order to eliminate the ambiguous behavior in the > case of a dist tarball? Good point. I can probably limit it to cases of single file distros. I'll look into this. > On another note about scripts: sleepserver still never made it into the > index despite my reading of mldistwatch and working to try to get the > META.yml 'provides' field right. Is there something that says I have > to have a .pm file to get indexed? There's something that says that 02packages.details.txt is about namespaces which implicitly says it is about modules and not about scripts. Package names within scripts are never a exposed (except the perverse use cases like the user evals the script inside perl or so). > That is, this distribution is: > bin/sleepserver > META.yml > Build.PL > t/00-load.t I think this goes beyond the perl-qa agenda. I'll write you separately about this. > Which means that it can have dependencies and tests. >>> Incidentally, I would love to be able to move forward to the time >>> when there is neither Build.PL nor Makefile.PL. >> Hear, hear! :-) > Is 'dynamic_config: 0' supported? The Build.PL in the above distro is > not really needed. In CPAN.pm it is supported, yes. In the PAUSE I see no use for it because PAUSE takes every META.yml as the best it can get, so. -- andreas
Re: imaginary Makefile.PL
> On Wed, 3 Sep 2008 10:57:20 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said: >> And IMO this hints at a real problem that was mentioned >> in this thread, but was not really indicted: namely CPAN.pm’s >> logic that if there is no Makefile.PL, it is a sane idea to make >> one up out of whole cloth. I can’t believe anyone would think >> this could ever *ever* work, though Andreas does not strike me as >> the type to put harebrained heuristical magic in code. So I have >> to wonder what the justification for this behaviour might be. Is >> it really necessary or even helpful? > I've been told that it is intended for tarballs made in the times when > there was no such thing as Makefile.PL yet. Ah, history... Not quite. The Makefile.PL was invented long before CPAN evolved. But many early uploaders believed that uploading Foobar.pm is the way to go. Or foobar.pl. And when you ask the CPAN shell to install ANDK/keepcool-0.344 you'll probably be surprised that this *script* installs just fine. % head /home/ftp/pub/PAUSE/authors/id/A/AN/ANDK/keepcool-0.344 #!/usr/bin/perl -w =head1 NAME keepcool - throttle a process with STOP und CONT calls And if you read $CPAN/scripts/index.html you might imagine that the mechanism had its merits. I'm not opposed to giving it up, just providing the historical context. > Incidentally, I would love to be able to move forward to the time when > there is neither Build.PL nor Makefile.PL. Hear, hear! :-) -- andreas
Re: git tarballs / tarfile comments
>>>>> On Wed, 03 Sep 2008 05:55:19 +0200, [EMAIL PROTECTED] (Andreas J. Koenig) >>>>> said: > (I'll have a look what CPAN.pm can do about this ASAP.) CPAN 1.92_64 is uploaded with a workaround for broken tar implementations. Please upgrade: cpan> install ANDK/CPAN-1.92_64.tar.gz Bugreport against Archive::Tar is filed. http://rt.cpan.org/Ticket/Display.html?id=38932 Thanks for the heads up! -- andreas
Re: git tarballs / tarfile comments
> On Tue, 2 Sep 2008 18:21:34 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said: >> a comment (a GIT commit id in this case). You need GNU tar 1.14 to >> handle the extended header correctly. Earlier versions will display >> a warning and extract the comment as a file. ew> Ah, interesting. >>> That first file is the problem. Because the distribution doesn't >>> untar cleanly into a subdirectory, CPAN.pm creates a subdir for you >>> ... >> >> Given that GIT is becoming more popular it would be good to teach >> CPAN.pm to deal with these kind of tarballs even when they are >> being processed by older tar versions. ew> And then CPAN.pm will need to be upgraded ;-) >>> This might also explain why the distribution doesn't appear on >>> search.cpan.org. ew> The tar on that machine (or PAUSE?) needs an upgrade? For the record: the tar on PAUSE is 1.16 since December 2006. (I'll have a look what CPAN.pm can do about this ASAP.) -- andreas
Re: [Slightly OT] Interpreting cpan-testers failures
> On Fri, 21 Mar 2008 08:34:15 -0500, Michael Carman <[EMAIL PROTECTED]>
> said:
> The common theme is this:
>
> Output from '/usr/bin/make':
>
> ERROR: Cannot copy 'Tk-DiffText-0.18libTkDiffText.pm' to
> 'blib/lib/Tk-DiffText-0.18libTkDiffText.pm': No such file or directory
>
> at -e line 1
> *** Error code 255
> Stop in /usr/local/src/CPAN/build/MJCARMAN-xVUXJa.
>
> Note the lack of path separators. I received an email from one user
> who including a directory listing. It appeared that the directory
> structure was flattened. e.g. There was a file named
> "Tk-DiffText-0.18\lib\Tk\DiffText.pm" instead of DiffText.pm in the
> folder Tk-DiffText-0.18/lib/Tk.
I can confirm that this happens when I use Archive::Zip to extract the
zipfile but does not happen when I use unzip 5.52. This is on a Debian
Linux system. But unzip complains loudly about other things and
finally does not return success after the untar operation. Here are
the complaints from unzip:
% unzip /home/ftp/pub/PAUSE/authors/id/M/MJ/MJCARMAN/Tk-DiffText-0.18.zip
Archive: /home/ftp/pub/PAUSE/authors/id/M/MJ/MJCARMAN/Tk-DiffText-0.18.zip
Tk-DiffText-0.18\MANIFEST: mismatching "local" filename
(Tk-DiffText-0.18/MANIFEST),
continuing with "central" filename version
warning: /home/ftp/pub/PAUSE/authors/id/M/MJ/MJCARMAN/Tk-DiffText-0.18.zip
appears to use backslashes as path separators
inflating: Tk-DiffText-0.18/MANIFEST
Tk-DiffText-0.18\t\Tk-DiffText.t: mismatching "local" filename
(Tk-DiffText-0.18/t/Tk-DiffText.t),
continuing with "central" filename version
inflating: Tk-DiffText-0.18/t/Tk-DiffText.t
Tk-DiffText-0.18\lib\Tk\DiffText.pm: mismatching "local" filename
(Tk-DiffText-0.18/lib/Tk/DiffText.pm),
continuing with "central" filename version
inflating: Tk-DiffText-0.18/lib/Tk/DiffText.pm
Tk-DiffText-0.18\Changes: mismatching "local" filename
(Tk-DiffText-0.18/Changes),
continuing with "central" filename version
inflating: Tk-DiffText-0.18/Changes
Tk-DiffText-0.18\README: mismatching "local" filename
(Tk-DiffText-0.18/README),
continuing with "central" filename version
inflating: Tk-DiffText-0.18/README
Tk-DiffText-0.18\Makefile.PL: mismatching "local" filename
(Tk-DiffText-0.18/Makefile.PL),
continuing with "central" filename version
inflating: Tk-DiffText-0.18/Makefile.PL
Tk-DiffText-0.18\META.yml: mismatching "local" filename
(Tk-DiffText-0.18/META.yml),
continuing with "central" filename version
inflating: Tk-DiffText-0.18/META.yml
zsh: exit 1 unzip
/home/ftp/pub/PAUSE/authors/id/M/MJ/MJCARMAN/Tk-DiffText-0.18.zip
And here is what Archive::Zip does:
perl -le '
use Archive::Zip;
my $zip = Archive::Zip->new();
my $file =
"/home/ftp/pub/PAUSE/authors/id/M/MJ/MJCARMAN/Tk-DiffText-0.18.zip";
my $status;
$status = $zip->read($file);
$CPAN::Frontend->mydie("Read of file[$file] failed\n")
if $status != Archive::Zip::AZ_OK();
$CPAN::META->debug("Successfully read file[$file]") if $CPAN::DEBUG;
my @members = $zip->members();
for my $member ( @members ) {
my $af = $member->fileName();
print "$af";
}
'
Tk-DiffText-0.18\MANIFEST
Tk-DiffText-0.18\t\Tk-DiffText.t
Tk-DiffText-0.18\lib\Tk\DiffText.pm
Tk-DiffText-0.18\Changes
Tk-DiffText-0.18\README
Tk-DiffText-0.18\Makefile.PL
Tk-DiffText-0.18\META.yml
So it seems you have the backward slashes in the archive which may or
may not be correct. The manpage of Archive::Zip seems to suggest that
I, as a user do not have to care.
> The zip file was created by IZArc 3.81 on Windows XP SP2.
Now it will need some reasearch to write a good bugreport against one
or more of Archive::Zip, unzip, IZArc. Or you choose to use a
different tool. I think if I were you I'd use a different tool. Or
many different tools:) I'll leave that to you...
--
andreas
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
> On Mon, 24 Dec 2007 17:26:47 +, David Cantrell <[EMAIL PROTECTED]> > said: dc> Michael G Schwern wrote: >> [1] It can be argued that bleadperl testers should probably not email >> authors I tend to agree. dc> I'd argue that they should, as problems found testing against bleadperl dc> seem to end up being problems in the next stable release. The argument is not about the usefulness of the reports per se, just about the practice to send CPAN authors unsolicited email. dc> Personally dc> I'd prefer to at least have the opportunity to fix my modules before dc> ordinary users (who never touch a dev perl) will ever see the problem. As author you have already the option to fetch the reports from cpantesters either by visiting the site or by using MARCEL's App::sync_cpantesters. Perhaps needs more propagation. dc> Additionally, results sent to the cpan-testers list are largely dc> un-monitored AFAIK - it's really just a convenient way of feeding nntp dc> and the various webby tools. If by testing a module we find an dc> honest-to-goodness bug in bleadperl, it's far more likely to get noticed dc> and reported to p5p if the *module* author is notified cos he's the one dc> who is most likely to be paying attention. This is rather an argument against sending because the author has the right to be spared from the utter nonsense[1] that happens in bleadperl and in a separate thread it has already been confirmed that this is not desireable. dc> And no, p5p definitely shouldn't be fed cpan-testers failure reports dc> from dev perls directly! Even ignoring the load on the perl.org mail dc> server, I can bet you that most people would just procmail them to dc> /dev/null because most are irrelevant to p5p - they're the same bugs in dc> modules that are also caught on stable perls. You hit the nail on the head: we need better monitoring of the test reports. But this doesn't necessarily mean that we have the right to send the reports to the authors. -- andreas [1] not that it happens every day, but every now and then a patch breaks lots of modules at once.
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
> On Sun, 23 Dec 2007 13:24:30 -0600 (CST), Dave Rolsky <[EMAIL PROTECTED]>
> said:
>> Sorry I didn't notice before I posted that this can be refactored into
>> a while loop:
>>
>> while (You don't understand the output of your own test script){
>> Rewrite your test script;
>> Release;
>> }
> If only it were that easy.
I didn't say it was easy.
> [...]
> If the tester were a device it shouldn't be telling the developer what
> to do either, now should it?
No sir, the tester is not only a tester, he is a user too. If the
tester has something to say and writes a bug report through the bug
channels he is a normal user, is he not?
> [...]
> Should testers pre-install Module::Build? I don't freaking care if
> they do. OTOH, if the passthrough Module::Build installer bits don't
> work, that is worth fixing, and is worthy of a bug report _for
> Module::Build_.
Objection! If you distribute software that can cause some sort of
problems on the target system it should be reported to you because it
is your decision to distribute it. And you should then consider
reporting it upstream or stopping using that software or whatever else
is appropriate.
> OTOH, if tester configure their systems to _intentionally_ not
> follow the passthrough and install Module::Build, yeah, some stuff
> will just not work, and that's not my problem. If you don't want
> to install the prereqs as part of testing, then don't test.
Thank you for your argument. I don't like it but that's not your
problem.
--
andreas
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
>>>>> On Sat, 22 Dec 2007 11:12:43 -0800, chromatic <[EMAIL PROTECTED]> said: > On Saturday 22 December 2007 05:22:05 Andreas J. Koenig wrote: >> 1. You get a fail report with an error message that doesn't tell you >> exactly what went wrong. >> >> 2. You rewrite your test in a way that it does tell you more. >> >> 3. Release. >> >> 4. If you now understand the problem, fix it, else goto 1. > I agree in principle, but in practice I seem to get a lot of failure reports > from someone who's installed Perl on Windows into a directory with spaces in > the name, and whatever installer there is just can't cope with that > situation. It seems pretty impossible to me that such a user has managed to install the whole toolchain. CPAN::Reporter has a lot of dependencies to be installed before it can start to send reports. And if they were good enough to get this going I'd expect they only send occasionally some crappy report. Let them drop on the floor. Your source for information is the cpantesters website where all reports are collected and draw your educated conclusions what is a systematic breakage and what is a glitch. > I'm not sure how to write a test for "Tester's installation of Perl is fatally > broken and can't actually install anything." In this case you should be able to differentiate between mails from clueless users and the testing infrastructure without losing too much time. The really tricky cases are somewhere else. The testing infrastructure will likely sometimes send out false positives because something broke, like Test::Harness or ExtUtils::MakeMaker. That's why the testing modules need to report how they are composing their results. So far I (as a smoker) have recognized these glitches pretty quickly, stopped the testing, rolled back, and informed all parties. This gives me serious headache because many testers will often not be able to react accordingly. -- andreas
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
>>>>> On Sat, 22 Dec 2007 14:22:05 +0100, [EMAIL PROTECTED] (Andreas J. Koenig)
>>>>> said:
> 1. You get a fail report with an error message that doesn't tell you
>exactly what went wrong.
> 2. You rewrite your test in a way that it does tell you more.
> 3. Release.
> 4. If you now understand the problem, fix it, else goto 1.
Sorry I didn't notice before I posted that this can be refactored into
a while loop:
while (You don't understand the output of your own test script){
Rewrite your test script;
Release;
}
It's as simple as it can get. And I probably do not have to explain
why I'm backing the position of imacat. The developer never tells the
tester what to do. The tester is a device and you can use it IFF you
want to fix your bugs. Otherwise, don't.
There are, of course, rough edges in my point of view. I'm sure we
could do better in many ways. If reporters are intrusive and want to
tell you what to do, they are most probably also wrong. But then there
is a chance to talk or to opt out or to ask for assistance etc.
In case it is not obvious from what I'm saying, let me illustrate:
when I go to work I'm often away from my testing setup for more than
12 hours, sometimes for more than a day. In that time you can easily
get 12 answers from my smoking machine. So before you ever ask *me*,
consider making a developer release just to find out something on my
smoker. It's a bot, after all, just a bit slower.
--
andreas
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
> On Fri, 21 Dec 2007 13:34:49 -0600 (CST), Dave Rolsky <[EMAIL PROTECTED]> > said: > However, usually I end up needing to investigate aspects of the > testers platform, often by having them run snippets of Perl code from > the shell, or asking them to try a patch. There's not much you can do > to automate that. I'd argue that without any change to today's practice there is a very easy way to automate this and it goes like: 1. You get a fail report with an error message that doesn't tell you exactly what went wrong. 2. You rewrite your test in a way that it does tell you more. 3. Release. 4. If you now understand the problem, fix it, else goto 1. > As chromatic mentioned, failures often happen on platforms to which I > as a module author don't have ready access, so I need some assistance > from the user of that platform. You're right, there may be cases where you have no idea into which direction to continue, but 99% of the time you *as a programmer* should be able to solve the problem without talking to the tester. -- andreas
Re: What's the point of a SIGNATURE test?
> On Sat, 15 Dec 2007 01:34:37 -0800, Michael G Schwern <[EMAIL PROTECTED]> > said: >> See above. Once the bug is reported there is no justification to keep >> the test around. In this case I prefer a skip over a removal because >> the test apparently once was useful. > Bt skipped tests don't get run so it's effectively deleted, except a > permanently skipped test sits around cluttering things up. Smells like > commenting out code that maybe someday you might want to use again in the > future. Just adds clutter. > If I want to bring a test (or code) back from the dead that's what version > control is for. I think I did indicate I was talking about a $VERSION-dependent skip. Let me reiterate. A test reveals a bug in module A, version N. The bug now is known and filed to RT. No need to run it again and again. Skip it ***if version N of module A is installed***. Apparently the test was useful to detect a malfunctioning of module A. Do not throw it away until you have verified that the test has found a better home. If it has found a better home for sure, I do not care if you delete it. POtherwise it is vital to keep the test because it has proved to be useful. It is unacceptable to to run the test on the broken version over and over again. A $VERSION check should be sufficient from that point in time on. What if everybody on CPAN deletes tests just because a related bug has been fixed? Nobody would notice if the bug were reintroduced. Nuff said? -- andreas
Re: What's the point of a SIGNATURE test?
> On Fri, 14 Dec 2007 15:49:32 -0800, Michael G Schwern <[EMAIL PROTECTED]> > said: >> Asking the wrong question. None of our testsuites is there to protect >> against spoof or attacks. That's simply not the goal. Same thing for >> 00-signature.t > We would seem to be agreeing. If the goal of the test suite is not to protect > against spoofing, and if it doesn't accomplish that anyway, why put a > signature check in there? Of course we are agreeing 99%. But I'm citing the Michael Schwern saying that is dearer to me than the above paragraph: tests are there to find bugs. >> Yupp. And testing the signature in a test is better than not >> testing it because a bug in a signature or in crypto software is >> as alarming as a bug in perl or a module. > I believe this to be outside the scope of a given module's tests. It's not > the responsibility of every CPAN module to make sure that your crypto software > is working. Or perl. Or the C compiler. Or make. That's the job of the > toolchain modules which more directly use them (CPAN, Module::Signature, > MakeMaker, Module::Build, etc...). [1] You're barking up the wrong tree. Stick to your older wisdom that bugs are there to find tests, err, forgive me, tests are there to find bugs, and when a test found a bug it is a hero forever. > At some point you have to trust that the tools work, you can't test the whole > universe. You simply don't have the time. I agree totally. But you also do not have the wisdom that you can predict which tests will find bugs in which software. Your test found a bug in Module::Signature? Great, so it was a good test. Of course you should not annoy people with a test once the bug is known and reported. Make a new release, skip the test with the skip statement 'Module::Signature 123.45 known bug see RT #54321' and wait for the next time the test finds a bug once Module::Signature gets upgraded. Besides that I agree with the rest of your musings. Great writup. Some guidelines about cost/benefit relations are worthwhile but one should take care not to make them too narrow. The last thing we want to have is a new kind of CPAN police dictating people to remove tests. > [...] But if the test failed because it's a bad test, Clearly a strawman's argument. It's impossible to contradict you on this. Thou shalt not write bad tests. Period. > Let's look at the example of Test::More. The last release has 120 passes and > just 4 failures. > http://cpantesters.perl.org/show/Test-Simple.html#Test-Simple-0.74 > What are those four failures? Three are due to a threading bug in certain > vendor patched versions of perl, one is due to the broken signature test. > Look at the previous gamma release, 0.72. 256 passes, 9 failures. > 5 due to the threading bug, 4 from the signature test. > 0.71: 73 passes, 2 failures. 1 signature, 1 threads > 0.70: 221 passes, 12 failures. 3 signature, 9 threads > And so on. That's nine months with nothing but false negatives. The bug lies in the time span of nine months. Bad tests are bugs, insidious bugs and need to be fixed and shall not be kept for 9 months. > The > signature test is not actually indicating a failure in Test::More, so it's of > no benefit to me or the users, and the bug has already been reported to > Module::Signature. See above. Once the bug is reported there is no justification to keep the test around. In this case I prefer a skip over a removal because the test apparently once was useful. > The threading test is indicating a perl bug that's very difficult to detect > [2], only seems to exist in vendor patched perls, I can't do anything about > and is unlikely to effect anyone since there's so few threads users. It's > already been reported to the various vendors but it'll clear up as soon as > they stop mixing bleadperl patches into 5.8. > In short, I'm paying for somebody else's known bugs. I get nothing. > Test::More gets nothing. The tools get nothing. Cost with no benefit. So > why am I incurring these costs? Maybe the individual users find out their > tools are broken, but it's not my job to tell them that. During smoking CPAN I often find bugs in one module revealed by a test in another one. Only because David Golden tests so hard his tests were well suited to reveal a bug in Test::Harness. I'm glad he doesn't ask if it is his job or not. Just a few RT headlines of the past year: Catalyst:Plugin:Authorization:Roles found a bug in C:P:Authentication. DBI 1.601 broke Exception::Class::DBI. HTML-TreeBuilder-XPath 0.09 broke Web::Scraper. Test::Distribution 1.29 broke Lingua::Stem. Math-BigInt-FastCalc broke Convert::ASN1. Test:Harness 3.0 broke POE. DBM-Deep-1.0006 broke IPC::PubSub. DateTime-Locale-0.35 broke Strptime. Data::Alias 1.06 breaks Devel:EvalContext. Class::Accessor breaks Class::Accessor::Class. DBIx-DBSchema-0.33 breaks Jifty::DBI. File::chdir 0.08 breaks Mod
Re: What's the point of a SIGNATURE test?
> On Mon, 10 Dec 2007 21:12:51 -0800, Michael G Schwern <[EMAIL PROTECTED]> > said: > Adam Kennedy posed me a stumper on #toolchain tonight. In short, having a > test which checks your signature doesn't appear to be an actual deterrent to > tampering. The man-in-the-middle can just delete the test, or just the > SIGNATURE file since it's not required. So why ship a signature test? Asking the wrong question. None of our testsuites is there to protect against spoof or attacks. That's simply not the goal. Same thing for 00-signature.t > The only thing I can think of is to ensure the author that the signature > they're about to ship is valid, but that's not something that needs to be shipped. Has the world changed over night? Are we now questioning tests instead of encouraging them? Do now suddenly authors have to justify their testing efforts? I don't mind if we set up a few rules what tests should and should not do, but then this topic needs to be put into perspective. > It appears that a combination of a CHECKSUMS check against another CPAN mirror > and a SIGNATURE check by a utility external to the code being checked is > effective, and that's what the CPAN shell does. The CHECKSUMS check makes > sure the distribution hasn't been tampered with. Checking against a CPAN > mirror other than the one you downloaded the distribution from checks that the > mirror has not been compromised. Checking the SIGNATURE ensures that the > module is from who you think its from. Yupp. And testing the signature in a test is better than not testing it because a bug in a signature or in crypto software is as alarming as a bug in perl or a module. > Schwern: What's the deal with adding 00-signature.t to Test::More? > What's it supposed to achieve? > Checks that the files patch the author's signature > s/patch/match/ > To what end? > Is it an anti-tamper thing? Nope. > Well, if it fails then your files are not what the author uploaded Or something else failed. > Yep > It's semi-redundant with the CPAN shells as they should already be > making that check > So... if I was tampering with your module, wouldn't deleting the test > script be the first thing I did? > You can do that, but there are other things which do a signature check > So basically, 00-signature.t as a concept is 1) Exploitable 2) > Redundant 3) A source of spurious failures Exploitable is everything, starting with Makefile.PL Redundant are most of all tests all the time. If it is a source of spurious failures, it's time to fix the failures. > How is it exploitable? > I just delete the test script > That's not exactly an exploit > Why not? > This is getting into semantics, but an exploit implies that you do > something with it, not just diable it. > disable > Granted, it's a trivial exploit > However, I see your point I don't. > They also tend to be a source of test failures > Because the crypto chain is horrid > Can I recommend removing all of them? I don't think this is a good idea. > Just let the CPAN client take care of it? > For example, looks like Test::More won't install on Windows if you > have gpg installed? > (And Module::Signature) It's really bad if there is a class of tests that fail on a platform. But discouraging tests because of that is to put the cart before the horse. -- andreas
UNKNOWN despite only failing tests -- how come?
Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm? http://www.nntp.perl.org/group/perl.cpan.testers/796974 http://www.nntp.perl.org/group/perl.cpan.testers/825449 All tests fail but Test::Harness reports NOTESTS and CPAN::Reporter concludes UNKNOWN and CPAN.pm then installs it. Your opinions welcome, -- andreas
Re: New proposed CPANTS metric: prereq_matches_use
> On Sat, 17 Nov 2007 21:47:57 -0800, Matisse Enzer <[EMAIL PROTECTED]>
> said:
> On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:
>> So in order to make everything work robustly, distros should
>> explicitly list every single module they explicitly use no
>> shortcuts, no implications.
> basically, I agree completely, with the possible exception of modules
> that are in the Perl core - the standard libraries. On the otehr
> hand, if a specific version of a standard library is required then it
> most certainly should be listed, for example:
> # In Something.pm
> use File::HomeDir 0.66;
> and
> # In Makefile.PL
> PREREQ_PM=> { 'File::HomeDir' => '0.66' },
Even if it's in the perl core, the developer may have compiled with
-Dnoextensions=Encode
In such a case Encode is not present. I have skipped Encode many times
because it takes up so much time, others may do likewise.
--
andreas
Re: [Fwd: FAIL Time-HiRes-1.9708 x86_64-linux-thread-multi 2.6.20-1.3001.fc6xen]
> On Thu, 15 Nov 2007 07:27:55 +0100, "Rafael Garcia-Suarez" <[EMAIL > PROTECTED]> said: >> (Why do I care? Because I get every other week a report of Time::HiRes >> failing, that's why.) > Yes, and other core tests are sensitive to load (stress tests for > threads, Benchmark.pm, ...). So that would be useful. But since that > probably needs to be discussed at the TAP level, please followup-to > perl-qa. Why is nobody adjusting the time expectations? When I build perl with threads support I run into test failure far too often. Maybe there is really a bug? This is not only a TAP issue, it must be decided about better values for what the thresholds expected by the tests should be. To me it seems they are wrong. -- andreas
Re: New proposed CPANTS metric: prereq_matches_use
> On Tue, 13 Nov 2007 02:08:41 +0100, Sébastien Aperghis-Tramoni <[EMAIL > PROTECTED]> said: > There was already a module that does this, I can't remember it's name, Maybe B::Prereq and its companion Test::Dependencies. -- andreas
Image::Magick vs Test::Harness 3.00
Since 3.00 I have the following test output in my Image::Magick test
t/wmf/read..
1..2
ok 1
ok 2
ok
You already have a parser for (t/wmf/read.t) at
/home/src/perl/repoperls/installed-perls/perl/pe1S7WD/[EMAIL
PROTECTED]/lib/5.10.0/TAP/Harness.pm line 412
On IRC AndyA and I already had a short exchange about this and Andy
cannot reproduce it. I can confirm that I see the other broken test
output from I:M in t/setattribute.t. But when I fix this in their
test, the problem with T:H output remains for me.
% for f in ImageMagick-6.3.5-2.tar.bz2; do ls -l $f;md5sum $f;done
-rw-rw-r-- 1 k k 6088930 2007-07-17 20:15:23 ImageMagick-6.3.5-2.tar.bz2
20b2867f6c34de7034cbe5f56fc5a671 ImageMagick-6.3.5-2.tar.bz2
Tested with [EMAIL PROTECTED] and @32235, stock 5.8.8, 5.8.7.
Then I tested with 32235 and Test-Harness 2.99_01 with the same
result, only differing line:
[...]
t/setattribute..ok
t/tiff/read.ok
t/tiff/writeok
t/wmf/read..ok
t/wmf/read..ok
You already have a parser for (t/wmf/read.t) at
/home/src/perl/repoperls/installed-perls/perl/pe1S7WD/[EMAIL
PROTECTED]/lib/site_perl/5.10.0/TAP/Harness.pm line 377
Now I see the bug in the call to the Harness itself. It indeed calls that test
twice:
% make test
/bin/sh ../magick.sh PERL_DL_NONLAZY=1
/home/src/perl/repoperls/installed-perls/perl/pe1S7WD/[EMAIL
PROTECTED]/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib',
'blib/arch')" t/*.t t/bzlib/*.t t/jpeg/*.t t/jp2/*.t t/png/*.t t/tiff/*.t
t/wmf/*.t t/wmf/*.t t/zlib/*.t
Because in the Makefile.PL it says:
foreach $delegate (qw/bzlib fontconfig freetype jpeg jp2 lcms png tiff wmf
x11 xml wmf zlib/) {
if( -d "t/$delegate" ) {
$delegate_tests .= " t/$delegate/*.t";
}
}
I see the "wmf" twice there. Everything beyond this point is not of
interest for Test::Harness. I'll take that bug over to Image-Magick.
Maybe an upgrade has this fixed already.
So this is a new (to me) incompatibility: with old T:H it was OK to
run a test twice, with the new one it isn't. Maybe this restriction
could be lifted, I have no strong opinion. In any case the error
message could be improved, something like. "Did you call this test
twice?" might really help to nail such a bug quicker.
--
andreas
Re: Devel::CheckLib: Please try to break our code!
> On Sat, 20 Oct 2007 01:31:41 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> > said: > Doesn’t seem like you can do that from within MakeMaker so far. See also http://rt.cpan.org/Ticket/Display.html?id=30098 (Documentation for EXTRA_META is missing) -- andreas
Re: [Cpanplus-devel] Q: Build.PL/Makefile.PL, and CPAN testers...
> On Sun, 30 Sep 2007 16:55:45 +0200, "Jos I. Boumans" <[EMAIL PROTECTED]> > said: > This is a known issue and something that afaik Adam Kennedy is > looking to > resolve with having 'configure requires' support in META.yml. This sounds as if you understood configure_requires to be just a vague idea, but I understand it is reality, finished, approved. > Unfortunately, there's no standard solution for this. What a lot of > people > do currently (myself included), is to bundle these prerequisites. > I'm not sure how easy this is with Apache::Test though. That's why configure_require now needs support. It got CPAN.pm support with 1.92. -- andreas
Re: [ANNOUNCE] Test::Builder/More/Simple 0.72
> On Thu, 20 Sep 2007 03:00:59 -0700, Michael G Schwern <[EMAIL PROTECTED]> > said: > Most CPAN smoke testers wouldn't have caught it because even though they often > run alphas they usually don't install them. So the interactions with > dependencies would be lost. Not true. My smokes would have caught it. -- andreas
Re: [ANNOUNCE] Test::Builder/More/Simple 0.72
> On Thu, 20 Sep 2007 03:04:14 -0700, Michael G Schwern <[EMAIL PROTECTED]> > said: > Well, the repository trunk is always kept at passing so if folks want to smoke > with that it's safe. Smoking repositories is not comparable with smoking release candidates. The number of possible collisions when smoking repositories against each other is close to infinity. Dev releases is the way to go. -- andreas
Re: Test::Pod / YAML explodes (and taking cpants with it...)
> On Thu, 13 Sep 2007 20:45:38 +0200, Thomas Klausner <[EMAIL PROTECTED]>
> said:
> perl -MYAML=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")'
Use YAML::Syck! It will cut your execution time too. Significantly!
% time perl -MYAML::Syck=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")'
perl -MYAML::Syck=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")' 0,04s user
0,00s system 95% cpu 0,042 total
--
andreas
Re: CPANTS: suggestion for a new metric
> On Sat, 26 May 2007 20:06:18 +0200, demerphq <[EMAIL PROTECTED]> said: > On 5/26/07, Andy Armstrong <[EMAIL PROTECTED]> wrote: >> On 26 May 2007, at 18:45, demerphq wrote: >> > Maybe ill just upload my files in zip format from now on only, then >> > its not my problem anymore right? Would that be better? >> >> That would be fine. > Fine then. You do not have to change anything, Yves. Your tarballs were all fine as far as I know. Do not switch to zip format, please, without a reason. While ZIP has several significant advantages over TAR.GZ, it is inferior in compression metrics. CPAN is not fond of seeing zip files because they usually are 10-30 percent bigger. > The fact that ExtUtils make dist automatically produces a > .tar.gz and the fact that Archive::Tar does not do the right thing is > not exactly my fault however. AFAIK it is not Archive::Tar either. I have not found out which compression software packages do it right and which do it wrong. I have communicated with several authors about it but being Windows users, they do not know it either. On new metrics: I agree with the OP that software packaged with absurd permission bits offends kwality. But everybody should know that PAUSE cannot index these beasts anyway and sends mail to the authors that it cannot read the contents of the distro and that they need to make a new upload when they want to be indexed. -- andreas
Re: CPANTS: suggestion for a new metric
>>>>> On Sat, 26 May 2007 20:47:18 +0200, demerphq <[EMAIL PROTECTED]> said: > On 5/26/07, Andreas J. Koenig <[EMAIL PROTECTED]> wrote: >> >>>>> On Sat, 26 May 2007 20:06:18 +0200, demerphq <[EMAIL PROTECTED]> said: >> >> > On 5/26/07, Andy Armstrong <[EMAIL PROTECTED]> wrote: >> >> On 26 May 2007, at 18:45, demerphq wrote: >> >> > Maybe ill just upload my files in zip format from now on only, then >> >> > its not my problem anymore right? Would that be better? >> >> >> >> That would be fine. >> >> > Fine then. >> >> You do not have to change anything, Yves. Your tarballs were all fine >> as far as I know. Do not switch to zip format, please, without a >> reason. While ZIP has several significant advantages over TAR.GZ, it >> is inferior in compression metrics. CPAN is not fond of seeing zip >> files because they usually are 10-30 percent bigger. > Is 7z supported by CPAN? :-) > http://sevenzip.sourceforge.net/download.html CPAN will start to support bz2 sometime this year. Eleven years after its invention. So much about our readiness to adopt new formats:) >> > The fact that ExtUtils make dist automatically produces a >> > .tar.gz and the fact that Archive::Tar does not do the right thing is >> > not exactly my fault however. >> >> AFAIK it is not Archive::Tar either. I have not found out which >> compression software packages do it right and which do it wrong. I >> have communicated with several authors about it but being Windows >> users, they do not know it either. > It would be nice to know tho. If only so as to know what to avoid. One data point is https://rt.cpan.org/Ticket/Display.html?id=25913 -- andreas
Re: CPANTS up and running again
> On Sun, 11 Mar 2007 19:17:11 +0100, Thomas Klausner <[EMAIL PROTECTED]> > said: > Hi! > CPANTS is now up and running again, with fresh data, which will be available > daily. (There might be a problem with UTF8 and the database, but that > should be solvable soon (especially as I know finally groked Unicode)). > CPANTS now lives on a new server provided by hexten.net . Thanks!! > You can now continue playing the CPANTS game and raising your kwalitee (and > hopefully making CPAN a nicer place in the process...) > Thanks to the nice DBD::PgLite::MirrorPgToSQLite there is now a daily SQLite > dump of the CPANTS database available. I hope you won't get blind from looking > at the schema... You can get the latest dump from this URL: > http://cpants.perl.org/static/sqlite/cpants_all.db.gz. > Have fun playing with the data! > Oh, now that the basic things are working (again), I'll look into new metrics > when I have a few spare minutes (which is unfortunantly unlikely to happen > before April.. - but patches (and suggestions) are of course welcome) What's the politically correct way to deal with 503 Service Temporarily Unavailable - Retry immediatly in endless loop? - Retry after 24 hours? - make a new release of CPAN.pm, then try again? - submit a talk to YAPC Europe, then try again? - actually talk at YAPC Europe, then try again? - wait until perl6 is stable? - read all messages in the spamfolder? OK, so before I get too silly let me ask: are the results already sorted? -- andreas
Re: which modules can be used on an older version of perl?
> On Mon, 4 Dec 2006 05:56:18 +0200, "Gabor Szabo" <[EMAIL PROTECTED]> said: > On 12/4/06, Michael G Schwern <[EMAIL PROTECTED]> wrote: >> David Romano patched up Test-Simple to restore 5.4.5 compatibility. I'll >> see about releasing that as 0.66. That might make a whole lot more of CPAN >> happy on 5.4.x. >> >> PS I don't see 5.4.5 in your list. >> sqlite> select count(*) from reports where perl LIKE '5.4.5'; > 0 > that's from the cpantesters database. The official name was 5.004_05. -- andreas
Re: CPAN::Shell->install() downloads dependencies, but doesn't add them to @INC for tests
> On Wed, 15 Nov 2006 18:19:30 +, Florian Scharinger <[EMAIL > PROTECTED]> said: > Hi Andreas, > I updated CPAN and version > v1.6 works, meaning that the path to the > newly installed Perl modules is added to @INC. > However, this doesn't really solve my problem, since my code should also > run on a freshly installed Scientific Linux 3, which comes with CPAN v1.6. > Anyone an idea how I can get v1.6 to install the modules correctly? The following sequence has worked quite well in the past: cpan> install CPAN cpan> reload cpan After this you're effectively running the new version. This is due to Perl's capability of redefining itself while running. I discovered bugs in the way how I implemented this recently but as said, it worked quite well already in very old versions of CPAN.pm. And 1.6 is very old. Release date seems to have been Apr 19, 2002. So please test this method before you recommend it to your users! Hope this helps, -- andreas
Re: CPAN::Shell->install() downloads dependencies, but doesn't add them to @INC for tests
> On Wed, 08 Nov 2006 18:13:26 +, Florian Scharinger <[EMAIL
> PROTECTED]> said:
> Hi perl-qa,
> I'm trying to download missing Perl test modules automatically during
> build time of my project, by using:
> use CPAN;
> CPAN::Shell->install("Test::Exception");
> Test::Exception has dependencies, which the CPAN shell detects correctly:
> Unsatisfied dependencies detected during
> [A/AD/ADIE/Test-Exception-0.24.tar.gz] -
> Test::Builder
> Sub::Uplevel
> Test::Builder::Tester
> The dependencies are downloaded and built, however, when then running
> the tests for Test::Exception it doesn't include the path to the just
> downloaded modules:
Should not matter at all. I just tried the example with my current
sources and it worked for me, so either the problem has been fixed in
the meantime or you have some other problem that I cannot recognize
from the bugreport.
What is particularly interesting is where is Sub::Uplevel when this
test fails? It should be installed and thus in @INC because it was
recognized as prereq.
Note that 1.88_59 is in my CPAN directory in case you're interested.
--
andreas
Sort by kwalitee, descending! (Was: CPANTS and META.yml)
> On Fri, 3 Nov 2006 06:47:03 +0100, Thomas Klausner <[EMAIL PROTECTED]> > said: > Hi! > On Fri, Nov 03, 2006 at 03:35:41PM +0100, David Landgren wrote: >> Question: how are the dists sorted on the /author/CPANID page? > Currently random (whatever the DB spits out), but I'll change that to > sorted by distname Sorting by qualitee shows which modules the author loves at the top and the neglected ones at the bottom. So there is only one right sort order: by kwalitee, descending. Thanks:) -- andreas
Re: CPAN.pm to install only flagged versions of modules
> On Tue, 31 Oct 2006 09:42:52 +0200, "Gabor Szabo" <[EMAIL PROTECTED]> > said: > Sure, I did not mean that you implement it just because I had this > idea about 10 years later than Bundles were implemented. > I just meant to address one of the concerned raised in the discussion. Oops, I'm sorry for my tone:-( > Sorry if I sounded like trying to volunteer you for a job. Thanks:) -- andreas
Re: CPAN.pm to install only flagged versions of modules
> On Tue, 31 Oct 2006 08:51:42 +0200, "Gabor Szabo" <[EMAIL PROTECTED]> > said: > What about adding a mechanism to PAUSE to map module/version pairs > to the bundles they are mentioned in? One could parse the most recent > bundles, extract the list of modules and the frozen version number. > When the module author is about to delete old versions the form > could show her a list of bundles that are still pointing to a > particular version. > I am not sure if preventing the deletition would be a good idea but > warning the author might be. Sorry, I'm very conservative on this. The rule is that first somebody must develop, maintain, promote, support, and with continuity champion such a bundle. Within this job that somebody teaches the community how easy it is to add a backpan server to the urllist. Then we see how the community gathers around the wonderful thing. And then we want to see if the problem of disappearing distros really hits. And when it then really turns out to be a problem we solve it in one day or maybe a week if the discussion about the problem turns out to be difficult. Not the other way round:) On the other hand, this is a task that does not need any support from PAUSE and can be done _now_ by any volunteer anywhere. -- andreas
Re: CPAN.pm to install only flagged versions of modules
> On Tue, 31 Oct 2006 00:23:09 +0200, "Gabor Szabo" <[EMAIL PROTECTED]> > said: > The mapping of flag to Module-Version pairs could actually reside on any > server with ftp or http access. CPAN.pm would be configured to use such > a URL. > What do you think? What you describe can be done with CPAN.pm since the very early days, but never was it deployed widely. It's called bundle mechanism and the point of bundles is that they can reference modules, distributions and recursively bundles again. By including distributions with their CPAN path you freeze not only the version number but the exact file to be used. I suppose it is not used because it is hard to maintain. Too many new releases every day. People prefer to use the bundle mechanism for modules because it is convenient. YMMV:) -- andreas
Re: Module Signatures
> On Wed, 26 Jul 2006 12:10:07 +0800, Adam Kennedy <[EMAIL PROTECTED]> said: > I do agree, but if you are going to do that we should know NOT to tell > people on failing platforms to do something we know is going to fail. > So if we know it doesn't work on Windows (for example) we shouldn't be > telling them to install Module::Signature, because it just leads them > down the wrong (painful) path. Right. CPAN 1.87_54 is uploaded and there you can turn on and off signature checking more conveniently than in 1.87. I'll make a 1.88 release RSN. -- andreas
Re: Module Signatures
> On Thu, 20 Jul 2006 02:35:02 +1000, Adam Kennedy <[EMAIL PROTECTED]> said: > On the other hand, give me an easy to use, works _everywhere_, never > fails falsely positive or negative, never crashes, low-dependency > security enhancement to CPAN clients that I never have to think about, > then I'm in and I'll do anything you want. Security is not a "never have to think about". We can inprove the tools and make them work under battle conditions, but that's only one dimension. The other dimension is about improving security even with tools that fail on Windows. We can and should do that. If we improve security only for a small subset of users, we improve the overall security of CPAN because the small subset can pull the alarm bell faster. -- andreas
Re: Module Signatures
> On Wed, 26 Jul 2006 04:08:05 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> > said: > I’ll assume you didn’t actually mean it the way it came out; that > you were actually complaining about the tools. I agree that > Module::Signature falls far short of doing an adequate job; no > argument from me about that. But I think so not because it > decreases utility but because it doesn’t actually increase > security. When it decreases utility, it’s just because it fails > to work, not because in exchange for security. > If I could trade some utility for an actual increase in security, > I would. I'll assume you didn’t actually mean it the way it came out;) that you were actually complaining that M:S falls short because our security model needs *further* action not because M:S has deficiencies. If M:S has deficiencies, maybe we should address them now. -- andreas
Re: Module Signatures
> On Wed, 19 Jul 2006 18:09:08 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> > said: >> Maybe we need a perlish kind of building it. It's not perlish >> to show each other a passport and make sure that the image >> there matches the face. > hmm, I don’t know how else you’d do it; at least for high > confidence, you really have to be absolutely sure that you’re > signing the key of the person who is who they’re claiming to be, > and there isn’t much opportunity to be completely certain in > online interactions. > 1. If you ask CPAN contributors to supply their PK *at signup >time* (but no later!), you can be certain that the key belongs >to the person who signed up – whoever that is. (Keys uploaded >later do not confer the same trust, because that key might >belong to the person who signed up, or it might belong to an >impostor who stole their credentials – you can’t know.) >These could be signed with an extra CPAN key that confers more >trust. > 2. The best opportunity for strong trust is probably the fact >that a lot of the really active Perl hackers run into each >other face-to-face quite a bit; e.g. the London.pm’ers should >have absolutely no trouble exchanging keys face-to-face, but >the same is true of many Perlmongers groups. Likewise, many of >the core contributors of Perl attend the pertinent conferences >(YAPC, OSCON et al). >And of course the meaning of “web of trust” is that once >direct trust relationships have been established in local >groups where they are easily feasible, then every time someone >travels around or goes to a confidence and exchanges keys, you >get “six degrees of separation” style trust chains. >If we decided to make a big awareness push, we’d probably get >the prolific CPAN contributors covered well very quickly, and >then it’s a matter of continual evangelism to keep the web >expanding. > It is easy to implement #1 immediatly, but coverage will take a > very long time to go up with that method because it will only > apply to new authors. Besides, private digital keys can expire or be revoked, both are important parts of the life cycle that CPAN must pay attention to. I would hate to tell people that they need a new CPAN account when their private key expires or is revoked or that everybody needs a new CPAN account because they didn't supply a digital key at signup. Then there are pseudonyms like TELS or ERYQ or ABIGAIL. While they do have a civic name, not many know it or care about it and so doesn't CPAN either. Then there is my favorite security builder: security by visibility. By sending emails to authors for every important transaction, we give them the chance to shout when suspicious things happen and make it harder for intruders to impersonate somebody else. Another helping fact might be that when you use a digital signature often in public conversation or for your uploads, you leave a trace, a fingerprint of your personality associated with the signature. It's hard for me to imagine how this effect can be harvested by programming interfaces, but see, I read your words in this thread and others and that's how my trust in your name emerges. Were your postings signed, I would be ready to sign your signature after a while of ongoing conversation *without* seeing your passport. > In contrast, coverage should expand pretty quickly with #2, but > it will take a lot of community cooperation and lots of > evangelism to implement. When we come up with a process that works similarly as #2 but only for the trust we have into an email address, then we could get even better and faster spread. -- andreas
Re: fetching module version from the command line
> On Mon, 17 Jul 2006 02:24:37 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> > said: > * Graham Barr <[EMAIL PROTECTED]> [2006-07-17 02:00]: >> perl -MDBI\ 999 >> DBI version 999 required--this is only version 1.50. >> BEGIN failed--compilation aborted. > You can use an equals sign instead of a space, there, which makes > it a little easier to type: > perl -MDBI=666 -e1 This is dangerous to believe, witness % perl -Mstrict\ 999 strict version 999 required--this is only version 1.03. BEGIN failed--compilation aborted. zsh: exit 9 perl -Mstrict\ 999 % perl -Mstrict=999 Unknown 'strict' tag(s) '999' at - line 0 BEGIN failed--compilation aborted. zsh: exit 9 perl -Mstrict=999 -- andreas
Re: fetching module version from the command line
> On Thu, 13 Jul 2006 19:36:52 -0400, "Randy W. Sims" <[EMAIL PROTECTED]> > said: > David Wheeler wrote: >> On Jul 13, 2006, at 05:56, Fergal Daly wrote: >> >>> That's funny, it looks like I did put some code in to disable the END >>> block if it's "require"d rather than "use"d. Turns out I did this to >>> make MakeMaker happy, so MakeMaker does actually do a full require, >> Well, IIRC, both MakeMaker and Module::Build grep for the version >> line and eval that one line, but not the whole file. The CPAN >> indexer, OTOH, evals no code but just uses a regular expression >> search of the module file. > Actually, I believe the CPAN indexer now uses META.yml whenever possible. That's correct. -- andreas
Re: Module Signatures
>>>>> On Fri, 7 Jul 2006 03:52:52 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> >>>>> said: > * Adam Kennedy <[EMAIL PROTECTED]> [2006-07-07 03:25]: >> Andreas J. Koenig wrote: >> >>>>>>On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy <[EMAIL PROTECTED]> >> >>>>>>said: >> > >> (What would be marginally worth it is having PAUSE sign >> > >> distros. At least we can assure that the CPAN mirror >> > >> didn't tamper with the files, which I think is the most >> > >> likely "attack" on CPAN.) >> > >> > > Frankly, that's the best idea I've heard yet. >> > >> >What does it bring you more that the signed CHECKSUMS file? >> > >> >> That sounds more or less equivalent. Are they signed now? > And if so, by whom? It's a batch signing key. This doesn't bring you what a web of trust brings you but I never pretended it did. By the way, I liked your summary of the situation in your posting <[EMAIL PROTECTED]> and I wonder how we could promote the web of trust on CPAN which clearly is the only way forward. Maybe we need a perlish kind of building it. It's not perlish to show each other a passport and make sure that the image there matches the face. -- andreas
Re: Module Signatures
>>>>> On Fri, 07 Jul 2006 11:22:16 +1000, Adam Kennedy <[EMAIL PROTECTED]> said: > Andreas J. Koenig wrote: >>>>>>> On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy <[EMAIL PROTECTED]> >>>>>>> said: >> >> (What would be marginally worth it is having PAUSE sign distros. >> At >> >> least we can assure that the CPAN mirror didn't tamper with the >> >> files, which I think is the most likely "attack" on CPAN.) >> > Frankly, that's the best idea I've heard yet. >> What does it bring you more that the signed CHECKSUMS file? >> > That sounds more or less equivalent. Are they signed now? Yes, since about February 2003, courtesy Audrey. -- andreas
Re: Module Signatures
> On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy <[EMAIL PROTECTED]> said: >> (What would be marginally worth it is having PAUSE sign distros. At >> least we can assure that the CPAN mirror didn't tamper with the >> files, which I think is the most likely "attack" on CPAN.) > Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? -- andreas
Re: CPAN and META.yml: no_index dir vs directory
> On Wed, 5 Jul 2006 21:39:06 -0500, Ken Williams <[EMAIL PROTECTED]> said: > On Jul 5, 2006, at 7:47 PM, David Golden wrote: >> Some potential options: >> >> (a) Add "directory" as a synonym to the spec and add "dir" as >> something that CPAN sites recognize. >> >> (b) Change the spec to "directory" -- if CPAN sites are the only >> real user of META.yml no_index, then the pain should be minimal. >> >> (c) Change CPAN sites to follow the spec, despite breaking many >> distributions' current indexing. > Randy Sims keeps some statistics on the META.yml files that exist on > CPAN, perhaps he could tell us the relative frequencies of 'dir' vs. > 'directory' in the wild? The page is there, http://thepierianspring.org/perl/meta/, but does not provide direct statistics so I made up my own. no_index/dir 13 no_index/directory 1397 private/directory40 David's D/DA/DAGOLDEN/Perl-Dist-Vanilla-5 used both dir and directory:) Those who used just "dir" were ignored up to now: B/BL/BLM/Win32API-Registry-0.27 B/BW/BWARFIELD/NRGN/Test-AutoLoader-0.03 D/DA/DAGOLDEN/Object-LocalVars-0.15 D/DA/DAGOLDEN/Object-LocalVars-0.16 D/DA/DAGOLDEN/Perl-Dist-Vanilla-4 G/GU/GUIDO/Test-Unit-GTestRunner-0.03 G/GU/GUIDO/Test-Unit-GTestRunner-0.04 J/JV/JV/EekBoek-0.91 J/JV/JV/EekBoek-0.60 J/JV/JV/EekBoek-0.61 R/RC/RCAPUTO/POE-0.3502 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801 -- andreas
Re: What is the Value of t/0-signature.t?
> On Thu, 9 Mar 2006 12:51:02 -0800, chromatic <[EMAIL PROTECTED]> said: > Hi all, > In http://rt.cpan.org/Ticket/Display.html?id=17934, a Test::MockObject user > dislikes the t/0-signature.t test that always runs. I have filed a couple of bug reports against distributions with a wrong signature and I have even released such myself. Now, with a combination of having t/0-signature.t and a dependency from 'release' to 'disttest', this cannot happen. qed:) -- andreas
Re: Request for Comments: Package testing results analysis, result codes
> On Sun, 19 Feb 2006 22:22:20 +1100, Adam Kennedy <[EMAIL PROTECTED]> said: > 1. Broken or corrupt packaging. > A bad tarball, MANIFEST files missing. Make sure you verify that all files in the distro are readable. Reject if the permissions are bogus. Recently we had an increasig number of distros that had absurd permissions. Also there is the rule that it must unpack into a single top level directory and must not clobber the working directory. Besides that, we reject distros that contain a blib/ directory. This seems arbitrary usually just catches a trivial error that might cause grief later. I have only 1/3 of a cent today:/ -- andreas
Re: Test::Kwalitee 0.10
>>>>> On Wed, 15 Feb 2006 12:41:25 -0800, chromatic <[EMAIL PROTECTED]> said: > On Wednesday 15 February 2006 12:33, Andreas J. Koenig wrote: >> The prerequisite Module::CPANTS::Analyse can currently not be >> installed because it relies on sme YAML import feature: > Ahh right, I forgot to mention I removed the ':all' import request in that > module manually. Everything still worked for my purposes. I've just opened a ticket on RT about the issue. -- andreas
Re: Test::Kwalitee 0.10
> On Tue, 14 Feb 2006 21:15:01 -0800, chromatic <[EMAIL PROTECTED]> said: > Hi all, > I've released a snapshot of the long-promised Test::Kwalitee. Internally, it > uses the CPANTS code to analyze a module along 13 of the Kwalitee indicators. > I recommend using this in developer tests before distributing a module > publicly. > I haven't written any documentation besides the t/01-kwalitee.t file, but > using it is straightforward. I'll be sure to add more explanation and such > before releasing it more publicly. > http://wgz.org/chromatic/perl/Test-Kwalitee.tar.gz The prerequisite Module::CPANTS::Analyse can currently not be installed because it relies on sme YAML import feature: t/analyse.."all" is not defined in %YAML::EXPORT_TAGS at /usr/local/[EMAIL PROTECTED]/lib/site_perl/5.9.4/YAML.pm line 5 cannot load Module::CPANTS::Kwalitee::Prereq: Can't continue after import errors at /home/k/.cpan/build/Module-CPANTS-Analyse-0.5/blib/lib/Module/CPANTS/Kwalitee/Prereq.pm line 5 BEGIN failed--compilation aborted at /home/k/.cpan/build/Module-CPANTS-Analyse-0.5/blib/lib/Module/CPANTS/Kwalitee/Prereq.pm line 5. Compilation failed in require at (eval 13) line 3. at /home/k/.cpan/build/Module-CPANTS-Analyse-0.5/blib/lib/Module/CPANTS/Analyse.pm line 27 # Looks like your test died before it could output anything. t/analyse..dubious This will give you plenty of minus points:) Thomas, I'e tried YAML 0.57 and 0.58, both with bleadperl. The harness output is good for a laugh, actually: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/analyse.t255 6528010 20 200.00% 1-10 t/calc.t 255 6528011 22 200.00% 1-11 t/plugins.t255 65280 5 10 200.00% 1-5 t/testdir.t255 65280 24 200.00% 1-2 t/testfile.t 255 65280 36 200.00% 1-3 t/unpack.t 255 65280 5 10 200.00% 1-5 t/unpack_notextractable.t 255 65280 24 200.00% 1-2 Failed 7/10 test scripts, 30.00% okay. 38/56 subtests failed, 32.14% okay. -- andreas
Re: Binary distributions
> On Sun, 29 Jan 2006 15:05:02 -0800, Tyler MacDonald <[EMAIL PROTECTED]> > said: > Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote: >> Did anybody here have played with CPANPLUS::Dist::Deb? >> http://search.cpan.org/dist/CPANPLUS-Dist-Deb/ >> >> Believing its documentation, it should build a valid Debian package >> and take care of its dependencies (dunno if that means just listing >> or actually adding them in the package). > This excited me, but even with all the debian helper utils installed > and CPANPLUS on default settings running as root, it crashes not being able > to find the right dist_cpan object out of CPANPLUS. :-( FWIW, we're using dh-make-perl to create debian packages from CPAN modules. -- andreas
Re: Binary distributions
>>>>> On Sun, 29 Jan 2006 17:13:40 -0800, Tyler MacDonald <[EMAIL PROTECTED]> >>>>> said: > Andreas J. Koenig <[EMAIL PROTECTED]> wrote: >> FWIW, we're using dh-make-perl to create debian packages from CPAN >> modules. > Andreas, > I've used this tool a few times when a CPAN module wasn't already > available in unstable/main, but I havent looked into it too closely. I'm > curious, does it do anything about .so's that XS modules need, or build vs. > runtime dependancies in environments that support it (Module::Build, etc)? Recently I haven't had to work with XS modules that have not already an associated Debian package. Support for modules that have only a Build.PL seems to be missing. The manpage is not promising too much when it says: BUGS Several, let me know when you find them. :/ -- andreas
Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
> On Fri, 27 Jan 2006 15:42:58 +0100, Tels <[EMAIL PROTECTED]> said: > I am still considering building something[0] that shows the > module-dependency as a graph to show how "bad" the problem has become. > Even "simple" modules like YAML seem to include everything and the > kitchen-sink :-( Have a look at Test::Prereq. -- andreas
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
> On Fri, 27 Jan 2006 13:26:52 -0800, Luke Closs <[EMAIL PROTECTED]> said: > This would allow non-perl people to install perl packages much easier, > without having to mess with the CPAN shell and running tests. It > would also make installing CPAN packages into hosted environments much > easier. What's so messy about the CPAN shell? If you do not want to run tests, use the notest pragma: cpan> notest install YAML will install YAML without running the tests. -- andreas
Re: [ANNOUNCE] Devel::TypeCheck 1.2
> On Thu, 12 Jan 2006 22:55:26 -0500, Gary Jackson <[EMAIL PROTECTED]> said: > The latest release of Devel::TypeCheck adds typing of functions (without polymorphism) as well as numerous bug fixes: > The uploaded file >Devel-TypeCheck-1.2.tar.gz > has entered CPAN as > file: $CPAN/authors/id/B/BA/BARGLE/Devel-TypeCheck-1.2.tar.gz > size: 37304 bytes > md5: 04369069c2a307c85bbe54ee5a267c9b Hey you need to upgrade your Test::Pod before running make dist:-) t/pod.NOK 3 # Failed test 'blib/lib/Devel/TypeCheck/Glob2type.pm' # in /usr/local/[EMAIL PROTECTED]/lib/site_perl/5.9.3/Test/Pod.pm at line 172. # blib/lib/Devel/TypeCheck/Glob2type.pm (57): '=item' outside of any '=over' # blib/lib/Devel/TypeCheck/Glob2type.pm (68): You forgot a '=back' before '=head1' # Looks like you failed 1 test of 26. [...] Failed Test Stat Wstat Total Fail Failed List of Failed --- t/pod.t1 256261 3.85% 3 This is with Module id = Test::Pod DESCRIPTION Tests POD files for correctness CPAN_USERID PETDANCE (Andy Lester <[EMAIL PROTECTED]>) CPAN_VERSION 1.22 CPAN_FILEP/PE/PETDANCE/Test-Pod-1.22.tar.gz UPLOAD_DATE 2005-10-24 DSLI_STATUS RdpO (released,developer,perl,object-oriented) MANPAGE Test::Pod - check for POD errors in files INST_FILE /home/src/perl/repoperls/installed-perls/maint-5.8/pkfUy6M/[EMAIL PROTECTED]/lib/site_perl/5.8.7/Test/Pod.pm INST_VERSION 1.22 -- andreas
Re: what slow could be in Compress::Zlib?
> On Mon, 4 Jul 2005 14:19:16 +0100, "Paul Marquess" <[EMAIL PROTECTED]> > said: > If I give the module a version number like 2.000_00, will the CPAN > shell ignore it? Yes. To be precice, the indexer on PAUSE will ignore it. But don't forget to write it with quotes around. -- andreas
Re: [ Memory ] Re: Thought
> On Thu, 03 Oct 2002 13:01:52 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]> said: >> If it only returns the value from sbrk(), damn well call it sbrk. > Ahh, someone on /my/ side. Mee too. > So far, all I got was criticism. I asked for it. But no-one said it was useful. > (Or I didn't read between the lines enough). Sure it looks useful to me, but I'm so happy when I do not have to deal with that stuff that I hope I won't have to use it. But should I ever have the need again (and you cannot anticipate when that happens) I definitely will be happy to have it available. > You, might know. Are there systems where the sbrk () value /decreases/ after > mallocs? Top-down stacks and heaps a.o.t. bottom-up. You know, my all-time-favorite manpage is on the NeXT computer, where you *have* brk and sbrk, but they return just random data. And the *full* manpage reads: BRK(2) UNIX Programmer's Manual BRK(2) NAME brk, sbrk - change data segment size The UNIX system calls brk and sbrk are not supported on the NeXT computer. :-) -- andreas
Re: Maintaining Archive::Tar and Archive::Zip
> On 16 Mar 2002 11:14:56 -0800, Stephen Zander <[EMAIL PROTECTED]> said: > "Michael" == Michael G Schwern writes: Michael> and here's a patch. > Applied, thanks! Thanks to you both. Looking forward to test the new version. -- andreas
Re: Maintaining Archive::Tar and Archive::Zip
> On 02 Mar 2002 18:41:15 -0800, Stephen Zander <[EMAIL PROTECTED]> said:
> If someone would like to send them to me, I'll get my act together a
> little better and get a new release out.
A pseudo-patch would be OK? I found that Tar.pm contains
chdir $_;
and
chdir $cwd
if @path;
I'd like to see these guarded by something like:
... or Carp::croak("Could not chdir to directory ...: $!");
That would be a very high security requirement.
--
andreas
Re: B::Scan, Perl Refactoring Tool, CPANTS attainable...
> On Sun, 15 Apr 2001 16:03:51 +0100, Michael G Schwern <[EMAIL PROTECTED]> said:
> I anticipated this. From the docs...
>Perl has alot of wierd features. We love Perl for it, but
>it makes predictable refactorings really difficult. This
>module attempts to find (hopefully rare) uses of such
>features.
>We're not passing judgement on them, just noting that they
>can make program behavior hard to predict.
Thanks for the clarification. Now that makes sense.
> I spent a night hacking up a B module and suddenly I know the secrets
> of the universe? (The answer, at least according to what I can see,
> is no). I'll bet even Abigail couldn't figure that
> one out!
> This is an interesting bit of hackery, though...
> $ perl -cwe 'sub __ANON__::BEGIN { print 23 } BEGIN { print 42 }'
> -e syntax OK
> 2342
> Don't know where that gets you, though.
I already had the impression XML had something to contribute to save
the world.
--
andreas
Re: B::Scan, Perl Refactoring Tool, CPANTS attainable...
> On Sun, 15 Apr 2001 14:38:47 +0100, Michael G Schwern <[EMAIL PROTECTED]> said: > It detects things like Autoloaders, eval STRING, goto LABEL, dynamic > method calls, using non-exported variables and functions... Why are you considering dynamic method calls an ill? I'm using them frequently. > This is just a proof of concept, but it proves a few things... Very impressive and very encouraging. Thank you! So now please let me ask *everything* I always wanted to know and didn't dare to ask: Can we scan perl code with a guarantee that no BEGIN block will ever be executed? -- andreas
Re: Why t/TEST and not Test::Harness?
> On Sun, 18 Feb 2001 16:08:49 -0500, [EMAIL PROTECTED] (Michael G. Schwern) said: > On Sun, Feb 18, 2001 at 07:20:55PM +, [EMAIL PROTECTED] wrote: >> <[EMAIL PROTECTED]> writes: >> >Why is t/TEST anything more than a thin wrapper around Test::Harness? >> >> Because t/TEST pre-dates Test::Harness by years, and no one has got >> round to changing 'make test' call the new style. > Is that it? Historical reasons? No. For me the reason was this reminder in TEST: # This is written in a peculiar style, since we're trying to avoid # most of the constructs we'll be testing for. > Would anyone scream if I gave a shot at gutting TEST? No, but I do believe, we should keep something like TEST for at least base/, cmd, and op/ as a fallback. When some construct within Test::Harness breaks, the poor pumking should get a quicker alternative than running single tests manually. -- andreas
Re: Putting Test::Harness back on CPAN?
Thanks! I've registered you as maintainer on PAUSE, so that the indexer will pick your uploads of Test::Harness in the usual way. -- andreas
Re: Bug Tracking
> On Wed, 02 Aug 2000 07:50:46 +0200, Richard Foley <[EMAIL PROTECTED]> said: > Hmmm. > For my part I'd like to say that I don't want to continue to work on any of > this unless a consensus is reached that this would be a good idea. It absolutely is a good idea. Those who believe they can write a bug tracking system in a week or month or year must be extremely talented and have nothing else to do. I'd suggest they should dedicate their abilities to fixing bugs instead. Fixing bugs in the bugtracking system itself isn't a shame either. It's a shame though to not honour the marvelous steady and patient approach that Richard has taken. > I'm heartily fed up of taking spurious flak, (valid flak is OK :). > It's mega-frustrating to be at the point where it all runs well, > and after so much work has gone into it, and has a pile of > interested enthusastic administrators/users to have all the effort > continually trashed. Thank you, Richard. Please keep up your humor. And your fine work too. I see the critical phase of the system is now over and I hope people will start contributing their ideas by submitting code to it. You are the man to integrate these patches, I presume. > I was doing this because no-one else wanted to. Perhaps now is a good time > for me to pass on, at least now there's appear to be lots of willing takers! I'd suggest to workinggroupize and pumkingify the development system. Well, thia apparently has happened already. You should be the first pumpking unless you can name a candidate that is willing and able to take that role. > Before I do, you should know that there has been positive criticism too > eg: "This is very important work. Thanks!", > (and it was nice to get a 'thumbs-up' from the man himself :) > the next says: > "I come to bury it!"... Weird kind of fun, but you must admit, it woke up the masses to join forces as they did. Thanks SC. But now's the time to revoke. > OK, we're now on a stable v2.20 and I'll maintain it until you find a > replacement. Thanks again. I just joined bugmongers and hope to be of help occasionally. -- andreas
