I am seeing unexpected binary differences in generated zoneinfo files that (in theory) should not differ from 2022a. Here are the binary differences minus what’s listed in NEWS: modified: zoneinfo/Africa/Casablanca modified: zoneinfo/Africa/El_Aaiun modified: zoneinfo/America/New_York modified: zoneinfo/Asia/Jakarta modified: zoneinfo/Europe/Gibraltar modified: zoneinfo/Europe/Guernsey modified: zoneinfo/Europe/Isle_of_Man modified: zoneinfo/Europe/Jersey modified: zoneinfo/Europe/London modified: zoneinfo/Europe/Madrid modified: zoneinfo/Europe/Malta modified: zoneinfo/Europe/Rome modified: zoneinfo/Europe/San_Marino modified: zoneinfo/Europe/Simferopol modified: zoneinfo/Europe/Vatican modified: zoneinfo/GB modified: zoneinfo/Pacific/Easter modified: zoneinfo/US/Eastern I tried to be careful to remove synonyms of the zones listed as changed in NEWS, but as far as I can tell none of the above zones should have changed at all. Is there a tool that can dump transitions in zoneinfo files that have *not* been installed in the standard platform location? zdump only works on zoneinfo files that have been installed. Thanks, Debbie
On Aug 11, 2022, at 10:36 PM, Deborah Goldsmith via tz <tz@iana.org> wrote:
Thanks, I will go through the process in the morning!
Debbie
On Aug 11, 2022, at 6:28 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 8/11/22 16:40, Deborah Goldsmith wrote:
Is it possible you built with something other than onetrueawk?
I looked into that, and it turns out I made a different mistake: on FreeBSD 13 I accidentally tested with 2020b not 2022b. So you're right, 2022b's make_traditional_tarballs also fails on FreeBSD 13. Sorry about that mistake.
We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded.
Oh, I thought you were running "make traditional_tarballs" (the subject line of this thread). If you're running "make rearguard_tarballs" I think I now see why it's needed.
One worry is that if we release a new version 2022c right away with the installed patch, we'll run into some other issue on macOS that would mean we'd need to release 2022d, 2022e, etc. To prevent that, can you please try running the rest of your build procedure with the rearguard tarball? If that works, we can release 2022c with more confidence.
To help you try that out, I built the rearguard tarball and you can pick it up here temporarily:
https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz
Here's the output of 'sha512sum' on it:
e9470bdf35349080143c5c36bd6460d45ad506b2b3bd6ce192df1cae1739a945dbf4d4b128ae0f8026e4187dcd2e25a0b3cb2a74be820406f99e4a895d31e3ed tzdata2022b-rearguard.tar.gz
and you can find the GPG signed checksum here:
https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz.asc