Re: CPAN Testers Daily Summary Report
Nothing. It only happens in your smoker, and every time it looks like
something removes all files while smoker is running. Are you sure you're
only running one CPAN process at the time?
On 2019-12-29 07:07, Nigel Horne wrote:
What is different about your package that makes it fail in this way?
-Nigel
On 29/12/2019 02:23, Serguei Trouchelle wrote:
It's happening again:
http://www.cpantesters.org/cpan/report/b78880ce-27da-11ea-a823-10fac181c852
On 2019-10-22 05:05, Nigel Horne wrote:
My set up hasn't changed. If it's not working on 31.5 there's
something amiss somewhere, but not with my setup.
-Nigel
On 10/22/19, 5:26 AM, "Serguei Trouchelle" wrote:
Hello,
There's something wrong with your smoker setup.
On 2019-10-21 21:12, CPAN Tester Report Server wrote:
> Dear Serguei Trouchelle,
>
> Please find below the latest reports for your distributions,
generated by CPAN Testers, from the last 24 hours.
>
> To change your preferences, or disable notifications, please
visit the CPAN Testers Preferences system at
https://prefs.cpantesters.org.
>
>
> CPAN-SQLite-0.217:
> - amd64-netbsd / 5.31.5:
> - UNKNOWN
http://www.cpantesters.org/cpan/report/b52b2232-f427-11e9-934a-579662b887d7
("Nigel Horne" )
>
>
>
> If you have an issue with a particular report, or wish to
gain further information from the tester, please use the 'Find A
Tester' tool at http://stats.cpantesters.org/cpanmail.html, using
the ID or GUID of the report, as listed above, to locate the correct
email address.
>
> You can also adjust the frequency and nature of these
notifications or unsubscribe from the notifications entirely, by
going to the CPAN Testers Preferences website
(https://prefs.cpantesters.org) and login with your PAUSE
credentials. You can disable CPAN Testers notifications permanently
or temporarily. If you have problems with accessing the site, please
contact the admins and request to be removed
from the automatic mailings.
>
> Thanks,
> The CPAN Testers
>
> CPAN Testers is only made possible with the support of our
sponsors.
> For more information on sponsoring, please visit the I ♥
CPAN Testers website (http://iheart.cpantesters.org)
>
> One of our esteemed sponsors is Xiing - GeekUni, a Bronze
Sponsors.
>
> Geekuni is an institute which provides online software
development courses. Every concept is presented in the context of a
hands-on exercise and the completion of the course is a fully
functional piece of software.
>
> https://geekuni.com/
>
--
S.T.
--
S.T.
Re: CPAN Testers Daily Summary Report
It's happening again:
http://www.cpantesters.org/cpan/report/b78880ce-27da-11ea-a823-10fac181c852
On 2019-10-22 05:05, Nigel Horne wrote:
My set up hasn't changed. If it's not working on 31.5 there's something amiss
somewhere, but not with my setup.
-Nigel
On 10/22/19, 5:26 AM, "Serguei Trouchelle" wrote:
Hello,
There's something wrong with your smoker setup.
On 2019-10-21 21:12, CPAN Tester Report Server wrote:
> Dear Serguei Trouchelle,
>
> Please find below the latest reports for your distributions, generated
by CPAN Testers, from the last 24 hours.
>
> To change your preferences, or disable notifications, please visit the
CPAN Testers Preferences system at https://prefs.cpantesters.org.
>
>
> CPAN-SQLite-0.217:
> - amd64-netbsd / 5.31.5:
>- UNKNOWN http://www.cpantesters.org/cpan/report/b52b2232-f427-11e9-934a-579662b887d7
("Nigel Horne" )
>
>
>
> If you have an issue with a particular report, or wish to gain further
information from the tester, please use the 'Find A Tester' tool at
http://stats.cpantesters.org/cpanmail.html, using the ID or GUID of the report, as
listed above, to locate the correct email address.
>
> You can also adjust the frequency and nature of these notifications or
unsubscribe from the notifications entirely, by going to the CPAN Testers Preferences
website (https://prefs.cpantesters.org) and login with your PAUSE credentials. You can
disable CPAN Testers notifications permanently or temporarily. If you have problems with
accessing the site, please contact the admins and request
to be removed from the automatic mailings.
>
> Thanks,
> The CPAN Testers
>
> CPAN Testers is only made possible with the support of our sponsors.
> For more information on sponsoring, please visit the I ♥ CPAN Testers
website (http://iheart.cpantesters.org)
>
> One of our esteemed sponsors is Xiing - GeekUni, a Bronze Sponsors.
>
> Geekuni is an institute which provides online software development
courses. Every concept is presented in the context of a hands-on exercise and the
completion of the course is a fully functional piece of software.
>
> https://geekuni.com/
>
--
S.T.
--
S.T.
Re: Data Retention Policies
On 2019-10-17 10:33, Doug Bell wrote: That said, timely data is more useful than untimely data. Do we need reports submitted in 2006? Data for modules only available on BackPAN isn't actionable, so do we need to keep that information? As long as we have BackPAN, this information is useful, for one particular case. Sometimes, you need to find when the module started to fail for some outdated Perl version. Often, this version is already removed from CPAN. This situation is really rare but I ran into it when dealing with old versions of Perl. And it was quite popular module. So, questions for those affected: * Do you look at text reports older than 5 years? 3 years? 1 year? Usually, less than 1 year. But I'd like to have access to recent FAIL reports though. If distribution Acme-A was last tested on platform X with Perl 5.12.0 and failed, I'd like to have access to this particular information regardless of when the report was submitted. PASS report for DBI.pm on Perl 5.28 or 5.30 on i686-linux platform? No one really needs the contents of every (or any for that matter) report. * Are test summaries useful to you without the full text of the report? The grade is useful even without the text. Full text for PASS reports is probably not really useful at all. * Are pass/fail counts older than 5 years useful to you? 3 years? 1 year? Yes, especially for versions/platforms that are not being actively tested anymore. -- S.T.
Re: Windows testing/debugging
Probably somewhere in MSDN.
The problem is not in Perl, the problem is in Windows command line where
single quote is not a quote, and double quote should be doubled (or
escaped) to work as people from bash/sh world would expect.
Examples:
C:\>perl -M5.010 -we "say ""a"""
a
C:\>perl -M5.010 -we "say "a""
Unquoted string "a" may clash with future reserved word at -e line 1.
Name "main::a" used only once: possible typo at -e line 1.
say() on unopened filehandle a at -e line 1.
C:\>perl -M5.010 -we 'say "a"'
Can't find string terminator "'" anywhere before EOF at -e line 1.
C:\>perl -M5.010 -we "say \"a\""
a
On 2019-02-26 09:32, Karen Etheridge wrote:
Is there any documentation on that? `perldoc -f system` only describes
the different handling of "system LIST" vs "system PROGRAM LIST" on
windows, not any differences between different types of quote
characters.
On Mon, Feb 25, 2019 at 11:28 PM Serguei Trouchelle wrote:
On 2019-02-25 05:11, David Cantrell wrote:
I don't need to use Andreas's analysis tool to figure out what the
common factor is in these test failures :-)
http://cpantesters.org/distro/T/Test-Differences.html
But I don't have access to any Windows machines, or any knowledge of how
to use any of the tools on that platform or how to install stuff. Does
anything exist now like the project a few years ago where Microsoft
donated some cloudy VMs for use by perl people that already had a
sensible toolchain and stuff installed?
I looked into the problem, the issue lies in calling system() with
double quotes. Double quotes on Win32 behave different from Unix-like
systems and should generally be avoided. This diff fixes the problem:
25,26c25,26
< ["\\N{U+2603}", "\\N{U+1F4A9}"],
< [reverse "\\N{U+2603}", "\\N{U+1F4A9}"]
---
> [qq{\\N{U+2603}}, qq{\\N{U+1F4A9}}],
> [reverse qq{\\N{U+2603}}, qq{\\N{U+1F4A9}}]
--
S.T.
--
S.T.
Re: Windows testing/debugging
On 2019-02-25 05:11, David Cantrell wrote:
I don't need to use Andreas's analysis tool to figure out what the
common factor is in these test failures :-)
http://cpantesters.org/distro/T/Test-Differences.html
But I don't have access to any Windows machines, or any knowledge of how
to use any of the tools on that platform or how to install stuff. Does
anything exist now like the project a few years ago where Microsoft
donated some cloudy VMs for use by perl people that already had a
sensible toolchain and stuff installed?
I looked into the problem, the issue lies in calling system() with
double quotes. Double quotes on Win32 behave different from Unix-like
systems and should generally be avoided. This diff fixes the problem:
25,26c25,26
< [ "\\N{U+2603}", "\\N{U+1F4A9}"],
< [reverse "\\N{U+2603}", "\\N{U+1F4A9}"]
---
> [ qq{\\N{U+2603}}, qq{\\N{U+1F4A9}}],
> [reverse qq{\\N{U+2603}}, qq{\\N{U+1F4A9}}]
--
S.T.
Re: Heads up: Unix::Sudo incoming, it will ask for your password
On 2019-02-07 15:05, David Cantrell wrote:
The tests will ask for your password, and I would be very grateful if
you would consider allowing it to run - but please read the source
first, for both the module and the tests.
|
use Test::More;
||plan ||skip_all| |=> ||'Automated testing' if
$ENV{'AUTOMATED_TESTING'}||;|
--
S.T.
Re: How to process a Build-Pre-req as a prereq and not a FAIL?
L Walsh wrote: I tried checking for the OS and BAILING out before running the test, but BAIL OUT just causes a fail. Isn't BAILOUT the supported way to abort due to a due to missing pre-reqs or is there another function I should be using? You should "plan skip_all => 'OS not supported';" -- S.T.
Re: Invalid reports due to a broken installation
Karen Etheridge wrote: Hi Serguei, here is another: :) http://www.cpantesters.org/cpan/report/28218354-2f6e-11e5-8be5-d039436f2841 I've reset this particular smoker. I suspect that trust_test_reports_history has something to do with it, I tried installing a module, and CPAN shell didn't install anything because this module was already tested. Switched it to off. The email you used to send me email haven't been in use since pre-Metadata (when reports had to be sent by email), why it has suddenly popped out? No idea; I found that email via http://stats.cpantesters.org/cpanmail.html, using the GUID of one of your recent reports. So either metabase is holding on to your old email, or this is actually the email you still have configured to send reports under? I'm not even sure emails are used anymore. My understanding, Test::Reporter should use Metabase profile instead. +Barbie, can you check my account? I don't see this email in my configuration on admin.cpantesters.org -- S.T.
Re: Test suite in NetBSD doesn't run tests in alphabetical order
Tony Cook wrote: The tests are being run in parallel because of the j2 in HARNESS_OPTIONS: Environment variables: HARNESS_OPTIONS = c:j2 which can produce this effect. I see, thanks. Since my module is single-process by its nature, I'll probably just bail out. -- S.T.
Test suite in NetBSD doesn't run tests in alphabetical order
I see this kind of problems in NetBSD smokers:
http://www.cpantesters.org/cpan/report/e19112ce-219e-11e5-816f-279aaf4b258a
More at
http://www.cpantesters.org/distro/C/CPAN-SQLite.html#CPAN-SQLite-0.206?grade=3perlmat=2patches=2oncpan=2distmat=2perlver=ALLosname=netbsdversion=0.206
Output from '/usr/bin/make test':
PERL_DL_NONLAZY=1 /home/njh/perl5/perlbrew/perls/perl-5.14.4/bin/perl -MExtUtils::Command::MM -MTest::Harness -e
undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/01basic.t .. ok
t/02drop.t ... ok
t/00compile.t ok
DBD::SQLite::db prepare failed: no such table: auths at
/home/njh/.cpan/build/CPAN-SQLite-0.206-GPrKpn/blib/lib/CPAN/SQLite/DBI/Search.pm line 50.
DBD::SQLite::db prepare failed: no such table: auths at
/home/njh/.cpan/build/CPAN-SQLite-0.206-GPrKpn/blib/lib/CPAN/SQLite/DBI/Search.pm line 50.
# Looks like you planned 2668 tests but ran 2.
# Looks like your test exited with 2 just after 2.
t/04search.t .
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2666/2668 subtests
DBD::SQLite::db prepare failed: no such table: auths at
/home/njh/.cpan/build/CPAN-SQLite-0.206-GPrKpn/blib/lib/CPAN/SQLite/DBI/Search.pm line 50.
DBD::SQLite::db prepare failed: no such table: auths at
/home/njh/.cpan/build/CPAN-SQLite-0.206-GPrKpn/blib/lib/CPAN/SQLite/DBI/Search.pm line 50.
# Looks like you planned 14 tests but ran 2.
# Looks like your test exited with 2 just after 2.
t/04search_everything.t ..
Dubious, test returned 2 (wstat 512, 0x200)
Failed 12/14 subtests
t/03info.t ... ok
Note that tests are run in completely random order:
t/01basic.t
t/02drop.t
t/00compile.t
t/04search.t
t/04search_everything.t
t/03info.t
ExtUtils::Command::MM explicitly wants to run tests in order:
sub test_harness {
require Test::Harness;
require File::Spec;
$Test::Harness::verbose = shift;
# Because Windows doesn't do this for us and listing all the *.t files
# out on the command line can blow over its exec limit.
require ExtUtils::Command;
my @argv = ExtUtils::Command::expand_wildcards(@ARGV);
local @INC = @INC;
unshift @INC, map { File::Spec-rel2abs($_) } @_;
Test::Harness::runtests(sort { lc $a cmp lc $b } @argv);
}
Any idea why this happens?
--
S.T.
Re: Many FAILs due to unsatisfied prerequisites
Karen Etheridge wrote: I've been continuing to receive reports (several a day, on average) like this: http://www.cpantesters.org/cpan/report/5421bfb0-1e88-11e5-b327-3e6ce14af301 ...where the test failures were clearly caused by unsatisfied prerequisites. It is my understanding that this should not result in a FAIL report, but rather NA -- any reasonable attempt to run tests and achieve a PASS should attempt to satisfy prerequisites first. Please could you investigate and fix? I've seen several reports like this with my module that used Module::Build. After I finally switched to EUMM, this kind of reports stopped. Consider using EUMM, it's just one line in dist.ini. Finding a real problem would be much more difficult, because it may be somewhere between Module::Build, CPAN, and CPAN::Reporter. -- S.T.
Re: Ignore lists for a specific PAUSE id + tester
yary wrote: The more salient question is whether we can identify such things (NFS) in the report, so, say, something like Andreas' analysis sites could clearly show the problem is NFS. In a perfect world, CPAN distributions would be able to opt out of supporting NFS as cleanly as they can with operating systems. :P It would be nice to have something like $OSNAME for filesystem type discovery... Beef up Sys::Filesystem and put it in the core? Or at least encourage its use where helpful... One can use different filesystems for different files. NFS is usually used in home directories, and that's where people keep smokers. Enterprise level Perl installations will not use NFS, I believe. -- S.T.
Re: Ignore lists for a specific PAUSE id + tester
Andreas Koenig wrote: If you can point us at a couple of example failure reports, maybe someone here can figure out what's going wrong. In my experience it is almost always the case that things like this are caused by an error in the distribution under test. Here's the most recent example of such failures: http://www.cpantesters.org/cpan/report/cb01432c-6737-11e2-992e-e7c00a4a7996 I have contacted Nigel and he sent me his CPAN.pm configuration and I cannot see anything wrong in it. Especially my suspect about trust_test_report_history was wrong, trust_test_report_history is off. At least two of Nigel's smoker setups generate errors because they use NFS, and everything that uses IPC::Run3 fails because File::Temp cannot guarantee successful unlinking on NFS. Probably, some modules that use File::Temp, may fail too. In my opinion, these results are useless for module authors. I, as an author, do not benefit from reports like this: http://www.cpantesters.org/cpan/report/835621d4-6b45-11e2-a82e-ca470f55919d as it has nothing to do with the module itself. It's not even a problem with architecture (this module has no problems running on arm), it's a problem with smoker setup. -- S.T.
Re: smoke tester hanging during tests
IPC-Pipeline is known to hang on Windows. Add it to distroprefs to skip testing. Would be a wise idea to use someone's distroprefs to avoid reinventing the wheel. I can offer my set (which is a little outdated, don't have much time/resources lately to continue smoking): http://svn.trouchelle.com/perl/cpan/prefs/ You can also search for other testers distroprefs on github: https://github.com/eserte/srezic-cpan-distroprefs https://github.com/dagolden/distroprefs Alceu Rodrigues de Freitas Junior wrote: Every time that I start the program, it became hanging while executing the following test: Running make test Delayed until after prerequisites Running test for module 'IPC::Pipeline' Running make for C/CP/CPANEL/IPC-Pipeline-0.6.tar.gz -- S.T.
Re: Issues with VERSION migration in a module suite
Guys, are you sure it's not a module-authors topic? I don't see any relation to CPAN testers here. -- S.T.
Re: Fwd: Failed: PAUSE indexer report WPMOORE/NetApp-500.001.tar.gz
Dean Hamstead wrote: Can dist::zilla do it for you automatically? Yes, Dist::Zilla::Plugin::PkgVersion (and/or Dist::Zilla::Plugin::AutoVersion for very lazy authors). -- S.T.
Outdated reports
Hi Barbie, I've received a summary report on May 14, but links to actual reports are two months old. Can you take a look at this? The message is attached. -- S.T. ---BeginMessage--- Dear Serguei Trouchelle, Please find below the latest reports for your distributions, generated by CPAN Testers, from the last 24 hours. To set your preferences for what you wish to have reported in this Daily Summary, please visit the CPAN Testers Preferences system at https://prefs.cpantesters.org. Data-Define-1.03: - i686-linux / 5.15.8: - FAIL http://www.cpantesters.org/cpan/report/bd07c0d0-657a-11e1-9be1-4b2a977d05bc Lingua-RU-Jcuken-1.04: - i686-linux / 5.15.8: - FAIL http://www.cpantesters.org/cpan/report/31bdd780-653e-11e1-ae8c-eec6967d05bc Lingua-UK-Jcuken-1.04: - i686-linux / 5.15.8: - FAIL http://www.cpantesters.org/cpan/report/2d71b034-653e-11e1-b1d1-38c6967d05bc If you have an issue with a particular report, or wish to gain further information from the tester, please use the 'Find A Tester' tool at http://stats.cpantesters.org/cpanmail.html, using the ID or GUID of the report, as listed above, to locate the correct email address. If you wish to unsubscribe from these notifications, please login to the CPAN Testers Preferences system, with your PAUSE credentials, and disable CPAN Testers notifications permanently or temporarily. If you have problems with accessing the site, please contact Barbie bar...@cpan.org and request to be removed from the automatic mailings. Thanks, The CPAN Testers -- Reports: http://www.cpantesters.org Statistics: http://stats.cpantesters.org Wiki:http://wiki.cpantesters.org Preferences: https://prefs.cpantesters.org ---End Message---
CPAN::Index
Hi Kevin, It seems that you've installed CPAN-Index (http://search.cpan.org/dist/CPAN-Index/) which is an abomination and should be banished from Planet Earth forever. Here's report, I think there's a whole lot of similar ones: http://www.cpantesters.org/cpan/report/a173b2b0-50c7-11e1-9696-aae50df65b4f -- S.T.
Re: Blacklist removal request
Marvin Humphrey wrote: I know that at least one Windows tester had the Lucy distro blacklisted a while back: http://svn.trouchelle.com/perl/cpan/prefs/_stro_win32.yml |KARMAN/Lucy-0.1.0 # Crashes We've been working hard on portability and things are pretty good now -- all green for Lucy 0.2.9_04 and 0.2.9_05 except for certain Perl 5.15.5+ installs. (There are some perlapi symbol export bugs in blead which we're trying to work around.) Can you please turn your smokers back on for us? 0.2.9 is not blacklisted by these distroprefs, only 0.1.0, so you don't need to worry. -- S.T.
Re: Devel-Trepan-v0.1.0a fixing die in use Term::ReadLine::Perl
Rocky Bernstein wrote: I recently put on CPAN a gdb-like debugger for Perl that I am working on. It uses Term::ReadLine but I don't have that listed as a dependency. It does list Psh as a dependency and that requires Term::ReadLine. So although this isn't ideal and should be fixed, I am getting a failure from Term::ReadLine because some versions of Term::ReadLine::Perl have a die in them on some platforms. See: http://www.cpantesters.org/cpan/report/15c55094-00d0-11e1-b45a-b28a378affb7 So how do I fix? It's hard to tell what's causing this error, but it's not a latest version of Term::ReadLine::Perl used in this report. You may want to add recent version as a prerequisite for your module. Also, is there a way I can run the tests on demand *before* making a release? You can make a development version by adding underscore to your version number. And v0.1.0a is NOT a number, so you have to change it to something like 0.101_001 and then upload to CPAN. Smokers will test it while CPAN clients will ignore. But you cannot make a release anyway because you have DB.pm in your package. You should rename it, because CPAN will refuse to index it. For a very good reason, btw. -- Serguei Trouchelle
Re: send report from file scrambles report info
Here's script I'm using:
http://svn.trouchelle.com/perl/cpan/0sendreports.pl
Yours has two flaws: first, you remove a report file before submitting it to Metabase. If something goes wrong, your
report is lost. Second, you should check if you really removed report file. I had a problem when my filesystem was set
to readonly and 4 reports was sent over and over again for few thousand times.
About the issue with different information in tail log and report, it was addressed some time ago and Metabase contains
correct information. Probably, a server part responsible for writing log files seems to still have the same problem and
is using client information and not report's one. But Metabase itself should be unaffected by this.
Chris Marshall wrote:
I'm trying to implement a way to submit CPAN Testers
reports generated offline from the report files. Here
is the script I came up with and just tried. The problem
is it appears from the tail/log.txt from the metabase site
that some of the information of the sending perl
instance (cygwin perl) may have gotten mixed in
with the information of the test report (asperl). Is this
a bug in the metabase transport or is there something
else I need to add to make this work?
Thanks in advance,
Chris
use Test::Reporter;
use Test::Reporter::Transport::Metabase;
$reports_dir = 'reports';
opendir(DIR, $reports_dir);
@reports = grep { /^[^.]/ -f $reports_dir/$_ } readdir(DIR);
closedir DIR;
print join(\n, Got reports to process: , @reports) . \n;
foreach $file (sort @reports) {
unless (-e $reports_dir/$file) { next }
# load file and set in
$reporter = Test::Reporter-new();
$reporter-transport('Metabase');
$reporter-transport_args(
uri = 'http://metabase.cpantesters.org/api/v1/',
id_file = '/cygdrive/f/chm/.cpanreporter/chm.json',
);
# output file being processed
print processing... $file\n;
# sanitize email address in report
### `perl -i -p -e 's|dcol...@gmail.com|dcol...@cpan.org|g'
/usr/share/reports/$file`;
eval('$report = $reporter-read($reports_dir/$file)');
$error = $reporter-errstr();
$error ? print $error.\n next : undef;
# clean up file after processing
print rm -f /usr/share/reports/$file\n;
# send report in
eval('$retval = $report-send()');
$error = $reporter-errstr();
$error ? (print $error.\n) : undef;
}
--
Serguei Trouchelle
Re: 2- or 3-part version numbers?
Just increase major version of your modules and switch to x.x version numbering. So after 0.1.2 you can use 1.000, and this should be enough. Just remember that 1.2 1.11, so you should use the same number of digits when you continue increasing version numbers. John A. Kunze wrote: How hideous would it be if I switched back to uniform 2-part version numbering across my modules using the nuclear option, ie, entirely deleting from CPAN my few (I believe lightly used) module versions that for less than a year have borne 3-part version numbers? Would this plan qualify as an exception to the never clause below? When I asked in June about the wisdom of switching from 2-part to 3-part version numbering, I'd already mistakenly done so for half my modules, innocently violating the primary rule. I want to switch back because it hurts my sense of esthetics and has caused disruption in some smokers. -John --- On Tue, 28 Jun 2011, David Cantrell wrote: Do folks have thoughts on whether it's better for CPAN modules to use 2- or 3-part version numbers? I switched recently to using vI.J.K version numbering with my modules v1.2.3 isn't a number. Nor is 1.2.3. Therefore they are wrong. However, because Wrongness was once thought to be Rightness, they are supported, and using them is fine, *provided that* you are consistent and *never* mix different types of number for a distribution. Once a distribution uses proper numbers, it should *never* be changed to use Wrongness, and if it already uses Wrongness it should *never* be changed to use proper numbers. (for values of never that are accurate enough for a brief email, I really can't be arsed with explaining when it's OK to mix and match and when it's not). -- David Cantrell | Official London Perl Mongers Bad Influence Arbeit macht Alkoholiker -- S.T.
Automatic fallback mechanism (Was: Metabase looks to be down)
Hello testers, David Golden wrote: In the mean time, please store your reports locally or just give those smokers a summer holiday. By the way, is there any interest in something like Test::Reporter::Transport::MetabaseFallback? I have some preliminary realization of transport which tries to send report to Metabase and if there's any error, it saves it in a file. If sending is successful, it also sends a small batch of saved reports if they exist in the file cache. If anyone is interested, I can bundle it and release to CPAN. -- Serguei Trouchelle
Feature request: list of reports generated by tester
Hello Barbie et al, Right now, cpantesters.org is not very searchable. I'd like to track down possible false failures which can be generated by 2nd generation Test::More, but I'm unable to easily find my own reports to investigate further. Also, having this feature for any CPAN tester can be a very useful tool to find if some smoker is misbehaving. I'd like to have searches by Perl version, platform, distribution and maybe time of report. Maybe other criteria may be useful too. What do you think? -- Serguei Trouchelle
Re: Using an old XML-Writer here: http://www.cpantesters.org/cpan/report/c9bc7d3b-6bf9-1014-adbd-077e73fdb553
Hi Shlomi, Sorry for late reply, I was quite busy this week and just got some free time for emails. Shlomi Fish wrote: Why don't you just specify a minimum supported version of XML::Writer in Build.PL? It's much easier and definitely more correct than anything else. Because I don't know how much this is realistic. I don't know what is the oldest version of XML::Writer that my module is still supposed to work with and I don't wish to investigate. If the failure is in the real world, then I will be getting a valid report, but otherwise I can assume that XML::Writer is in a recent enough version for my module to work with. When I'm in the same situation, I read Changes for this distribution and usually find an answer really quickly. For example, I needed DBD::SQLite which supports REGEX in WHERE clauses and easily found that it's 1.27. If you don't want to spend time reading or Changes doesn't provide an answer, I think you can safely assume that the version you are using right now on your machine is the minimum. This way, you'll be sure that your module is working fine in other environments. Upgrade may be unnecessary but it would save a lot of time for those who use older versions of prerequisites. -- Serguei Trouchelle
Re: Test-Count testing on Windows often gives me Could not open file 'C:\Temp\bUmehRFuVH\with-include-temp.t' for writing - Permission denied.
Hi Shlomi, Shlomi Fish wrote: Here is another failing test report for Test-Count on MS Windows: http://www.cpantesters.org/cpan/report/303b21da-55cd-101b-b0bd-c0f01c721f4d I'm trying to figure out why it keeps complaining that it cannot write to the files in the temporary directory (which was a workaround for the fact that it could not write into files under t/data/** ). Tried to run this tests on my machine, this failure is reproducible. It's failing because with-include.t is read-only, and File::Copy::copy produces read-only file as well. You can either change its permissions from 444 to 644 in distribution file, or set it to read-write in your test. It's actually some kind of weird behavior of File::Copy, which doesn't keep permissions on Linux and keeps them on Windows, OS/2 and VMS -- reasons unknown. -- Serguei Trouchelle
Re: Smoking on Windows and Module::Build
David Golden wrote: Comments from people who knows MB well is much appreciated. I'll try to debug it myself, but I'm not sure I can find a source of problem quickly. My best guess is that it's Pod::Html trying to build an index for resolving L tags. C.f. https://rt.cpan.org/Ticket/Display.html?id=68651 Yes, this is it. I remember similar problem with Pod::Html when installing PPM packages on ActivePerl. It was fixed by removing html directory (or not installing it in the first place), then ActiveState HTML generator wouldn't run Pod::Html. I think that it would be a good idea to add similar check to Module::Build. It seems it runs Pod::Html even if perl/html is absent. My other observation on why things are slow is Makefile.PL specific -- every system operation is emulated with Perl. So a simple copy mean spawning another Perl process and process spawns are very slow on Windows. So if the Pod::Html problem were fixed, then M::B should be faster than EU::MM by not having to spawn for every system operation. AFAIK, these commands are running very rarely. When running nmake test, ExtUtils::Install is used to copy files to blib, and it uses File::Copy. I'm not even sure ExtUtils::Command commands are actually running on any stage of testing. Maybe having MSYS's cp.exe may help in this case, I didn't look at it closely. -- Serguei Trouchelle
Smoking on Windows and Module::Build
Hi there! Everyone knows that CPAN smoking on Windows is S-L-O-W. I've tried to take a look why it's so slow using ProcMon from Sysinternals (microsoft.com/sysinternals). It turned out that building every distribution that is using Module::Build results in reading every single file in Perl directory (bin/*, lib/*, etc). Distributions that use ExtUtil::MakeMaker don't experience this problem. I don't use Module::Build myself and cannot tell why this happens, and was it intentional or not, but if you're running smokers on Windows, make sure you set 'prefer_installer' to 'EUMM' in CPAN config. It will save you a lot of time and harddisk life -- though it will still take a hit when it's MB-only distribution. Comments from people who knows MB well is much appreciated. I'll try to debug it myself, but I'm not sure I can find a source of problem quickly. -- Serguei Trouchelle
Re: CPAN Testers Statistics update
Chris 'BinGOs' Williams wrote: My explicit exclusions are: https://github.com/bingos/cpan-smoke-tools/blob/master/cpansmoke.ini I think Prima is CPAN-friendly now. I have no problem with it on both Windows and Linux. -- Serguei Trouchelle
Re: Fw: Using an old XML-Writer here: http://www.cpantesters.org/cpan/report/c9bc7d3b-6bf9-1014-adbd-077e73fdb553
Shlomi Fish wrote: I'm testing with an old XML-Writer, because your module does not provide a minimum version. Apparantly your module does not work with all versions of XML-Writer. My smoker tries to create scenarios in which older versions of the module are already installed. So this shows that if someone with this version of XML-Writer installed tries to install your module, CPAN/CPANPLUS won't upgrade XML-Writer. Please stop doing that. I'm not interested in such terminal-case reports, which may be very unrealistic. In real world, they are very REALISTIC. People don't update modules in production just because they can. Only when they must. So please either stop doing that altogether or alternatively black list all of my (= SHLOMIF's) distributions from this kind of testing. Why don't you just specify a minimum supported version of XML::Writer in Build.PL? It's much easier and definitely more correct than anything else. -- Serguei Trouchelle
Re: why no testing under Windows?
Gabor Szabo wrote: ps. I see one of my modules is in that list too :( It's not a problem, I think. There are some modules from well-respected authors in my prefs (and some well-respectful modules too), just because they don't fit my smokers. Or they just can take too long time because of my configuration (like ExtUtils-Install, its older versions scanned all installed modules, and I install everything while smoking). Or they were developer versions which had some problems (like Module-Build). Regarding testing on Windows, some modules crash when using MinGW, some crash when it's MSVC. There's no single way and no Definitive Guide to CPAN Testing, really. -- Serguei Trouchelle
Re: why no testing under Windows?
Chris Marshall wrote: Thanks for the link. CHM/OpenGL- is disabled in win32 because it Needs freeglut.dll. [...] I've tried to build 0.64_002 manually, it fails, but it did copy dll file to my ActivePerl site/bin. Then 0.64 had no problems with building and testing. I don't think that FreeGLUT is available in ActiveState perl distributions. No, it's definitely not. Any suggestions for CPAN Tester appropriate way to get and (temporarily) install library dependencies are welcome. The best and easier way is to copy freeglut.dll to blib\arch\auto\OpenGL It will not interfere with other versions (if any), and Dynaloader will use this directory first when trying to load OpenGL.dll Both (n)make install and make_ppm should process this correctly and place it to site\lib\auto\OpenGL Static linking is a good option too, if it's possible. While trying to build some modules for my PPM Repository, I've changed them to use static linking, and it worked great. Yes, it makes dll bigger, but -- THANK GOD IT'S 2011! -- nobody cares about disk size anymore. -- Serguei Trouchelle
Re: why no testing under Windows?
Chris Marshall wrote: Many smoke testers blacklist distributions that prompt for user input during testing. Any way to get a list of such blacklists? I've got a couple of modules that don't ever seem to be tested but have no way of determining why not or what to do to resolve the problem---if it is possible to do so You may try my prefs: http://svn.trouchelle.com/perl/cpan/prefs/ You may want to take a look at hangs, pl_prompts, t_prompts, and (when running tests under Windows) win32 Regarding File-Pairtree, yes, I've blacklisted it long time ago. I know it would be a good idea to contact author, but I had negative experience with trying to inform authors and get silence as answer. So I just block anything that is testing more than 30 minutes (would love to have some robot to do this for me :) -- Serguei Trouchelle
Re: CPAN Testers and companies
Alceu Rodrigues de Freitas Junior wrote: I'm not sure if the reports by e-mail are still working (long time out of testing cycles to know) but maybe you could check the usage of the module Test::Reporter::Transport::Outlook (http://search.cpan.org/~arfreitas/Test-Reporter-Transport-Outlook-0.01/lib/Test/Reporter/Transport/Outlook.pm). No, they are not working anymore. It's basically a hack, but it works and in your case you wouldn't need to install Redemption. Well, in fact it doesn't work. All emails will be bounced by cpan.org's MX. -- Serguei Trouchelle
Problem with smoker, possibly PERL5LIB involved
Hello Daniel and CPAN Testers, I've found this very strange test result: http://www.cpantesters.org/cpan/report/048e04de-9b35-11e0-96f4-fdd92c767501 And after quick investigation found that there are also similar reports, and all of them have one similarity: an enormous PERL5LIB variable (more than 64k), which contains modules that totally unrelated to currently smoking package. So, if you use build_dir_reuse, PLEASE set clean_cache_after to some small value, and don't use default 100, because it's very likely to fill PERL5LIB to the point when unpredicted problems start to appear. Having something like Dist::Zilla::Some::Plugin smoked will definitely add *kilobytes* to PERL5LIB because of hundred of Moose dependencies (174 including core modules to be precise). -- Serguei Trouchelle
Re: perl crashing while trying to install File::Flock on Strawberry Perl
Hi,
I've tried testing this module on ActivePerl and tests fail with error messages
like this one:
Your vendor has not defined POSIX macro EWOULDBLOCK, used at
C:\bin\dev\perl\cpan\build\File-Flock-2008.01-J2fs8W\blib\lib/File/Flock.pm line 108
flock /tmp/flt2.7660 UN: Unknown error at C:\bin\dev\perl\cpan\build\File-Flock-2008.01-J2fs8W\blib\lib/File/Flock.pm
line 189
File::Flock::unlock('/tmp/flt2.7660') called at
C:\bin\dev\perl\cpan\build\File-Flock-2008.01-J2fs8W\blib\lib/File/Flock.pm line 229
File::Flock::END() called at C:/bin/dev/perl/lib/Carp.pm line 44
eval {...} called at C:/bin/dev/perl/lib/Carp.pm line 44
I think ActiveState disabled it for a reason and real problem can be inside
POSIX.pm (or POSIX.dll).
As for me, I just blocked this particular distribution in preferences long ago.
Gabor Szabo wrote:
As I was running the smoker in Strawberry Perl 5.12.3 I got a crash
with a pop-up asking me if I want to report the bug to Microsoft so
I guess this crashed perl itself.
Then I tried to manually install the module and got the same pop-up
crash. Below is the output. If I am not mistaken flock is not even
implemented on Windows so this module should probably not create
its Makefile when running on Windows but still this is a crash.
Where do you think I should report this? to RT of File::Flock?
To Strawberry Perl?
To p5p via perlbugs?
--
Serguei Trouchelle
Broken smoker
Hello Jeroen, It seems your LWP installation is broken for some reason. Your smoker reports LWP::Simple to be 6.00, while libwww-perl 6.0 definitely has HTTP::Status as a prerequisite: http://cpansearch.perl.org/src/GAAS/libwww-perl-6.00/Makefile.PL Side note: CPANPLUS-based smokers should do something like CPAN::Reporter::PrereqCheck do, so they can discard obviously erroneous reports. Original Message Subject: CPAN Testers Daily Summary Report Date: Wed, 15 Jun 2011 02:17:48 + From: CPAN Tester Report Server do_not_re...@cpantesters.org To: Serguei Trouchelle s...@cpan.org Dear Serguei Trouchelle, Please find below the latest reports for your distributions, generated by CPAN Testers, from the last 24 hours. To set your preferences for what you wish to have reported in this Daily Summary, please visit the CPAN Testers Preferences system at https://prefs.cpantesters.org. CPAN-SQLite-0.200: - x86_64-linux-thread-multi / 5.14.0: - FAIL http://www.cpantesters.org/cpan/report/757779ac-9598-11e0-8a7f-f2dad20d8f17 If you have an issue with a particular report, or wish to gain further information from the tester, please use the 'Find A Tester' tool at http://stats.cpantesters.org/cpanmail.html, using the ID or GUID of the report, as listed above, to locate the correct email address. If you wish to unsubscribe from these notifications, please login to the CPAN Testers Preferences system, with your PAUSE credentials, and disable CPAN Testers notifications permanently or temporarily. If you have problems with accessing the site, please contact Barbie bar...@cpan.org and request to be removed from the automatic mailings. Thanks, The CPAN Testers -- Reports: http://www.cpantesters.org Statistics: http://stats.cpantesters.org Wiki:http://wiki.cpantesters.org Preferences: https://prefs.cpantesters.org
Re: CPAN smoking on Windows
Gabor Szabo wrote: Following QuickStart I installed CPAN::Reporter and configured it. The config.ini file was created in c:\Documents and Settings\Gabor Szabo\.cpanreporter which is probably based on the %HOMEPATH% environment variable. It's Win32::CSIDL_PERSONAL actually. The edit_report and send_report options seem to be a bit unclear to me though I recall once I understood them. (old age :) I wonder if it would not be better to change them never to ask questions as this is a smoke testers. What do you use in this configuration? edit_report=no send_report=yes c: cpan CPAN::Reporter::Smoker and while I saw [Hello] in the title bar of the window I have not seen the questions that were waiting for an answer: # (y/n) # Do you see '[Hello]' in the title bar (or tab) of this window? (y/n)? y # Has the title bar (or tab) been cleared? (y/n)? y After stopping the installation with Ctrl-C I started the cpan shell and ran cpan install Term::Title that time it showed the prompts as well. Yes, I have this problem too, starting from 5.12. Maybe it's something with newer versions of CPAN shell. I don't mind it because I install Term::Title as a first move (because it's interactive) and then install C::R, which takes more time, so I can start doing something else while it's installing. -- Serguei Trouchelle
CPAN::Reporter::Smoker and 5.13.9
Hello, I've just tried to setup an environment for testing recently released Perl 5.13.9 and found out that it's not possible to install C::R::S because Text-Glob prerequisite is failing its tests. Then I've tried previous versions of C::R::S which don't rely on Text-Glob, but they failed too. Any ideas? Maybe 5.13.9 is just buggy enough to not to be tested at all? (I'm also unable to compile 5.13.9 multi-thread on Debian). -- Serguei Trouchelle
Re: CPAN Testing: File::Temp is broken on your Win32 tester
Shlomi Fish wrote: I recently received a failure report from several machines while testing the new Config-IniFiles version 2.64 on Win32: http://www.cpantesters.org/cpan/report/fb07a351-72c6-1014-a617-6c529855645b It seems that File::Temp is broken there and the two tests that use it failed as a result. Please fix it there. It's not broken, you're using it wrong. # TEST my ($newfh, $newfilename) = tempfile(); my $content; $ini-WriteConfig($newfilename); $newfh is opened filehandle for $newfilename, and you're trying to open this file again in your code. You should close $newfh first, if you're going to use $newfilename and not $newfh. -- Serguei Trouchelle
Re: More version number madness
Nigel Horne wrote: $ perl -e 'printf %f\n, 0 + (1 0)' 0.00 $ perl -e 'printf %g\n, 0 + (1 0)' 3.33761e-308 $ What does your perl -V say? -- Serguei Trouchelle
Re: CPAN::Config::Trust_Test_Report_History
David Golden wrote: Case 1. When you manage to make module working (and therefore pass tests), it's not installing without force. Example: Some module, let's name it Format::LibFormat is a prerequisite for a few hundreds modules. You run smoker, it tries to install this module, but find out that it requires libformat library. You run apt-get install libformat2, and then cpan Format::LibFormat. And it doesn't work. I think I made CPAN let force override test report history. Yes, force overrides history, that's true, but it should be manually invoked. It's not critical, but somewhat inconvenient. Case 2. You don't have any benefit for failing builds. Example: Some module, like Super::Something fails on Perl 5.15.1, and is a prerequisite for another few hundreds modules. It's not building because of problem with XS or something, doesn't matter. Result is UNKNOWN like in previous case. Next time smoker tries to test/install it, it would compile it again. No benefit. So it works only with FAIL, not UNKNOWN. And if you find a common prerequisite that is failing, it's easier to just disable it in distroprefs. I actually find it most useful for PASS for common dependencies. Let's say lots of thing require a newer version of Test::More. Once that tests OK once, there's no need to test it again and again when satisfying prerequisites. On most operating systems, the speed isn't a big deal, but when I was working on Win32 smoking, everything there is so damn slow due to all the process forking that I was trying to find every possible speed optimization. Hmm, yes, it should speed up things. Personally, I prefer to install all modules (except development versions) during smoking. I lose a few gigabytes of disk space for every Perl instance, but it really speeds up testing modules with a lot of prerequisites. And disk space is not a big problem during these days. There's one week point in this approach: it lowers possibility to find missing prerequisite for module. -- Serguei Trouchelle
Re: FAIL CPAN-ParseDistribution-1.2 v5.13.4 Windows (Win32)
David Cantrell wrote: Please find below the latest reports for your distributions, generated by CPAN Testers, from the last 24 hours. CPAN-ParseDistribution-1.2: - MSWin32-x86-multi-thread / 5.13.4: - FAIL http://www.cpantesters.org/cpan/report/d70512b8-bada-1025-8363-ce6c7bd6fb57 The report is full of: tar: Cannot fork: Function not implemented tar: Error is not recoverable: exiting now Does this mean that you have a non-GNU tar? Or that perl on Win32 can't run tar via system() for some weird reason? Sadly, I'm unable to reproduce a problem. I've re-run testing and tests passed ok. Modules configuration have been changed since original tests, maybe some other modules can interfere? I have GNU tar 1.13 from GNUWin32 and it seems to work fine, but I don't know about Cannot fork: Function not implemented message and why it appears in the first place. -- Serguei Trouchelle
Re: Who so few MSWin32 tests for DBI?
Tim Bunce wrote: DBI 1.613_71 was uploaded on the 16th yet for MSWin32 there is only 1 test report: http://matrix.cpantesters.org/?dist=DBI%201.613_71;reports=1;os=MSWin32 Any reason for that? (Holiday season?) Any way it could be improved? I've sent about 8 reports for DBI 1.613_71 for different perl versions yesterday, but I don't see them appearing on cpantesters.org. Still, I see my other submissions in the tail log. By the way, they are all FAILs, I can send more details if needed. -- Serguei Trouchelle
Re: Casual testers
David Golden wrote: I install Test::Reporter on any machine I administer, so that as I install perl modules, their success or failure gets reported. Now I'm getting emails asking me to use HTTP. I'm trying to follow them, but am hitting roadblocks, and am wondering why I'm jumping through hoops to fix what seemed to be working fine from my perspective. Hi, yary. Thanks for writing with your questions. The switchover to HTTP based submission was prompted by the perl.org administrators, who were getting nearly half a million test reports by email -- accounting for about 99% of monthly email traffic to perl.org mailing lists. Since more and more people were having trouble with email submission due to restrictive firewalls and ISP's, the second generation transport is HTTP. Unfortunately, due to the haste of the switch and the limited volunteer time to write documentation and code to automate the conversion, there is still a good deal of manual work to do. Just a thought about default behavior. Wouldn't it be better if Test::Reporter would use File transport by default? T::R::T::File itself can print some message offering to install T::R::T::Metabase and set it up. I also think of failover mechanism, which can be implemented using T::R::T::File as a backup transport, when there's some problem with submission to Metabase. -- Serguei Trouchelle
Re: load_fact_classes not found
M W487 wrote: I get a similar error on cygwin. [...] cpan[5] install Test::Reporter::Transport::Metabase Test::Reporter::Transport::Metabase is up to date (1.999006). cpan[6] install Test::Reporter Test::Reporter is up to date (1.57). cpan[9] install CPAN::Testers::Report CPAN::Testers::Report is up to date (1.999). What version of Metabase::Fact do you use? CTR requires version 0.003, while latest one is 0.016, and this may be the source of problem. -- Serguei Trouchelle
Re: CPAN::Reporter: test results were not valid, Prerequisite version too *high*
David Golden wrote: I have ranted in many other forums that dotted decimal versions should always be expressed in normal form -- meaning a leading v and at least 3 parts (v2.17.1 or v2.6.0) to avoid confusion. I strongly disagree. ExtUtils::MakeMaker doesn't handle v-strings. It's documented in http://search.cpan.org/dist/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm, it's advised to use version or regular strings. I had some bad experience because of v-strings in certain modules' Makefile.PL because '2.1.3' 2.1.4 and v49.46.48 == 1.0 I'd say any version that has more than one dot in it, is evil. And v-strings are even more evil. -- Serguei Trouchelle
Re: Test::Reporter::Transport::Metabase error (pmax)
Nigel Horne wrote: fact submission failed: Server closed connection without sending any data back at fact submission failed: Connect failed: connect: Connection timed out; Connection timed out at Might be something with the network. Consider using Test::Report::Transport::File to store results on local disk, and then submit them to Metabase. When submission error appears, you can retry after network problem is resolved, or, if it's a Metabase problem, you can send it to David for investigation. I can write a step-by-step guide about how to setup such configuration if anybody's interesting. Also, I think that CPAN::Reporter can use some fallback mechanism for errors. First, trying to submit report to Metabase, in case of failure, store it somewhere (~/.cpanreporter/pending/ for example) and probably try to resend them later. -- Serguei Trouchelle
Re: use 5.008008; but get test results for 5.8.7
Torsten Förtsch wrote: So, why is a perl 5.8.7 trying to test a module that states to require at least 5.8.8? It isn't. The result is NA, not FAIL. So I am to expect NAs for perl versions less than required? Yes, it means that your module is not available on certain perl version/platform. This result is produced during Makefile.PL/Build.PL stage, so nothing is actually tested. -- Serguei Trouchelle
Re: CPAN::Reporter: test results were not valid, Prerequisite version too *high*
Nigel Horne wrote: I have raised bug reports against both RWDE and DBD::Pg. DBD::Pg is not to blame, they have consistent numbering: 1.xx then 2.x.y The problem is with RWDE. -- Serguei Trouchelle
2.0 in action or just my bad?
Hello, I've found that I hit 750 in Notable Reports on http://stats.cpantesters.org/interest.html#reports Report's URL is http://www.cpantesters.org/cpan/report/7659068 But I don't email any PASS reports for 5.13.* and 5.12.*, I only submit them to 2.0 using Test::Reporter::Transport::Metabase. Does this mean that 2.0 is actually working right now, or I have some runaway messages because of some misconfiguration or something? -- Serguei Trouchelle
Re: How big should test reports be?
Bill Birthisel wrote: It would work for Pass reports. But if there is a failure, authors would like to see as much as possible. Nobody would like to see one million Use an uninitialized value in lines, usually appearing in such big reports. -- Serguei Trouchelle
Re: more thinking on getting RC status into reports
David Golden wrote: The header will also be preserved through file save/load, but I have not yet done corresponding work on the CT2.0 Test::Reporter::Transport::Metabase. (I'm out of tuits for tonight) It's possible that all 5.12.0 reports on CT2.0 will need to be purged. Just update them to be RC0. There's no RC1 or release anyway. -- Serguei Trouchelle
Re: Fwd: CPAN Testers Using 5.12.0?
p...@0ne.us wrote: Yes, that was the impression I got from #p5p on IRC. They sorta expected it to be a quiet release and used just to test things. I blame BinGOs' bots for announcing it everywhere and making everyone excited :) Perl roadmap implies that a new development version is released every month around the 20th. So there's nothing secretive about it. I'm installing new smokers monthly (and drop old ones) without reading Perlbuzz or Perl Porters or something, I just know that there should be a new version. I believe Andreas and Chris do the same, knowing that they are interested in testing bleeding edge versions. -- Serguei Trouchelle
Re: Testing CT2.0 with CPANPLUS
Curtis Jewell wrote: If you wouldn't mind another Windows smoker, I can throw an x64/x86_64 Windows one at it. (a pre-beta Strawberry 5.11.5 :) ) If you manage it to work. :) There's some problem with parsing a report right now. -- Serguei Trouchelle
Is there life after deadline?
Hi there, March 1 has passed, and reports still appear on NNTP and CPAN testers website, but I'm not sure will it last long. Should we continue to send email reports with reduced rate or it's better to stop sending reports until CT2.0 is up and running? -- Serguei Trouchelle
Re: Default to y ? (CPAN testing halted on SIGINT. Continue (y/n)? [y] )
David Golden wrote: perl -MCPAN::Reporter::Smoker -e start If I recall, on Windows, you can't isolate CTRL-C to a single process. Everything in the process group gets it. Situation: (a) You're running CPAN::Reporter::Smoker (b) It tests some poorly behaved distribution (c) You hit CTRL-C to bail out the hung test process (d) CPAN::Reporter::Smoker gets the SIGINT, too My thought was that if you're smoking, you want to keep going when one distribution goes bad and not restart, so I made that the easy option. No, I'm smoking on Windows and smoker stays alive. Sometimes it realizes that SIGINT came only after testing next distro, but this is mostly ok. There's another problem, if you happen to hit Enter just to see if the distro awaits something from STDIN or just hangs, it became the default for y/N and C::R::S stops smoking. I'd like to have Y as default because of this. Moreover, as you may remember, I run smoke tests on WD Mybook where some distros want too much memory and got SIGTERM. Then everything waits for me to came to see what's going on, and it may take a few days. It would be good to force smoker to start testing further, though I cannot be sure if this is suitable for other testers. -- Serguei Trouchelle
Re: Very skinny test report
Andreas J. Koenig wrote: I found two reports from you that look sick: they contain only the first and last paragraph of a full report, it seems. http://www.cpantesters.org/cpan/report/6841116 http://www.cpantesters.org/cpan/report/6840716 Any ideas? These are reports made with Test::Reporter by the tool to populate my PPM repositories for ActivePerl. The code that makes them and send are very similar to the T::R synopsis' third example ($t = new; $t-send). It works that way for a long time and I didn't bother to add any other comments because I send only PASS reports when all tests are successful and only there were no warnings or anything else printing to STDERR during the building process. So there's technically nothing to diagnose, everything is ok. It's just not a CPAN::Reporter or CPANPLUS report. -- Serguei Trouchelle
An idea for discouraging Test::Perl::Critic
Hi there. Some modules uses Test::Perl::Critic tests outside of author environment, that can result in FAIL because some installed Perl::Critic::Policy'ies are violated. Once I've seen a policy that contradicts to one of default policies, leading test to failure every time when policy subject is triggered no matter how code is written. I'm thinking to have something like Perl::Critic::Policy::TestingAndDebugging::AlwaysFail installed in smoker environment, which reports P::C violation every time it is called. It would discourage CPAN authors from providing tests that have nothing with module functionality. LWP::Useragent, DBI, DBD::SQLite, CPAN.pm and thousands other modules would fail perlcritic even on level 5, but it doesn't mean they don't work. What do you think about it? -- Serguei Trouchelle
Re: CPAN TESTERS ALERT -- throttle your smokers NOW
David Golden wrote: In the meantime, please slow down testing -- put sleep loops in the smoker code or something. Whatever you have to do -- we need to get back down to the 100,000 reports/month level (or further) to take some pressure off the NOC. Most valuable tests (IMO) are FAIL tests, because they indicate that something's not right and raise author's attention. We had about 30,000-40,000 FAIL tests monthly during last 6 months, and it's less than 100,000. It may be a good idea to send FAIL/UNKNOWN reports and hold on with OK/NA. I estimated my smoking volume comparing to other testers and started to send FAIL/UNKNOWN not faster than 1 report/min rate and OK/NA at 1 report/10 mins. -- Serguei Trouchelle
Re: failures for WWW-Compete-0.01
Chris Mills wrote: I uploaded my first module today (WWW-Compete-0.01) and I see that some tests are failing. I believe that's because a Compete API key is required before the tests can be successfully executed. There's a point in one of the tests where the user is asked to input an API key, but I understand that's not very helpful for automated testing. I'd like to fix this. Can you provide any suggestions for handling this scenario, or perhaps point me to a module that handles this in what you would consider a well done way? First of all, use prompt(), because direct reading from STDIN hangs smokers, and you may find your module in disabled.yml, which is not very helpful for you either. Then, skip all tests when no key is given. -- Serguei Trouchelle
Re: More testing of common platforms
Andreas J. Koenig wrote: [...] One problem I see at the moment is the format of the reports-sent.db file: test FAIL Data-FormValidator-4.63 (perl-5.11.2) x86_64-linux 2.6.30-1-amd64 Right now a reporter will send a maximum of one pass and one fail for this distro/perl combination. There's already send_duplicates configuration variable for CPAN::Reporter, it can be set to yes, then duplicate reports would be sent regardless of reports-sent.db. Though, it may produce a great amount of FAIL reports of common prerequisites when they get tested for every package that requires them. I'd add another user (if it's possible) and run smokers for different configurations from different accounts. -- Serguei Trouchelle
Re: Hardware overload
Martin Evans wrote: Well I tried but didn't get very far. I managed to build perl 5.10.1 and set up cpan shell but whenever I try and install CPAN::Reporter the machine runs out of memory (perl -MCPAN -e shell has it all) and the system kills the cpan shell. You may want to try to install manually (perl Makefile.PL make make test make install) following packages before running CPAN shell: DBI DBD-SQLite CPAN-DistnameInfo File-HomeDir libwww-perl CPAN-SQLite Then set use_sqlite to 1 in CPAN/Config.pm: 'use_sqlite' = q[1], After this, memory consumption of CPAN shell should decrease. You can speed up index rebuilding by having other CPAN shell (on more powerful machine) rebuilding index and copying cpandb.sql to your box's ~/.cpan -- Serguei Trouchelle
Re: Smoke Test on ARM (arm-eabi-linux)
imacat wrote: The Perl interpreter in the Android Scripting Environment was unable to run due to some problem with File::Spec. But, as more and more Perl-supported ARM devices are released (smartphones, netbooks), is there anyone ever think of running an ARM smoke machine? Will someone share their experience on this? I've run tests on WD Mybook World Edition, which is ARM9-based (armv5tejl-linux): http://stats.cpantesters.org/matrix/list-155.html http://stats.cpantesters.org/matrix/list-156.html There were no problems to build perl and run tests, except it is horribly slow. So I suppose your problem lies with Android. -- Serguei Trouchelle
Re: MISSING PREREQUISITES: Sub::Identify
Ingo Lantschner wrote: The quiet pragmatic solution was to add the line 'Sub::Identify' = 0, to Build.PL. But I have no clue about the source of this error, since I never used Sub::Identify in my project. Any idea? SUPER.pm uses it. http://cpansearch.perl.org/src/CHROMATIC/SUPER-1.16/Makefile.PL (Full report f.e. here: http://www.nntp.perl.org/group/perl.cpan.testers/2009/08/msg5023873.html) -- Serguei Trouchelle
Re: Devel::CheckLib has shiny new features
David Cantrell wrote: Before I bump it to version 0.7, I'd be grateful if people could test it on Windows, with both the GNU, MS and Borland toolchains. Fails for me on Vista with ActivePerl 5.10 using both MSVC6 and MinGW. MSVC's report was sent to cpantesters. Will check 5.8.8 on Windows 2003, but I suppose results would be the same. -- Serguei Trouchelle
Re: Help with SMTP
Chris Marshall wrote:
I'm trying to use Test::Reporter with Net::SMTP::TLS
and having no luck. If someone has gotten this to
work (especially with gmail smtp), I would appreciate
the working template for use.
Here's a script I'm using to send reports via google.
I'm using transport=File to store reports in directory and run this script from it once a day, because gmail accepts
only 500 messages to one recipient per day, and smokers often go over the limit.
--
Serguei Trouchelle
#!/usr/bin/perl -w
use strict;
use warnings;
use Test::Reporter;
$| = 1;
opendir(my $DIR, '.') or die $!;
my @files = sort { my @aa = stat($a); my @bb = stat($b); $aa[10] = $bb[10] }
grep { /\.rpt$/ } readdir $DIR;
closedir $DIR;
print 'Found ', scalar @files, ' files, sending ';
foreach my $file (@files) {
my $tr = Test::Reporter-new(
'mx' = ['smtp.gmail.com'],
'transport' = 'Net::SMTP::TLS',
'transport_args' = [
'User' = 'u...@gmail.com',
'Password' = 'PASSWORD',
],
)-read( $file );
my $res = $tr-send();
print '.';
if ($tr-errstr()) {
print \n\n, $tr-errstr();
if ($tr-errstr() =~ /Daily quota/) {
last;
}
sleep 60;
redo;
}
unlink $file;
}
print \n\n;
Re: Easier to test when testing the present
George Greer wrote: Actually, I wouldn't mind if the smoker tested+installed every package rather than only testing it. I'm running throwaway Perl installs so it can go nuts with packages and it won't permanently affect anything. Downside to that, of course, is not being able to find unspecified dependencies when doing so. It's easy to hack in Smoker.pm code, search for test( and replace it with install(. But it would be better to have a parameter for this. David, is it possible to implement? -- Serguei Trouchelle
Re: Dig The New Breed
Barbie wrote: http://use.perl.org/~barbie/journal/39031 Excellent! -- Serguei Trouchelle
Re: I Want to Believe in the CPAN (was Re: cpantesters - why exit(0)?)
Gabor Szabo wrote: Maybe there should be more possible report values? FAIL and PASS can be kept for when the actual tests fail or pass but there should be also MAKE_FAIL fr when the make phase failes MAKEPL_FAIL fails when Makefile.PL exits with error code As far as I understand, main purpose of PASS/FAIL is to see if module runs on some architectures/version or not. MAKE_FAIL and MAKEPL_FAIL make sense for author but not for average CPAN user. And author can be informed about failing stage without changing FAIL grade to something else. and I leave it open to the discussion what to do when Makefile.PL exits with 0 but there is no Makefile ? exit 0 is a way to avoid sending a report. I think it's OK to leave it as is. -- S.T.
Re: [SPAM] Re: Idea for a smoke setup: read-only home directory
David Cantrell wrote:
There also seem to be some things in ~/tmp/
That's on linux. It's worse on Win32. Lots of stuff winds up dumped
in c:\. In one case, I think there were several thousand tiny
directories.
On *nix I periodically clean out several hundred files from /tmp.
I assume that they're created by File::Temp.
File::Temp::tempdir() makes a directory in $ENV{'TEMP'}, unless
explicitly specified, so it should be a module author's fault, not
File::Temp's.
--
Serguei Trouchelle
