make rearguard_tarballs fails creates tzdataunknown-rearguard.tar.gz file with latest tzdata lzip
Hello, I've encountered two issues with the two latest files for the tz changes: https://data.iana.org/time-zones/releases/tzdb-2020c.tar.lz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz 1) The touch command for the new pacificnew empty file won't work on centos6 or centos7. The date format syntax is generating an error: I noticed this was already fixed here: https://github.com/eggert/tz/commit/ce89cbaa436f336dca4b239fa528405abd7d84b7... How long before that makes it to the /tzdb-2020c.tar.lz file? 2) Upon manually fixing the touch issue by replacing the touch command with the fixed version, I am now getting the wrong filenames for the rearguard file and tzcode and tzdata: Steps: [root@centos7 tzdb-2020c]# lzip -d tzdb-latest.tar.lz [root@centos7 tzdb-2020c]# mkdir tzdata-latest && tar xf tzdb-latest.tar -C tzdata-latest [root@centos7 tzdb-2020c]# pwd /home/tzdata/tzdata-2020c/tzdb-2020c [root@centos7 tzdb-2020c]# make rearguard_tarballs I get the following file as a result $tzdataunknown-rearguard.tar.gz I have reproduced this on centos6, centos7 and Mac OS 10.15.6. I get the following errors as well when I execute it: [root@centos6 tzdb-2020c]# make rearguard_tarballs >> ../../makeoutput.txt fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git Attached is the make output. This impacts us directly since we have customers in Fiji. I'm trying to reverse engineer and review what may be going wrong but any help would be great. -Carlos
I've found something that seems to work around the issue. Before I execute "make tarballs" or "make rearguard_tarballs" the version file has the 2020c value in it. When I run either of those commands I get the tzdataunknown-rearguard.tar.gz file which doesn't seem correct. When I check the version file it has the value "unknown" in it. If I update that version file and run "make tarballs" again it generates the tzdata2020c-rearguard.tar.gz file. This seems to also be a valid file as I was able to confirm it updated the Fiji time zone DST move. However, this seems like a hack and I'm not sure if it is reliable. -Carlos On 10/19/20, 3:03 PM, "Carlos Jimenez" <Carlos.Jimenez@servicenow.com> wrote: Hello, I've encountered two issues with the two latest files for the tz changes: https://data.iana.org/time-zones/releases/tzdb-2020c.tar.lz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz 1) The touch command for the new pacificnew empty file won't work on centos6 or centos7. The date format syntax is generating an error: I noticed this was already fixed here: https://github.com/eggert/tz/commit/ce89cbaa436f336dca4b239fa528405abd7d84b7... How long before that makes it to the /tzdb-2020c.tar.lz file? 2) Upon manually fixing the touch issue by replacing the touch command with the fixed version, I am now getting the wrong filenames for the rearguard file and tzcode and tzdata: Steps: [root@centos7 tzdb-2020c]# lzip -d tzdb-latest.tar.lz [root@centos7 tzdb-2020c]# mkdir tzdata-latest && tar xf tzdb-latest.tar -C tzdata-latest [root@centos7 tzdb-2020c]# pwd /home/tzdata/tzdata-2020c/tzdb-2020c [root@centos7 tzdb-2020c]# make rearguard_tarballs I get the following file as a result tzdataunknown-rearguard.tar.gz I have reproduced this on centos6, centos7 and Mac OS 10.15.6. I get the following errors as well when I execute it: [root@centos6 tzdb-2020c]# make rearguard_tarballs >> ../../makeoutput.txt fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git Attached is the make output. This impacts us directly since we have customers in Fiji. I'm trying to reverse engineer and review what may be going wrong but any help would be great. -Carlos
On 10/19/20 3:47 PM, Carlos Jimenez wrote:
Before I execute "make tarballs" or "make rearguard_tarballs" the version file has the 2020c value in it. When I run either of those commands I get the tzdataunknown-rearguard.tar.gz file which doesn't seem correct.
I see two explanations for the behavior you observed. 1. You used a 'make' that considers a file to be out-of-date if its timestamp exactly equals one of its dependencies. In the tzdb-2020c.tar.lz tarball, the files 'version' and 'NEWS' both have the timestamp 2020-10-16 18:18:46 UTC, and the Makefile says that 'version' depends on 'NEWS' which means that a 'make' that treats equal timestamps as out-of-date will try to rebuild 'version'. Since you were not in a git repository the version became "unknown". 2. You copied the distribution's files, thus altering their timestamps, or edited one of the files for some other reason; this can cause 'make' to try to rebuild 'version' because its timestamp is now older than one of its dependencies. Again, you weren't in a git repository so the version became "unknown". I doubt whether (1) was your problem since you mentioned CentOS whereas HP-UX 'make' is the only one I know that treats equal timestamps as out-of-date. But 'make' should do the right thing on HP-UX so I fixed (1) anyway, by installing the patch I mentioned in an email earlier today <https://mm.icann.org/pipermail/tz/2020-October/029401.html>. Most likely your problem was (2). If so, a simple fix would be for you to build from an unmodified tarball without copying or changing any file; that way, the 'version' file would have said "2020c" which would have been correct. But suppose you needed to modify some files before running 'make'; then what? Here, it strikes me that the Makefile can do something nicer than just setting the 'version' file to "unknown". Instead, it can look at the old 'version' file, and append "-dirty" to its contents (if they don't already end in "-dirty"). Had this behavior been present in 2020c, your 'version' file would have said "2020c-dirty" instead of just "unknown", and that would have been more helpful. I installed the attached patch into the development version to implement this idea. Please give 2020d a try now that it's out (it should fix your other problem), and if 2020d still has a problem please try 2020d with the attached patch.
participants (2)
-
Carlos Jimenez -
Paul Eggert