Learn more about these different git repos.
Other Git URLs
As discovered last Sunday and discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1609577
A bug was introduced in binutils starting with version binutils-2.31.1-4.fc29 which causes it to put the sections in ELF binaries it produces in non incrementing order. This causes eu-strip to mangle the binary into a broken binary when eu-strip is ran on the ELF binary generated by binutils-2.31.1-4.fc29 or newer. This is a big problem since /usr/lib/rpm/find-debuginfo.sh runs eu-strip on all binaries.
The binutils bug causing this was fixed in binutils-2.31.1-8.fc29 which was build yesterday.
Since any binaries produced by binutils >= 2.31.1-4.fc29 && binutils < 2.31.1-8.fc29 and then processed by eu-strip are (potentially) broken this means that all builds done with a binutils version of 2.31.1-4.fc29 - 2.31.1-7.fc29 need to be rebuild.
I have a list of affected builds based on actually generated ELF, and I'm in the process of doing targeted rebuilds of affected packages. If you want, I can generate a list of source packages and let you do the rebuilds.
Florian,
I did not realize you were already working on getting the rebuilds done.
I see that you've already started a bunch of rebuilds for this, I guess it is best then if you just do all the rebuilds.
Then once you're done with the rebuilds this issue can be closed.
Regards,
Hans
Please post the list of affected packages somewhere. I think I identified two of mine (suitesparse-4.4.6-14.fc29 and pseudo-1.9.0-5.fc29) and would like to confirm.
suitesparse-4.4.6-14.fc29
pseudo-1.9.0-5.fc29
Yes, suitesparse-4.4.6-15.fc29 and pseudo-1.9.0-5.fc29 in the Fedora rawhide buildroot are affected. I will schedule rebuilds for them.
suitesparse-4.4.6-15.fc29
Once I have the current set of affected packages in Fedora rawhide, I will post a list on the devel list.
I believe I have rebuilt all the affected packages on all architectures.
Someone else will have to close this ticket because I appear to lack the required permissions.
Thanks so much!
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Might be a good idea to recheck if indeed the list of packages is tackled. We have discovered that from "libqb/pacemaker" related packages Florian mentions: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3D2AX3Q7HQX3VQ77R2PAOZVZKDX57FBF/ actually one was provably run-time impacted, which I've taken care of for both f29 and f30 (corosync-2.99.3-3).
corosync-2.99.3-3
That also means following packages can be skipped easily:
booth corosync libqb pacemaker sbd
Accidentally, I've run into libreoffice issue much earlier: https://bugzilla.redhat.com/show_bug.cgi?id=1610964 but the rebuilt package was already pending propagation to mirrors by that time (thanks, Florian).
Perhaps also worth mentioning that lower bound for binutils to reproduce that issue appears to be 2.31.1-3.fc29, as this is what the faulty release, corosync-2.99.3-2.fc29, was built with.
2.31.1-3.fc29
corosync-2.99.3-2.fc29
@jpokorny corosync was corrupted in Fedora 28 as well. Part of the problem is that the logging framework (in libqb IIRC) produces objects which can only be linked correctly if an appropriate linker script is supplied to the link editor. I assumed the corruption was harmless. Do you have further details? Thanks.
libqb
Login to comment on this ticket.