On Thu, 14 Nov 2019, Harlan Lieberman-Berg wrote:

> tag 934843 +unreproducible
> thanks
> 
> On Thu, 15 Aug 2019 19:12:49 +0000 Santiago Vila <sanv...@debian.org> wrote:
> > I tried to build this package in stretch but it failed:
> 
> Hello!
> 
> This is quite strange.  I've tried rebuilding it several times in my
> stretch sbuild, and it worked every time without error.  I also
> re-triggered the build on reproducible-builds, and it's now clean
> there as well.
> 
> One possibility that comes to mind is locales -- what locales are you
> compiling under? It's possible there's a bug in one of the
> locale-specific parsers that's not getting exercised on my sbuild,
> through, I admit to not being sure how reproducible-builds could have
> been affected by the same thing.  Otherwise, maybe a difference in one
> of the deps that was fixed in the last... day?

Sprry for the late reply.

I reported this in 2019-08 and the first reply came in 2019-11.
By that time, the package built ok again in my autobuilders according
to my build history:

Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20190216T184806.957Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20190319T030404.993Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T104812.785Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115932.874Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115928.188Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115932.124Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115937.789Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115954.716Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T120006.211Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115946.514Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T120019.561Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T115949.086Z
Status: failed      parsedatetime_2.1-3+deb9u1_amd64-20190812T120022.496Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20191018T145214.267Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20191018T172715.052Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20200210T050524.951Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20200305T171505.547Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20200720T162707.522Z

However, by looking at the build log and the kind of error, I believe
it's the kind of date-related bug in the test suite which only happens
in certain times of the year. Does this make sense?

Why would this happen if not?

        Result:
                (time.struct_time(tm_year=2019, tm_mon=8, tm_mday=22,
tm_hour=3, tm_min=26, tm_sec=0,
+tm_wday=0, tm_yday=224, tm_isdst=-1), 3)

        Expected:
                (time.struct_time(tm_year=2020, tm_mon=8, tm_mday=22,
tm_hour=3, tm_min=26, tm_sec=0,
+tm_wday=5, tm_yday=235, tm_isdst=-1), 3)


I have not tested myself, but if this were my package I would try to
built it in 2019-08 (using "libfaketime" or something similar), as the
failure in the test suite seems to depend on the date on which it's
built.

(I'm not reopening the bug, but I believe this little extra
information belongs to the bug report).

Thanks.

Reply via email to