tzcode and tzdata tar base make checks fail
Cygwin uses separate packages of tzcode programs and tzdata files verbatim to support standard local time zones in preference to limited native data. Running make check on the separate tar file fails in both cases. When I took over the packages, I provided basic checks, but reviewed and changed the builds this release, and would like to reenable the built in checks you provide and mentioned recently. The attached logs show the results of having the package build scripts run `make check` from the package build directory which is set up with symlinks to each of the tar sources. Is there anything obviously missing or incorrect with `make check` invocations which could cause the observed failures, or things that may need changed? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-12-19 15:42, Brian Inglis via tz wrote:
The attached logs show the results of having the package build scripts run `make check` from the package build directory which is set up with symlinks to each of the tar sources.
Is there anything obviously missing or incorrect with `make check` invocations
The 'make check' rule checks all of tzdb, both code and data. In those logs it fails in a tzcode-only build because some data files are missing, and it fails in a tzdata-only build because some code files are missing. One fix would be to get both code and data into the same directory, do a 'make check' there, and then use that directory to generate the programs and/or data that you need (possibly as separate Cygwin packages).
On 2025-12-19 19:27, Paul Eggert wrote:
On 2025-12-19 15:42, Brian Inglis via tz wrote:
The attached logs show the results of having the package build scripts run `make check` from the package build directory which is set up with symlinks to each of the tar sources.
Is there anything obviously missing or incorrect with `make check` invocations
The 'make check' rule checks all of tzdb, both code and data. In those logs it fails in a tzcode-only build because some data files are missing, and it fails in a tzdata-only build because some code files are missing.
One fix would be to get both code and data into the same directory, do a 'make check' there, and then use that directory to generate the programs and/or data that you need (possibly as separate Cygwin packages).
For checking, I create symlinks to /dev/null for files missing from VERSION_DEPS, and make -k check now seems to be working mostly normally with both tar sources, except tzdata is trying to rebuild executables, rather than using the installed release. Copying from /usr/*bin/ does not work. Any suggestions for an adequate bypass? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-12-29 13:05, Brian Inglis via tz wrote:
On 2025-12-19 19:27, Paul Eggert wrote:
One fix would be to get both code and data into the same directory, do a 'make check' there, and then use that directory to generate the programs and/or data that you need (possibly as separate Cygwin packages).
For checking, I create symlinks to /dev/null for files missing from VERSION_DEPS, and make -k check now seems to be working mostly normally with both tar sources, except tzdata is trying to rebuild executables, rather than using the installed release.
Copying from /usr/*bin/ does not work. Any suggestions for an adequate bypass?
The simplest suggestion I can think of is the one quoted above. That is, when building the data, don't merely download <https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz>. Instead, download the combined tarball <https://data.iana.org/time-zones/releases/tzdb-2025c.tar.lz> (or, if you prefer, download both <https://data.iana.org/time-zones/releases/tzcode2025c.tar.gz> and <https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz>), and build from the combined set of files. Similarly for tzcode. But come to think of it, there's little point to running "make check" for tzcode, as the test cases all come from tzdata. So don't bother trying to run "make check" for tzcode, and for tzdata follow the procedure described above. It should be possible to complicate the Makefile so that "make check" does something reasonable in a tzdata-only (or tzcode-only) directory. However, that would take some work and I don't see why the work would be needed, if the simple suggestion works.
On 2025-12-31 00:58, Paul Eggert wrote:
On 2025-12-29 13:05, Brian Inglis via tz wrote:
On 2025-12-19 19:27, Paul Eggert wrote:
One fix would be to get both code and data into the same directory, do a 'make check' there, and then use that directory to generate the programs and/ or data that you need (possibly as separate Cygwin packages).
For checking, I create symlinks to /dev/null for files missing from VERSION_DEPS, and make -k check now seems to be working mostly normally with both tar sources, except tzdata is trying to rebuild executables, rather than using the installed release.
Copying from /usr/*bin/ does not work. Any suggestions for an adequate bypass?
The simplest suggestion I can think of is the one quoted above. That is, when building the data, don't merely download <https://data.iana.org/time-zones/ releases/tzdata2025c.tar.gz>. Instead, download the combined tarball <https:// data.iana.org/time-zones/releases/tzdb-2025c.tar.lz> (or, if you prefer, download both <https://data.iana.org/time-zones/releases/tzcode2025c.tar.gz> and <https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz>), and build from the combined set of files.
Similarly for tzcode. But come to think of it, there's little point to running "make check" for tzcode, as the test cases all come from tzdata. So don't bother trying to run "make check" for tzcode, and for tzdata follow the procedure described above.
It should be possible to complicate the Makefile so that "make check" does something reasonable in a tzdata-only (or tzcode-only) directory. However, that would take some work and I don't see why the work would be needed, if the simple suggestion works.
I would suggest at least the tzdata case should work standalone, as many distros use only that, possibly with their own historical backward compatibility customizations, and adapt or merge patches/selections from tzcode into their own libc or bin code base (pkgs.org and repology.org have no hits for tzcode). -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-12-31 10:30, Brian Inglis via tz wrote:
I would suggest at least the tzdata case should work standalone, as many distros use only that
Please feel free to suggest specific Makefile changes to do that. I'm not seeing this as high priority, as it's unlikely that downstream uses of "make check" will catch data bugs that we didn't catch upstream (we routinely run "make check" before each release).
On 2025-12-31 12:50, Paul Eggert wrote:
On 2025-12-31 10:30, Brian Inglis via tz wrote:
I would suggest at least the tzdata case should work standalone, as many distros use only that
Please feel free to suggest specific Makefile changes to do that. I'm not seeing this as high priority, as it's unlikely that downstream uses of "make check" will catch data bugs that we didn't catch upstream (we routinely run "make check" before each release).
Given no other comments we can await further input to decide an approach. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
participants (2)
-
Brian Inglis -
Paul Eggert