Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
It must be this upstream backport:
commit 42eb735a5d3458a24a44ace9eca87c8b61573d97
Author: Adhemerval Zanella <adhemerval.zanella>
Date: Thu May 20 14:20:18 2021 -0300
Use LFS and 64 bit time for installed programs (BZ #15333)
Even though we do not ship the 32-bit version of ldconfig, we need to fix this for i686 buildroot integrity.
It looks like one of the dependencies of this change was not backported along with it. The 2.35 upstream branch does not show the same bug.
If I had to guess it would be one of these two:
commit 9fe6f6363886aae6b2b210cae3ed1f5921299083
Author: Adhemerval Zanella <adhemerval.zanella>
Date: Wed Dec 29 10:20:46 2021 -0300
elf: Fix 64 time_t support for installed statically binaries
The usage of internal static symbol for statically linked binaries
does not work correctly for objects built with -D_TIME_BITS=64,
since the internal definition does not provide the expected aliases.
This patch makes it to use the default stat functions instead (which
uses the default 64 time_t alias and types).
Checked on i686-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos>
Tested-by: Carlos O'Donell <carlos>
commit 834ddd0432f68d6dc85b6aac95065721af0d86e9
Author: Adhemerval Zanella <adhemerval.zanella>
Date: Wed Apr 27 13:59:26 2022 -0300
linux: Fix missing internal 64 bit time_t stat usage
These are two missing spots initially done by 52a5fe70a2c77935.
Checked on i686-linux-gnu.
I didn't have time to confirm, but I can follow up tomorrow.
(In reply to Florian Weimer from comment #2)
> I assume this was spotted as the result of a build failure. Would you please
> name the failing package? Thanks.
The name of the package is pcs.
Link to the failed scratch-build: https://kojihub.stream.rdu2.redhat.com/koji/taskinfo?taskID=1898302
Link to the last working scratch-build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=50464283
There were glibc updates:
glibc-2.34-54.el9.i686 -> glibc-2.34-58.el9.i686
glibc-common-2.34-54.el9.i686 -> glibc-common-2.34-58.el9.i686
glibc-gconv-extra-2.34-54.el9.i686 -> glibc-gconv-extra-2.34-58.el9.i686
glibc-minimal-langpack-2.34-54.el9.i686 -> glibc-minimal-langpack-2.34-58.el9.i686
I reviewed the upstream test case and downstream CentOS 9 Stream MR. They both look good to me. Adding a smoke test is important, just like we smoke test valgrind.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (glibc bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:2481
Description of problem: Function ctypes.utils.find_library does not find pam library when only pam package is installed. Function found pam library after pam-devel package was installed. Version-Release number of selected component (if applicable): python3-3.9.16-1.el9.i686 glibc-2.34-57.el9.i686 pam-1.5.1-14.el9.i686 pam-devel-1.5.1-14.el9.i686 How reproducible: always, only on i686 architecture Steps to Reproduce: python3 -c "from ctypes.util import find_library; print(find_library('pam'));" Actual results: <mock-chroot> sh-5.1# python3 -c "from ctypes.util import find_library; print(find_library('pam'));" None Expected results: <mock-chroot> sh-5.1# python3 -c "from ctypes.util import find_library; print(find_library('pam'));" libpam.so.0 Additional info: Issue is probably in `ldconfig` which is used by `find_library` as first choice. Feel free to change component to glibc. Function `find_library` stopped working since glibc-2.34-57.el9.i686: <mock-chroot> sh-5.1# rpm -q glibc python3 pam pam-devel glibc-2.34-57.el9.i686 python3-3.9.16-1.el9.i686 pam-1.5.1-14.el9.i686 package pam-devel is not installed <mock-chroot> sh-5.1# python3 -c "from ctypes.util import find_library; print(find_library('pam'));" None <mock-chroot> sh-5.1# ldconfig -p ldconfig: mmap of cache file failed. : Invalid argument Function `find_library` found pam library after installing pam-devel: <mock-chroot> sh-5.1# rpm -q glibc python3 pam pam-devel glibc-2.34-57.el9.i686 python3-3.9.16-1.el9.i686 pam-1.5.1-14.el9.i686 pam-devel-1.5.1-14.el9.i686 <mock-chroot> sh-5.1# python3 -c "from ctypes.util import find_library; print(find_library('pam'));" libpam.so.0 <mock-chroot> sh-5.1# ldconfig -p ldconfig: mmap of cache file failed. : Invalid argument Function `find_library` and command `ldconfig -p` work with glibc-2.34-56.el9.i686: <mock-chroot> sh-5.1# rpm -q glibc python3 pam pam-devel glibc-2.34-56.el9.i686 python3-3.9.16-1.el9.i686 pam-1.5.1-14.el9.i686 package pam-devel is not installed <mock-chroot> sh-5.1# python3 -c "from ctypes.util import find_library; print(find_library('pam'));" libpam.so.0 <mock-chroot> sh-5.1# ldconfig -p | grep pam libpamc.so.0 (libc6) => /lib/libpamc.so.0 libpamc.so (libc6) => /lib/libpamc.so libpam_misc.so.0 (libc6) => /lib/libpam_misc.so.0 libpam_misc.so (libc6) => /lib/libpam_misc.so libpam.so.0 (libc6) => /lib/libpam.so.0 libpam.so (libc6) => /lib/libpam.so