FEDORA-2019-5fcc2049a1 created by djdelorie 2 years ago for Fedora 29
stable

This glibc update adds support for the new Japanese era, Reiwa, which will begin on May 1st. It also includes several other upstream bugfixes via upstream sync:

  • ja_JP locale: Add entry for the new Japanese era [BZ #22964]
  • S390: Mark vx and vxe as important hwcap.
  • Record CVE-2019-9169 in NEWS and ChangeLog [BZ #24114]
  • regex: fix read overrun [BZ #24114]
  • RISC-V: don't assume PI mutexes and robust futexes before 4.20 (bug 23864)
  • powerpc: Only enable TLE with PPC_FEATURE2_HTM_NOSC
  • RISC-V: Fix elfutils testsuite unwind failures.
  • nptl: Fix pthread_rwlock_try*lock stalls (Bug 23844)
  • nptl: Avoid fork handler lock for async-signal-safe fork [BZ #24161]
  • Add compiler barriers around modifications of the robust mutex list for pthread_mutex_trylock. [BZ #24180]
  • NEWS: Mention bug 24112.
  • nscd: Do not use __inet_aton_exact@GLIBC_PRIVATE [BZ #20018]
  • CVE-2016-10739: getaddrinfo: Fully parse IPv4 address strings [BZ #20018]
  • resolv: Do not send queries for non-host-names in nss_dns [BZ #24112]
  • resolv: Reformat inet_addr, inet_aton to GNU style
  • x86-64 memcmp: Use unsigned Jcc instructions on size [BZ #24155]
  • x86-64 strnlen/wcsnlen: Properly handle the length parameter [BZ #24097]
  • x86-64 strncpy: Properly handle the length parameter [BZ #24097]
  • x86-64 strncmp family: Properly handle the length parameter [BZ #24097]
  • x86-64 memset/wmemset: Properly handle the length parameter [BZ #24097]
  • x86-64 memrchr: Properly handle the length parameter [BZ #24097]
  • x86-64 memcpy: Properly handle the length parameter [BZ #24097]
  • x86-64 memcmp/wmemcmp: Properly handle the length parameter [BZ #24097]
  • x86-64 memchr/wmemchr: Properly handle the length parameter [BZ #24097]
  • Add XFAIL_ROUNDING_IBM128_LIBGCC to more fma() tests
  • Only build libm with -fno-math-errno (bug 24024)
  • sysdeps/ieee754/soft-fp: ignore maybe-uninitialized with -O [BZ #19444]
  • ARM: fix kernel assisted atomics with GCC 8 (bug 24034)
  • riscv: Use __has_include__ to include <asm/syscalls.h> [BZ #24022]
  • intl: Do not return NULL on asprintf failure in gettext [BZ #24018]
  • malloc: Always call memcpy in _int_realloc [BZ #24027]
  • Update Alpha libm-test-ulps
  • m68k: Fix sigaction kernel definition (BZ #23967)
  • RISC-V: properly terminate call chain (bug 23125)
  • support: Do not require overflow builtin in support/blob_repeat.c

How to install

sudo dnf upgrade --advisory=FEDORA-2019-5fcc2049a1

This update has been submitted for testing by djdelorie.

2 years ago
User Icon codonell commented & provided feedback 2 years ago
karma

Verified that LANG=ja_JP date -s 2019-05-01 +%EY shows REIWA ERA e.g. 令和元年. Looks good to me.

BZ#1696390 glibc: The Japanese Era name will be changed on May 1, 2019 [f29]

This update has been pushed to testing.

2 years ago
User Icon bojan commented & provided feedback 2 years ago
karma

Works here.

User Icon proski commented & provided feedback 2 years ago
karma

There is an error message coming from glibc being replaced: Cleanup : glibc-2.28-26.fc29.i686 Running scriptlet: glibc-2.28-26.fc29.i686 /var/tmp/rpm-tmp.oWJ2fH: line 5: /sbin/sln: No such file or directory

There is no /sbin/sln on my system, and it doesn't appear to be part of any package. Please make sure there are no references to /sbin/sln in the current glibc package.

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

2 years ago
User Icon codonell commented & provided feedback 2 years ago

@proski I never saw any /sbin/sln issues during my upgrade, and no scriptlets in glibc use sln. We removed /sbin/sln on Jan 2018 (commit d8e1573f9c8c28f6390791c329512045f0c52868). Which means that no F29 release (branched 2018-02-20) has ever has /sbin/sln. I believe you have a unique configuration issue with your install that is triggering the use of sln and is not related to this update.

User Icon djdelorie commented & provided feedback 2 years ago

also please verify that you're seeing this from a 2.28-27 install, and not a 2.28-26 install.

User Icon proski commented & provided feedback 2 years ago
karma

I can reproduce the message about /sbin/sln both when downgrading from 2.28-27 to 2.28-26 and when upgrading from 2.28-26 to 2.28-27. That said, I have verified that there are no references to /sbin/sln in the glibc install scripts, as I wrongly assumed. So I'm reverting the negative karma. I'll keep digging, it must be some other package running a trigger on glibc upgrade.

BZ#1696390 glibc: The Japanese Era name will be changed on May 1, 2019 [f29]
User Icon fweimer commented & provided feedback 2 years ago

A likely candidate for the sln error source is redhat-lsb:

https://src.fedoraproject.org/rpms/redhat-lsb/blob/f29/f/redhat-lsb.spec#l622

This update has been submitted for batched by codonell.

2 years ago

This update has been submitted for stable by codonell.

2 years ago

This update has been submitted for batched by codonell.

2 years ago
User Icon codonell commented & provided feedback 2 years ago

We should push to batched to avoid update churn.

User Icon proski commented & provided feedback 2 years ago

It was redhat-lsb. Uninstalling it fixed the error messages. All is good now.

User Icon proski commented & provided feedback 2 years ago

A bug existed already, but "sln" was misspelled, which is why I could not find it. https://bugzilla.redhat.com/show_bug.cgi?id=1625584

This update has been submitted for stable by bodhi.

2 years ago

This update has been pushed to stable.

2 years ago

Please login to add feedback.

Metadata
Type
enhancement
Karma
3
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
2 years ago
in testing
2 years ago
in stable
2 years ago
BZ#1696390 glibc: The Japanese Era name will be changed on May 1, 2019 [f29]
0
0

Automated Test Results