Summary: | app-misc/dateutils-0.4.9 fails tests (DASH-SYSTEM): FAIL: dzone.008.ctst | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Matthias Coppens <coppens.matthias.abc> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | kingjon3377, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
1-test-suite.log |
Description
Agostino Sarubbo
2022-12-15 08:31:10 UTC
Created attachment 842767 [details]
build.log
build log and emerge --info
Created attachment 842769 [details]
1-test-suite.log
1-test-suite.log
Error(s) that match a know pattern in addition to what has been reported in the summary: FAIL: dzone.008.ctst make[2]: ./tzmap: No such file or directory When I last built dateutils-0.4.9 on one machine in February 2022, it passed all its tests fine; trying to get Gentoo set up on a new machine, I just hit this test failure. (Testing locally on the former machine reveals that 0.4.10 also suffers the same test failure.) Some digging on the IANA tzdata announcement list shows that the timestamp of Singapore's December-31-1991 time-zone transition was corrected by half an hour in November 2022 (timezone-data-2022g), which broke the test. The dateutils git repository includes two commits that together fix the test (one fixes it for the new timezone-data version but breaks it for the old, then the next commit replaces that with test data from Jakarta a decade before, which works against both timezone-data versions), namely 841c635bf283e4b023bd98fbff9ebda1f340b024 and 35041f4d9f06f94e4e408a3a12be237d4aa9ef44. Once I put them in /etc/portage/patches (named so as to be applied in that order), the tests passed. |