On ma, 07 helmi 2022, lejeczek via CentOS-devel wrote: >On 04/02/2022 15:58, Johnny Hughes wrote: >>On 2/4/22 03:02, lejeczek via CentOS-devel wrote: >>>Hi guys, >>> >>>I did not rush with this but now after a week and some - does >>>anybody else sees it to? >>> >>>Last metadata expiration check: 0:03:21 ago on Fri 04 Feb 2022 >>>08:57:59 GMT. >>>Error: >>> Problem 1: package >>>bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires >>>libdns.so.1112()(64bit), but none of the providers can be >>>installed >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-6.el8.x86_64 >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-3.el8.x86_64 >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-4.el8_4.x86_64 >>> - cannot install the best update candidate for package >>>bind-libs-lite-32:9.11.26-6.el8.x86_64 >>> - cannot install the best update candidate for package >>>bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 >>> Problem 2: problem with installed package >>>bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 >>> - package >>>bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires >>>libdns.so.1112()(64bit), but none of the providers can be >>>installed >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-6.el8.x86_64 >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-3.el8.x86_64 >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-4.el8_4.x86_64 >>> - package bind-32:9.11.36-2.el8.x86_64 requires >>>libdns.so.1115()(64bit), but none of the providers can be >>>installed >>> - package bind-32:9.11.36-2.el8.x86_64 requires >>>bind-libs-lite(x86-64) = 32:9.11.36-2.el8, but none of the >>>providers can be installed >>> - cannot install the best update candidate for package >>>bind-32:9.11.26-6.el8.x86_64 >>> Problem 3: package >>>ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch >>>requires bind-dyndb-ldap >= 11.2-2, but none of the providers can >>>be installed >>> - package >>>bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires >>>libdns.so.1112()(64bit), but none of the providers can be >>>installed >>> - package >>>bind-dyndb-ldap-11.6-2.module_el8.4.0+639+a88aab78.x86_64 requires >>>libdns.so.1112()(64bit), but none of the providers can be >>>installed >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-6.el8.x86_64 >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-3.el8.x86_64 >>> - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 >>>and bind-libs-lite-32:9.11.26-4.el8_4.x86_64 >>> - package bind-libs-32:9.11.36-2.el8.x86_64 requires >>>libdns.so.1115()(64bit), but none of the providers can be >>>installed >>> - package bind-libs-32:9.11.36-2.el8.x86_64 requires >>>bind-libs-lite(x86-64) = 32:9.11.36-2.el8, but none of the >>>providers can be installed >>> - cannot install the best update candidate for package >>>ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch >>> - cannot install the best update candidate for package >>>bind-libs-32:9.11.26-6.el8.x86_64 >>> Problem 4: problem with installed package >>>ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch >>> - package >>>ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch >>>requires bind-dyndb-ldap >= 11.2-2, but none of the providers can >>>be installed >>> - package >>>bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires >>>libdns.so.1112()(64bit), but none of the providers can be >>>installed >>> - package >>>bind-dyndb-ldap-11.6-2.module_el8.4.0+639+a88aab78.x86_64 requires >>>libdns.so.1112()(64bit), but none of the providers can be >>>installed >>> - package bind-libs-lite-32:9.11.26-6.el8.x86_64 requires >>>bind-license = 32:9.11.26-6.el8, but none of the providers can be >>>installed >>> - package bind-libs-lite-32:9.11.26-3.el8.x86_64 requires >>>bind-license = 32:9.11.26-3.el8, but none of the providers can be >>>installed >>> - package bind-libs-lite-32:9.11.26-4.el8_4.x86_64 requires >>>bind-license = 32:9.11.26-4.el8_4, but none of the providers can >>>be installed >>> - cannot install both bind-license-32:9.11.36-2.el8.noarch and >>>bind-license-32:9.11.26-6.el8.noarch >>> - cannot install both bind-license-32:9.11.36-2.el8.noarch and >>>bind-license-32:9.11.26-3.el8.noarch >>> - cannot install both bind-license-32:9.11.36-2.el8.noarch and >>>bind-license-32:9.11.26-4.el8_4.noarch >>> - cannot install the best update candidate for package >>>bind-license-32:9.11.26-6.el8.noarch >>> >>>many thanks, L >>> >> >>CentOS 8 Linux is EOL and no longer on the mirrors. >> >>If you are using CentOS 8 Linux, youu need to replace it with CentOS >>8 Stream, RHEL 8, or one of the RHEL 8 rebuilds. >> >>I am not getting this issue on CentOS 8 Stream. >> >But it's not CentOS EOL - system was 'swapped' a while go. This is >on/from CentOS Stream. > >Something - module? - must have not "migrated" over to 'stream'. This >must be easily reproducible - have IdM up & working (from 'idm' >module) on non-stream then 'swap'. This is one more sample of manual CentOS 8 Stream update mode, unfortunately. In December 2021 bind and bind-dyndb-ldap were rebuilt when bind bumped its ABI. Since bind-dyndb-ldap is in idm:DL1 module stream, it got combined with the whole idm:DL1 update. That update also included hardening for CVE-2021-25717 (Samba and Active Directory issue). Now that all updates for this CVE were shipped in RHEL z-streams, it can be pushed to CentOS 8 Stream. In fact, it could have been pushed for about two weeks now, together with bind update, but since these checks on 'CVE should be fixed in released RHEL first' are partially manual for CentOS 8 Stream, it was only noticed when bind update broke the stream. I asked Carl to unblock us here. In CentOS 9 Stream this is automated and coordinated builds will be blocked together until all of them allowed. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland