Re: CPAN security improvements

[Alceu R. de Freitas Jr.]

 Great, thanks Slaven!

Em sexta-feira, 26 de abril de 2019 08:02:42 BRT, Slaven Rezic 
 escreveu:  
 
 
> Slaven Rezic  hat am 6. April 2019 um 10:14 geschrieben:
> 
> 
> > Andreas Koenig  hat am 6. April 
> > 2019 um 08:27 geschrieben:
> > 
> > 
> > > On Fri, 5 Apr 2019 23:32:11 -0300, Alceu Rodrigues de Freitas Junior 
> > > via cpan-testers-discuss  said:
> [...]
> > > 2 - Fix the PAUSE TLS certificate:
> > Do you get the same for pause.perl.org?
> 
> Regardless, it has to be fixed. Either get also a certificate for 
> pause.cpan.org through Let's Encrypt (and possibly for other CNAMEs), or, 
> maybe easier, setup a redirect from http://pause.cpan.org to 
> https://pause.perl.org, and disallow https on pause.cpan.org.
> 
> (Maybe a small task for the PTS?)

It's PTS right now, and we fixed the certificate problem with 
https://pause.cpan.org

Regards,
    Slaven
  

Re: time to update the CPAN Testers Matrix?

[Alceu R. de Freitas Jr.]

 In that case, makes much more sense to add the footnote and live with that. 
Changing $^O would be wrong as it is dependent on the value of something 
defined by the OS maintainer.
At least for now it is clear that I need to maintain "darwin" as a OS that 
supports Archive-Tar-Wrapper. But others can go into the wrong assumption in 
the future.

Em quarta-feira, 27 de março de 2019 21:37:14 BRT, Karen Etheridge 
 escreveu:  
 
 > we (well, p5p) should probably delete the entry in that list
> for Darwin (with a capital D) as it is potentially confusing

No, that's the value that's in use today in `uname -s` on OSX, as I
showed in my earlier reply.

On Wed, Mar 27, 2019 at 5:19 PM David Cantrell  wrote:
>
> On 2019-03-27 17:31, Karen Etheridge wrote:
> > Alceu,
> > I don't understand what you're asking. `$^O` returns 'darwin' on MacOS
> > systems. Are you suggesting that *that* be changed?
>
> He's saying that the CPAN-testers website should say "Mac OS X" instead
> of "Darwin", and ...
>
> >> It seems also that the official documentation should be updated regarding 
> >> Darwin/MacOSX as well: https://perldoc.perl.org/perlport.html#Unix.
>  > `perldoc perlport` is clear that $Config{archname} and $^O are derived
>  > from uname.
>
> It would obviously be silly to change the value of $^O for OS X at this
> stage, but we (well, p5p) should probably delete the entry in that list
> for Darwin (with a capital D) as it is potentially confusing. Open
> Darwin barely existed and has been dead for over a decade. I doubt that
> there is a single person actually using any vaguely recent perl on it.
>
> --
> David Cantrell | Enforcer, South London Linguistic Massive
>
> I think the most difficult moment that anyone could face is seeing
> their domestic servants, whether maid or drivers, run away
>    -- Abdul Rahman Al-Sheikh, writing on 25 Jan 2004 at
>      http://www.arabnews.com/node/243486
  

Re: time to update the CPAN Testers Matrix?

[Alceu R. de Freitas Jr.]

 I mean, the perl gave "darwin", but it should mean "macosx" or something like 
that.

We could suggest (I guess) to change that on the interpreter or to update the 
matrix at matrix.cpantesters.org. I think the later should be easier since 
"darwin" => "macosx" anyway.

Em quarta-feira, 27 de março de 2019 14:31:24 BRT, Karen Etheridge 
 escreveu:  
 
 Alceu,
I don't understand what you're asking. `$^O` returns 'darwin' on MacOS
systems. Are you suggesting that *that* be changed?

On Wed, Mar 27, 2019 at 7:08 AM Alceu R. de Freitas Jr. via
cpan-testers-discuss  wrote:
>
> Hello folks,
>
> I was having a little chat with David 
> (https://github.com/DrHyde/perl-modules-Devel-CheckOS/pull/22#issuecomment-477154904)
>  and looks like I was leaded into the wrong way by the "Darwin" appearing in 
> the CPAN Testers Matrix for a distribution (for example, 
> http://matrix.cpantesters.org/?dist=Archive-Tar-Wrapper+0.34). Shouldn't we 
> change that to MacOSX or something else? I'm not a MacOSX user myself, but it 
> seems I should list it as a acceptable OS for Archite-Tar-Wrapper.
>
> It seems also that the official documentation should be updated regarding 
> Darwin/MacOSX as well: https://perldoc.perl.org/perlport.html#Unix.
>
> Thanks,
>
> Alceu
>
>
>
>
>
>
>
>
>  

time to update the CPAN Testers Matrix?

[Alceu R. de Freitas Jr.]

Hello folks,
I was having a little chat with David 
(https://github.com/DrHyde/perl-modules-Devel-CheckOS/pull/22#issuecomment-477154904)
 and looks like I was leaded into the wrong way by the "Darwin" appearing in 
the CPAN Testers Matrix for a distribution (for example, 
http://matrix.cpantesters.org/?dist=Archive-Tar-Wrapper+0.34). Shouldn't we 
change that to MacOSX or something else? I'm not a MacOSX user myself, but it 
seems I should list it as a acceptable OS for Archite-Tar-Wrapper.

It seems also that the official documentation should be updated regarding 
Darwin/MacOSX as well: https://perldoc.perl.org/perlport.html#Unix.
Thanks,
Alceu

adding META.yml "provides" with ExtUtils::MakeMaker

[Alceu R. de Freitas Jr.]

Hello folks,
I'm looking for to add "provides" information to META.yml from 
Archive::Tar::Wrapper distribution, but without requiring Module::Build as a 
requirement.
I did basically a hack to ExtUtils::MakeMaker in order to do that, more details 
at https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/212
I'm not sure how reliable this would be, what do you think about it?
I'm all ears for different ideas too.
Best regards,
Alceu

CPAN::SQLite being downgraded on smokers

[Alceu R. de Freitas Jr.]

Hello folks,
Does anybody here experimenting the CPAN::SQLite being downgraded at some point?
Today was the third time in the past few days I got errors like this:
Smoker: testing Router-XS-0.02 [6736/38277] at Thu Feb  7 09:26:30 2019

Database was generated on Wed, 06 Feb 2019 12:45:44 GMT
Checksum for /minicpan/authors/id/D/DF/DFARRELL/Router-XS-0.02.tar.gz ok
DBD::SQLite::db prepare failed: no such column: chapterid at 
/home/vegeta/perl5/perlbrew/perls/perl-blead/lib/site_perl/5.29.8/CPAN/SQLite/DBI/Search.pm
 line 102.
DBD::SQLite::db prepare failed: no such column: chapterid at 
/home/vegeta/perl5/perlbrew/perls/perl-blead/lib/site_perl/5.29.8/CPAN/SQLite/DBI/Search.pm
 line 102.


Smoker: testing HPC-Runner-Command-3.2.3 [6737/38277] at Thu Feb  7 09:26:34 
2019

Database was generated on Wed, 06 Feb 2019 12:45:44 GMT
^C
Stopped during HPC-Runner-Command-3.2.3.

CPAN testing halted on SIGINT.  Continue (y/n)? [n]
Use of uninitialized value $answer in lc at 
/home/vegeta/perl5/perlbrew/perls/perl-blead/lib/site_perl/5.29.8/CPAN/Reporter/Smoker.pm
 line 317.
Lockfile removed.
-bash-4.4$
-bash-4.4$ mversion CPAN::SQLite
0.213
-bash-4.4$ cpan

cpan shell -- CPAN exploration and modules installation (v2.22)
Enter 'h' for help.

cpan[1]> o conf use_sqlite 0
    use_sqlite [0]
Please use 'o conf commit' to make the config permanent!


cpan[2]> o conf commit
commit: wrote '/home/vegeta/.cpan/CPAN/MyConfig.pm'

cpan[3]> q
Lockfile removed.
-bash-4.4$ cpan

cpan shell -- CPAN exploration and modules installation (v2.22)
Enter 'h' for help.

cpan[1]> install CPAN::SQLite
Reading '/home/vegeta/.cpan/Metadata'
  Database was generated on Fri, 25 Jan 2019 17:41:02 GMT
Reading '/minicpan/authors/01mailrc.txt.gz'
DONE
Reading '/minicpan/modules/02packages.details.txt.gz'
  Database was generated on Sun, 03 Feb 2019 21:17:03 GMT
DONE
Reading '/minicpan/modules/03modlist.data.gz'
DONE
Writing /home/vegeta/.cpan/Metadata
Running install for module 'CPAN::SQLite'
Checksum for /minicpan/authors/id/S/ST/STRO/CPAN-SQLite-0.217.tar.gz ok

Funy is that on my other smoker that didn't happen. I blacklisted the release 
0.213 of CPAN-SQLite on the smokers right now, but I wonder what is happening 
over there.
Thanks,
Alceu

new release of OpenBSD smoker

[Alceu R. de Freitas Jr.]

For those interested, I just released a new version of the CPAN Smoker for 
OpenBSD 6.4:
https://app.vagrantup.com/arfreitas/boxes/openbsd-6.4-cpan-smoker
Regards,Alceu

RE: socket based make server (was: First Time CPAN Testing on Windows)

[Alceu R. de Freitas Jr.]

> FWIW I wouldn't use a daemon like that, because I strive to make mytesting 
> environments as close as possible to those that ordinary usershave.

> -- David Cantrell | Official London Perl Mongers Bad Influence
Got it. But if you take in consideration that on Windows a variation of "make" 
is already distribuited with perl (at least for Strawberry), it does make 
sense. Besides, I think this is a specific problem with Windows, and maybe it 
would improve things with OpenBSD.

new Vagrant boxes for OpenBSD 6.3

[Alceu R. de Freitas Jr.]

Hello folks,
For those interested, I released a new Vagrant box for OpenBSD:

https://app.vagrantup.com/arfreitas/boxes/openbsd-6.3-cpan-smoker
Besides the OpenBSD version upgrade, the project now uses Packer to build the 
VM and install OpenBSD 6.3 automatically (pretty neat stuff!).
At this moment only Virtualbox is supported, but supporting other providers 
should be much easier now.
Regards,Alceu

Archive::Tar::Wrapper makes sense with MS Windows?

[Alceu R. de Freitas Jr.]

Hi again,

This report:

https://www.cpantesters.org/cpan/report/aa4f5cac-6e3a-1014-a899-817a51db77ab

Is about an error with MS Windows trying to run tar.exe:

2018/06/05 11:08:18 C:\WINDOWS\system32\tar.EXE jx -f 
C:\STRAWB~1\cpan\build\Archive-Tar-Wrapper-0.25-0\t\data\foo.tar.bz2 failed: 
tar.EXE: Error opening archive: Can't initialize filter; unable to run program 
"bzip2 -d"

Does it make any sense at all to try to make the distro to work with MS 
Windows? I'm not using Windows for a while already, so I'm not sure if the 
tar.exe can work together with bzip2 or not.

I could skip the tests (maybe with some explanatory message stating that the 
configuration is broken) but Archive::Tar::Wrapper would be broken anyway, at 
least when bzip2 is involved.

Thanks,
Alceu

"find a tester" not working?

[Alceu R. de Freitas Jr.]

Hello folks,
I'm trying to fetch the author for both reports below:
https://www.cpantesters.org/cpan/report/aa4f5cac-6e3a-1014-a899-817a51db77abhttps://www.cpantesters.org/cpan/report/1de885b4-687c-11e8-a021-da16591eefd3
At http://stats.cpantesters.org/cgi-bin/cpanmail.cgi and both are giving the 
message "Sorry, we were unable to retrieve that ID/GUID."
I'm using as ID the string right after the last slash (e.g. 
"1de885b4-687c-11e8-a021-da16591eefd3").
Thanks,
Alceu

standard configuration for CPAN build_dir

[Alceu R. de Freitas Jr.]

Hello folks,
Is there any kind of standards/recommendations about CPAN build_dir 
configuration regarding disk space available?
In order to speed things up on OpenBSD, I'm using a MFS filesystem which is 
allocated exclusively for build_dir. Of course, since it RAM, I don't have much 
space for it (~1G).
Even with an aggressive control of cache ("clean_cache_after => 50" for 
CPAN::Reporter::Smoker), in some situations I'm still getting all build_dir 
storage consumed, which of course cause reports to fail.
I was able to identify distributions that uses a lot of storage during it's 
build... not sure if they should look for a different filesystem (/tmp ?) in 
cases like that.
Another things is how to identify those distributions... is there any way to 
measure this?
Thanks!
Alceu

Re: news on CPAN-Smoker-OpenBSD

[Alceu R. de Freitas Jr.]

 Indeed Yary, we need more people running OpenBSD. It's basically me and Nigel 
nowadays and I'm getting tired of kicking some serious butt to the top of the 
"contest" (http://stats.cpantesters.org/leaders/leaders-openbsd-all.html) :-D

Just kidding... again, we should have more boxes running on OpenBSD too, if not 
for the OS sake, but also for the bugs detected over there.

After two years of project I may say that we got errors that were not being 
generated on other OS, specially with those distributions that use C and XS. As 
I'm not a C programmer myself (shame is on me, I guess), I can only guess that 
this is related to the way OpenBSD is more restricted about what is allowed or 
not.
I'm not seeing many other improvements opportunities to this project right now, 
but I'm considering extending the provisioning automation to other UNIX-like 
OSes. If it comes out right, maybe this project itself will lose it's meaning.

Em sábado, 31 de março de 2018 22:26:47 BRT, yary  
escreveu:  
 
 cool, thanks! OpenBSD needs some love- I'm not running any of those servers 
now but I do remember seeing some tests failing on that platform which passed 
on others back when I did a few years ago.
-y

On Sat, Mar 31, 2018 at 5:24 PM, Alceu Rodrigues de Freitas Junior via 
cpan-testers-discuss  wrote:

  
For those interested in running CPAN smokers on OpenBSD, I just merged changes 
on that project that allows to define an arbitrary number of users* inside the 
VM and define all options available to perlbrew to compile a new perl for those 
users (see perlbrew help install), all this inside the Vagrantfile.
 
Adding the options --noman and --notest with perlbrew to running the install 
with parallel, I was able to reduce provisioning time by about 30%. It should 
be simple to define different sets of configuration.
 
 
See https://github.com/ glasswalk3r/cpan-openbsd- smoker for more details.
 
Regards,
 
Alceu
 
 
* Just occurred to me that storage space might need to be extended in order to 
acommodate that too. Unless, of course, the cpan client is not configured to 
install the successfully tested distributions.
 
 

  

testing scripts inside your distro

[Alceu R. de Freitas Jr.]

Hello guys,
I'm in need to test some scripts inside one of my distributions and I'm bit 
tired of writing boilerplate code for doing it.

Maybe you could suggest something available on CPAN for that?

I took a look at Test-Script, but there are no evaluations about it yet.
Thanks!Alceu

OpenBSD smoker paid off...

[Alceu R. de Freitas Jr.]

https://github.com/perl5-dbi/DBD-mysql/issues/120#issuecomment-359835586
And looks like we now will have a fork from DBD::Mysql:
https://www.nntp.perl.org/group/perl.dbi.users/2018/01/msg37584.html
But Proc::Processtable seems to be still broken on OpenBSD. Here is a 
workaround:

https://github.com/perl5-dbi/DBD-mysql/pull/222
If any good soul over there would like to help me with XS/C code to fix it, 
please let me know.

Regards,Alceu

is QNX relevant to Perl?

[Alceu R. de Freitas Jr.]

Hello folks,
Is QNX relevant for Perl, considering is basically only applicable to 
BlackBerry... or I'm wrong?
I'm a bit curious about the OS, and saw that the number of tests executed under 
is really small compared to the rest:
http://stats.cpantesters.org/leaders/leaders-nto-all.html
Regards,
Alceu

Re: smoker and "Index version 1.93 required--this is only version 0.01" errors

[Alceu R. de Freitas Jr.]

 I guess it is time to choose a different package name for CPAN-Index... or 
maybe remove it from CPAN completely.

Em quarta-feira, 10 de janeiro de 2018 18:37:52 BRST, Slaven Rezic 
 escreveu:  
 
 See also https://rt.cpan.org/Ticket/Display.html?id=43349

Regards,
    Slaven

-- 
Slaven Rezic - slaven  rezic  de
  BBBike - route planner for cyclists in Berlin
  WWW version:                          http://www.bbbike.de
  Perl/Tk version for Unix and Windows:  http://bbbike.sourceforge.net
  

Re: smoker and "Index version 1.93 required--this is only version 0.01" errors

[Alceu R. de Freitas Jr.]

Hello Andreas,

Thanks for the compliments. But I guess that I didn't reach that milestone 
yet...

I had to manually delete CPAN/Index.pm because it was installed in my site_perl 
directory, so it didn't overwrite the CPAN distribution.

CPAN-Index is already blocked, things should run (kind of) smoothly by now.

Regards,

Alceu

Em quarta-feira, 10 de janeiro de 2018 18:35:05 BRST, Andreas Koenig 
<andreas.koenig.7os6v...@franz.ak.mind.de> escreveu: 

>>>>> On Wed, 10 Jan 2018 20:29:09 +0000 (UTC), "Alceu R. de Freitas Jr." via 
>>>>> cpan-testers-discuss <cpan-testers-discuss@perl.org> said:

  > Hello all,
  > I finally was able to get a smoker to go around the 37097 distribution
  > available on CPAN.

Congrats, I already noticed your achievement in the statics tables. Well
done!


  > Despite the personal milestone, I see those errors and I'm not sure if
  > it is a problem with the distribution itself (I believe it is the
  > later):

  > Smoker: testing lastlog.pm.gz [37095/37097] at Wed Jan 10 18:12:17
  > 2018

  > CPAN::Index version 1.93 required--this is only version 0.01 at
  > /home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line
  > 29.


You caught the flu. If you have CPAN::Index version 0.01 you have to
stop and reinstall CPAN.pm. CPAN.pm never had a CPAN::Index 0.01. Simply
overwrite it, verify you did so successful and continue.

And block ADAMK/CPAN-Index-0.01.tar.gz

Good luck,
-- 
andreas

smoker and "Index version 1.93 required--this is only version 0.01" errors

[Alceu R. de Freitas Jr.]

Hello all,
I finally was able to get a smoker to go around the 37097 distribution 
available on CPAN.Despite the personal milestone, I see those errors and I'm 
not sure if it is a problem with the distribution itself (I believe it is the 
later):

Smoker: testing lastlog.pm.gz [37095/37097] at Wed Jan 10 18:12:17 2018
CPAN::Index version 1.93 required--this is only version 0.01 at 
/home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line 29.
BEGIN failed--compilation aborted at 
/home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line 29.
Compilation failed in require.
BEGIN failed--compilation aborted.


Smoker: testing TimeOut.pm.gz [37096/37097] at Wed Jan 10 18:12:18 2018

CPAN::Index version 1.93 required--this is only version 0.01 at 
/home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line 29.
BEGIN failed--compilation aborted at 
/home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line 29.
Compilation failed in require.
BEGIN failed--compilation aborted.


Smoker: testing CORBA-IDLtree-1.6 [37097/37097] at Wed Jan 10 18:12:18 2018

CPAN::Index version 1.93 required--this is only version 0.01 at 
/home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line 29.
BEGIN failed--compilation aborted at 
/home/vegeta/perl5/perlbrew/perls/perl-5.27.6/lib/5.27.6/CPAN.pm line 29.
Compilation failed in require.
BEGIN failed--compilation aborted.

If the problem lies with the distribution, maybe I should "blacklist" them in 
the distroprefs?
Thanks,Alceu

new Vagrant box for OpenBSD 6.2

[Alceu R. de Freitas Jr.]

For those interested, I finally released a Vagrant box for running a CPAN 
Smoker on OpenBSD 6.2:
https://app.vagrantup.com/arfreitas/boxes/openbsd-6.2-cpan-smoker
Regards,Alceu

new release of CPAN::Reporter::Smoker over OpenBSD

[Alceu R. de Freitas Jr.]

For those inclined in running a smoker over OpenBSD, I released both a new box 
for OpenBSD 6.1 and updated the provisioning scripts on Github as well.
Besides the newer version of OpenBSD (I still have to work on 6.2), this 
release allows usage of a local CPAN mirror (and the optional creation of one 
inside the VM, which improves substantially the provisioning if disabled), much 
smaller Vangrant box and using "perl-stable" and "perl-blead" as entries to 
fetch the newest releases of perl.
Details are available at https://github.com/glasswalk3r/cpan-openbsd-smoker.
Cheers,Alceu

Re: More submission woes

[Alceu R. de Freitas Jr.]

 Submission from metabase-relayd also give some more info on that:
Submit 'EMdljmvQ5xGUeWU5uJWrTQ==' (1.11863589286804s) error: fact submission 
failed


  
    Server error (development mode)
    
    
    
    
    
    

getting errors from Varnish during submissions to metabase

[Alceu R. de Freitas Jr.]

Hello folks,
Are you too getting errors when trying to submit reports to the metabase 
server? In getting those for all requests:
Submit 'kKoXalLQ5xGOZ/LiuJWrTQ==' (1.05785799026489s) error: fact submission 
failed


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>

  
    503 No healthy backends
  
  
    Error 503 No healthy backends
    No healthy backends
    Guru Mediation:
    Details: cache-gru17129-GRU 1511448756 3282637873
    
    Varnish cache server
  


Thanks!Alceu

Re: reports flowing?

[Alceu R. de Freitas Jr.]

Hello Peter,
The process is still running, but taking longer than the expected. CPU usage 
seems to be high, I'm trying to check it out with Doug.
Alceu

  De: Peter Karman 
 Para: cpan-testers-discuss@perl.org 
 Enviadas: Quarta-feira, 5 de Abril de 2017 11:10
 Assunto: reports flowing?
   
This is just a sanity check.

I notice that http://www.cpantesters.org/ says the last report was 2017-03-30.

I had been checking this page
http://matrix.cpantesters.org/?dist=SWISH-3+1.15
for several days since I first uploaded that version and I am not seeing any 
test reports.

Are things just moving more slowly these days?

-- 
Peter Karman  .  https://karpet.github.io  .  https://keybase.io/peterkarman


   

Re: np updates from submissions at http://stats.cpantesters.org?

[Alceu R. de Freitas Jr.]

Hello Doug,
Send me the details on private, I'll take a look (but can't make promises 
besides trying and reporting progress back to you).
Regards,Alceu

  De: Doug Bell <d...@preaction.me>
 Para: Alceu R. de Freitas Jr. <glasswal...@yahoo.com.br> 
Cc: CPAN Testers Discuss <cpan-testers-discuss@perl.org>
 Enviadas: Domingo, 19 de Março de 2017 22:10
 Assunto: Re: np updates from submissions at http://stats.cpantesters.org?
   
The statistics sites have been down for quite some time, and I've had no tuits 
with which to fix them (since there are other things that require more urgent 
attention). If anyone wishes to volunteer to see what's going wrong here, I can 
provide them with a login (and, once a potential culprit is found, sudo access).
Doug belld...@preaction.me



On Mar 19, 2017, at 12:36 PM, Alceu R. de Freitas Jr. via cpan-testers-discuss 
<cpan-testers-discuss@perl.org> wrote:
Hello folks,
I submitted some tests from my OpenBSD smoker this last week, but so far I 
didn't see any update regarding them on 
http://stats.cpantesters.org/leaders/leaders-openbsd-all.html.
I double checked on http://stats.cpantesters.org/leaders/leaders-linux-all.html 
and there is nothing too for 2017, and I'm sure I at least updated my local 
perls this year more than once.
Is it having some kind of general issue, or it is related to my id?
Thanks,
Alceu









   

np updates from submissions at http://stats.cpantesters.org?

[Alceu R. de Freitas Jr.]

Hello folks,
I submitted some tests from my OpenBSD smoker this last week, but so far I 
didn't see any update regarding them on 
http://stats.cpantesters.org/leaders/leaders-openbsd-all.html.
I double checked on http://stats.cpantesters.org/leaders/leaders-linux-all.html 
and there is nothing too for 2017, and I'm sure I at least updated my local 
perls this year more than once.
Is it having some kind of general issue, or it is related to my id?
Thanks,
Alceu

smoker urllist not being respected

[Alceu R. de Freitas Jr.]

Hello folks,
I just noticed that some modules on my minicpan are missing and when that 
happens the CPAN::Reporter::Smoker tries to fetch those modules from 
www.cpan.org, even though this URL is not listed in the urllist parameter 
anymore (just the minicpan, nothing else).
Is this expected? Is there any way to change this behavior? The client will not 
be connected to the internet every time so it doesn't make sense even to try 
http://www.cpan.org./
Thanks,Alceu

Re: metabase does not accept new reports

[Alceu R. de Freitas Jr.]

I can confirm the error, got the same thing here.


 
  De: Slaven Rezic 
 Para: David Golden  
Cc: CPAN Testers Discuss 
 Enviadas: Domingo, 20 de Novembro de 2016 13:13
 Assunto: metabase does not accept new reports
   
metabase is full again:

fact submission failed: submission was not stored: Too many bytes in this Domain

Last report was stored at 2016-11-20T14:50:25Z.

-- 
Slaven Rezic - slaven  rezic  de
  BBBike - route planner for cyclists in Berlin
  WWW version:                          http://www.bbbike.de
  Perl/Tk version for Unix and Windows:  http://bbbike.sourceforge.net


   
 

Re: Test system configurations

[Alceu R. de Freitas Jr.]

Joel++
Didn't know about that, very interesting. The tradeoff is not being able to use 
newer versions of OpenSSL (and probably missing new features because of it).

 
  De: Joel Maslak 
 Para: CPAN Testers Discuss  
 Enviadas: Terça-feira, 11 de Outubro de 2016 13:36
 Assunto: Re: Test system configurations
   
On Tue, Oct 11, 2016 at 9:39 AM, Timothe Litt  wrote:

  On 11-Oct-16 11:14, Dan Collins wrote:
  
  But other modules may work fine with these older versions of the library.   
 Yes, though versions with missing security patches seems like a very bad idea 
for all concerned.

Are these Red Hat or CentOS machines?  If so, having .9.8 versions don't 
necessarily mean they have security bugs.

Red Hat Enterprise Linux has a philosophy of not changing the API of libraries 
during the life of a major version.  I.E. code that linked against libraries in 
RHEL 5.0 should link against 5.8.  They backport security patches from new 
versions to the old version, but don't backport most features.  Thus even 
though RHEL 5 machines might be running ".9.8e" (hopefully -40), they will have 
the critical security patches - even though OpenSSL officially doesn't have 
them in .9.8e.
RHEL 5 will have end of production support by Red Hat on Mar 31, 2017.  
Extended support is available until Nov 30, 2020.

As much as this sucks, I'd urge people to consider that RHEL is often chosen 
because it has this incredibly long support with stable APIs, with Red Hat 
backporting security fixes to those ancient versions of libraries.  Basically 
people use it because their binaries will work unchanged for 10+ years. 

FWIW:

RHEL 5 will have .9.8e versions of OpenSSL with security patches backported if 
people keep the box updated.  Red Hat will support these machines until 2020.

RHEL 6 will have 1.0.1e versions and Red Hat will support these until sometime 
after 2020 (probably +3 or +4 years after, at least).


   
 

Re: Test system configurations

[Alceu R. de Freitas Jr.]

I think you can safely use the Makefile.PL to decide if the current OpenSSL 
available has the minimum expected interface and cause a "NA" in the case it 
doesn't.
You can generate a "NA" with die() on the Makefile.PL. One good example of that 
is Devel::CheckOS.
If you add to that the declaration of minimum version of OpenSSL, I think 
you'll be OK.
OpenSSL is a project that has known problems and a lot of people depend on it. 
Not sure if the OpenBSD's replacement LibreSSL will be able to replace it on 
the future, but I think that would be great.

 
  De: Timothe Litt 
 Para: "cpan-testers-discuss@perl.org"  
 Enviadas: Terça-feira, 11 de Outubro de 2016 12:39
 Assunto: Re: Test system configurations
   
 On 11-Oct-16 11:14, Dan Collins wrote:
  
  But other modules may work fine with these older versions of the library.   
 Yes, though versions with missing security patches seems like a very bad idea 
for all concerned.
 
  And, without testers reporting these failures, you wouldn't know that 
Crypt::PKCS10 is failing on those platforms!  
 It's not failing. An unspecifiable prerequisite isn't being met :-) Seriously, 
if it's not met, I don't want to know - though as a good citizen I think the 
machine should run safer software.  And I greatly appreciate test coverage.
 
 
  I suspect that you want to probe for the OpenSSL version at the Makefile.PL 
stage, and if there is an insufficient version, fail there. This will prompt 
real  users to upgrade to a supported version (be sure that the message shows 
what version of which library you require, and ideally, explains why), and it 
will cause CPAN testers to report either NA (which means we couldn't test your 
distribution) or not at all, instead of reporting FAIL. 
   
 I didn't know that's how to produce an NA.  Thanks.
 
 It's not trivial to do this as the dependency is one level down, OpenSSL has 
multiple streams and an unusual version numbering scheme.  About all I can do 
is try a higher level function that's sensitive to this, and if it fails 
'assume' that it's a version issue.
 
 A better fix would be for the module that I call, which are closer to OpenSSL, 
to complain... I can submit a bug for that.  But they'll have the same 
challenges.  And they may want to work with old versions for some unfathomable 
reason...
 
 
  CPAN Testers machines are operated by many different users, including both 
Smokers (which run automated testing) and regular users (which send reports of  
distributions they install manually). It isn't practical to require a set of 
ever-changing minimum library versions, especially given the many different 
platforms in use. Instead, I suggest you inspect similar distributions for a 
way to bail out at the Makefile.PL stage on unsupported OSes, or with 
unsupported library versions. 
   
 I do understand the general problem.  However, strongly encouraging the 
Smokers to be up-to-date with security-related software seems sensible.  And 
however difficult the problem is for CPAN Testers, it's worse for every module 
to do its own thing.
 
 I would welcome suggestions of which distributions are 'similar'.
 
 
  Regards, Dan Collins 
  
  
  
 On Tue, Oct 11, 2016 at 10:58 AM, Timothe Litt  wrote:
 
  Recently, I released a CPAN module (Crypt::PKCS10 v1.7/8) that uses modules 
which depend on OpenSSL. I've seen quite a few test failures (11 on v1.8) from 
systems that are running OpenSSL version 9.8.something. That version, and 1.0.0 
stream are out of support, have security issues, and should not be run by any 
production site.  So I consider the test failures invalid.
  This raises two questions:
   - What versions of system libraries should the test pools have?  I think 
it's reasonable and desirable to run old OS versions, as they exist in the 
wild.  (I even run some...)  But where serious security issues exist and the 
library is upgradable independent of the OS, I think that those upgrades  (and 
all security patches) should be required.
   - Is there a way specify requirements like this as prerequisites?  In my 
case, I depend on Crypt::OpenSSL::{RSA,DSA}.  These aren't my modules.  But 
even if they were, they will build against the old libraries and keep working 
without rebuilding indefinitely.  And the version of OpenSSL is independent of 
the version of any module that calls it... CPAN::Meta::Spec doesn't seem to 
address  this scenario.   

 I could try to check for a reasonable version in my tests - but they'd still 
fail.  My current approach is to attempt to print out the OpenSSL version, so 
at least it's easy to diagnose the problem.   

 But 'reasonable version' is a moving target, and really should gate the 
install, not the test...   

 I could exit with "Pass", but that would be a lie.   
 
 http://wiki.cpantesters.org/wi ki/SmokeTesting says:
 
Provide a update version of OpenSSL development files. That 

CPAN-Testers wiki update (OpenBSD and more)

[Alceu R. de Freitas Jr.]

Hi again,
I finally took some time to add my notes about setting up a smoker on OpenBSD. 
Since I was already there, I updated some other pages as well:
http://wiki.cpantesters.org/wiki/TipsAndTricks
http://wiki.cpantesters.org/wiki/CPANReporterSmokerFaster
http://wiki.cpantesters.org/wiki/MetabaseRelayd
http://wiki.cpantesters.org/wiki/SmokeTesting
http://wiki.cpantesters.org/wiki/SmokerOnOpenBSD

Cheers,Alceu

suggestion for Bundle::CPAN::Reporter::Smoker::Tests

[Alceu R. de Freitas Jr.]

Hello all,
I uploaded Bundle::CPAN::Reporter::Smoker::Tests some time ago to PAUSE with 
the objective of grouping the most used tests and make them available to a 
smoker.
Being not a easy task at all to select which I should include/remove from, I 
would to know if any of you would have any suggestions.
Thanks,
Alceu

metabase-relayd on OpenBSD 5.9

[Alceu R. de Freitas Jr.]

Hello all,
Are any of you using metabase-relayd for smoker tests submission?
I see it particular difficult to install it on OpenBSD... I had to manually 
resolve dependencies, and the following modules were particular problematic:
- POE::XS::Loop::Poll -> doesn't install from the CPAN shell (don't generate 
the Makefile) but it works from the bash shell. I opened a RT ticket for it.- 
POE::Component::SSLify -> it fails the tests, I believe due incompatibilities 
with Net::SSLeay/LibreSSL interfaces. A workaround is to force its install and 
disable HTTPS usage by metabase-relayd by changing the configuration 
fromurl=https://metabase.cpantesters.org/beta/

To

url=http://metabase.cpantesters.org/beta/

Re: Your smoke testing reports

[Alceu R. de Freitas Jr.]

Hello Karen,
I'm glad it worked. My smoker is using metabase-relayd to send the results, 
which I save first to the filesystem. This gives me opportunity to review tests.
For those interested, I wrote a simple script to send only the tests with PASS 
result to metabase-relayd. The code (and my distro prefs) are located in github:
https://github.com/glasswalk3r/CPAN-Reporter-Smoker

The script still needs some adjustments to command line arguments, but it works 
well enough.
My smoker machine is actually running two smokers, one with the standard perl 
of OpenBSD 5.9 (5.20.2) and the other with a specific user compiled (5.20.3) 
with perlbrew. Results so far are the same for Sub::Name (0.20) and Moose.

Please let me know if any of you guys find something wrong with my reports... I 
don't mind going over and finding the issue.

 
  De: Karen Etheridge 
 Para: Alceu Rodrigues de Freitas Junior  
Cc: CPAN Testers Discuss 
 Enviadas: Domingo, 11 de Setembro de 2016 22:42
 Assunto: Re: Your smoke testing reports
   
> Anyway, Sub::Name passed all the tests.

Awesome, thank you!

> I'll keep the smoker shutdown... when you release an official Sub::Name
new version, I'll try again from the cpan shell. If it is all good, I'll
turn on the smoker again, although I'm thinking about implementing
something to send only the PASSed reports, which would give a change to
review those that failed.

All that sounds fine, except you can turn on the smoker now... It would be
nice to see some test coverage using the trial release before it goes
stable.

> Is it possible to provide a list of the (tested) distro directory content
to the report? That would help making sure the test failed with a core dump

I don't know if it's possible to run an arbitrary command after smoking a
module -- anyone?


On Sun, Sep 11, 2016 at 6:25 PM, Alceu Rodrigues de Freitas Junior via 
cpan-testers-discuss  wrote:

Em 09-09-2016 13:04, Karen Etheridge escreveu:

Alceu, would it be possible for you to test the patch in
https://rt.cpan.org/Ticket/Dis play.html?id=117072 ?  (You don't have to
do anything with git; just applying the patch to the latest CPAN release
should work fine, and then perl Makefile.PL && make test && make install).

(I wonder if this is the sources of all the segfaults I've been seeing
from BinGOs's FreeBSD smokers as well...)

If this looks good, I'll release it as -TRIAL.  thanks so much!



Looks like I got into this a little bit late, I saw that you're already release 
Sub::Name as trial, so I grabbed it from CPAN.

I was able to install it but not from the CPAN shell, I did it directly from 
bash. Keep in mind that the previous release I was able to install all from 
bash, but not from the CPAN shell.

Anyway, Sub::Name passed all the tests. I went through all the reports from me 
that you requested a review and I was able to install all of them (I sent some, 
but not all, reports, for those not yet tested).

I'll keep the smoker shutdown... when you release an official Sub::Name new 
version, I'll try again from the cpan shell. If it is all good, I'll turn on 
the smoker again, although I'm thinking about implementing something to send 
only the PASSed reports, which would give a change to review those that failed.

Is it possible to provide a list of the (tested) distro directory content to 
the report? That would help making sure the test failed with a core dump.




   
 

Re: Your smoke testing reports

[Alceu R. de Freitas Jr.]

Hello Dan,
This information is on the report I sent below (Karen post). The backtrace 
looks like the same I got from trying to test Moose.

 
  De: Dan Collins 
 Para: CPAN Testers Discuss  
 Enviadas: Sexta-feira, 9 de Setembro de 2016 1:27
 Assunto: Re: Your smoke testing reports
   
Have you considered using Valgrind or GDB to locate the source of the SEGV? Is 
it always the same line of code? Does Sub::Name's test suite always fail after 
the exact same test, or is it intermittent/variable? 


On Thu, Sep 8, 2016 at 10:59 PM, Karen Etheridge  wrote:

Here is that Sub-Name report: http://www.cpantesters.org/ 
cpan/report/3a995cce-760c- 11e6-a32c-cd9de3776ab1

On Thu, Sep 8, 2016 at 2:48 PM, Alceu Rodrigues de Freitas Junior via 
cpan-testers-discuss  wrote:

I checked all those reports and despite the "BSD" part, I don't see much that 
can be related that they have in common. There are different configurations of 
perl (some with ithreads, others without it) and SO versions. Also, all have in 
common this failure (but not always for the same tests):

   Non-zero wait status: 139
   Parse errors: No plan found in TAP output

One thing that is not easy to detected is if those system are running under 
virtualization or not (maybe we could add this to reports as static 
information?). My newest OpenBSD was a VM running on Virtualbox 5 and the host 
Microsoft Windows 7.

My older VM was also running on Virtualbox, but under Linux and version 4.3.36. 
You can check the PASS report here: http://www.cpantesters.org/cpa 
n/report/20aa9630-7430-11e6-a7 54-2713ddf53d17

I'm don't know about the other BSD OSes, but OpenBSD hasn't a good reputation 
on VMs, but I never was able to confirm an issue with Virtualbox.

After my first success on installing Moose, I took a chance to upgrade all 
installed modules. After that, I manually checked the reports and see that 
there was a failure with Sub::Name. Since Moose was already at the latest 
version, nothing was executed related to it.

I tried to manually install Sub::Name from the CPAN shell. It failed due a core 
dump. Since I was saving the reports on disk, I manually included information 
to the report and submit it. I'm not sure if this will work, but let me know if 
doesn't, I have a copy and can send it by e-mail in private (or to the group if 
it accepts text attachments).

The interesting part is that I did "look Sub::Name" after the failure, execute 
"make clean" and repeat all the process for test it again... and it passed all 
tests and got installed.

Went back again to install Moose... I couldn't even pass the Makefile.PL step. 
It fails and generates a large core dump on the VM.

So, my guess is that we have something wrong with Sub::Name.

Em 06-09-2016 16:31, Karen Etheridge escreveu:

I don't know if this is helpful, but I've been seeing widespread issues
with FreeBSD and NetBSD as well lately.  I've been receiving a lot of
FAIL reports containing segmentation faults from FreeBSD and NetBSD that
look similar to the OpenBSD issues, for example:

FreeBSD (BinGOs):
http://www.cpantesters.org/cpa n/report/eef9bd38-6704-11e6-ab 41-c893a58a4b8c
http://www.cpantesters.org/cpa n/report/8665c62c-73c0-11e6-88 07-814d1da4c10f

NetBSD (Nigel Horne):
http://www.cpantesters.org/cpa n/report/8d46746e-73b1-11e6-b8 50-10220ec14a5e
http://www.cpantesters.org/cpa n/report/42d3ed70-73ad-11e6-b8 50-10220ec14a5e
http://www.cpantesters.org/cpa n/report/ae162bf6-73ae-11e6-b8 50-10220ec14a5e
http://www.cpantesters.org/cpa n/report/3ec4326c-73ad-11e6-b8 50-10220ec14a5e
http://www.cpantesters.org/cpa n/report/98868544-73b1-11e6-b8 50-10220ec14a5e
http://www.cpantesters.org/cpa n/report/a34aa63c-73b0-11e6-b8 50-10220ec14a5e









   
 

Re: Your smoke testing reports

[Alceu R. de Freitas Jr.]

I'm still trying to test and eliminate the possibilities.
I discarded my previous OpenBSD VM and took an older one to validate if I could 
install Moose on it. All tests passed, you will get the report because I 
submitted it.
Today I created a new VM from scratch on OpenBSD 5.9. My first attempted with 
default perl and local::lib failed all the tests with a generated core dump. 
I'm still to tests with a custom perl installed through perlbrew (it fails a 
hash test during the test phase, but I think it's harmless, see my post on 
OpenBSD for details). I also submitted this test.

What was different from my brand new VM and the older one (where the tests 
succeeded)? Well, I didn't upgrade all the modules installed using "cpan -u" 
before trying to install a new version of Moose.
I'll let you know if I find something new.

 
  De: Karen Etheridge <p...@froods.org>
 Para: Alceu R. de Freitas Jr. <glasswal...@yahoo.com.br> 
Cc: Alceu R. de Freitas Jr. via cpan-testers-discuss 
<cpan-testers-discuss@perl.org>
 Enviadas: Terça-feira, 6 de Setembro de 2016 16:31
 Assunto: Re: Your smoke testing reports
   
I don't know if this is helpful, but I've been seeing widespread issues with 
FreeBSD and NetBSD as well lately.  I've been receiving a lot of FAIL reports 
containing segmentation faults from FreeBSD and NetBSD that look similar to the 
OpenBSD issues, for example:

FreeBSD (BinGOs):
http://www.cpantesters.org/cpan/report/eef9bd38-6704-11e6-ab41-c893a58a4b8c
http://www.cpantesters.org/cpan/report/8665c62c-73c0-11e6-8807-814d1da4c10f

NetBSD (Nigel Horne):
http://www.cpantesters.org/cpan/report/8d46746e-73b1-11e6-b850-10220ec14a5e
http://www.cpantesters.org/cpan/report/42d3ed70-73ad-11e6-b850-10220ec14a5e
http://www.cpantesters.org/cpan/report/ae162bf6-73ae-11e6-b850-10220ec14a5e
http://www.cpantesters.org/cpan/report/3ec4326c-73ad-11e6-b850-10220ec14a5e
http://www.cpantesters.org/cpan/report/98868544-73b1-11e6-b850-10220ec14a5e
http://www.cpantesters.org/cpan/report/a34aa63c-73b0-11e6-b850-10220ec14a5e




On Sun, Sep 4, 2016 at 8:31 AM, Alceu R. de Freitas Jr. via 
cpan-testers-discuss <cpan-testers-discuss@perl.org> wrote:

Hello Slaven,
It is a possibility that the default perl on OpenBSD is causing the issues.
I won't say that is heavily patched, but there is obviously differences from 
standard interpreter. In initial attempts with OpenBSD (5.8) I found that that 
I was unable to compile any perl with perlbrew since all of them failed the 
tests. In this thread here: installation of Perl on OpenBSD 5.8 with perlbrew 
fails due crypt.h there are more details about that.
|   |
|   |  |   |   |   |   |   |
| installation of Perl on OpenBSD 5.8 with perlbrew fails ...Hi there,My name 
is Alceu and I'm a newbie with OpenBSD. I hope I reached the right mailing list 
to ask about compiling Perl with perlbrew on OpenBSD. Advertisin... |
|  |
| Visualizar em www.mail-archiv... | Visualizado por Yahoo |
|  |
|   |


Of course I can try to compile the interpreter without perlbrew, but that leads 
to the questions: are we looking for to validate CPAN modules against the 
interpreter shipped with OpenBSD or the standard perl?

 
  De: Slaven Rezic <sla...@rezic.de>
 Para: Alceu R. de Freitas Jr. via cpan-testers-discuss 
<cpan-testers-discuss@perl.org > 
Cc: Karen Etheridge <p...@froods.org>; Alceu R. de Freitas Jr. 
<glasswal...@yahoo.com.br>
 Enviadas: Domingo, 4 de Setembro de 2016 12:11
 Assunto: Re: Your smoke testing reports
   
Hi Alceu,

it looks like you're using OpenBSD's system perl (PERL=/usr/bin/perl
appears in the reports). A possibility is that this perl is heavily
patched and now broken for even simple things like reading a META.yml
file. If this is the case, then it would be good to find out, maybe with
the help of the OpenBSD guys.

Maybe the reports would be better if you would compile perl yourself?

As for checking reports: I am doing this, at least the non-pass reports,
and have some scripts to help in this workflow. One of the scripts is
this one:
https://github.com/eserte/ srezic-misc/blob/master/ 
scripts/ctr_good_or_invalid.pl
I can give you assistance if you want to go this way (but it's still
time-consuming!).

Regards,
    Slaven
   
 



   
 

Re: Your smoke testing reports

[Alceu R. de Freitas Jr.]

Hello Slaven,
It is a possibility that the default perl on OpenBSD is causing the issues.
I won't say that is heavily patched, but there is obviously differences from 
standard interpreter. In initial attempts with OpenBSD (5.8) I found that that 
I was unable to compile any perl with perlbrew since all of them failed the 
tests. In this thread here: installation of Perl on OpenBSD 5.8 with perlbrew 
fails due crypt.h there are more details about that.
|   |
|   |  |   |   |   |   |   |
| installation of Perl on OpenBSD 5.8 with perlbrew fails ...Hi there,My name 
is Alceu and I'm a newbie with OpenBSD. I hope I reached the right mailing list 
to ask about compiling Perl with perlbrew on OpenBSD. Advertisin... |
|  |
| Visualizar em www.mail-archiv... | Visualizado por Yahoo |
|  |
|   |


Of course I can try to compile the interpreter without perlbrew, but that leads 
to the questions: are we looking for to validate CPAN modules against the 
interpreter shipped with OpenBSD or the standard perl?

 
  De: Slaven Rezic <sla...@rezic.de>
 Para: Alceu R. de Freitas Jr. via cpan-testers-discuss 
<cpan-testers-discuss@perl.org> 
Cc: Karen Etheridge <p...@froods.org>; Alceu R. de Freitas Jr. 
<glasswal...@yahoo.com.br>
 Enviadas: Domingo, 4 de Setembro de 2016 12:11
 Assunto: Re: Your smoke testing reports
   
Hi Alceu,

it looks like you're using OpenBSD's system perl (PERL=/usr/bin/perl
appears in the reports). A possibility is that this perl is heavily
patched and now broken for even simple things like reading a META.yml
file. If this is the case, then it would be good to find out, maybe with
the help of the OpenBSD guys.

Maybe the reports would be better if you would compile perl yourself?

As for checking reports: I am doing this, at least the non-pass reports,
and have some scripts to help in this workflow. One of the scripts is
this one:
https://github.com/eserte/srezic-misc/blob/master/scripts/ctr_good_or_invalid.pl
I can give you assistance if you want to go this way (but it's still
time-consuming!).

Regards,
    Slaven
   
 

Re: Your smoke testing reports

[Alceu R. de Freitas Jr.]

Thanks Kent.
I think it is frustrating for everybody: I can't imagine anyone that would run 
on to all the troubles to configure a smoker only to generate garbage instead 
of reliable tests.

There were days that this smoker was generating ~500 reports. As I stated 
before, it would be quite easily to know something was fishy if I got ~90% of 
them indicating failure, but that's not the reality.

I could also check aleatory samples of the reports to check. What would 
indicate that reports with failures are presenting problems due smoker issues? 
Let's use this report from Karen as an example: 
http://www.cpantesters.org/cpan/report/70299f0a-4f8f-11e6-af52-86b6688db7f4.

The only thing that comes to my mind is check for core files, since it seems 
all that are failing on the smoker are generating core dumps. That includes 
Moose, for example.
I removed everything under the non-root user home directory and started over 
again.

I'm using the standard perl from OpenBSD 5.9 and local::lib, which is the only 
thing I see that is unusual compared to all other smokers I have created in the 
past.
All other things seems to be OpenBSD specifics, like using a MFS partition for 
the build_dir option on CPAN, which in fact leads me to ask what the report 
shows that @INC includes paths from there, considering that I configured CPAN 
to install everything that is required/recommended as passes the tests:  @INC:
/var/cpan/MooseX-UndefTolerant-0.20-0/blib/arch
/var/cpan/MooseX-UndefTolerant-0.20-0/blib/lib
/home/arfreitas/perl5/lib/perl5/5.20.2/amd64-openbsd
/home/arfreitas/perl5/lib/perl5/5.20.2
/home/arfreitas/perl5/lib/perl5/amd64-openbsd
/home/arfreitas/perl5/lib/perl5
/usr/local/libdata/perl5/site_perl/amd64-openbsd
/usr/libdata/perl5/site_perl/amd64-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/site_perl
/usr/libdata/perl5/amd64-openbsd/5.20.2
/usr/local/libdata/perl5/amd64-openbsd/5.20.2
/usr/libdata/perl5
/usr/local/libdata/perl5
. 
I can share my notes about smoker preparation if you're willing to check.
 
  De: Kent Fredric <kentfred...@gmail.com>
 Para: Alceu R. de Freitas Jr. <glasswal...@yahoo.com.br> 
Cc: Karen Etheridge <p...@froods.org>; Alceu R. de Freitas Jr. via 
Cpan-testers-discuss <cpan-testers-discuss@perl.org>
 Enviadas: Sábado, 3 de Setembro de 2016 22:47
 Assunto: Re: Your smoke testing reports
   
On 4 September 2016 at 11:39, Alceu R. de Freitas Jr. via
cpan-testers-discuss <cpan-testers-discuss@perl.org> wrote:
>
> I'm willing to fix the smoker as long as I got a positive feedback (like
> yours). On the other hand, "turn off your smoker or block my id" hardly
> qualifies as positive.
Smokers of all kinds I just want to say I appreciate.

But I really do also understand the frustration of having to wade
through lots of reports from smoke boxes that turn out to be problems
outside a scope I can even diagnose, be they tooling bugs or smoker
misconfiguration.

I guess there's some kind of (perhaps unwarrented) expectation that
people running smoke boxes should keep an eye on what they're sending
to eliminate cases that are obviously "their problem".

But eh, I don't know how viable that is for everyone.

There's just a shortage of tools that help us here that don't turn
into pain for somebody.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL


   
 

Re: Your smoke testing reports

[Alceu R. de Freitas Jr.]

Hello Karen,
Thanks for the feedback.
My smoker uses a minicpan mirror, but somehow the CPAN client kept the indexes 
outdated and was not refreshing from the mirror, even though I was updating 
(the mirror) from time to time. After checking it, even "upgrade" from the CPAN 
stopped working as supposed (trace show the error was coming from CPAN::SQLite, 
which was outdated).

I didn't notice any issue so far... I have a single OpenBSD smoker, it is 
months old and was not getting 100% failures for all distributions attempted. 
Its off now and I'm upgrading/reinstalling as errors come by and discarding the 
tests results. I'll keep an eye. I configured the smoker to install modules on 
success, which surely make this more complicated.

But I don't think its feasible to check all reports from time to time after I 
think its ready. Any tips on that would be appreciated. 

I'm willing to fix the smoker as long as I got a positive feedback (like 
yours). On the other hand, "turn off your smoker or block my id" hardly 
qualifies as positive.

 
  De: Karen Etheridge <p...@froods.org>
 Para: Karen Etheridge <p...@froods.org> 
Cc: Alceu R. de Freitas Jr. via Cpan-testers-discuss 
<cpan-testers-discuss@perl.org>; Alceu R. de Freitas Jr. 
<glasswal...@yahoo.com.br>
 Enviadas: Sábado, 3 de Setembro de 2016 20:13
 Assunto: Re: Your smoke testing reports
   
And here are some more, where a segmentation fault happened for no apparent 
reason:

http://www.cpantesters.org/cpan/report/70299f0a-4f8f-11e6-af52-86b6688db7f4
http://www.cpantesters.org/cpan/report/2e821c8e-6723-11e6-b00a-ef039efd898b
http://www.cpantesters.org/cpan/report/160e6f0c-4ee8-11e6-8ccd-ed0cba742ec1
http://www.cpantesters.org/cpan/report/fe12276a-4931-11e6-84ff-dfbf4e0f064e
http://www.cpantesters.org/cpan/report/fd165cd2-4931-11e6-84ff-dfbf4e0f064e
http://www.cpantesters.org/cpan/report/cdbcef6e-3f1d-11e6-a514-8183992ad5f0
http://www.cpantesters.org/cpan/report/cbb2b0c8-3f1d-11e6-a514-8183992ad5f0


On Sat, Sep 3, 2016 at 4:06 PM, Karen Etheridge <p...@froods.org> wrote:

Yes, I've received similar problematic reports from you, for example:

http://www.cpantesters.org/ cpan/report/f06f0a70-7095- 11e6-b0d4-db1a5d222160
http://www.cpantesters.org/ cpan/report/f066dbca-7095- 11e6-b0d4-db1a5d222160

I believe some testers check over all their reports before sending them; 
perhaps you could do this for a while as well, to be sure that the failure 
reports you are submitting are genuine as opposed to a misconfigured system?


On Sat, Sep 3, 2016 at 3:43 PM, Alceu R. de Freitas Jr. via 
cpan-testers-discuss <cpan-testers-discuss@perl.org > wrote:

Hello all,
I just receive this e-mail and would like to know if any of you share the same 
idea regarding my Smoker having issues, since most probably all of you are also 
contributors to CPAN.
Considering the results of OpenBSD Tester Leaderboard 
(http://stats.cpantesters.org/ leaders/leaders-openbsd-all.ht ml) nobody else 
is running a Smoker over OpenBSD.

Thanks,
Alceu

 
 
- Mensagem encaminhada -
 De: Peter Flanigan <no-re...@roxsoft.co.uk>
 Para: arfrei...@cpan.org 
 Enviadas: Sábado, 3 de Setembro de 2016 14:01
 Assunto: Your smoke testing reports
   
Alceu,

Please consider the following reports from your smoker

http://www.cpantesters.org/cpa n/report/efe5df0c-7095-11e6- b0d4-db1a5d222160

http://www.cpantesters.org/cpa n/report/f0892d4c-7095-11e6- b0d4-db1a5d222160

Your smoker has now reached the point where it cannot even
run the tool chain. Please either;

1. Take it offline (I know I'm not the only one who has
had issues with the reports your smoker generates) so
this would be a popular solution

2. Put my PAUSE id (pjfl) in your configuration to
prevent it from smoking any of my distributions

-- 

TIA


   
 





   
 

Enc: Your smoke testing reports

[Alceu R. de Freitas Jr.]

Hello all,
I just receive this e-mail and would like to know if any of you share the same 
idea regarding my Smoker having issues, since most probably all of you are also 
contributors to CPAN.
Considering the results of OpenBSD Tester Leaderboard 
(http://stats.cpantesters.org/leaders/leaders-openbsd-all.html) nobody else is 
running a Smoker over OpenBSD.

Thanks,
Alceu

 
 
- Mensagem encaminhada -
 De: Peter Flanigan 
 Para: arfrei...@cpan.org 
 Enviadas: Sábado, 3 de Setembro de 2016 14:01
 Assunto: Your smoke testing reports
   
Alceu,

Please consider the following reports from your smoker

http://www.cpantesters.org/cpan/report/efe5df0c-7095-11e6-b0d4-db1a5d222160

http://www.cpantesters.org/cpan/report/f0892d4c-7095-11e6-b0d4-db1a5d222160

Your smoker has now reached the point where it cannot even
run the tool chain. Please either;

1. Take it offline (I know I'm not the only one who has
had issues with the reports your smoker generates) so
this would be a popular solution

2. Put my PAUSE id (pjfl) in your configuration to
prevent it from smoking any of my distributions

-- 

TIA


   
 

Re: smoker gettting prompts from Module::AutoInstall

[Alceu R. de Freitas Jr.]

Thanks!
Actually I banned the Module-Install-RPM from the smoker... no sense to have 
RPM stuff on OpenBSD anyway.
But your reference is still valid, I probably may use it in the future.
By the way, is there any standard way to share those preference files?
I also ask myself if there is any way a CPAN author may known that his/her 
distribution was blocked because cause some kind of issue with a smoker. For 
example, it took me years to notice that MY Win32-SQLServer-DTS was disabled 
directly on CPAN distribution. :-)
I have myself disabled some distribution on OpenBSD, I'm willing to share that 
(probably on GitHub also).

Regards,
Alceu

 
  De: Andreas Koenig <andreas.koenig.7os6v...@franz.ak.mind.de>
 Para: Alceu R. de Freitas Jr. via cpan-testers-discuss 
<cpan-testers-discuss@perl.org> 
Cc: Alceu R. de Freitas Jr. <glasswal...@yahoo.com.br>
 Enviadas: Terça-feira, 16 de Agosto de 2016 14:09
 Assunto: Re: smoker gettting prompts from Module::AutoInstall
   
OK, I have refreshed my memory a bit and found my distroprefs file for
it:

  https://github.com/andk/cpanpm/blob/master/distroprefs/MI.yml

Apparently it always answers this question with RETURN.
   

Re: Errors in metabase delivery

[Alceu R. de Freitas Jr.]

Hi Slaven,
I have see that happening occasionally (maybe less then 10%), but I'm using 
metabase-relayd so I believe it's harmless since the report will be kept in the 
database until can be successfully sent.
Unfortunately metabase-relay seems to be broken regarding SSL support (due a 
dependency), but you can just change the address of metabase server from 
"https" to "http" and the right thing will be done.

 
  De: Ron Savage 
 Para: cpan-testers-discuss@perl.org 
 Enviadas: Segunda-feira, 18 de Julho de 2016 20:15
 Assunto: Re: Errors in metabase delivery
   
Hi Slaven

On 19/07/16 03:26, Slaven Rezic wrote:
> Hello,
>
> since a few days (approximately since Friday) I observe occasional
> failures (1 out of 10..20) while delivering reports to metabase:
>
>      Test::Reporter: error from 'Test::Reporter::Transport::Metabase:'
>      fact submission failed: Internal Exception at 
>/usr/perl5.22.1sp/lib/site_perl/5.22.1/Metabase/Client/Simple.pm line 129.
>              
>Metabase::Client::Simple::submit_fact(Metabase::Client::Simple=HASH(0x80480f828),
> CPAN::Testers::Report=HASH(0x804820d50)) called at 
>/usr/perl5.22.1sp/lib/site_perl/5.22.1/Test/Reporter/Transport/Metabase.pm 
>line 122
>              
>Test::Reporter::Transport::Metabase::send(Test::Reporter::Transport::Metabase=HASH(0x804b6c168),
> Test::Reporter=HASH(0x804823648)) called at 
>/usr/perl5.22.1sp/lib/site_perl/5.22.1/Test/Reporter.pm line 272
>              eval {...} called at 
>/usr/perl5.22.1sp/lib/site_perl/5.22.1/Test/Reporter.pm line 272
>              Test::Reporter::send(Test::Reporter=HASH(0x804823648)) called at 
>/home/e/eserte/devel/send_tr_reports.pl line 126
>
>      . Stop.
>
> Resending the failed reports usually works. Is it just me, or do others
> see similar problems?

I've never seen this one.

-- 
Ron Savage - savage.net.au


   

Re: Failing CPAN Testers reports and misconfigured smokers

[Alceu R. de Freitas Jr.]

I already had issues with some distribution by running Harness in parallel.I 
had it disabled after that.
The problem with blacklist/whitelist is that you need to do it yourself (or 
copy from somebody else) and the author will never know that his/her 
distribution test files don't support parallel tests. In some cases they might 
just not bother fixing but others are just unaware of it.
Is there any work already being done to have a central repository for such 
things?
Regards,
Alceu
 
  De: Slaven Rezic 
 Para: Ben Aveling  
Cc: cpan-testers-discuss@perl.org
 Enviadas: Domingo, 10 de Julho de 2016 10:24
 Assunto: Re: Failing CPAN Testers reports and misconfigured smokers
   
Yes. You can see this in the environment variables section:

    HARNESS_OPTIONS = j20

Is there already a consensus about enabling parallel smoking on all CPAN
distributions? Is it possible to blacklist/whitelist distributions for
parallel testing?

Regards,
    Slaven

   

requirements on META.yml and OS dependent requirements

[Alceu R. de Freitas Jr.]

Hello to all,
I have a distribution on CPAN (Siebel::Srvrmgr) that uses Dist::Zilla. Some 
modules requirements are dependent of the OS where the distribution is 
installed. I'm controlling that with the plug-in OSPrereqs.
All seems to be working fine except it is generating an issue with kwalitee 
test. A test from it is expecting to have all the prereqs declared in the 
META.yml file, but OSPrereqs is not generating them there, although the are 
(conditionally) considered in the Makefile.PL.
I wonder if this is a bug of OSPrereqs Dist::Zilla plug-in, a problem in the 
standard or the kwalitee test itself.
If there is any documentation that you can point me to I would appreciate.
Thanks,
Alceu

testers leaderboard not being updated

[Alceu R. de Freitas Jr.]

Hi,
Are we having some issues with the tester leader board statistics update?

I think the report is stale... I'm not seeing any update the last couple of 
days even thought I'm submitting tests:
OpenBSD Tester Leaderboard : CPAN Testers Statistics
Regards,Alceu

|   |
|   |   |   |   |   |
| OpenBSD Tester Leaderboard : CPAN Testers StatisticsAnalysis of reports 
submitted by the CPAN Testers community, who automatically black box test 
submissions to Perl's CPAN code repository |
|  |
| Visualizar em stats.cpantesters.org | Visualizado por Yahoo |
|  |
|   |

ExtUtils::MakeMaker 7.10 ignores TEST_REQUIRES

[Alceu R. de Freitas Jr.]

Hi there,
I migrating my distro to Dist::Zilla and spot a problem when trying to to run 
"dzil test" with it: my tests fails due dependency failure in installing 
Test::TempDir::Tiny. That happened in a Windows 7 with Strawberry Perl 
installed:
his is perl 5, version 18, subversion 2 (v5.18.2) built for 
MSWin32-x64-multi-thread

The problem is that this distro is not stated as missing. I tried with "dzil 
build", checked the Makefile.PL and Test::TempDir::Tiny is inside the 
TEST_REQUIRES:
  "TEST_REQUIRES" => {
    "Class::Data::Inheritable" => "0.08",
    "Config::IniFiles" => "2.83",
    "Cwd" => 0,
    "Devel::Gladiator" => "0.07",
    "Proc::Background" => "1.10",
    "Proc::Daemon" => "0.18",
    "Test::Class" => "0.36",
    "Test::Moose" => "2.0801",
    "Test::More" => 0,
    "Test::Most" => "0.25",
    "Test::Pod" => "1.22",
    "Test::Pod::Coverage" => "1.08",
    "Test::TempDir::Tiny" => "0.004"
  },
C:\temp\siebel-monitoring-tools\Siebel-Srvrmgr\Siebel-Srvrmgr-0.21>prove -l
t\ActionCheckComps.t  Can't locate Test/TempDir/Tiny.pm in @INC 
(you may need to install the Test::TempDir::Tiny module) (@INC contains: t 
C:\temp\siebel-monitoring-tools\Siebel-Srvrmgr\Siebel-Srvrmgr-0.21\lib 
C:/strawberry/perl/site/lib/MSWin32-x64-multi-thre
ad C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib 
C:/strawberry/perl/lib .) at t/Test/Siebel/Srvrmgr/Daemon/Action.pm line 6.
BEGIN failed--compilation aborted at t/Test/Siebel/Srvrmgr/Daemon/Action.pm 
line 6.
Compilation failed in require at C:/strawberry/perl/lib/parent.pm line 20.
BEGIN failed--compilation aborted at 
t/Test/Siebel/Srvrmgr/Daemon/Action/CheckComps.pm line 3.
Compilation failed in require at t\ActionCheckComps.t line 2.
BEGIN failed--compilation aborted at t\ActionCheckComps.t line 2.
t\ActionCheckComps.t  Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t\ActionCheckCompsRoleComp.t  ok
t\ActionCheckCompsRoleServer.t .. ok
t\ActionDumper.t  Terminating on signal SIGINT(2)
Terminate batch job (Y/N)? y
If I move Test::TempDir::Tiny (directly in the Makefile.PL) to BUILD_REQUIRES, 
I do get a warning for the missing dependency (which is the expected thing). 
But I think that defeats the purpose of TEST_REQUIRES.
The current version of Extutils::MakeMaker is above the minimum required to 
understand TEST_REQUIRES:

C:\temp\siebel-monitoring-tools\Siebel-Srvrmgr\Siebel-Srvrmgr-0.21>mversion 
ExtUtils::MakeMaker
7.10
And finally, Test::TempDir::Tiny is referenced in the Makefile itself:
#   MakeMaker Parameters:

# ABSTRACT => q[utilities to be used with the Siebel srvrmgr program]
# AUTHOR => [q[Alceu Rodrigues de Freitas Junior ]]
# BUILD_REQUIRES => {  }
# CONFIGURE_REQUIRES => { ExtUtils::MakeMaker=>q[0] }
# DISTNAME => q[Siebel-Srvrmgr]
# EXE_FILES => [q[bin/srvrmgr-mock.pl]]
# LICENSE => q[gpl]
# MIN_PERL_VERSION => q[5.008009]
# NAME => q[Siebel::Srvrmgr]
# PREREQ_PM => { Carp=>q[0], Class::Data::Inheritable=>q[0.08], 
Config::IniFiles=>q[2.83], Cwd=>q[0], Data::Dumper=>q[0], DateTime=>q[1.12], 
Devel::Gladiator=>q[0.07], Encode=>q[0], Exporter=>q[0], FSA::Rules=>q[0.34], 
Fcntl=>q[0], File::BOM=>q[0.14], File::Copy=>q[0], File::Spec=>q[0], 
File::Temp=>q[0.2304], Getopt::Std=>q[0], Hash::Util=>q[0], IO::Select=>q[0], 
IO::Socket=>q[0], IPC::Open3=>q[0], List::Util=>q[1.42], 
Log::Log4perl=>q[1.41], Moose=>q[2.0401], Moose::Role=>q[2.1604], 
Moose::Util=>q[2.1604], Moose::Util::TypeConstraints=>q[2.0402], 
MooseX::AbstractFactory=>q[0.004000], MooseX::FollowPBP=>q[0.05], 
MooseX::Singleton=>q[0], MooseX::Storage=>q[0.33], POSIX=>q[0], 
Proc::Background=>q[1.10], Proc::Daemon=>q[0.18], Scalar::Util=>q[0], 
Scalar::Util::Numeric=>q[0.40], Set::Tiny=>q[0.02], Storable=>q[2.51], 
String::BOM=>q[0.3], Symbol=>q[0], Test::Class=>q[0.36], 
Test::Moose=>q[2.0801], Test::More=>q[0], Test::Most=>q[0.25], 
Test::Pod=>q[1.22], Test::Pod::Coverage=>q[1.08], 
Test::TempDir::Tiny=>q[0.004], YAML::Syck=>q[1.29], 
namespace::autoclean=>q[0.13] }
# TEST_REQUIRES => { Class::Data::Inheritable=>q[0.08], 
Config::IniFiles=>q[2.83], Cwd=>q[0], Devel::Gladiator=>q[0.07], 
Proc::Background=>q[1.10], Proc::Daemon=>q[0.18], Test::Class=>q[0.36], 
Test::Moose=>q[2.0801], Test::More=>q[0], Test::Most=>q[0.25], 
Test::Pod=>q[1.22], Test::Pod::Coverage=>q[1.08], Test::TempDir::Tiny=>q[0.004] 
}
# VERSION => q[0.21]
# test => { TESTS=>q[t/*.t] }
Maybe I just caught a bug in ExtUtils::MakeMaker? Or I'm missing something?
I'm still to try the same test in other OS without those dependencies installed.

Thanks,
Alceu

Re: Spurious test failures from your OpenBSD smokers

[Alceu R. de Freitas Jr.]

Hello Kent,

My apologies, but definitely something is wrong with my smoker, or at least it 
was.
I double checked if "recommended" was installed, and it was not. Interesting 
enough, I got a report of PASS for it and my smoker is configured to 
automatically install all distros with that grade of testing.
On the other side, your distribution is already installed. So my guess is that 
in some moment it was fixed, but I don't understand how come it got installed 
if "recommended" was not available.
Here is some evidence: 
https://www.dropbox.com/s/hl1zqit68ir4dvy/2015-11-16%2007_38_04-CPAN%20OpenBSD%20%5BExecutando%5D%20-%20Oracle%20VM%20VirtualBox.png?dl=0
I'm copying this e-mail to the CPAN tester mailing list, maybe a good soul 
there already has some experience with cases like this. I'm clueless.
Regards,
Alceu
 
  De: Kent Fredric 
 Para: arfrei...@cpan.org 
 Enviadas: Segunda-feira, 16 de Novembro de 2015 1:50
 Assunto: Spurious test failures from your OpenBSD smokers
   
I'm getting a lot of fail reports from your OpenBSD box, for instance:

http://www.cpantesters.org/cpan/report/6de22078-8b6d-11e5-841a-c79391aaabaa

They all share the same thing in common:

They have a broken installation of Dist::Zilla::Util:Test::KENTNL

The version your reports claim to have installed is 1.005013

That version clearly dictates that `recommended` is a runtime requirement:

https://metacpan.org/source/KENTNL/Dist-Zilla-Util-Test-KENTNL-1.005013/META.json#L125

And this basically means all my Dzil plugins are expected to fail in this way.

As such your reports are in error for failing to satisfy prerequisites.

Thanks.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL


   
 

Enc: Invalid CPAN Testers report

[Alceu R. de Freitas Jr.]

Hello folks,
I got an e-mail from a CPAN author (that you can find below) about a mistaken 
report I sent him. I'm trying to figure out what happened and would like to 
know if you had the same problem.
That's the second e-mail I got today about problems with Test::More. Looks like 
that somehow I got a developer version of Test::More installed and checking it 
right now it is already version 1.302012003.
I tried to install manually Image-PNG-QRCode and everything was fine.
I'm using a minicpan repository but I didn't provide any configuration to add 
developer distributions.
Thanks,
Alceu
 
- Mensagem encaminhada -
  De: Graham Knop 
 Para: arfrei...@cpan.org 
Cc: benkasminbull...@gmail.com 
 Enviadas: Quinta-feira, 5 de Novembro de 2015 15:35
 Assunto: Invalid CPAN Testers report
   
You generated a CPAN Testers failure report:
http://www.cpantesters.org/cpan/report/2c5f9c14-7deb-11e5-a067-3e4f850e5dbe

This report appears to be invalid.  The machine seems to have a broken
Test::More, likely due to installing a development version.  Either
reverting to the stable version of Test::More, or updating to the
latest development release should resolve this issue.

Thanks.

   

problems with reports command of CPAN shell?

[Alceu R. de Freitas Jr.]

Hello there again,
During manual intervention from my part, I was trying to understand why my 
smoker was not being able to install Config-MVP-Reader-INI (due a missing 
dependency declaration, which I manually fixed).
Meanwhile when I was trying to check reports with the same error, I got this 
from the CPAN shells on different machines and perl distributions:
C:\>perl -MCPAN -e shell

cpan shell -- CPAN exploration and modules installation (v2.10)
Enter 'h' for help.


cpan> reports RJBS/Config-MVP-Reader-INI
Fetching with LWP:
http://cpan.strawberryperl.com/authors/01mailrc.txt.gz
Fetching with LWP:
http://cpan.strawberryperl.com/modules/02packages.details.txt.gz
Fetching with LWP:
http://cpan.strawberryperl.com/modules/03modlist.data.gz
Database was generated on Fri, 30 Oct 2015 14:19:41 GMT

Updating database file ...
Done!
Distribution: R/RJ/RJBS/Config-MVP-Reader-INI
Use of uninitialized value $dist in sprintf at 
C:\strawberry\perl\lib/CPAN/Distribution.pm line 4363.
Fetching 'http://www.cpantesters.org/show/.yaml'...Could not download 
'http://www.cpantesters.org/show/.yaml': 404


cpan>

The error looks consistent between all the places I tried to reproduce it.
I'm using the latest CPAN shell version (2.10).
Regards,
Alceu

smoker and parallelism

[Alceu R. de Freitas Jr.]

Hi again,
I was doing some research to see if there is any way to improve smoker 
performance by using parallelism. I found this article on 
http://modernperlbooks.com/mt/2011/11/parallelism-and-test-suites.html that 
discuss some issues when trying to do something like that.
Interesting as is, is there any feature to mark the tests results from a 
distribution that was executed with parallelism? That could help the authors to 
identify issues with their tests when running with parallelism. Maybe we could 
even mark (in Metacpan) the distribution as capable to be tested with 
parallelism.
Or maybe the distribution author could explicit ask to not test the 
distribution with parallelism.
Anyway, I just brainstorming here, no patches available right now. :-)
Regards,
Alceu

smoker speed and statistics

[Alceu R. de Freitas Jr.]

Hello there,
I've setup a smoker test on OpenBSD and noticed that it's somehow slower than 
running a Smoker on Linux using the same VM configuration (I use Virtualbox).
Not sure if Linux can take some advantages when using Virtualbox that OpenBSD 
can't (at least I know that Guest Additions is not available to the latter, but 
that shouldn't have a impact on performance anyway). The real problem is that I 
can't tell how much slower OpenBSD is for CPAN::Reporter::Smoker compared to 
Linux. Of course that are a lot of others things involved (kernel 
configuration, difference of filesystem) but I couldn't find any easier way to 
compare speed between the two.

Is it possible to implement the features below on CPAN::Reporter::Smoker?
- How many distributions tested- How many yet to test- Calculate how many 
distros per unit (minutes, hour, etc)
I didn't configure the smoker to skip some known problematic distributions, but 
I already caught the smoker sitting idle waiting for output of make. This is 
something that I already experimented (a lot) with Windows, but I think this is 
OK since IPC is problematic anyway on that OS. But I'm surprise to see it 
happening with OpenBSD.

In time: I'm using OpenBSD 5.7 with Perl 5.22.0 (compiled with Perlbrew) with 
noatime and softdep configured on FFS 
(http://www.openbsd.org/faq/faq14.html#DiskOpt). For some reason, compiling 
Perl with Perlbrew on OpenBSD 5.8 is not working (it fails with crypt.t and 
taint.t tests), but I didn't tried compiling it manually either.
Regards,
Alceu

Re: Is a mail server required to participate in cpantesters?

[Alceu R. de Freitas Jr.]

Hello James,
No, you shouldn't need any mail server installed. All the transport is done by 
HTTPS nowadays.
Check out if you have SSL installed correct, usually this is the most trick 
part to get CPAN::Reporter working. Be sure to check if the prerequisites are 
in place. Install Net::SSLeay and IO::Socket::SSL separated to check for 
errors. You might need to update your SSL libraries before doing that.

Then try to install Task::CPAN::Reporter.

I strongly recommend you to use Perlbrew to avoid using the "wide" interpreter 
and messing it around in the process. See 
http://wiki.cpantesters.org/wiki/SmokeTesting and 
http://slashlogging.blogspot.com/2015/01/installing-openssl-inside-your-perlbrew.html
 for more details on that.
Regards,
Alceu

 
  De: James E Keenan 
 Para: cpan-testers-discuss@perl.org 
 Enviadas: Quinta-feira, 8 de Outubro de 2015 21:16
 Assunto: Is a mail server required to participate in cpantesters?
   
Is it still the case that one can only submit reports to cpantesters if 
one is running a mail server on the machine running the smoker?

I've read recently complaints that because most people submitting 
reports are using cpanm-reporter, the reports being received have been 
limited in variety.  I also know that while Linux and some BSDs are well 
represented in the reports, Darwin is surprisingly poorly represented. 
(See, for example, http://matrix.cpantesters.org/?dist=File-Path, where 
as of this writing there are 0 reports from Darwin.)

Bearing those two facts in mind, tonight I read the instructions at 
http://wiki.cpantesters.org/wiki/QuickStart and decided to try to submit 
smoke reports from an older Mac I have.  After about an hour, I was able 
to get CPAN::Reporter, Test::CPAN::Reporter and all their many 
prerequisites installed and looked forward to generating my first report 
on my latest CPAN distribution, which I had not previously installed on 
this Mac.

$ cpan
cpan> o conf init test_report
cpan> o conf commit
cpan> force test Parse::Taxonomy
cpan> q

While the library tested (and subsequently got installed) okay, I got 
this output during the 'force test' phase:

#
CPAN::Reporter: Test::Reporter: error from 
'Test::Reporter::Transport::Metabase:'
fact submission failed: Can't locate object method "new" via package 
"LWP::Protocol::https::Socket" at 
/usr/local/lib/perl5/site_perl/5.20.1/Metabase/Client/Simple.pm line 124.
 
Metabase::Client::Simple::submit_fact(Metabase::Client::Simple=HASH(0xd8f3310), 
CPAN::Testers::Report=HASH(0xd8e1d80)) called at 
/usr/local/lib/perl5/site_perl/5.20.1/Test/Reporter/Transport/Metabase.pm line 
122
 
Test::Reporter::Transport::Metabase::send(Test::Reporter::Transport::Metabase=HASH(0xd8fdb90),
 
Test::Reporter=HASH(0xd8e2080)) called at 
/usr/local/lib/perl5/site_perl/5.20.1/Test/Reporter.pm line 272
        eval {...} called at 
/usr/local/lib/perl5/site_perl/5.20.1/Test/Reporter.pm line 272
        Test::Reporter::send(Test::Reporter=HASH(0xd8e2080)) called at 
/usr/local/lib/perl5/site_perl/5.20.1/CPAN/Reporter.pm line 495
        CPAN::Reporter::_dispatch_report(HASH(0xd8fe0e0)) called at 
/usr/local/lib/perl5/site_perl/5.20.1/CPAN/Reporter.pm line 107
        CPAN::Reporter::grade_test(CPAN::Distribution=HASH(0xbea4290), 
"/usr/bin/make test", ARRAY(0xd904ee0), 0) called at 
/usr/local/lib/perl5/site_perl/5.20.1/CPAN/Reporter.pm line 202
        CPAN::Reporter::test(CPAN::Distribution=HASH(0xbea4290), 
"/usr/bin/make test") called at 
/usr/local/lib/perl5/5.20.1/CPAN/Distribution.pm line 3552
        CPAN::Distribution::test(CPAN::Distribution=HASH(0xbea4290)) 
called at /usr/local/lib/perl5/5.20.1/CPAN/Shell.pm line 2063
        CPAN::Shell::rematein("CPAN::Shell", "force", "test", 
"Parse::Taxonomy") called at /usr/local/lib/perl5/5.20.1/CPAN/Shell.pm 
line 2230
        CPAN::Shell::__ANON__("CPAN::Shell", "test", "Parse::Taxonomy") 
called at /usr/local/lib/perl5/5.20.1/CPAN.pm line 376
        eval {...} called at /usr/local/lib/perl5/5.20.1/CPAN.pm line 373
        CPAN::shell() called at /usr/local/lib/perl5/5.20.1/App/Cpan.pm 
line 339
        App::Cpan::_process_options("App::Cpan") called at 
/usr/local/lib/perl5/5.20.1/App/Cpan.pm line 422
        App::Cpan::run("App::Cpan") called at /usr/local/bin/cpan line 12
#

At that point I recalled that *eight years ago* I had tried to set up 
CPANtester reporting on this machine, failed, and was told that because 
I wasn't running a "real" mail server I was out of luck.

But, of course, the overwhelming majority of Mac users don't run mail 
servers on their laptops or desktops; they use regular mail clients 
(assuming they don't use webmail applications).  This, it seems to me, 
might explain the paucity of CPANtester reports from Darwin.

So, is it still the case that you have to run a mail server to 
participate in cpantesters?

Thank you very much.
Jim Keenan


   

Re: Metabase down?

[Alceu R. de Freitas Jr.]

Don't know if it is related, but tests results webpage is unavailable too:
http://www.cpantesters.org/index.html
- Alceu

 
  De: David Golden x...@xdg.me
 Para: Nigel Horne n...@bandsman.co.uk 
Cc: CPAN Testers Discuss cpan-testers-discuss@perl.org 
 Enviadas: Sexta-feira, 21 de Agosto de 2015 12:51
 Assunto: Re: Metabase down?
   
First I've heard of it.  I'll start looking into it.

On Fri, Aug 21, 2015 at 11:40 AM, Nigel Horne n...@bandsman.co.uk wrote:

Apologies if this is already known and I missed it.  It the submission system 
down?

$  curl http://metabase.cpantesters.org/api/v1/submit/CPAN-Testers-Report
curl: (7) couldn't connect to host

-Nigel





-- 
David Golden x...@xdg.me Twitter/IRC: @xdg

   

Re: How do you handle a perl process that never seems to exit?

[Alceu R. de Freitas Jr.]

Hello there,


I found this part interesting in the code:

1537 if ($is_mswin || $is_vms) {
1538 # On Windows, try to get the 'real' PID
1539 if ($is_mswin) {
1540 eval { require Win32; };
1541 if (defined(Win32::GetCurrentProcessId)) {
1542 $pid_to_kill = Win32::GetCurrentProcessId();
1543 }
1544 }

If it tries to load specific platform code, why not try to use the Win32 API to 
take care of creating and removing a process (see Win32::Process)?

Regards,

Alceu



Em Domingo, 10 de Agosto de 2014 16:25, bulk 88 bul...@hotmail.com escreveu:
 






 Date: Thu, 7 Aug 2014 13:57:48 +0100
 From: da...@cantrell.org.uk
 To: cpan-testers-discuss@perl.org
 Subject: Re: How do you handle a perl process that never seems to exit?

 On Thu, Aug 07, 2014 at 08:29:41AM -0400, Dave Horner wrote:

 it seems to happen more on windows than other platforms...

 Unfortunately I know exactly  that much about Windows so can't
 help with that - although I'm sure you could write a watchdog thingy in
 perl if you don't have a decent shell available.


perl core has 
http://perl5.git.perl.org/perl.git/blob/10380cb3585f27510276b532ec6e5450d1b16391:/t/test.pl#l1513
                          

Enc: smoke tester hanging during tests

[Alceu R. de Freitas Jr.]

Hello there Reini,

 De: Reini Urban re...@cpanel.net
 Para: Alceu Rodrigues de Freitas Junior glasswal...@yahoo.com.br;
cpan-testers-discuss@perl.org
 Enviadas: Quinta-feira, 26 de Julho de 2012 11:48
 Assunto: Re: smoke tester hanging during tests

 1. IPC::Pipeline does not work on windows (yet). It hangs.
 Maybe I'll get to it later.

That seems OK considering how it is difficult to use IPC on Windows.

Anyway, it would be great if the maintainer use something like Devel-AssertOS to
validate if the tests should run in the host OS or not. I did that with
Win32-SqlServer-DTS and got nice NA reports results in OS's that the
distribution will simple not work
(http://www.cpantesters.org/distro/W/Win32-SqlServer-DTS.html#Win32-SqlServer-DTS-0.09).

 2. The answer to your question is visible in my CPAN::Reporter console:

 CPAN: CPAN::Reporter loaded ok (v1.2006)
 CPAN::Reporter: you need Win32::Job for inactivity_timeout support.
 Continuing without timeout...
 Checking if your kit is complete...
 Looks good

 I hope your CPAN::Tester::Smoker follows the same rules.

 So do:
 cpan
 i Win32::Job
 o conf inactivity_timeout 20
 o conf commit
 quit

 distroprefs are also nice, but hard to maintain.


That's look like exactly what I need. I'll try that and let you know.
Maybe the tutorial on CPAN smoking tests could include that (being honest, I
didn't checked the POD of CPAN::Reporter::Smoker), specially the Win32::Job
information.

Considering my RTFM syn, I'm volunteer to update the wiki, if possible, with
this information. :-)

Thanks to all,

Alceu Rodrigues de Freitas Junior
--
glasswal...@yahoo.com.br
---
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1

Re: Smoking on Windows and Module::Build

[Alceu R. de Freitas Jr.]

 De: Serguei Trouchelle s...@cpan.org
 Para: David Golden xda...@gmail.com
 Cc: CPAN-Testers-Discuss cpan-testers-discuss@perl.org
 
 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.
 


Hello there,

Wouldn't be better if the Pod::Html would be executed in parallel, freeing 
Module::Build to finishes its work?

AFAIK documentation doesn't matter for smoke testing, but it does matters if 
the developer is installing modules manually in Windows (let's not consider PPM 
packages on ActivePerl). Doing that would help in both cases of testing.

Just my five cents of contribution.

Regards,
 
Alceu Rodrigues de Freitas Junior
--
glasswal...@yahoo.com.br
---
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1

Re: Is a CPAN testers release reasonable?

[Alceu R. de Freitas Jr.]

--- Em ter, 20/4/10, David Cantrell da...@cantrell.org.uk escreveu:

 if( $name =~ /\b$platform\b/i )
 
 will match ...::Darwin, thus incrementing $specific, thus
 returning 0
 which I assume means this is not a relevant result, throw
 it away.

Maybe should be documented the use of Devel::AssertOS for modules that depends 
on a specific OS. Or those modules with several FAIL's during tests results 
should have an email sent to the module maintainer notifying about this issue 
and how to deal with it.

Looking for solving tests results by working in the module name could not be 
the best option, since those names will change a lot.

Or, even better, this kind of information should be supplied at the META.yml.

Just some quick thoughts.

Regards,
Alceu

Re: Daily Summary Report - A better explanation?

[Alceu R. de Freitas Jr.]

--- Em ter, 10/2/09, Barbie bar...@missbarbell.co.uk escreveu:

  Or, frankly a contact author mailto link
 would be better.
 
 At the moment I'm only sending ASCII mail. Might look
 at HTML mail and
 use that in the future though.

Maybe this is not a wise choice. I personally don't like receiving HTML emails, 
specially if I need to forward them with comments.
 
  Or a link to a form that emails the sender.
 
 Ah, you mean a Matt's Script Archive formmail.cgi. ;)

Gee, please don't do that! :-)

I think it doesn't matter much which way to communicate a FAIL to a developer 
on CPAN. Of course the process can be improved, but the truth is, if the 
developer is interested in checking what is wrong, he will do it anyway. Or at 
least ask somebody else if he/she doesn't have the time or inclination to keep 
developing the distro.

That's my two cents.

Regards,
Alceu


  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: Daily Summary Report - A better explanation?

[Alceu R. de Freitas Jr.]

--- Em ter, 10/2/09, Barbie bar...@missbarbell.co.uk escreveu:

 I did think about reordering, but was a bit worried authors
 might get a
 bit annoyed at too much boilerplate before they get to the
 real meat.
 Bearing in mind this is only really applicable to people
 who don't know
 about the service.

What about giving the developer the choise to use one format or the other?

There is the CPAN Testers preference page, but I don't how much trouble is to 
setup this kind of thing in the email report.

Regards,
Alceu


  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: testers.cpan.org not displaying most recent version of distribution in summary

[Alceu R. de Freitas Jr.]

 jk...@verizon.net escreveu:
 
 Can anyone explain why testers.cpan.org is saying that
 such
 an old version of a CPAN distribution is the latest?


I'm not sure, but check if your lastest distribution
can be reindexed by using the proper options available in
the PAUSE menu.
 
Maybe your distribution has some issue with directory
permissions like I had in the past. If the permission is not
OK, nothing works as expected.
 
Regards,

Alceu Rodrigues de Freitas Junior
--
glasswal...@yahoo.com.br
---
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1




  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: rfc: safer smoking

[Alceu R. de Freitas Jr.]

--- Em seg, 19/1/09, Gabor Szabo szab...@gmail.com escreveu:

 For additional safety you might want to limit the
 installations to
 
 1) Modules that already have N reports in the database
 meaning that some other testers have already tested it.
 
 2) Modules that have been on CPAN for at least M days
 hoping that if the module and its tests do something
 bad
 someone has already caught this, reported to the
 rulers of CPAN and the module was taken off
 CPAN.
 
 
 regards
Gabor

What about those distributions that have only that dummy test file with a 
single BEGIN { use Foo::Bar; } that h2xs generates?

This actually does not means to much for me, but the smoke test (and mannually 
too) will consider this distribution OK.

Shouldn't the smoke test include something like Devel::Cover?

Regards,
Alceu


  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: Test::Reporter::Transport::Outlook

[Alceu R. de Freitas Jr.]

Greetings Barbie,

I commented your email below.

--- Em qua, 14/1/09, Barbie bar...@missbarbell.co.uk escreveu:

 Be aware that Redemption will not be a complete solution,
 as it really
 only allows for the scripts to just send mail. It
 doesn't guarantee
 anything regards customized headers, as that is total
 dependant on the
 configuration of the Exchange server, which for most people
 is totally
 out of their control.

I touched this point in the documentation just a few minutes ago. 8-|

Well, I think there is little to do in this case besides documenting what is 
necessary to have enabled in Exchange Server. If the CPAN tester does not have 
the necessary acccess to the server configuration and cannot ask to the server 
admin to do it, he/she will need to look for another transport method. 
Honestly, I don't know if the Exchange server of my company will have such 
features enabled. :-)

Do you know what is necessary to have enabled in the Exchange server? Or just a 
note in the POD about that is enough?

And, as permanent workaround suggestion... would it be possible to use a 
standard field like Subject to retain some information about the method being 
used to report the test (CPAN-Reporter, for example)? It would be pretty simple 
to implement something like:

Subject: [CPAN::Reporter version XX] PASS Win32-SqlServer-DTS-0.08.2 
MSWin32-x86-multi-thread 5.00

Of course, I don't know how simple is to modify the other software that checks 
for the X-Header to parse the Subject field.
 
 Unfortunately I don't run a Windows box any more, so am
 unable to test
 the current versions we have here at $work, but if you do
 manage to
 resolve the X-Header issues I would be delighted to hear
 about it, so
 that I can add it to Mail::Outlook :)

I really willing to do it, but before that I would like to discuss some details 
about how to implement that in Mail::Outlook (probably subclass 
Mail::Outlook::Message but I think we will need to do some changes in the 
interface of ). Can we discuss such details here (because I think it's quite 
related to Test::Reporter) or should I send you an email directly?

Now testing can be a issue. As I said, I'm not sure the Exchange server that I 
use will help, but I can check at least. If you have any code with the 
Redemption implemented, please send me to my email and I can send a test email 
right away.

Regards,
Alceu Rodrigues de Freitas Junior
--
glasswal...@yahoo.com.br
---
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1



  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: Test::Reporter::Transport::Outlook

[Alceu R. de Freitas Jr.]

Hello David,

I commented you email below.

--- Em qua, 14/1/09, David Golden xda...@gmail.com
escreveu:

  And, as permanent workaround
suggestion...
 would it be possible to use a
  standard field like Subject to retain some
information
 about the method
  being used to report the test (CPAN-Reporter, for
 example)? It would be
  pretty simple to implement something like:
 
 No, at this point, we're not going to change the
 subject line format or
 related tools, as we're actually trying to migrate
away
 from email as a
 transport mechanism.  The X-Header is a
 good-to-have feature but not a
 must-have.

Ok then, I'll try to modify and test the X-Header. A
note requesting help to test the X-Header in a Exchange
server should attract attention from a good soul out there.
:-)

As you mentioned that you want to use a different
transport, what are the plans? A webservice?

Regards,
Alceu




  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Test::Reporter::Transport::Outlook

[Alceu R. de Freitas Jr.]

Greetings,

My name is Alceu and I'm new in the list. I'm a Brazilian Perl monk and started 
contributing to CPAN something like two years ago.

I joining you due an advice of David to post here instead of using the CPAN 
Forum.

I would like to develop a new module to be used as a subclass of 
Test::Reporter::Transport and send messages through Outlook, since using a 
Exchange server directly is not that easy.

I'm quoting original David's message from the CPAN forum below:

 Posted on Mon Jan 12 18:20:18 2009 by dagolden in response to 9705  (See the 
 whole thread of 2) 
 
 Re: Test::Reporter::Transport::Outlook 
 Hi, Alceu. The idea behind Test::Reporter::Transport was to open it up to 
 people to figure out new 
 ways to send reports.
 
That's great. The available methods expects that the CPAN user will have 
directly access to the Internet, which I usually don't have.
 
I think it would be great to have an webservice to use this service, but I'll 
try to start something about this latter.
 
 I think it would be great for you to publish your module on CPAN. From the 
 display() call, I assume 
 it pops up the message for the user to click send? You might want to note 
 that in the 
 documentation so that someone using it and testing a module with a lot of 
 dependencies isn't 
 shocked to find a dozen or more mail windows opening up.
 
That´s true indeed. I didn't have this situation because all dependencies that 
I would need to resolve before starting my tests were already resolved.
 
I think I could implement easily modification on the object constructor to 
enable the user to send messages automatically (this will depend on having 
Redemption installed) or save the messages in the Draft folder of Outlook.
 
 If you've got further ideas, I encourage you to subscribe to 
 cpan-testers-discuss@perl.org (send an  email to 
 cpan-testers-discuss-subscr...@perl.org) and continue the conversation there, 
 as you'll  
 probably get the attention of more people. (Also, Barbie, who wrote 
Mail::Outlook, is one of the  CPAN Testers leaders and may be interested.)
 
It would be great to have some feedback from Barbie also, although this mailing 
list may not be the right place to do it. I think getting Redemption working 
with Mail::Outlook would be great to be able to send emails from Outlook 
automatically and being able to send messages with customized headers.
 
By the way, how important is to have the customized headers in the email 
messages? I didn't send the X-Reported-Via with my test by email but the test 
was published in CPAN correctly.
 
Regards, 

 Alceu Rodrigues de Freitas Junior
--
glasswal...@yahoo.com.br
---
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1 


  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com