| Message ID | 20210110164711.1708062-2-bernd.kuhls@t-online.de |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/2] package/zic: bump version to 2020f | expand |
>>>>> "Bernd" == Bernd Kuhls <bernd.kuhls@t-online.de> writes: > Release notes: > https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html > Upstream removed timezones pacificnew and systemv: > https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Committed to 2020.02.x and 2020.11.x, thanks.
Hello, Le 12/01/2021 à 18:40, Peter Korsgaard a écrit : >>>>>> "Bernd" == Bernd Kuhls <bernd.kuhls@t-online.de> writes: > > > Release notes: > > https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html > > > Upstream removed timezones pacificnew and systemv: > > https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html > > > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> > > Committed to 2020.02.x and 2020.11.x, thanks. > This version bump seems introduce a regression in the Buildroot testsuite for timezone tests TestGlibcAllTimezone and TestGlibcNonDefaultLimitedTimezone. See: https://gitlab.com/buildroot.org/buildroot/-/pipelines/253940390/failures The Buildroot configuration was: BR2_TARGET_TZ_INFO=y BR2_TARGET_TZ_ZONELIST="northamerica" BR2_TARGET_LOCALTIME="America/New_York" And the test is checking "date" output: tz, _ = self.emulator.run("date +%Z") self.assertEqual(tz[0].strip(), "EST") tz, _ = self.emulator.run("TZ=UTC date +%Z") self.assertEqual(tz[0].strip(), "UTC") tz, _ = self.emulator.run("TZ=America/Los_Angeles date +%Z") self.assertEqual(tz[0].strip(), "PST") tz, _ = self.emulator.run("TZ=Europe/Paris date +%Z") self.assertEqual(tz[0].strip(), "Europe") This patch has been backported to stable version 2020.11.2 and 2020.02.10. Can you have a look? Best regards, Romain
>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes: > Hello, > Le 12/01/2021 à 18:40, Peter Korsgaard a écrit : >>>>>>> "Bernd" == Bernd Kuhls <bernd.kuhls@t-online.de> writes: >> >> > Release notes: >> > https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html >> >> > Upstream removed timezones pacificnew and systemv: >> > https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html >> >> > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> >> >> Committed to 2020.02.x and 2020.11.x, thanks. >> > This version bump seems introduce a regression in the Buildroot testsuite for > timezone tests TestGlibcAllTimezone and TestGlibcNonDefaultLimitedTimezone. > See: > https://gitlab.com/buildroot.org/buildroot/-/pipelines/253940390/failures > The Buildroot configuration was: > BR2_TARGET_TZ_INFO=y > BR2_TARGET_TZ_ZONELIST="northamerica" > BR2_TARGET_LOCALTIME="America/New_York" > And the test is checking "date" output: > tz, _ = self.emulator.run("date +%Z") > self.assertEqual(tz[0].strip(), "EST") > tz, _ = self.emulator.run("TZ=UTC date +%Z") > self.assertEqual(tz[0].strip(), "UTC") > tz, _ = self.emulator.run("TZ=America/Los_Angeles date +%Z") > self.assertEqual(tz[0].strip(), "PST") > tz, _ = self.emulator.run("TZ=Europe/Paris date +%Z") > self.assertEqual(tz[0].strip(), "Europe") > This patch has been backported to stable version 2020.11.2 and 2020.02.10. > Can you have a look? Are you able to reproduce it? When I gave it a quick test here I got sensible output from date. But maybe I missed something?
Hello Peter, Le 14/02/2021 à 16:30, Peter Korsgaard a écrit : >>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes: > > > Hello, > > Le 12/01/2021 à 18:40, Peter Korsgaard a écrit : > >>>>>>> "Bernd" == Bernd Kuhls <bernd.kuhls@t-online.de> writes: > >> > >> > Release notes: > >> > https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html > >> > >> > Upstream removed timezones pacificnew and systemv: > >> > https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html > >> > >> > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> > >> > >> Committed to 2020.02.x and 2020.11.x, thanks. > >> > > > This version bump seems introduce a regression in the Buildroot testsuite for > > timezone tests TestGlibcAllTimezone and TestGlibcNonDefaultLimitedTimezone. > > > See: > > https://gitlab.com/buildroot.org/buildroot/-/pipelines/253940390/failures > > > The Buildroot configuration was: > > BR2_TARGET_TZ_INFO=y > > BR2_TARGET_TZ_ZONELIST="northamerica" > > BR2_TARGET_LOCALTIME="America/New_York" > > > And the test is checking "date" output: > > > tz, _ = self.emulator.run("date +%Z") > > self.assertEqual(tz[0].strip(), "EST") > > > tz, _ = self.emulator.run("TZ=UTC date +%Z") > > self.assertEqual(tz[0].strip(), "UTC") > > > tz, _ = self.emulator.run("TZ=America/Los_Angeles date +%Z") > > self.assertEqual(tz[0].strip(), "PST") > > > tz, _ = self.emulator.run("TZ=Europe/Paris date +%Z") > > self.assertEqual(tz[0].strip(), "Europe") > > > This patch has been backported to stable version 2020.11.2 and 2020.02.10. > > Can you have a look? > > Are you able to reproduce it? When I gave it a quick test here I got > sensible output from date. > > But maybe I missed something? > Yes, I tried on master, 2020.02.x, 2020.11.x and 2020.02.9 and 2020.11.1 (before the version bump). I'm looking at it but I don't have a patch yet. Best regards, Romain
>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes: Hi, >> > This patch has been backported to stable version 2020.11.2 and 2020.02.10. >> > Can you have a look? >> >> Are you able to reproduce it? When I gave it a quick test here I got >> sensible output from date. >> >> But maybe I missed something? > Yes, I tried on master, 2020.02.x, 2020.11.x and 2020.02.9 and 2020.11.1 (before > the version bump). > I'm looking at it but I don't have a patch yet. Ok, thanks. There was a report on IRC that timezones on uClibc were broken as well because of an incompatibility between the new tzdata files and tzdump.
On 14/02/2021 17:34:47+0100, Peter Korsgaard wrote: > >>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes: > > Hi, > > >> > This patch has been backported to stable version 2020.11.2 and 2020.02.10. > >> > Can you have a look? > >> > >> Are you able to reproduce it? When I gave it a quick test here I got > >> sensible output from date. > >> > >> But maybe I missed something? > > > Yes, I tried on master, 2020.02.x, 2020.11.x and 2020.02.9 and 2020.11.1 (before > > the version bump). > > > I'm looking at it but I don't have a patch yet. > > Ok, thanks. There was a report on IRC that timezones on uClibc were > broken as well because of an incompatibility between the new tzdata > files and tzdump. No, the issue is with zic that is not generating proper Tzif2 files (the tzif2 header is there twice).
Le 14/02/2021 à 19:21, Alexandre Belloni a écrit : > On 14/02/2021 17:34:47+0100, Peter Korsgaard wrote: >>>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes: >> >> Hi, >> >> >> > This patch has been backported to stable version 2020.11.2 and 2020.02.10. >> >> > Can you have a look? >> >> >> >> Are you able to reproduce it? When I gave it a quick test here I got >> >> sensible output from date. >> >> >> >> But maybe I missed something? >> >> > Yes, I tried on master, 2020.02.x, 2020.11.x and 2020.02.9 and 2020.11.1 (before >> > the version bump). >> >> > I'm looking at it but I don't have a patch yet. >> >> Ok, thanks. There was a report on IRC that timezones on uClibc were >> broken as well because of an incompatibility between the new tzdata >> files and tzdump. > > No, the issue is with zic that is not generating proper Tzif2 files (the > tzif2 header is there twice). > > The issue happen on Glibc toolchain. I added back the previous default zic format "fat" instead of "slim" [1] to pass the test. The default format has been changed in 2020b release. I'm not sure if we should keep the "fat" format... [1] https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 Best regards, Romain
On 2021-02-14 19:35 +0100, Romain Naour spake thusly: > Le 14/02/2021 à 19:21, Alexandre Belloni a écrit : > > On 14/02/2021 17:34:47+0100, Peter Korsgaard wrote: > >> Ok, thanks. There was a report on IRC that timezones on uClibc were > >> broken as well because of an incompatibility between the new tzdata > >> files and tzdump. > > No, the issue is with zic that is not generating proper Tzif2 files (the > > tzif2 header is there twice). > The issue happen on Glibc toolchain. The issues *also* happends on uClibc toolchains (as reported on IRC), and I suspect it also happens on musl toolchains (as it uses the same tzdata and zic as for glibc). And Alexandre investigated quickly a few days ago, and reported on IRC (quoting): 01:01 < abelloni> mcon: temporary workaround, you can revert 7868289fd53480201f8be7b72097246b7923611c. 01:02 < abelloni> y_morin: ^ 01:02 < abelloni> y_morin: since the bump the zic output has two TZif2 headers, this breaks tzdump 01:03 < abelloni> maybe this also break glibc, I didn't check yet So it looks like the duplicated header is causing issues everywhere... > I added back the previous default zic format "fat" instead of "slim" [1] to pass > the test. The default format has been changed in 2020b release. > I'm not sure if we should keep the "fat" format... > [1] https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 From this, it looks like the 'fat' format is not 2038-safe, while the 'slim' one is. To be noted: the glibc version used in thoses tests is 2.18, released in August 2013... It seems the support for the slim format was only introduced with glibc 2.32. 2.31 has no mention of either slim or fat, while 2.32 mention both, as it synced with upstream tz 2020a; the previous sync was with 2018i... So, what I suggest we do: - for master (and next): revert to fat for external glibc, use slim for internal glibc (check for c-sky) - for maintenance branches: unconditionally revert to fat. Thoughts? Regards, Yann E. MORIN.
Le 14/02/2021 à 21:35, Yann E. MORIN a écrit : > On 2021-02-14 19:35 +0100, Romain Naour spake thusly: >> Le 14/02/2021 à 19:21, Alexandre Belloni a écrit : >>> On 14/02/2021 17:34:47+0100, Peter Korsgaard wrote: >>>> Ok, thanks. There was a report on IRC that timezones on uClibc were >>>> broken as well because of an incompatibility between the new tzdata >>>> files and tzdump. >>> No, the issue is with zic that is not generating proper Tzif2 files (the >>> tzif2 header is there twice). >> The issue happen on Glibc toolchain. > > The issues *also* happends on uClibc toolchains (as reported on IRC), > and I suspect it also happens on musl toolchains (as it uses the same > tzdata and zic as for glibc). Ok good to know! > > And Alexandre investigated quickly a few days ago, and reported on IRC > (quoting): > > 01:01 < abelloni> mcon: temporary workaround, you can revert 7868289fd53480201f8be7b72097246b7923611c. > 01:02 < abelloni> y_morin: ^ > 01:02 < abelloni> y_morin: since the bump the zic output has two TZif2 headers, this breaks tzdump > 01:03 < abelloni> maybe this also break glibc, I didn't check yet > > So it looks like the duplicated header is causing issues everywhere... > >> I added back the previous default zic format "fat" instead of "slim" [1] to pass >> the test. The default format has been changed in 2020b release. >> I'm not sure if we should keep the "fat" format... >> [1] https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 > > From this, it looks like the 'fat' format is not 2038-safe, while the > 'slim' one is. > > To be noted: the glibc version used in thoses tests is 2.18, released in > August 2013... Yes, the codesourcery toolchain is really old and maybe we should stop using it. I believe we should focus on recent toolchain testing in the autobuilders with stable or bleeding-edge Bootlin prebuilt toolchain. But this is another topic :) > > It seems the support for the slim format was only introduced with glibc > 2.32. 2.31 has no mention of either slim or fat, while 2.32 mention > both, as it synced with upstream tz 2020a; the previous sync was with > 2018i... The slim support has been added in zic with 2019b release: https://github.com/eggert/tz/commit/7879a3fba1310da0ccc1c336515b5b4a409c3ccb > > So, what I suggest we do: > > - for master (and next): revert to fat for external glibc, use slim > for internal glibc (check for c-sky) What's the plan to support slim format ? > > - for maintenance branches: unconditionally revert to fat. OK Best regards, Romain > > Thoughts? > > Regards, > Yann E. MORIN. >
On 14/02/2021 21:35:43+0100, Yann E. MORIN wrote: > On 2021-02-14 19:35 +0100, Romain Naour spake thusly: > > Le 14/02/2021 à 19:21, Alexandre Belloni a écrit : > > > On 14/02/2021 17:34:47+0100, Peter Korsgaard wrote: > > >> Ok, thanks. There was a report on IRC that timezones on uClibc were > > >> broken as well because of an incompatibility between the new tzdata > > >> files and tzdump. > > > No, the issue is with zic that is not generating proper Tzif2 files (the > > > tzif2 header is there twice). > > The issue happen on Glibc toolchain. > > The issues *also* happends on uClibc toolchains (as reported on IRC), > and I suspect it also happens on musl toolchains (as it uses the same > tzdata and zic as for glibc). > > And Alexandre investigated quickly a few days ago, and reported on IRC > (quoting): > > 01:01 < abelloni> mcon: temporary workaround, you can revert 7868289fd53480201f8be7b72097246b7923611c. > 01:02 < abelloni> y_morin: ^ > 01:02 < abelloni> y_morin: since the bump the zic output has two TZif2 headers, this breaks tzdump > 01:03 < abelloni> maybe this also break glibc, I didn't check yet > > So it looks like the duplicated header is causing issues everywhere... > > > I added back the previous default zic format "fat" instead of "slim" [1] to pass > > the test. The default format has been changed in 2020b release. > > I'm not sure if we should keep the "fat" format... > > [1] https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 > > From this, it looks like the 'fat' format is not 2038-safe, while the > 'slim' one is. > > To be noted: the glibc version used in thoses tests is 2.18, released in > August 2013... > > It seems the support for the slim format was only introduced with glibc > 2.32. 2.31 has no mention of either slim or fat, while 2.32 mention > both, as it synced with upstream tz 2020a; the previous sync was with > 2018i... > > So, what I suggest we do: > > - for master (and next): revert to fat for external glibc, use slim > for internal glibc (check for c-sky) > > - for maintenance branches: unconditionally revert to fat. > > Thoughts? > I'll add that tzdump probably needs to be rewritten (or fixing but a rewrite is probably better) to handle the slim format, until then, you'd have to use the fat format for uclibc.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, > So it looks like the duplicated header is causing issues everywhere... >> I added back the previous default zic format "fat" instead of "slim" [1] to pass >> the test. The default format has been changed in 2020b release. >> I'm not sure if we should keep the "fat" format... >> [1] https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 https://github.com/eggert/tz/commit/7879a3fba1310da0ccc1c336515b5b4a409c3ccb (the commit adding the slim variant) gives more info. > To be noted: the glibc version used in thoses tests is 2.18, released in > August 2013... > It seems the support for the slim format was only introduced with glibc > 2.32. 2.31 has no mention of either slim or fat, while 2.32 mention > both, as it synced with upstream tz 2020a; the previous sync was with > 2018i... It is also not clear to me exactly when the slim format support was added to glibc, but as additional datapoints, I have it working with a 2.30 based toolchain built by 2020.02.x and a 2.31 based one built by 2020.11.x. > So, what I suggest we do: > - for master (and next): revert to fat for external glibc, use slim > for internal glibc (check for c-sky) > - for maintenance branches: unconditionally revert to fat. Sounds sensible. Please do it in 2 patches, E.G. first use fat everywhere, and then as a followup patch change to slim for internal glibc.
>>>>> "Alexandre" == Alexandre Belloni <alexandre.belloni@bootlin.com> writes: Hi, > I'll add that tzdump probably needs to be rewritten (or fixing but a > rewrite is probably better) to handle the slim format, until then, you'd > have to use the fat format for uclibc. Ok, thanks.
Hello, Le lun. 15 févr. 2021 à 10:12, Peter Korsgaard <peter@korsgaard.com> a écrit : > >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > > Hi, > > > So it looks like the duplicated header is causing issues everywhere... > > >> I added back the previous default zic format "fat" instead of "slim" > [1] to pass > >> the test. The default format has been changed in 2020b release. > >> I'm not sure if we should keep the "fat" format... > >> [1] > https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 > > > https://github.com/eggert/tz/commit/7879a3fba1310da0ccc1c336515b5b4a409c3ccb > (the commit adding the slim variant) gives more info. > > > To be noted: the glibc version used in thoses tests is 2.18, released in > > August 2013... > > > It seems the support for the slim format was only introduced with glibc > > 2.32. 2.31 has no mention of either slim or fat, while 2.32 mention > > both, as it synced with upstream tz 2020a; the previous sync was with > > 2018i... > > It is also not clear to me exactly when the slim format support was > added to glibc, but as additional datapoints, I have it working with a > 2.30 based toolchain built by 2020.02.x and a 2.31 based one built by > 2020.11.x. > Actually we have the same issue with Bootlin armv5-eabi--glibc--bleeding-edge-2018.02-1 that use glibc 2.27 (tzcode 2017b). There is no problem with glibc-2.28 (tzcode 2018g) https://toolchains.bootlin.com/downloads/releases/toolchains/armv5-eabi/fragments/armv5-eabi--glibc--bleeding-edge-2018.02-1.frag Romain > > > > > So, what I suggest we do: > > > - for master (and next): revert to fat for external glibc, use slim > > for internal glibc (check for c-sky) > > > - for maintenance branches: unconditionally revert to fat. > > Sounds sensible. Please do it in 2 patches, E.G. first use fat > everywhere, and then as a followup patch change to slim for internal > glibc. > > -- > Bye, Peter Korsgaard >
>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes: Hi, >> It is also not clear to me exactly when the slim format support was >> added to glibc, but as additional datapoints, I have it working with a >> 2.30 based toolchain built by 2020.02.x and a 2.31 based one built by >> 2020.11.x. >> > Actually we have the same issue with Bootlin > armv5-eabi--glibc--bleeding-edge-2018.02-1 that use glibc 2.27 (tzcode > 2017b). > There is no problem with glibc-2.28 (tzcode 2018g) > https://toolchains.bootlin.com/downloads/releases/toolchains/armv5-eabi/fragments/armv5-eabi--glibc--bleeding-edge-2018.02-1.frag Ahh, good catch. Then it is probably because of the addition of: commit fc79706a3233b02909b1a75b1e43e40915eb5a04 Author: Florian Weimer <fweimer@redhat.com> Date: Fri May 11 16:30:30 2018 +0200 time: Use 64-bit time values for time zone parsing
diff --git a/package/tzdata/tzdata.hash b/package/tzdata/tzdata.hash index 8f0a9050fc..6a1ccc128d 100644 --- a/package/tzdata/tzdata.hash +++ b/package/tzdata/tzdata.hash @@ -1,4 +1,4 @@ -# From https://mm.icann.org/pipermail/tz-announce/2020-April/000058.html -sha512 2a2fc2e3ad8a6e4c574242296c847ad582c2c1d86add9c556e65c812d19b9528522e3c4dddb5239017091825d2acc5a2ccaf21dc41b900b6c300ef4264cc5a9d tzdata2020a.tar.gz +# From https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html +sha512 dd312def18c807452fda2e697514e2064c5f51ebdbedd0cfe6f231252c76ee5d4409f653b295ed5657b7d30b868690047fdb70a10942e69eaa40b77473e3f9ca tzdata2020f.tar.gz # Locally computed: sha256 0613408568889f5739e5ae252b722a2659c02002839ad970a63dc5e9174b27cf LICENSE diff --git a/package/tzdata/tzdata.mk b/package/tzdata/tzdata.mk index 114d60195e..41c4971584 100644 --- a/package/tzdata/tzdata.mk +++ b/package/tzdata/tzdata.mk @@ -4,7 +4,7 @@ # ################################################################################ -TZDATA_VERSION = 2020a +TZDATA_VERSION = 2020f TZDATA_SOURCE = tzdata$(TZDATA_VERSION).tar.gz TZDATA_SITE = https://www.iana.org/time-zones/repository/releases TZDATA_STRIP_COMPONENTS = 0 @@ -17,7 +17,7 @@ TZDATA_LICENSE_FILES = LICENSE # dependencies TZDATA_DEFAULT_ZONELIST = \ africa antarctica asia australasia europe northamerica \ - southamerica pacificnew etcetera backward systemv factory + southamerica etcetera backward factory ifeq ($(call qstrip,$(BR2_TARGET_TZ_ZONELIST)),default) TZDATA_ZONELIST = $(TZDATA_DEFAULT_ZONELIST)
Release notes: https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html Upstream removed timezones pacificnew and systemv: https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> --- package/tzdata/tzdata.hash | 4 ++-- package/tzdata/tzdata.mk | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)