Description of problem: The package dateutils fails to build because it's failing part of its standard test suite. That runs dzone --next Asia/Singapore 2014-02-22 which should return never -> never Asia/Singapore but instead gives never -> 1901-12-15T37:42:47+08:00 Asia/Singapore (Note that the Fedora-installed command uses the long name options so it becomes "datezone", but it's built and tested as "dzone".) Version-Release number of selected component (if applicable): tzdata-2017b-2.fc27 Additional info: This is on x86_64. The test suite is not completely comprehensive, and all other tests succeed; I'm afraid there may be wider problems that just happen to not be hit.
Oh, I left out something key! It works just fine with tzdata-2017b-1.fc27. Plus, the F26 binary fails with tzdata-2017b-2.fc27 and works with tzdata-2017b-1.fc27. This makes me super concerned because the only change between those two releases is the release bump and mass rebuild.
I guess one major difference is the version of glibc, from which zic comes -- that's what makes these binary databases, right? Looking at the build logs https://kojipkgs.fedoraproject.org//packages/tzdata/2017b/1.fc27/data/logs/noarch/root.log https://kojipkgs.fedoraproject.org//packages/tzdata/2017b/2.fc27/data/logs/noarch/root.log That seems to have been 2.25.90-1.fc27 (on i686) previously and 2.25.90-28.fc27 (on armv7hl) now. Did something change _intentionally_ in the format?
Hmmmm. The binary files definitely differ -- they're even different sizes. (410 bytes in -1, and 424 in -2.) But, comparing the output of `zdump -v` with the two versions gives identical output.
I thought the difference might be a bug due to the the build host archs, but no, when I rebuild -2 locally in f27 mock, I get the same file. When I build against f26, I get the same file as -1. So, the difference is something in the environment -- possibly a change in zic?
Ah. Found upstream fix for dateutils https://github.com/hroptatyr/dateutils/commit/1238f9bac1f652a0e28eab1bed66914dedbcd282.patch