I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall.
I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected.
Is there something I am overlooking or did the automatic process fall flat?
On Wed, 2021-08-18 at 17:21 +0200, Jan Drögehoff wrote:
I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall.
I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected.
Is there something I am overlooking or did the automatic process fall flat?
I don't think the process is wrong, but rather your VMs were outdated. (Note this line in the report: "P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors.") It looks like lld got bumped to 13.0rc1 yesterday:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1819661
which probably wouldn't have made it into the package set in your VMs. So, you'll need to rebuild your packages against the new lld libs.
This looks like an unannounced soname bump, which is against the packaging policy. Tom, please remember to announce soname bumps in advance and co-ordinate with the packagers of packages that build against the library. We now have the multi-build update process you can use to handle soname bumps smoothly, and it would be a good idea to do this: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
On 8/18/21 6:02 PM, Adam Williamson wrote:
On Wed, 2021-08-18 at 17:21 +0200, Jan Drögehoff wrote:
I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall.
I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected.
Is there something I am overlooking or did the automatic process fall flat?
I don't think the process is wrong, but rather your VMs were outdated. (Note this line in the report: "P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors.") It looks like lld got bumped to 13.0rc1 yesterday:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1819661
which probably wouldn't have made it into the package set in your VMs. So, you'll need to rebuild your packages against the new lld libs.
Yeah that was it
I completely missed the soname bump
and because its not on the mirrors yet it obviously wouldn't cause a problem on a VM
Thanks
This looks like an unannounced soname bump, which is against the packaging policy. Tom, please remember to announce soname bumps in advance and co-ordinate with the packagers of packages that build against the library. We now have the multi-build update process you can use to handle soname bumps smoothly, and it would be a good idea to do this: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
On 18. 08. 21 18:02, Adam Williamson wrote:
This looks like an unannounced soname bump, which is against the packaging policy. Tom, please remember to announce soname bumps in advance and co-ordinate with the packagers of packages that build against the library. We now have the multi-build update process you can use to handle soname bumps smoothly, and it would be a good idea to do this: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
This was announced via a change proposal:
https://fedoraproject.org/wiki/Changes/LLVM-13
On Wed, 2021-08-18 at 19:09 +0200, Miro Hrončok wrote:
On 18. 08. 21 18:02, Adam Williamson wrote:
This looks like an unannounced soname bump, which is against the packaging policy. Tom, please remember to announce soname bumps in advance and co-ordinate with the packagers of packages that build against the library. We now have the multi-build update process you can use to handle soname bumps smoothly, and it would be a good idea to do this: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
This was announced via a change proposal:
Right, I missed that it was part of that, sorry. It sounds like Tom meant to take care of all users in the side tag but just missed these.
On 8/18/21 9:02 AM, Adam Williamson wrote:
On Wed, 2021-08-18 at 17:21 +0200, Jan Drögehoff wrote:
I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall.
I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected.
Is there something I am overlooking or did the automatic process fall flat?
I don't think the process is wrong, but rather your VMs were outdated. (Note this line in the report: "P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors.") It looks like lld got bumped to 13.0rc1 yesterday:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1819661
which probably wouldn't have made it into the package set in your VMs. So, you'll need to rebuild your packages against the new lld libs.
This looks like an unannounced soname bump, which is against the packaging policy. Tom, please remember to announce soname bumps in advance and co-ordinate with the packagers of packages that build against the library. We now have the multi-build update process you can use to handle soname bumps smoothly, and it would be a good idea to do this: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
Hi,
Sorry for the package failures. I did not realize there were lld library users in Fedora, so I don't not include these packages in the side-tag.
As Miro mentioned rebuilding your packages should fix the issue. Let me know if there is anything I can do to help.
-Tom
On 18. 08. 21 17:21, Jan Drögehoff wrote:
I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall.
I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected.
Is there something I am overlooking or did the automatic process fall flat?
Hello Jan, As said in the bugzillas, the reports are based on Koji buildroot. That is usually ahead of what is available on the mirrors.
A nice reproducer might be:
$ mock -r fedora-rawhide-x86_64 --init $ mock -r fedora-rawhide-x86_64 --disablerepo='*' --enablerepo=local --install zig ... Error: Problem: conflicting requests - nothing provides liblldCOFF.so.12()(64bit) needed by zig-0.8.0-7.fc35.x86_64 - nothing provides liblldDriver.so.12()(64bit) needed by zig-0.8.0-7.fc35.x86_64 - nothing provides liblldELF.so.12()(64bit) needed by zig-0.8.0-7.fc35.x86_64 - nothing provides liblldWasm.so.12()(64bit) needed by zig-0.8.0-7.fc35.x86_64
I can see that on the mirrors, liblldCOFF.so.12()(64bit) is provided by lld-libs-0:12.0.1-1.fc35:
$ repoquery --repo=rawhide --whatprovides 'liblldCOFF.so.12()(64bit)' lld-libs-0:12.0.1-1.fc35.x86_64
But that was updated already in Koji:
$ repoquery --repo=koji lld-libs lld-libs-0:13.0.0~rc1-1.fc36.x86_64
And now it provides a newer version:
$ repoquery --repo=koji --provides lld-libs | grep liblldCOFF liblldCOFF.so.13.0()(64bit)
This new updated version will eventually hit the mirrors as well.
It was updated in:
https://src.fedoraproject.org/rpms/lld/c/2cb02d9e03958b9352e170b3f8d65ac5f77...
Rebuilding your package on rawhide and F35 should fix the problem.
V Wed, Aug 18, 2021 at 05:21:59PM +0200, Jan Drögehoff napsal(a):
I've received 2 automated bugzilla reports for F35[1] and F36[2] that my package FailsToInstall.
I tried to replicate this with a Fedora 35 and Rawhide VM created from the last known good ISOs provided by the nightly compose finder and found everything to be working as expected.
Is there something I am overlooking or did the automatic process fall flat?
The bugs are about missing liblldCOFF.so.12()(64bit). Those are provided by lld-libs from lld-12.0.1-1.fc35. I recall there were issues with merging llvm from a side tag (some packages were missing in the target tag) recently. Maybe that caused it.
-- Petr
-
Adam Williamson -
Jan Drögehoff -
Miro Hrončok -
Petr Pisar -
Tom Stellard