Bug#928405: Package: Version: <2.28-10>
Package: Version: <2.28-10> Wysłane z aplikacji Poczta dla Windows 10 pl.po Description: Binary data
Bug#928404: unblock: glibc/2.28-10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, The glibc package in version 2.28-10 currently in sid mostly updates the git-updates.diff patch to the latest upstream stable branch: - Fix security issue CVE-2019-9169. - Support for the new Reiwa era to the ja_JP which seems to be something quite important for Japanese people. provide shared libraries (not) tuned for the corresponding platforms. - Fix for an infinite loop in the pldd binary, which makes it unusable (regression from stretch). - Support for vector instructions related hwcap on s390x to allow one to - Fix for a riscv specific issue in a file which is not used on other architectures, so with no risk for them. In addition to that it includes a fix for a bug in dlopen introduced by an arm patch, but affecting all architectures. I believe that all the above changes are suitable for buster. If you agree, could you please unblock package glibc: unblock glibc/2.28-10 Thanks, Aurelien -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Bug#927933: icu: Please update to deal with Japanese new era "Reiwa"
On Sat, 27 Apr 2019 19:47:03 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > Hi Hideki, > > On Thu, Apr 25, 2019 at 8:51 AM Hideki Yamane wrote: > > As http://site.icu-project.org/home, upstream says > > > > > These maintenance updates for past ICU versions include support for new > > > Japanese era Reiwa (令和) > Yup, I've followed ICU upstream commits way before 63.2 was released. > > > However, it also seems to include other changes (in 63.2) > > > > > $ diff -urN /tmp/icu-63.1 icu|wc -l > > >2685 > It does and my previous testing which is just confirmed with the > official release of ICU 63.2: some internal things changed. This means > the new ICU release breaks at least breaks Chromium big at least. It > crashes before even starting after 63.2 is installed. > Currently testing if a binNMU would be enough to fix that and / or it > breaks other applications or not. > Given that we will be updating libicu for this issue most likely for all stable releases, IMHO this is a great opportunity to enable the config option for dynamic loading of timezone data. Specifically I mean "ICU4C TZ update with Drop-in .res files (ICU 54 and newer)" from http://userguide.icu-project.org/datetime/timezone#TOC-ICU4C-TZ-Update-with-Drop-in-.res-files-ICU-54-and-newer- I think we should compile ICU with U_TIMEZONE_FILES_DIR set to any value we can agree on, e.g. something like "/usr/share/zoneinfo-icu/44/le" (little endian), "/usr/share/zoneinfo-icu/44/be" (big endian), "/usr/share/zoneinfo-icu/44/ee" (the ibm one). To mimick the directory layout structure as seen in https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew/2019a/44 44 is the format of res files that is supported by icu from version 4.4 and up. 'le|ee|be' are different endianess/encoding of the data. Then once ICU is compiled with U_TIMEZONE_FILES_DIR, at some later point we can change tzdata package to either (a) download icu upstream precompiled .res files and ship them in U_TIMEZONE_FILES_DIR or (b) change tzdata packaging to compile icu4c .res files (c) introduce a new icu-tzdata package that would ship those .res files. Even if we never ship the package that has the updated .res files, I think it will still be good to at least start building icu with U_TIMEZONE_FILES_DIR set, such that users at least have the ability to inject the .res files themselves. This will solve the multiple bugs that we have filed against icu4c using out of data timezone data. Regards, Dimitri.
