Bug#1091076: libschedule-cron-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 "TEST_FILES=t/after_job.t t/callbackreschedule.t t/delete_entry.t t/dst_back.t t/entry.t t/execution_time.t t/load_crontab.t t/nofork.t t/pod.t t/pod_coverage.t t/pretty_print_args.t t/process_name.t t/same_time_with_reschedule.t t/sighandler.t t/startup.t t/timeshift.t" returned exit code 2

[gregor herrmann]

On Sun, 22 Dec 2024 10:28:38 +0100, Lucas Nussbaum wrote:

> > #   Failed test 'Expected time for PST8PDT ( Ref: Sun Nov  1 00:55:00 2009, Calc: Sun Nov  1 01:00:00 2009'
> > #   at t/dst_back.t line 43.
> > #          got: '1257066000'
> > #     expected: '1257062400'
> > # Looks like you failed 1 test of 3.
> > t/dst_back.t ................... 
> > 1..3
> > ok 1 - Timezone MET not available
> > ok 2 - Expected time for Europe/Berlin ( Ref: Sun Oct 25 02:55:00 2009, Calc: Sun Oct 25 03:00:00 2009
> > not ok 3 - Expected time for PST8PDT ( Ref: Sun Nov  1 00:55:00 2009, Calc: Sun Nov  1 01:00:00 2009
> > Dubious, test returned 1 (wstat 256, 0x100)
> > Failed 1/3 subtests 


> > Test Summary Report
> > -------------------
> > t/dst_back.t                 (Wstat: 256 (exited 1) Tests: 3 Failed: 1)
> >   Failed test:  3
> >   Non-zero exit status: 1
> > Files=16, Tests=108, 42 wallclock secs ( 0.06 usr  0.03 sys +  1.68 cusr  0.32 csys =  2.09 CPU)
> > Result: FAIL
> > Failed 1/16 test programs. 1/108 subtests failed.
> > make[2]: *** [Makefile:835: test_dynamic] Error 255
> > make[2]: Leaving directory '/<<PKGBUILDDIR>>'
> > dh_auto_test: error: make -j8 test TEST_VERBOSE=1 "TEST_FILES=t/after_job.t t/callbackreschedule.t t/delete_entry.t t/dst_back.t t/entry.t t/execution_time.t t/load_crontab.t t/nofork.t t/pod.t t/pod_coverage.t t/pretty_print_args.t t/process_name.t t/same_time_with_reschedule.t t/sighandler.t t/startup.t t/timeshift.t" returned exit code 2

Interesting.

The background for this test is in the POD/manpage:

DST ISSUES

  Daylight saving occurs typically twice a year: In the first switch,
  one hour is skipped. Any job which triggers in this skipped hour
  will be fired in the next hour. So, when the DST switch goes from
  2:00 to 3:00 a job which is scheduled for 2:43 will be executed at
  3:43.

  For  the reverse backwards switch later in the year, the behavior
  is undefined. Two possible behaviors can occur: For jobs triggered
  in short intervals, where the next execution time would fire in the
  extra hour as well, the job could be executed again or skipped in
  this extra hour. Currently, running "Schedule::Cron" in "MET" would
  skip the extra job, in "PST8PDT" it would execute a second time.
  The reason is the way how Time::ParseDate calculates epoch times
  for dates given like "02:50:00 2009/10/25". Should it return the
  seconds since 1970 for this time happening 'first', or for this
  time in the extra hour ? As it turns out, Time::ParseDate returns
  the epoch time of the first occurrence for "PST8PDT" and for "MET"
  it returns the second occurrence. Unfortunately, there is no way to
  specify which entry Time::ParseDate should pick (until now). Of
  course, after all, this is obviously not Time::ParseDate's fault,
  since a simple date specification within the DST back-switch period
  is ambiguous. However, it would be nice if the parsing behavior of
  Time::ParseDate would be consistent across time zones (a ticket has
  be raised for fixing this). Then Schedule::Cron's behavior within a
  DST backward switch would be consistent as well.

  Since  changing  the  internal  algorithm  which  worked  now for
  over ten years would be too risky and I don't see any simple
  solution for this right now, it is likely that this undefined
  behavior will exist for some time. Maybe some hero is coming along
  and will fix this, but this is probably not me ;-)

  Sorry for that.


What makes this interesting is that the test failure happens for
Lucas and in the same way on ci.debian.net.

On reproducible-builds.org and locally the tests pass:

t/dst_back.t ................... 
1..3
ok 1 - Timezone MET not available
ok 2 - Timezone Europe/Berlin not available
ok 3 - Expected time for PST8PDT ( Ref: Sun Nov  1 01:55:00 2009, Calc: Sun Nov  1 01:00:00 2009
ok


Smells like tzdata{,-legacy} maybe?
And indeed, if a add tzdata to B-D-I, I get the same test failure.
If I add both tzdata and tzdata-legacy, it passes again.

Somehow this looks like different build environments … and making
them consistent by requiring both packages, and thereby enabling all
3 subtests, doesn't sound obviously wrong, so I'm doing this now.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: Digital Signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20241222/6416f65f/attachment.sig>