| Message ID | 20241028080425.2232475-1-jinfeng.wang.cn@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] v2 tzdata&tzcode-native: upgrade 2024a -> 2024b | expand |
Please ignore this patch. I will send a V3 later. Thanks. Jinfeng On 10/28/2024 4:04 PM, Wang, Jinfeng (CN) via lists.openembedded.org wrote: > From: Jinfeng Wang <jinfeng.wang.cn@windriver.com> > > Signed-off-by: Jinfeng Wang <jinfeng.wang.cn@windriver.com> > --- > ...all-back-if-legacy-System-V-PST8PDT-.patch | 79 +++++++++++++++++++ > meta/recipes-core/glib-2.0/glib.inc | 1 + > 2 files changed, 80 insertions(+) > create mode 100644 meta/recipes-core/glib-2.0/files/0001-gdatetime-test-Fall-back-if-legacy-System-V-PST8PDT-.patch > > diff --git a/meta/recipes-core/glib-2.0/files/0001-gdatetime-test-Fall-back-if-legacy-System-V-PST8PDT-.patch b/meta/recipes-core/glib-2.0/files/0001-gdatetime-test-Fall-back-if-legacy-System-V-PST8PDT-.patch > new file mode 100644 > index 0000000000..1909abb557 > --- /dev/null > +++ b/meta/recipes-core/glib-2.0/files/0001-gdatetime-test-Fall-back-if-legacy-System-V-PST8PDT-.patch > @@ -0,0 +1,79 @@ > +From 2edbf994f9625a564ecf4a6e7f39de077d6b3b77 Mon Sep 17 00:00:00 2001 > +From: Simon McVittie <smcv@debian.org> > +Date: Fri, 18 Oct 2024 11:23:42 +0100 > +Subject: [PATCH] gdatetime test: Fall back if legacy System V PST8PDT is not > + available > + > +On recent versions of Debian, PST8PDT is part of the tzdata-legacy > +package, which is not always installed and might disappear in future. > +Successfully tested with and without tzdata-legacy on Debian unstable. > + > +Upstream-Status: Backport [https://github.com/GNOME/glib/commit/fe2699369f79981dcf913af4cfd98b342b84a9c1] > +Signed-off-by: Simon McVittie <smcv@debian.org> > +Signed-off-by: Jinfeng Wang <jinfeng.wang.cn@windriver.com> > +--- > + glib/tests/gdatetime.c | 38 ++++++++++++++++++++++++++++++-------- > + 1 file changed, 30 insertions(+), 8 deletions(-) > + > +diff --git a/glib/tests/gdatetime.c b/glib/tests/gdatetime.c > +index d46f653ac..01498cb54 100644 > +--- a/glib/tests/gdatetime.c > ++++ b/glib/tests/gdatetime.c > +@@ -2930,6 +2930,8 @@ test_posix_parse (void) > + { > + GTimeZone *tz; > + GDateTime *gdt1, *gdt2; > ++ gint i1, i2; > ++ const char *expect_id; > + > + /* Check that an unknown zone name falls back to UTC. */ > + G_GNUC_BEGIN_IGNORE_DEPRECATIONS > +@@ -2952,17 +2954,37 @@ test_posix_parse (void) > + g_time_zone_unref (tz); > + > + /* This fails rules_from_identifier on Unix (though not on Windows) > +- * but passes anyway because PST8PDT is a zone name. > ++ * but can pass anyway because PST8PDT is a legacy System V zone name. > + */ > + tz = g_time_zone_new_identifier ("PST8PDT"); > ++ expect_id = "PST8PDT"; > ++ > ++#ifndef G_OS_WIN32 > ++ /* PST8PDT is in tzdata's "backward" set, packaged as tzdata-legacy and > ++ * not always present in some OSs; fall back to the equivalent geographical > ++ * name if the "backward" time zones are absent. */ > ++ if (tz == NULL) > ++ { > ++ g_test_message ("Legacy PST8PDT time zone not available, falling back"); > ++ tz = g_time_zone_new_identifier ("America/Los_Angeles"); > ++ expect_id = "America/Los_Angeles"; > ++ } > ++#endif > ++ > + g_assert_nonnull (tz); > +- g_assert_cmpstr (g_time_zone_get_identifier (tz), ==, "PST8PDT"); > +- g_assert_cmpstr (g_time_zone_get_abbreviation (tz, 0), ==, "PST"); > +- g_assert_cmpint (g_time_zone_get_offset (tz, 0), ==, - 8 * 3600); > +- g_assert (!g_time_zone_is_dst (tz, 0)); > +- g_assert_cmpstr (g_time_zone_get_abbreviation (tz, 1), ==, "PDT"); > +- g_assert_cmpint (g_time_zone_get_offset (tz, 1), ==,- 7 * 3600); > +- g_assert (g_time_zone_is_dst (tz, 1)); > ++ g_assert_cmpstr (g_time_zone_get_identifier (tz), ==, expect_id); > ++ /* a date in winter = non-DST */ > ++ gdt1 = g_date_time_new (tz, 2024, 1, 1, 0, 0, 0); > ++ i1 = g_time_zone_find_interval (tz, G_TIME_TYPE_STANDARD, g_date_time_to_unix (gdt1)); > ++ /* a date in summer = DST */ > ++ gdt2 = g_date_time_new (tz, 2024, 7, 1, 0, 0, 0); > ++ i2 = g_time_zone_find_interval (tz, G_TIME_TYPE_DAYLIGHT, g_date_time_to_unix (gdt2)); > ++ g_assert_cmpstr (g_time_zone_get_abbreviation (tz, i1), ==, "PST"); > ++ g_assert_cmpint (g_time_zone_get_offset (tz, i1), ==, - 8 * 3600); > ++ g_assert (!g_time_zone_is_dst (tz, i1)); > ++ g_assert_cmpstr (g_time_zone_get_abbreviation (tz, i2), ==, "PDT"); > ++ g_assert_cmpint (g_time_zone_get_offset (tz, i2), ==,- 7 * 3600); > ++ g_assert (g_time_zone_is_dst (tz, i2)); > + g_time_zone_unref (tz); > + > + tz = g_time_zone_new_identifier ("PST8PDT6:32:15"); > +-- > +2.34.1 > + > diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc > index 0855e6eb00..6dcb0eb866 100644 > --- a/meta/recipes-core/glib-2.0/glib.inc > +++ b/meta/recipes-core/glib-2.0/glib.inc > @@ -225,6 +225,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \ > file://0001-meson-Run-atomics-test-on-clang-as-well.patch \ > file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \ > file://0010-Do-not-hardcode-python-path-into-various-tools.patch \ > + file://0001-gdatetime-test-Fall-back-if-legacy-System-V-PST8PDT-.patch \ > file://skip-timeout.patch \ > " > SRC_URI:append:class-native = " file://relocate-modules.patch \ > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#206423): https://lists.openembedded.org/g/openembedded-core/message/206423 > Mute This Topic: https://lists.openembedded.org/mt/109253284/8617462 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [Jinfeng.Wang.CN@windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 1 Nov 2024, at 02:03, Wang, Jinfeng (CN) via lists.openembedded.org <Jinfeng.Wang.CN=windriver.com@lists.openembedded.org> wrote: > > Please ignore this patch. I will send a V3 later. Can you elaborate on what the problem with v2 is? It passed the AB testing, so I’m curious if you’ve found problems that the AB doesn’t test. Cheers, Ross
On Fri, 2024-11-01 at 10:03 +0800, Wang, Jinfeng (CN) via
lists.openembedded.org wrote:
> Please ignore this patch. I will send a V3 later.
Could you perhaps mention why? The v2 did pass in testing so I'm
wondering what the v3 is going to change. I will hold off merging.
Cheers,
Richard
Hi all, Sorry for my mistakes. I have mistake in cherry-pick. When resolving the cherry-pick conflicts, I modify the codes according the the newest codes. In fact, my modification includes fe2699369f79981dcf913af4cfd98b342b84a9c1 and c0619f08e6c608fd6464d2f0c6970ef0bbfb9ecf. After I manually modify the codes, there are two lines missing: g_time_zone_unref (tz); + g_date_time_unref (gdt1); + g_date_time_unref (gdt2); So v3 will add the above two lines, and have more details of commit messages. Thanks. Jinfeng On 11/1/2024 7:53 PM, Richard Purdie wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Fri, 2024-11-01 at 10:03 +0800, Wang, Jinfeng (CN) via > lists.openembedded.org wrote: >> Please ignore this patch. I will send a V3 later. > Could you perhaps mention why? The v2 did pass in testing so I'm > wondering what the v3 is going to change. I will hold off merging. > > Cheers, > > Richard
diff --git a/meta/recipes-extended/timezone/timezone.inc b/meta/recipes-extended/timezone/timezone.inc index 4734adcc08..adf095280f 100644 --- a/meta/recipes-extended/timezone/timezone.inc +++ b/meta/recipes-extended/timezone/timezone.inc @@ -6,7 +6,7 @@ SECTION = "base" LICENSE = "PD & BSD-3-Clause" LIC_FILES_CHKSUM = "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba" -PV = "2024a" +PV = "2024b" SRC_URI =" http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode;subdir=tz \ http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata;subdir=tz \ @@ -16,5 +16,5 @@ S = "${WORKDIR}/tz" UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones" -SRC_URI[tzcode.sha256sum] = "80072894adff5a458f1d143e16e4ca1d8b2a122c9c5399da482cb68cba6a1ff8" -SRC_URI[tzdata.sha256sum] = "0d0434459acbd2059a7a8da1f3304a84a86591f6ed69c6248fffa502b6edffe3" +SRC_URI[tzcode.sha256sum] = "5e438fc449624906af16a18ff4573739f0cda9862e5ec28d3bcb19cbaed0f672" +SRC_URI[tzdata.sha256sum] = "70e754db126a8d0db3d16d6b4cb5f7ec1e04d5f261255e4558a67fe92d39e550"