Guys,

Okay, trying to track down what's causing a certain quite prolific
failure in my initial module upload. Here's what I've been able to
determine (I'm pretty confident of almost all these numbers):

92% of reports with an empty config_args[1] pass
100% of reports with a *non*-empty config_args[2] fail
0% of the failures with an empty config_args relate to this particular
problem
85% of the failures with a non-empty config_args relate to this
particular problem

So, two questions:

# Does anyone have a clue what that could possibly mean?
# How do I reproduce a Perl with a non-empty config_args on my own
machine (preferably using Perlbrew) so I can reproduce the error and fix it?

TIA for any help, and a very gracious thanks for all that the CPAN
Testers folks do for the community. It is invaluable and immeasureable.


   -- Buddy


[1] "empty config_args" means that, at the bottom of the report, under
"Platform," there's a line like this:
      config_args=''
[2] "non-empty config_args" means that the report has that line, but
there's _stuff_ between the quotes (regardless of what the stuff
actually is)

Search Discussions

  • Ron Savage at Mar 27, 2016 at 9:57 pm
    Hi Buddy
    On 28/03/16 08:09, Buddy Burden wrote:
    Guys,

    Okay, trying to track down what's causing a certain quite prolific
    failure in my initial module upload. Here's what I've been able to
    determine (I'm pretty confident of almost all these numbers):

    92% of reports with an empty config_args[1] pass
    100% of reports with a *non*-empty config_args[2] fail
    0% of the failures with an empty config_args relate to this particular
    problem
    85% of the failures with a non-empty config_args relate to this
    particular problem

    So, two questions:

    # Does anyone have a clue what that could possibly mean?
    Reading this msg, none of us has a clue as to the code you've used :-).

    I suggest you upload your tarball to your website and perhaps someone
    will download it and analyze it for you.

    --
    Ron Savage - savage.net.au
  • Buddy Burden at Mar 27, 2016 at 11:59 pm
    Ron,
    Reading this msg, none of us has a clue as to the code you've used :-).
    Well, I'm not actually asking for help solving the actual _problem_ ...
    I have a pretty good idea what the problem is, and even how to fix it.
    The problem is, I can't actually _reproduce_ the problem on my machine.
       So what I'd like help with is, what does the "config_args" line in the
    report actually _mean_, and how do I build a version of Perl (again,
    preferably using Perlbrew) which can replicate a given config_args line?
    I suggest you upload your tarball to your website and perhaps someone
    will download it and analyze it for you.
    Well, no need for that; the code's right there on CPAN.[1] :-) If
    anyone's interested in the code, that's cool, but like I said: I'm not
    really asking anyone to debug my code for me. ;-> Just help with
    understanding what config_args means.

    Perhaps some examples might be helpful:

    * A report with an empty config_args which passes[2]
    * A report with an empty config_args which fails[3], not the current
    problem[4]
    * A report with a non-empty config_args which fails[5], *this* is the
    problem in question
    * A report with a non-empty config_args which fails[6], not the current
    problem[7]

    I'm still working on identifying _which_ things in the config_args make
    it pass vs fail (or whether the split amongst reports with a non-empty
    config_args actually relates to an orthogonal categorization), but none
    of that is going to help me if I can't figure out how to build a Perl
    that will reproduce the problem locally.

    Thanx guys.


       -- Buddy


    [1]
    https://metacpan.org/source/BAREFOOT/Date-Easy-0.01/lib/Date/Easy/Date.pm
    [2] http://cpantesters.org/cpan/report/eaac1ee2-e4fa-11e5-a56f-bda5e839e4f8
    [3] http://cpantesters.org/cpan/report/e38224f8-e514-11e5-a56f-bda5e839e4f8
    [4] This is a whole different problem, which I already know what it is
    and how to fix it.
    [5] http://cpantesters.org/cpan/report/d5512c2e-f0f6-11e5-9e3d-91c58fb2e322
    [6] http://cpantesters.org/cpan/report/fd94422e-e4fe-11e5-a38c-f98eaef69d38
    [7] This a whole different problem from both the other two problems; I
    actually don't have a clue yet on this one, but I'm not that worried
    about it (yet).
  • Tony Cook at Mar 28, 2016 at 12:41 am
    On Sun, Mar 27, 2016 at 02:09:05PM -0700, Buddy Burden wrote:
    Subject: The meaning of config_args

    From Porting/Glossary in the perl distribution:

    config_args (Options.U):
      This variable contains a single string giving the command-line
      arguments passed to Configure. Spaces within arguments,
      quotes, and escaped characters are not correctly preserved.
      To reconstruct the command line, you must assemble the individual
      command line pieces, given in config_arg[0-9]*.

    It means STRO built perl with:

       ./Configure

    and then answered the configuration questions manually*.

    It's unlikely to have anything to do with the cause of your failures.

    Tony

    * Or wants us to think he did.
  • Buddy Burden at Mar 28, 2016 at 3:16 am
    Tony,
    From Porting/Glossary in the perl distribution:

    config_args (Options.U):
    This variable contains a single string giving the command-line
    arguments passed to Configure. Spaces within arguments,
    quotes, and escaped characters are not correctly preserved.
    To reconstruct the command line, you must assemble the individual
    command line pieces, given in config_arg[0-9]*.

    It means STRO built perl with:

    ./Configure

    and then answered the configuration questions manually*.
    Okay; thx. I figured it was something along those lines.
    It's unlikely to have anything to do with the cause of your failures.
    Well, I'll take your word for it, since I know you're a fellow who
    _really_ knows what he's talking about. :-) It's just that this is the
    _only_ point of correlation with this particular failure that I've been
    able to find. It's not Perl version or OS or threaded vs non-threaded.
       If it's not this, I have no idea what it is. But I'll keep looking at
    it ...


       -- Buddy
  • Tony Cook at Mar 28, 2016 at 4:03 am

    On Sun, Mar 27, 2016 at 08:16:42PM -0700, Buddy Burden wrote:
    Well, I'll take your word for it, since I know you're a fellow who _really_
    knows what he's talking about. :-) It's just that this is the _only_ point
    of correlation with this particular failure that I've been able to find.
    It's not Perl version or OS or threaded vs non-threaded. If it's not this,
    I have no idea what it is. But I'll keep looking at it ...
    You might want to try testing it under a few different time zones.

    Tony
  • James E Keenan at Mar 28, 2016 at 10:17 pm

    On 03/27/2016 05:09 PM, Buddy Burden wrote:
    Guys,

    Okay, trying to track down what's causing a certain quite prolific
    failure in my initial module upload. Here's what I've been able to
    determine (I'm pretty confident of almost all these numbers):
    Are you familiar with http://matrix.cpantesters.org/?dist=Date-Easy?

    The fact that your other CPAN distributions are shown in the matrix as
    mostly PASSing -- see http://matrix.cpantesters.org/?author=BAREFOOT --
    suggests that there are real problems with Date-Easy. My own hunch is
    that these problems have little or nothing to do with whether
    'config_args' is populated or not.

    Thank you very much.
    Jim Keenan
  • James E Keenan at Mar 28, 2016 at 10:29 pm

    On 03/28/2016 06:17 PM, James E Keenan wrote:
    On 03/27/2016 05:09 PM, Buddy Burden wrote:
    Guys,

    Okay, trying to track down what's causing a certain quite prolific
    failure in my initial module upload. Here's what I've been able to
    determine (I'm pretty confident of almost all these numbers):
    With perl-5.22.0 on linux x86_64 (unthreaded), I tried

    $> cpanm test Date::Easy

    Attaching results, which are very similar to this CPANtesters report
    from Slaven:
    http://www.cpantesters.org/cpan/report/5551d972-e496-11e5-81a9-4f49fcd2507e
  • Buddy Burden at Mar 29, 2016 at 3:15 am
    Jim,
    Are you familiar with http://matrix.cpantesters.org/?dist=Date-Easy? Sure.
    The fact that your other CPAN distributions are shown in the matrix as
    mostly PASSing -- see http://matrix.cpantesters.org/?author=BAREFOOT --
    suggests that there are real problems with Date-Easy.
    Oh, absolutely: I know there's a real problem, and I know exactly where
    it is in the code, and I have a _rough_ idea of how to fix it. The
    problem is, the problem doesn't show up on every system: only about 85%
    of them. My personal system just happens to be in the 15%. :-(

    So I want to be able to build a Perl that is in the 85%, and then I can
    fix the problem pretty easily.[1] Without that, the only way I can see
    if my code works is to release a new version to CPAN every time and then
    wait to see what the smokers throw up. That's a pretty slow dev cycle.
    :-) So that's what I'm trying to avoid.

    The challenge is to be able to identify exactly which aspect of a system
    causes it to be in the 85% vs the 15%. Admittedly the config_args thing
    was a wild guess that just happened to show some correlation with the
    problem.
    My own hunch is
    that these problems have little or nothing to do with whether
    'config_args' is populated or not.
    As is Tony's. I'm still looking. Going to try Curtis' suggestion next.

    On the plus side, I'm really souping up Tobyink's `cpan-testers`
    script.[2] :-) So I'll toss out my modified version once I finish with
    that and hopefully it can be useful to other folks as well.


       -- Buddy


    [1] Assuming of course that the problem is caused by a particular build
    as opposed to something I can't control for, like, say, a certain OS.
    But I'm _fairly_ sure that that is the case.
    [2] http://www.perlmonks.org/?node_id=978606
  • Andreas Koenig at Mar 29, 2016 at 6:36 am
    On Mon, 28 Mar 2016 20:15:50 -0700, Buddy Burden said:
      jim> My own hunch is
      jim> that these problems have little or nothing to do with whether
      jim> 'config_args' is populated or not.

      buddy> As is Tony's. I'm still looking. Going to try Curtis' suggestion next.

    Apparently I have missed Curtis' posting, but I have silently affirmed Tony's
    in which he said:

      tony> You might want to try testing it under a few different time zones.

    That's also my finding. I can vary the number of failing tests by
    setting the time zone. There is no reflection of the timezone of the
    smoker box in cpan testers reports, so if you do not find the
    correlation with different timezones yourself, it would be a good idea
    to add the reflection manually, e.g.

       diag "localtime: ".localtime;

    or something like that and make another release.

    --
    andreas
  • Buddy Burden at Mar 30, 2016 at 4:07 am
    Andreas,
    Apparently I have missed Curtis' posting, ...
    He suggested looking at the compiler used to build the particular Perl.
    ...but I have silently affirmed Tony's
    in which he said:

    tony> You might want to try testing it under a few different time zones.

    That's also my finding. I can vary the number of failing tests by
    setting the time zone.
    Yes, with your message and Joel's (which came right after yours), I can
    see that it really is the timezone that seems to cause this failure.
    That weirds me out, because I really thought I knew what was causing the
    problem ... and now it seems I have no clue after all. :-/
    There is no reflection of the timezone of the
    smoker box in cpan testers reports, so if you do not find the
    correlation with different timezones yourself, it would be a good idea
    to add the reflection manually, e.g.

    diag "localtime: ".localtime;

    or something like that and make another release.
    Yep, that's a great idea: andk++. I will definitely add that to my test
    output for future releases.

    Thx a lot! (And of course thx to Tony and Joel as well.)


       -- Buddy
  • Joel Maslak at Mar 29, 2016 at 6:49 am
    I took a look at your module. Trying to compile the dzil authordep
    "Dist::Zilla::PluginBundle::BAREFOOT, I got this error:

    t/tdist.t .... couldn't determine document name for lib/Test/Module.pm
    Add something like this to lib/Test/Module.pm:
    # PODNAME: bobby_tables.pl at
    /home/jmaslak/perl5/perlbrew/perls/perl-5.22.1/lib/site_perl/5.22.1/Pod/Weaver.pm
    line 135.
    t/tdist.t .... 1/?
    # Failed test 'command succeeded [dzil build]'
    # at t/tdist.t line 79.
    # got: '65280'
    # expected: '0'
    # Looks like you failed 1 test of 1.
    t/tdist.t .... Dubious, test returned 1 (wstat 256, 0x100)
    Failed 1/1 subtests

    That said, once I built it (after adding the line Pod::Weaver wanted) I was
    able to dzil build / dzil test your module that I cloned from git.

    I got a ton of errors for my America/Denver time zone.

    if I set my timezone to Los Angeles, I only got three failures (MUCH
    better), all for the same date:

    # Failed test 'successful parse: 04/95 00:22:12 PDT'
    # at t/date-parse.t line 123.
    # got: '1995-03-31'
    # expected: '1995-04-01'

    Of course April 1, 1995 was not yet daylight savings time, so 22 minutes
    after midnight PDT would be 38 minutes *before* midnight PST, which
    America/Pacific would use for time display.

    I'd suggest you set $ENV{TZ} in your test scripts to a known time zone to
    do these comparisons. I suspect some system somewhere also mis-handles
    when DST starts (it didn't always start when it starts now, at least in the
    USA).

    I suspect your issue is a combination of OS (possibly how up to date it is
    as well) and timezone.

    On Mon, Mar 28, 2016 at 9:15 PM, Buddy Burden wrote:

    Jim,

    Are you familiar with http://matrix.cpantesters.org/?dist=Date-Easy?
    Sure.

    The fact that your other CPAN distributions are shown in the matrix as
    mostly PASSing -- see http://matrix.cpantesters.org/?author=BAREFOOT --
    suggests that there are real problems with Date-Easy.
    Oh, absolutely: I know there's a real problem, and I know exactly where it
    is in the code, and I have a _rough_ idea of how to fix it. The problem
    is, the problem doesn't show up on every system: only about 85% of them.
    My personal system just happens to be in the 15%. :-(

    So I want to be able to build a Perl that is in the 85%, and then I can
    fix the problem pretty easily.[1] Without that, the only way I can see if
    my code works is to release a new version to CPAN every time and then wait
    to see what the smokers throw up. That's a pretty slow dev cycle. :-) So
    that's what I'm trying to avoid.

    The challenge is to be able to identify exactly which aspect of a system
    causes it to be in the 85% vs the 15%. Admittedly the config_args thing
    was a wild guess that just happened to show some correlation with the
    problem.

    My own hunch is
    that these problems have little or nothing to do with whether
    'config_args' is populated or not.
    As is Tony's. I'm still looking. Going to try Curtis' suggestion next.

    On the plus side, I'm really souping up Tobyink's `cpan-testers`
    script.[2] :-) So I'll toss out my modified version once I finish with
    that and hopefully it can be useful to other folks as well.


    -- Buddy


    [1] Assuming of course that the problem is caused by a particular build as
    opposed to something I can't control for, like, say, a certain OS. But I'm
    _fairly_ sure that that is the case.
    [2] http://www.perlmonks.org/?node_id=978606
  • Buddy Burden at Mar 30, 2016 at 4:17 am
    Joel,
    I took a look at your module. Trying to compile the dzil authordep
    "Dist::Zilla::PluginBundle::BAREFOOT, I got this error:
    Yeah, my bundle is a bit borked ATM.[1] But the tests should be
    runnable with `prove` without needing to use `dzil test`. I should
    probably note that in the docs somewhere ... I saw someone else who did
    that[2] and I think it's probably helpful for would-be contributors.
    I got a ton of errors for my America/Denver time zone.
    Right, I was able to reproduce that easily. Thx for giving me a
    concrete example to work with.
    if I set my timezone to Los Angeles, I only got three failures (MUCH
    better), all for the same date:

    # Failed test 'successful parse: 04/95 00:22:12 PDT'
    # at t/date-parse.t line 123.
    # got: '1995-03-31'
    # expected: '1995-04-01'

    Of course April 1, 1995 was not yet daylight savings time, so 22 minutes
    after midnight PDT would be 38 minutes *before* midnight PST, which
    America/Pacific would use for time display.
    Those weren't failing before ... I suspect it's because we were on
    standard time when I did the release, but we're on DST now. DST, of
    course, being one of the biggest PITAs to deal with, which is one of the
    reasons I wrote this module in the first place. :-) So I guess it's a
    good thing that I'm seeing these problems, because that forces me to
    really Get It Right(tm). ;->
    I'd suggest you set $ENV{TZ} in your test scripts to a known time zone
    to do these comparisons. I suspect some system somewhere also
    mis-handles when DST starts (it didn't always start when it starts now,
    at least in the USA).
    Well, I'm afraid if I do that I'm just going to end up masking the
    problem. But maybe I should have an additional set of tests where I set
    several different timezones and look for failures.

    Thx again for the pointers.


       -- Buddy


    [1] Although I *thought* that error was only in the latest dev release,
    not the latest full release. But apparently I was wrong on that score. :-/
    [2] I want to say David Golden, but I might be misremembering.
  • Buddy Burden at Apr 9, 2016 at 11:21 pm
    Guys,

    I want to once again thank everyone who helped me work through the
    issues here, and most especially Tony (for explaining what config_args
    meant and why it probably wasn't the smoking gun I thought it was),
    Andreas (for the brilliant suggestion of using `diag` to get what
    timezone the smoker is in on future failure reports), and Joel (for a
    nice simple example to check, and also for kicking me in the ass to get
    my Dist::Zilla plugin bundle fixed, finally). The problem, as many of
    you suspected, is rooted in timezone differences. Still working on the
    exact fix, although I have the methodology firmly in mind.

    In the meantime, I've put up a blog post[1] about my experiences trying
    to track down the problem, and, in particular the extensive rewrites I
    did to tobyink's `cpan-testers` CLI client. If you don't care to read
    through my whole post just to find a link to the script, you can hop
    directly to my GitHub repo.[2] Even though it didn't help me find the
    problem this time--*you* guys did that--I think it could help other
    folks find their problems, so I wanted to share it with the community.

    Thx again.


       -- Buddy


    [1]
    http://blogs.perl.org/users/buddy_burden/2016/04/a-date-with-cpan-and-now-a-word-from-our-sponsor.html
    [2]https://github.com/barefootcoder/common/blob/master/bin/cpan-testers

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-testers-discuss @
categoriesperl
postedMar 27, '16 at 9:09p
activeApr 9, '16 at 11:21p
posts14
users6
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase