Hide Forgot
The spec file contains this: %triggerpostun -- glibc if [ -x /usr/sbin/redhat_lsb_trigger.%{_target_cpu} ]; then /usr/sbin/redhat_lsb_trigger.%{_target_cpu} fi %ifnarch %{ix86} /sbin/sln %{ldso} /%{_lib}/%{lsbldso} || : %else if [ -f /emul/ia32-linux/lib/%{ldso} ]; then for LSBVER in %{lsbsover}; do /sbin/sln /emul/ia32-linux/lib/%{ldso} /%{_lib}/%{lsbldso}.$LSBVER || : done else for LSBVER in %{lsbsover}; do /sbin/sln %{ldso} /%{_lib}/%{lsbldso}.$LSBVER || : done fi %endif It will no longer work because /sbin/sln has bee removed from Fedora 29 (see bug 1531546). I think you can add the symbolic link directly to the package. The /emul/… paths are no longer needed without ia64 support.
They actually are part of the package already, this scriptlet creates them when glibc is upgraded. Which sounds weird. Does anyone have any idea what would happen if we just drop this whole piece?
The changelog message says this: * Wed Mar 27 2002 Matt Wilson <msw@redhat.com> - addeed trigger on glibc to re-establish the ld-lsb.so.1 symlink in the forced downgrade case. Florian any ideas why it was necessary to recreate that symlink in such case? http://pkgs.devel.redhat.com/cgit/rpms/redhat-lsb/diff/redhat-lsb.spec?h=rhel-8.0.0&id=1cfbf4f&context=40&ignorews=0&dt=0
I really have no idea. Perhaps some versions of ldconfig removed it when run? I tried to reproduced that in Fedora 27, but could not. Maybe this was about the value of %{ldso} changing? Perhaps there was an older version of LSB for libc5 or something like that?
Ok, let's just drop that part of the spec file.
The name of the missing executable is /sbin/sln, I'm fixing it in the title. The issue has caused a lot of wasted time in Bodhi today: https://bodhi.fedoraproject.org/updates/FEDORA-2019-5fcc2049a1
Still seeing this today: Cleanup : glibc-2.28-26.fc29.x86_64 Running scriptlet: glibc-2.28-26.fc29.x86_64 104/107 /var/tmp/rpm-tmp.tTR08p: line 5: /sbin/sln: No such file or directory
This is still present in fedora30: Running scriptlet: glibc-2.29-9.fc30.x86_64 216/217 /var/tmp/rpm-tmp.6a3Wju: line 5: /sbin/sln: No such file or directory
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
*** Bug 1779296 has been marked as a duplicate of this bug. ***
This issue is still present in fedora 31: during dnf update: [...] Cleanup : glibc-2.30-7.fc31.x86_64 705/710 Running scriptlet: glibc-2.30-7.fc31.x86_64 705/710 /var/tmp/rpm-tmp.gCkJZo: line 5: /sbin/sln: No such file or directory [...] rpm -q --triggers redhat-lsb-4.1-48.fc31.x86_64|grep sln /sbin/sln ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so || :
*** Bug 1780938 has been marked as a duplicate of this bug. ***
*** Bug 1793698 has been marked as a duplicate of this bug. ***
my investigation arrives where [1] and here [2] . And after read [3] I'd suggest replace sln by ldconfig [1] https://src.fedoraproject.org/rpms/glibc/pull-request/3 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1460264 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1315476
my propose to fix this bug: https://src.fedoraproject.org/rpms/redhat-lsb/pull-request/5
It's May 14, 2020. And Rawhide for fc33 just said: Running scriptlet: glibc-2.31.9000-12.fc33.x86_64 310/310 /usr/src/redhat/tmp/rpm-tmp.b5AHYT: line 5: /sbin/sln: No such file or directory It's been gone for 2 years now. Can somebody please take this bug out back and shoot it already?
*** Bug 1858628 has been marked as a duplicate of this bug. ***
*** Bug 1858656 has been marked as a duplicate of this bug. ***
*sigh* Running scriptlet: glibc-2.32.9000-11.fc34.x86_64 203/204 /usr/src/redhat/tmp/rpm-tmp.UraFx3: line 5: /sbin/sln: No such file or directory Can we get this fixed before the next major release of glibc? It's been broken since glibc 2.28.
*** Bug 1891267 has been marked as a duplicate of this bug. ***
*** Bug 1756789 has been marked as a duplicate of this bug. ***
Still there in the latest glibc update, Fedora 33