Bug#1068750: moment-timezone.js: FTBFS everywhere
Hi Santiago, On 30/04/2024 14:01, Santiago Vila wrote: It fails to build if tzdata is updated, but it never stops working. It just needs to be updated as often as tzdata is. But if you have a suggestion to make this more automatic, I would love to hear it.. Sorry, I still don't get it. Why does the package build needs to fail if tzdata is updated? What happens if we allow the package to be built anyway? (as in the attached patch). Would the resulting package be broken in any way? It works, but then there is no way to embed the (effective) tzdata version into the moment-timezone.js version, so you could have identical source packages producing binaries with the same version and different contents, and no way to depend on it. Plus, it almost always fails to build anyway, because many of the tests need to be adjusted when tzdata changes. The (better) alternative would be to make it always use a fixed tzdata version, but then tzdata migrations will be blocked each time until I upload a new version. I have been doing this very repetitive maintenance for years! Well, I get that you have to make a new upload so that the package is current. What I don't get is that the package fails to build. At most, it would result in an improved package, not worse. Or maybe I'm missing anything. What I described above, but I am really open to suggestions on how to better handle this. -- Martina Ferrari
Bug#1068750: moment-timezone.js: FTBFS everywhere
# Fail the build if the tzdata package does not match TZVER. grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi Yes, this is expected after each update to tzdata. I'm curious: Does this package embed the information from tzdata into javascript code, in such a way that a change in tzdata requires a rebuild? Yes. It is the only way I found to keep the package aligned with tzdata while ensuring it is fully built from source: upstream ships the pre-compiled tzdata information, so I regenerate those files using the tzdata package. I think it would be highly desirable to find a way for this package to do what it's supposed to do without having to fix it in oldstable and stable every year. Without a new upload, I cannot imagine how.. :-/ (In fact, I asked Paul Gevers about this, he says that a package which we know for sure that it will fail to build during the support time of the release is RC). It fails to build if tzdata is updated, but it never stops working. It just needs to be updated as often as tzdata is. But if you have a suggestion to make this more automatic, I would love to hear it.. Sorry, I still don't get it. Why does the package build needs to fail if tzdata is updated? What happens if we allow the package to be built anyway? (as in the attached patch). Would the resulting package be broken in any way? I have been doing this very repetitive maintenance for years! Well, I get that you have to make a new upload so that the package is current. What I don't get is that the package fails to build. At most, it would result in an improved package, not worse. Or maybe I'm missing anything. Thanks.--- a/debian/control +++ b/debian/control @@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13) , dh-sequence-nodejs , uglifyjs , ts-node + , tzdata (>= 2024a) , tzdata-legacy (>= 2024a) Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/js-team/moment-timezone.js --- a/debian/rules +++ b/debian/rules @@ -23,10 +23,6 @@ all: binary %: dh $@ -execute_before_dh_auto_configure: - # Fail the build if the tzdata package does not match TZVER. - grep -q '^# version $(TZVER)$$' /usr/share/zoneinfo/tzdata.zi - override_dh_auto_build: $(TARGETS) execute_before_dh_auto_test: tests/zones/zulu.js
Bug#1068750: moment-timezone.js: FTBFS everywhere
Hi Santiago, On Wed, 10 Apr 2024 12:39:54 +0200 Santiago Vila wrote: Dear maintainer: This package currently fails to build from source in all supported distributions. # Fail the build if the tzdata package does not match TZVER. grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi Yes, this is expected after each update to tzdata. I'm curious: Does this package embed the information from tzdata into javascript code, in such a way that a change in tzdata requires a rebuild? Yes. It is the only way I found to keep the package aligned with tzdata while ensuring it is fully built from source: upstream ships the pre-compiled tzdata information, so I regenerate those files using the tzdata package. I think it would be highly desirable to find a way for this package to do what it's supposed to do without having to fix it in oldstable and stable every year. Without a new upload, I cannot imagine how.. :-/ (In fact, I asked Paul Gevers about this, he says that a package which we know for sure that it will fail to build during the support time of the release is RC). It fails to build if tzdata is updated, but it never stops working. It just needs to be updated as often as tzdata is. But if you have a suggestion to make this more automatic, I would love to hear it.. I have been doing this very repetitive maintenance for years! -- Martina Ferrari
Bug#1068750: moment-timezone.js: FTBFS everywhere
Package: src:moment-timezone.js Version: 0.5.32+dfsg1-2+2021a Severity: serious Tags: bullseye bookworm trixie sid ftbfs Dear maintainer: This package currently fails to build from source in all supported distributions. make[1]: Leaving directory '/<>' dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf debian/rules execute_before_dh_auto_configure make[1]: Entering directory '/<>' # Fail the build if the tzdata package does not match TZVER. grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:24: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 See also: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/moment-timezone.js.html I'm curious: Does this package embed the information from tzdata into javascript code, in such a way that a change in tzdata requires a rebuild? I think it would be highly desirable to find a way for this package to do what it's supposed to do without having to fix it in oldstable and stable every year. (In fact, I asked Paul Gevers about this, he says that a package which we know for sure that it will fail to build during the support time of the release is RC). Thanks.
