Bug#1084190: breakage due to tzdata System V name removal
Control: affects -1 -src:systemd On Mon, 21 Oct 2024 17:38:24 +0100 Luca Boccassi wrote: > Control: affects -1 src:systemd > > This also breaks systemd's test suite, as it was using the CET > shortcut, fix in progress: > > https://github.com/systemd/systemd/pull/34847 The test case has been updated in unstable in 256.7-3.
Bug#1084190: breakage due to tzdata System V name removal
Control: affects -1 src:systemd This also breaks systemd's test suite, as it was using the CET shortcut, fix in progress: https://github.com/systemd/systemd/pull/34847
Bug#1084190: breakage due to tzdata System V name removal
On 11/10/2024 10:45, Rebecca N. Palmer wrote: I haven't checked recent FTBFS bugs for other affected packages. I have now, and it looks like there are several more: #1084245, #1084256, #1084286, #1084293 and maybe #1084262, #1084282, #1084888. Also, #1084301 is explicitly checking the version of tzdata.
Bug#1084190: breakage due to tzdata System V name removal
That didn't work because there are 6 places that need to be patched, not 2. Working version (in that it passes build+autopkgtest): https://salsa.debian.org/rnpalmer-guest/glib I think this means we now have patches for all the known instances of this bug, but some of them haven't been accepted yet, and I haven't checked recent FTBFS bugs for other affected packages.
Bug#1084190: breakage due to tzdata System V name removal
Sorry, that doesn't work; I don't yet know why. https://salsa.debian.org/rnpalmer-guest/glib/-/jobs/6410813 On 06/10/2024 17:36, Rebecca N. Palmer wrote: And yes, that glib test failure looks like another instance of this. Changing g_time_zone_get_abbreviation (tz, 0) to g_time_zone_get_abbreviation (tz, g_time_zone_find_interval(tz, G_TIME_TYPE_STANDARD, 0)) (and the g_time_zone_get_abbreviation (tz, 1) later in the test to g_time_zone_get_abbreviation (tz, g_time_zone_find_interval(tz, G_TIME_TYPE_DAYLIGHT, 1500 /*approximately 6 months, in seconds, to get into DST*/)) would probably fix it
Bug#1084190: breakage due to tzdata System V name removal
tzdata 2024b-3 also moves these short names to tzdata-legacy, causing 2 more failures (golang-github-teambition-rrule-go and reposurgeon). These can probably be fixed by test-depending on tzdata-legacy.
Bug#1084190: breakage due to tzdata System V name removal
Yavor Doganov wrote: > Yes, I confirm it's the same problem (fixed in 1.30.0-9). Sorry; I meant gnustep-base/1.30.0-8.
Bug#1084190: breakage due to tzdata System V name removal
On Sun, Oct 06, 2024 at 01:41:50PM +0100, Rebecca N. Palmer wrote: > Package: tzdata > Version: 2024b-2 > Severity: serious > Justification: fails multiple autopkgtests > > tadata 2024b changes the meaning of short names such as 'EST' from > 'always this offset' to 'alias for a place that currently uses this > offset'. > gnustep-base doesn't display a detailed enough error to say, but > plausibly might be a similar problem. Yes, I confirm it's the same problem (fixed in 1.30.0-9). The NSCalendarDate tests expect "MET" but "CET" is returned (most probably because it sorts as the first -- both are symlinks to Europe/Brussels).
Bug#1084190: breakage due to tzdata System V name removal
I now have dateparser and pandas building (but only have the right to actually upload pandas). https://salsa.debian.org/rnpalmer-guest/dateparser And yes, that glib test failure looks like another instance of this. Changing g_time_zone_get_abbreviation (tz, 0) to g_time_zone_get_abbreviation (tz, g_time_zone_find_interval(tz, G_TIME_TYPE_STANDARD, 0)) (and the g_time_zone_get_abbreviation (tz, 1) later in the test to g_time_zone_get_abbreviation (tz, g_time_zone_find_interval(tz, G_TIME_TYPE_DAYLIGHT, 1500 /*approximately 6 months, in seconds, to get into DST*/)) would probably fix it, but I haven't actually tried this, and I also don't know whether anything user-facing is currently relying on g_time_zone_get_abbreviation (tz, 0). It also raises the question of whether there might be more such packages.
Processed: Re: Bug#1084190: breakage due to tzdata System V name removal
Processing control commands: > tags -1 ftbfs Bug #1084190 [tzdata] breakage due to tzdata System V name removal Added tag(s) ftbfs. > affects -1 src:glib2.0 Bug #1084190 [tzdata] breakage due to tzdata System V name removal Added indication that 1084190 affects src:glib2.0 -- 1084190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1084190: breakage due to tzdata System V name removal
Control: tags -1 ftbfs
Control: affects -1 src:glib2.0
On Sun, Oct 06, 2024 at 01:41:50PM +0100, Rebecca N. Palmer wrote:
> Package: tzdata
> Version: 2024b-2
> Severity: serious
> Justification: fails multiple autopkgtests
>
> tadata 2024b changes the meaning of short names such as 'EST' from 'always
> this offset' to 'alias for a place that currently uses this offset'. This
> causes several autopkgtest failures:
>...
This is likely also what broke the glib2.0 build tests:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glib2.0.html
https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=alpha&ver=2.82.1-1&stamp=1728213262&raw=0
...
21/387 glib:glib+core+slow / gdatetime
ERROR 7.57s killed by signal 6 SIGABRT
― ✀ ―
stderr:
**
GLib:ERROR:../../../glib/tests/gdatetime.c:2960:test_posix_parse: assertion
failed (g_time_zone_get_abbreviation (tz, 0) == "PST"): ("LMT" == "PST")
(test program exited with status code -6)
――
...
cu
Adrian
Bug#1084190: breakage due to tzdata System V name removal
Package: tzdata Version: 2024b-2 Severity: serious Justification: fails multiple autopkgtests tadata 2024b changes the meaning of short names such as 'EST' from 'always this offset' to 'alias for a place that currently uses this offset'. This causes several autopkgtest failures: - pandas and dateparser: use python3-tz and create test reference objects by passing a pytz.timezone directly to datetime.datetime. This has never worked for non-constant time zones, and the python3-tz documentation explicitly warns against it (https://pythonhosted.org/pytz/). Because this is being done in the test reference and not the actual library, a likely fix is simply to change the test to either use a constant (Etc/GMT-x) timezone or use pytz localize(). I am attempting this on both of them, though my first build of dateparser failed: https://salsa.debian.org/science-team/pandas/-/commit/02fd14ebca5bf79f54e65a1a94df23361fa31a84 https://salsa.debian.org/rnpalmer-guest/dateparser - postgresql-16: is explicitly testing the handling of dates far in the past, which this really does (slightly) change the meaning of. I'm not sure what should be done here. gnustep-base doesn't display a detailed enough error to say, but plausibly might be a similar problem.
