[AUH] tzcode-native,tzdata: upgrading to 2026f FAILED

Hello,

this email is a notification from the Auto Upgrade Helper
that the automatic attempt to upgrade the recipe(s) *tzcode-native,tzdata* to *2026f* has Failed(do_compile).

Detailed error information:

do_compile failed



Next steps:
    - apply the patch: git am 0001-tzcode-native-tzdata-upgrade-2026e-2026f.patch
    - check the changes to upstream patches and summarize them in the commit message,
    - compile an image that contains the package
    - perform some basic sanity tests
    - amend the patch and sign it off: git commit -s --reset-author --amend
    - send it to the appropriate mailing list

Alternatively, if you believe the recipe should not be upgraded at this time,
you can fill RECIPE_NO_UPDATE_REASON in respective recipe file so that
automatic upgrades would no longer be attempted.

Please review the attached files for further information and build/update failures.
Any problem please file a bug at https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler

Regards,
The Upgrade Helper

-- >8 --
From 6bc2bac88f8388e8f1c89ca263923f01ce97185f Mon Sep 17 00:00:00 2001
From: Upgrade Helper <auh@yoctoproject.org>
Date: Thu, 29 Oct 2026 05:08:16 +0000
Subject: [PATCH] tzcode-native,tzdata: upgrade 2026e -> 2026f
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Release 2026f - 2026-10-27 23:16:49 -0700

  Briefly:
    Cuba will not fall back 2026-11-01; stays on -04 through 2027-11-07.
    No more leap seconds, and leap second tables no longer expire.
    Improve 1965/1966 data for Brazil.

  Changes to future timestamps

    Cuba will not fall back to -05 on 2026-11-01 and instead plans to
    maintain -04 through 2027-11-07.

  Changes to past timestamps

    In 1965 Brazil ended DST on 03-31 at 24:00 not 00:00, and in 1966
    it ended DST on 03-01 at 01:00 not 00:00.  (Thanks to Daniel Dias
    Rodrigues.)

  Changes to code

    zic now ignores Expires lines, as leap second tables in TZif files
    no longer expire now that there are no more leap seconds;
    see Internet RFC 9636 §3.2.  (Thanks to Garrett Wollman for the
    heads-up re no more leap seconds.)

    localtime.c no longer supports 49 leap seconds, as 27 now suffice.
    zic now warns if you go over the new limit.

    A new compile-time flag -DMIN_TRANSITION_GAP=N specifies a minimum
    transition gap of N seconds when reading TZif files.  It currently
    defaults to 0, but can be set to 1 if TZif files generated by zic
    2021b and earlier are no longer of concern.

    With 32-bit time_t, localtime.c functions now check for transition
    ordering in TZif data as carefully as they do with 64-bit time_t.
    (Problem reported by Ana Bobillo.)

    On platforms like FreeBSD that have O_RESOLVE_BENEATH but lack
    O_REGULAR, localtime.c compiled with -DOPENAT_TZDIR now checks
    that a TZ setting with ".." components names a regular file
    before opening it in an unprivileged program, as it already did
    for other settings that might name a file outside TZDIR.
    This fixes a bug introduced in 2026c.  (Thanks to Ana Bobillo.)

  Changes to documentation and commentary
    Documentation and commentary now reflect leap seconds’ demise.
  Changes to commentary

    Discussion on timekeeping in northwestern Ontario has been updated
    to reflect that provincial regulation has been issued to allow these
    areas to stay aligned with America/Winnipeg and follow Manitoba’s
    adoption of year-round -05 after all.  (Thanks to Aoun Khan,
    Chris Walton, and Heitor David Pinto.)

    Discussion on timekeeping in Saskatchewan has been updated to
    document its new Time Act, 2026 which comes into force on
    2026-10-30.  (Thanks to Heitor David Pinto.)  No change is expected.

    other recent temporary hacks.  This new temporary hack works
    around a limitation in Unicode CLDR 48.2.2 (2026-09-21)
    and ICU 78.3 (2026-03-17), and is planned to be removed after
    CLDR and ICU are fixed.  (Caution: see “NOTE FOR 2026
      not follow.  For now, given the short lead time with Manitoba’s
    for the same reason as other recent temporary hacks.
    This new temporary hack works around a limitation in Unicode CLDR
    48.2.1 (2026-07-08) and and ICU 78.3 (2026-03-17), and is planned
    to be removed after CLDR and ICU are fixed.  (Caution:
    see “NOTE FOR 2026 TEMPORARY HACK FOR CLDR AND CANADA” below.)
    temporary hack for British Columbia in 2026b.  This new temporary
    hack works around a limitation in Unicode CLDR 48.1 (2026-01-08)
    and ICU 78.2 (2025-01-30), and is planned to be removed after CLDR
    and ICU are fixed.  (Caution: see “NOTE FOR 2026 TEMPORARY HACK
    FOR CLDR AND CANADA” below.)
    to occur on 2026-11-01 at 02:00 instead.  This temporary hack
    works around a limitation in Unicode CLDR 48 (2025-10-29) and
    ICU 78 (2025-10-30), and is planned to be removed after CLDR and
    ICU are fixed.
    NOTE FOR 2026 TEMPORARY HACK FOR CLDR AND CANADA:
    This temporary hack works around limitations in Unicode CLDR and
    ICU, and is planned to be removed after CLDR and ICU are fixed.
    See <https://cldr.unicode.org/downloads/cldr-48> and
    <https://www.unicode.org/releases/> for 2026 changes there.
    Unfortunately the temporary hack also causes zic in tzcode
    2023d through 2026a, in the default slim mode, to generate a
    TZif file that does not conform to Internet RFC 9636 §3.3.
  Changes to code

    zic no longer mishandles a last transition to a new time type.

(just the same as their near neighbor, Samoa).
There will be a leap second 2012-06-30 23:59:60 UTC.
---
 meta/recipes-extended/timezone/timezone.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)