Red Hat Bugzilla – Bug 1478604
tzdata from F27 mass rebuild may be bad.
Last modified: 2017-08-05 08:51:00 EDT
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):
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
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