Since bind9-next was tagged into Rawhide recently, FreeIPA tests are failing. At first I thought the update to bind and bind-dyndb-ldap was the culprit: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f1accd4b37 but even with that update untagged, tests fail (though the error is different). On closer investigation, I noticed the bind9-next problem. When we install FreeIPA normally, the system winds up with all these packages installed, some from bind, some from bind9-next: bind-libs-9.18.11-1.fc38 bind-license-9.18.11-1.fc38 bind-utils-9.18.11-1.fc38 bind9-next-9.19.9-1.fc38 bind9-next-dnssec-utils-9.19.9-1.fc38 bind9-next-libs-9.19.9-1.fc38 bind9-next-license-9.19.9-1.fc38 with the newer bind and bind-dyndb-ldap from the update, we get a crash in named: === Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: loading DynDB instance 'ipa' driver '/usr/lib64/bind/ldap.so' Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: ../../../lib/isc/mem.c:473: REQUIRE(ctxp != ((void *)0) && *ctxp == ((void *)0)) failed, back trace Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /usr/sbin/named(+0x2165f) [0x56316732965f] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(isc_assertion_failed+0xe) [0x7f5ada82df5e] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(+0x4818d) [0x7f5ada84818d] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org audit[8490]: ANOM_ABEND auid=4294967295 uid=25 gid=25 ses=4294967295 subj=system_u:system_r:named_t:s0 pid=8490 comm="named" exe="/usr/sbin/named" sig=6 res=1 Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(isc__tls_initialize+0x14) [0x7f5ada85ecf4] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(isc__initialize+0x1c) [0x7f5ada81f79c] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(+0x517f) [0x7f5adadbf17f] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(+0x527d) [0x7f5adadbf27d] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(_dl_catch_exception+0x142) [0x7f5adadbb5c2] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(+0xbe5c) [0x7f5adadc5e5c] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(_dl_catch_exception+0xa3) [0x7f5adadbb523] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(+0xc1d4) [0x7f5adadc61d4] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libc.so.6(+0x88964) [0x7f5ad9caa964] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(_dl_catch_exception+0xa3) [0x7f5adadbb523] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/ld-linux-x86-64.so.2(+0x1679) [0x7f5adadbb679] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libc.so.6(+0x88443) [0x7f5ad9caa443] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libc.so.6(dlopen+0x6f) [0x7f5ad9caaa1f] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libuv.so.1(uv_dlopen+0x2f) [0x7f5ada7086df] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libdns-9.19.9.so(dns_dyndb_load+0x209) [0x7f5ada46eed9] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /usr/sbin/named(+0x3a11f) [0x56316734211f] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /usr/sbin/named(+0x45767) [0x56316734d767] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /usr/sbin/named(+0x4798b) [0x56316734f98b] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(+0x5e09a) [0x7f5ada85e09a] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(+0x5e4e5) [0x7f5ada85e4e5] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(+0x46a12) [0x7f5ada846a12] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libuv.so.1(uv_run+0x161) [0x7f5ada706181] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libisc-9.19.9.so(+0x47182) [0x7f5ada847182] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /usr/sbin/named(main+0xe7d) [0x56316732549d] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libc.so.6(+0x27b4a) [0x7f5ad9c49b4a] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /lib64/libc.so.6(__libc_start_main+0x8b) [0x7f5ad9c49c0b] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: /usr/sbin/named(_start+0x25) [0x563167325e65] Jan 28 08:20:04 ipa002.test.openqa.fedoraproject.org named[8490]: exiting (due to assertion failure) === with the older bind-9.18.10-2.fc38 and bind-dyndb-ldap-11.10-10.fc38 , we get this instead: Jan 28 13:24:23 ipa001.test.openqa.fedoraproject.org named[8323]: loading DynDB instance 'ipa' driver '/usr/lib64/bind/ldap.so' Jan 28 13:24:23 ipa001.test.openqa.fedoraproject.org named[8323]: failed to dlopen() DynDB instance 'ipa' driver '/usr/lib64/bind/ldap.so': /usr/lib64/bind/ldap.so: undefined symbol: cfg_obj_getdscp Jan 28 13:24:23 ipa001.test.openqa.fedoraproject.org named[8323]: failed to dynamically load DynDB instance 'ipa' driver '/usr/lib64/bind/ldap.so': failure Jan 28 13:24:23 ipa001.test.openqa.fedoraproject.org named[8323]: dynamic database 'ipa' configuration failed: failure Jan 28 13:24:23 ipa001.test.openqa.fedoraproject.org named[8323]: loading configuration: failure Jan 28 13:24:23 ipa001.test.openqa.fedoraproject.org named[8323]: exiting (due to fatal error) but I suspect in both cases, the real cause is that there's a mix of bind and bind9-next packages installed. I suspect this is happening because both bind and bind9-next provide 'bind', and freeipa-server-dns requires 'bind', and dnf picks bind9-next to provide bind because it is higher versioned, but that's only a guess.
Making bind-dyndb-ldap conflict with bind9-next seems to help here: https://openqa.stg.fedoraproject.org/tests/2542883 that's a test of a bind-dyndb-ldap build with the conflict added, it passed, and the logs show no bind9-next installed. bind9-next-dnssec-utils does still get installed and pull in bind9-next-libs - I guess for the same reason, it provides 'bind-dnssec-utils' with a higher version than the one from bind - but fortunately that doesn't seem to break anything. I don't know if this is the best fix, but it at least works and seems pretty safe for now, so I'll do an official build with that change to keep Rawhide working over the weekend. I'll test and see if the bind-9.18.11 update works OK with that change too.
sorry for the dumbly named build, I made it bind-dyndb-ldap-11.10-11.2.fc38 when it should've been bind-dyndb-ldap-11.10-12.fc38. d'oh. won't hurt anything, though. With that build things seem OK, but I'm going to leave this bug open for Petr to think what the best approach would be overall to avoid this kind of mixup or 'getting the wrong thing'. Does bind9-next really need to provide the exact package names of the bind packages?
See bz2165295. nothing provides libdns-9.18.10.so()(64bit) needed by bind-dyndb-ldap-11.10-11.2.fc38.x86_64
gah, that'll be because I did the bind-dyndb-ldap build with the Conflicts: against bind 9.18.10, as bind 9.18.11 was untagged at the time, then we retagged 9.18.11 after fixing this...one more rebuild of bind-dyndb-ldap should get it.
Nothing provides libdns-9.18.10.so, because I made update at friday to libdns-9.18.11. I think that means bind9-next-libs should have conflicts with bind-dyndb-ldap. But I admit this result is unexpected. I relied on prefference of dnf, but it seems it prefers bind-utils over bind9-next-utils only when it is specified on command line. If it is dragged by any dependency, it prefers bind9-next-utils since it is available in repositories. I think I will have to remove Provides: bind-utils and Provides: bind from the bind9-next (sub)packages. I want it to be working alternative, not preferred upgrade path. It seems my checks did not take nested depedencies into account.
FEDORA-EPEL-2023-116ae883fe has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-116ae883fe
FEDORA-2023-76a93ef3d2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-76a93ef3d2
FEDORA-2023-803a3b98c4 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-803a3b98c4
I have removed %{epoch}: from Provides:. This way this package still provides the dependency, but does not have higher version than bind package anymore. That should make manual installations to work, but with default bind or bind-utils installed by default. Because they have the highest version when including epoch in their own version. That should do the trick also for other packages depending on bind-utils.
Build on rawhide.
FEDORA-EPEL-2023-116ae883fe has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-116ae883fe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-76a93ef3d2 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-76a93ef3d2 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-76a93ef3d2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-803a3b98c4 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-803a3b98c4 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-803a3b98c4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
"Nothing provides libdns-9.18.10.so, because I made update at friday to libdns-9.18.11." That was my fault, sorry - what happened is first we untagged the bind update as I thought it was the cause of the problem, then I noticed the bind9-next mess, so I did a build of bind-dyndb-ldap with Conflicts: bind9-next . That solved the problem, but because bind 9.8.11 was untagged at the time, that build was against 9.8.10...then we re-tagged 9.8.11 :P So I had to rebuild bind-dyndb-ldap one more time against 9.8.11. All should be in line now. Thanks for the change to bind9-next, I think the Conflicts: in bind-dyndb-ldap is still probably a good idea though. It makes sense for it to conflict with whichever bind package it *wasn't* built against, I think.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
FEDORA-2023-803a3b98c4 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-76a93ef3d2 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.