[Buildroot] [PATCH 2/2] package/tzdata: bump version to 2020f

[Romain Naour]

Hello,

Le lun. 15 févr. 2021 à 10:12, Peter Korsgaard <peter at korsgaard.com> a
écrit :

> >>>>> "Yann" == Yann E MORIN <yann.morin.1998 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20210215/4dab82a2/attachment-0002.html>