Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Problem 1: package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2()(64bit), but none of the providers can be installed - package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2(NDR_0.0.1)(64bit), but none of the providers can be installed - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.4-2.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.3-0.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.4-0.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-0.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-3.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-4.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-5.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-8.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.1-0.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.2-1.el8.x86_64 - cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.4-1.el8.x86_64 - cannot install the best update candidate for package sssd-common-pac-2.7.3-4.el8.x86_64 - cannot install the best update candidate for package samba-client-libs-4.16.4-2.el8.x86_64 Problem 2: package sssd-idp-2.7.3-4.el8.x86_64 requires sssd-common = 2.7.3-4.el8, but none of the providers can be installed - package libsss_autofs-2.7.3-5.el8.x86_64 conflicts with sssd-common < 2.7.3-5.el8 provided by sssd-common-2.7.3-4.el8.x86_64 - cannot install the best update candidate for package sssd-idp-2.7.3-4.el8.x86_64 - cannot install the best update candidate for package libsss_autofs-2.7.3-4.el8.x86_64 Problem 3: package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2()(64bit), but none of the providers can be installed - package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2(NDR_0.0.1)(64bit), but none of the providers can be installed
Or it's just me? many thanks, L.
On pe, 25 marras 2022, lejeczek via CentOS-devel wrote:
Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Errors do happen in development branches.
CentOS 8 Stream process is backwards and does not allow to properly inherit build sequence for rebases that require side-tag use.
I have wrote a warning on FreeIPA mailing list yesterday: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
None of the developers involved in those packages' maintenance have any influence at how CentOS 8 Stream packages built and composed. We can suggest certain things but ultimately it is outside of our control. It is better with CentOS 9 Stream process but even that does not help when public holidays are involved, like Thanksgiving in US right now -- we simply have no reach to people who could do anything to composes.
Please refrain from an upgrade until next week.
Am 25.11.22 um 12:26 schrieb Alexander Bokovoy:
On pe, 25 marras 2022, lejeczek via CentOS-devel wrote:
Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Errors do happen in development branches.
CentOS 8 Stream process is backwards and does not allow to properly inherit build sequence for rebases that require side-tag use.
I have wrote a warning on FreeIPA mailing list yesterday: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
None of the developers involved in those packages' maintenance have any influence at how CentOS 8 Stream packages built and composed. We can suggest certain things but ultimately it is outside of our control. It is better with CentOS 9 Stream process but even that does not help when public holidays are involved, like Thanksgiving in US right now -- we simply have no reach to people who could do anything to composes.
Please refrain from an upgrade until next week.
Even with such constrains / dependencies, that always are in such complex sociotechnical-systems, one thing I would appreciate; in general more communication. Just an example (happens recurrently also in other corners) your mail never reached the CentOS list IIRC. So, like a marketing campaign I would suggest to spread the word into all kind of channels, to be sure that communication also happens outside of the own silo, :-).
-- Leon
On pe, 25 marras 2022, Leon Fauster via CentOS-devel wrote:
Am 25.11.22 um 12:26 schrieb Alexander Bokovoy:
On pe, 25 marras 2022, lejeczek via CentOS-devel wrote:
Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Errors do happen in development branches.
CentOS 8 Stream process is backwards and does not allow to properly inherit build sequence for rebases that require side-tag use.
I have wrote a warning on FreeIPA mailing list yesterday: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
None of the developers involved in those packages' maintenance have any influence at how CentOS 8 Stream packages built and composed. We can suggest certain things but ultimately it is outside of our control. It is better with CentOS 9 Stream process but even that does not help when public holidays are involved, like Thanksgiving in US right now -- we simply have no reach to people who could do anything to composes.
Please refrain from an upgrade until next week.
Even with such constrains / dependencies, that always are in such complex sociotechnical-systems, one thing I would appreciate; in general more communication. Just an example (happens recurrently also in other corners) your mail never reached the CentOS list IIRC. So, like a marketing campaign I would suggest to spread the word into all kind of channels, to be sure that communication also happens outside of the own silo, :-).
That's a fair ask, sorry for not cross-posting it here yesterday when I got to know about the problem.
On 11/25/22 12:26, Alexander Bokovoy wrote:
On pe, 25 marras 2022, lejeczek via CentOS-devel wrote:
Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Errors do happen in development branches.
CentOS 8 Stream process is backwards and does not allow to properly inherit build sequence for rebases that require side-tag use.
These sorts of issues are precisely why we'd like to see public integration testing where the community (including package maintainers, obviously) could contribute tests to catch these errors before they are distributed to the mirrors.
We've asked[1] the CentOS Board to help make this happen, but more community voices might help.
Cheers, Alex
On 11/28/22 10:00, Alex Iribarren wrote:
On 11/25/22 12:26, Alexander Bokovoy wrote:
On pe, 25 marras 2022, lejeczek via CentOS-devel wrote:
Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Errors do happen in development branches.
CentOS 8 Stream process is backwards and does not allow to properly inherit build sequence for rebases that require side-tag use.
These sorts of issues are precisely why we'd like to see public integration testing where the community (including package maintainers, obviously) could contribute tests to catch these errors before they are distributed to the mirrors.
We've asked[1] the CentOS Board to help make this happen, but more community voices might help.
Cheers, Alex
We are working on moving the CentOS Stream 8 process to be like the CentOS Stream 9 process. Once that process is in place it will help prevent issues like this. But this takes time.
The main reason these things can happen right now is the standard repoclosure does not work properly with modules integrated into the distribution.
We rolled in t_functional tests that catch many of these issues, like this test:
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/5...
That tests comps install groups.
When new items come up, we try to add tests to prevent them in the future.
We are now working on a specific t_functional test to check the Samba, IPA, SSSD, evolution-mapi, openchange chain.
Community pull requests for t_fucntional gladly accepted :)
Thanks, Johnny Hughes
Hi Johnny,
On 12/1/22 02:12, Johnny Hughes wrote:
We are working on moving the CentOS Stream 8 process to be like the CentOS Stream 9 process. Once that process is in place it will help prevent issues like this. But this takes time.
The main reason these things can happen right now is the standard repoclosure does not work properly with modules integrated into the distribution.
We rolled in t_functional tests that catch many of these issues, like this test:
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/5...
That tests comps install groups.
When new items come up, we try to add tests to prevent them in the future.
We are now working on a specific t_functional test to check the Samba, IPA, SSSD, evolution-mapi, openchange chain.
Community pull requests for t_fucntional gladly accepted :)
Thanks for highlighting 50_test_comps.sh. In fact, I contributed that test myself exactly to catch these sorts of issues. I suppose it didn't catch it in this case, but I can't actually confirm because ci.centos.org seems to be down. Maybe it was down when these packages were being built and that compose didn't go through the CI?
My open issue with the CentOS Board is precisely to have something like ci.centos.org and t_functional for Stream 9, which is something that doesn't currently exist.
Cheers, Alex
On 12/1/22 07:30, Alex Iribarren wrote:
Hi Johnny,
On 12/1/22 02:12, Johnny Hughes wrote:
We are working on moving the CentOS Stream 8 process to be like the CentOS Stream 9 process. Once that process is in place it will help prevent issues like this. But this takes time.
The main reason these things can happen right now is the standard repoclosure does not work properly with modules integrated into the distribution.
We rolled in t_functional tests that catch many of these issues, like this test:
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/5...
That tests comps install groups.
When new items come up, we try to add tests to prevent them in the future.
We are now working on a specific t_functional test to check the Samba, IPA, SSSD, evolution-mapi, openchange chain.
Community pull requests for t_fucntional gladly accepted :)
Thanks for highlighting 50_test_comps.sh. In fact, I contributed that test myself exactly to catch these sorts of issues. I suppose it didn't catch it in this case, but I can't actually confirm because ci.centos.org seems to be down. Maybe it was down when these packages were being built and that compose didn't go through the CI?
My open issue with the CentOS Board is precisely to have something like ci.centos.org and t_functional for Stream 9, which is something that doesn't currently exist.
We run tests CI tests for 'el7' and 'c8s' in our QA CI setup right now. That test did run and pass. It seems it does not test the right combinations of packages for that chain together in an install (samba/ipa/openchange/evolution-mapi/sssd). Which is why we are writing a specific test for this specific chain. We am also working on a test to ensure we don't forget to rebuild annobin if we upgrade gcc.
I know that as a group we are working on getting t_functional working for CentOS Stream 9 (you can see that from the many updates by Adam Selah in there lately).
https://github.com/CentOS/sig-core-t_functional/commits/master
My understanding is that this will be run on CentOS Stream 9 composes (and CentOS Stream 8 composes once the builds move to the new koji stream builder) in a different location that publicly available, before release.
You can also see the builds from the current c8s builder are being moved to the new koji stream builder (right now actually):
https://kojihub.stream.centos.org/koji/builds
Everything 'el8' in there is me moving things over.
So this is being actively worked on.
Thanks, Johnny Hughes
On 01/12/2022 14:53, Johnny Hughes wrote:
On 12/1/22 07:30, Alex Iribarren wrote:
Hi Johnny,
On 12/1/22 02:12, Johnny Hughes wrote:
We are working on moving the CentOS Stream 8 process to be like the CentOS Stream 9 process. Once that process is in place it will help prevent issues like this. But this takes time.
The main reason these things can happen right now is the standard repoclosure does not work properly with modules integrated into the distribution.
We rolled in t_functional tests that catch many of these issues, like this test:
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/5...
That tests comps install groups.
When new items come up, we try to add tests to prevent them in the future.
We are now working on a specific t_functional test to check the Samba, IPA, SSSD, evolution-mapi, openchange chain.
Community pull requests for t_fucntional gladly accepted :)
Thanks for highlighting 50_test_comps.sh. In fact, I contributed that test myself exactly to catch these sorts of issues. I suppose it didn't catch it in this case, but I can't actually confirm because ci.centos.org seems to be down. Maybe it was down when these packages were being built and that compose didn't go through the CI?
My open issue with the CentOS Board is precisely to have something like ci.centos.org and t_functional for Stream 9, which is something that doesn't currently exist.
We run tests CI tests for 'el7' and 'c8s' in our QA CI setup right now. That test did run and pass. It seems it does not test the right combinations of packages for that chain together in an install (samba/ipa/openchange/evolution-mapi/sssd). Which is why we are writing a specific test for this specific chain. We am also working on a test to ensure we don't forget to rebuild annobin if we upgrade gcc.
I know that as a group we are working on getting t_functional working for CentOS Stream 9 (you can see that from the many updates by Adam Selah in there lately).
https://github.com/CentOS/sig-core-t_functional/commits/master
My understanding is that this will be run on CentOS Stream 9 composes (and CentOS Stream 8 composes once the builds move to the new koji stream builder) in a different location that publicly available, before release.
You can also see the builds from the current c8s builder are being moved to the new koji stream builder (right now actually):
https://kojihub.stream.centos.org/koji/builds
Everything 'el8' in there is me moving things over.
So this is being actively worked on.
Thanks, Johnny
It's great that Centos, Redhat & freeIPA want to resolve these CI issues - as this has been the problem every single time for past ~2 yrs - once and for all and together. The rest of us appreciate it greatly. Meanwhile - it's been almost a month - is there any fix on the horizon for this very rpm-conflicts occurrence? many thanks, L.
On Wed, Nov 30, 2022 at 8:12 PM Johnny Hughes johnny@centos.org wrote:
We are working on moving the CentOS Stream 8 process to be like the CentOS Stream 9 process. Once that process is in place it will help prevent issues like this. But this takes time.
In the middle term, he building of FreeIPA and sssd on top of the same libraries as Samba hinders updates to Samba. Samba does have the ability to compile ldb, talloc, and the Heimdal kerberos libraries internally. It's what I've been doing to backport current Samba releases to RHEL/CentOS 8 and 9. I've also given up on current Samba releases for RHEL 7, because of the gnutls dependencies.
This is one of those cases where demanding that Samba share these libraries with these other components is counterproductive. My samba.spec file to support this is at:
https://github.com/nkadel/samba-4.17.x-srpm/blob/master/samba.spec
The main reason these things can happen right now is the standard repoclosure does not work properly with modules integrated into the distribution.
Unfortunately, that word "module" is overburdened.
We rolled in t_functional tests that catch many of these issues, like this test:
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/5...
That tests comps install groups.
When new items come up, we try to add tests to prevent them in the future.
We are now working on a specific t_functional test to check the Samba, IPA, SSSD, evolution-mapi, openchange chain.
If I may suggest, don't test them together, for precisely the design reasons I mention above. Samba and those other tools do not need to share the same libtevent, libldb, etc.
Community pull requests for t_fucntional gladly accepted :)
Thanks, Johnny Hughes _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Nov 25, 2022 at 6:02 AM lejeczek via CentOS-devel centos-devel@centos.org wrote:
Hi gents.
It seems this has been a routine - each time when either sssd or Samba or FreeIPA gets new releases (with freeIPA deployed) there will be 'rpm' conflicts:
Yup! This is the problem with both Samba, and sssd, relying extensively on divverent versions of the same libraries. I publish RPM building tools for Samba, with full domain controller features and the known funcitonal Heimdal kerberos library, over at https://github.com/nkadel/samba4repo/ .
One solution is to throw out sssd: it is a wrapper on top of Samba libraries, it has a *lot* of architectural issues, and its configuration tools are very poor. But if you want to leave sssd in place for use as a client, it's possible to compile Samba with with the "with_includelibs" option. It takes some tuning to accomplish because it hasn't been used by anyone else I can detect in years, but I publish a .spec file for just this purpose at:
https://github.com/nkadel/samba-4.17.x-srpm/blob/master/samba.spec
This approach fully divorces Samba from the RHEL published libldb, libtdb, libtevent, and libtalloc in favor of internal versions. Given the version incompatibilities, and the very weird relationships between sssd and Samba, I'd recommend this approach for anyone who really wants to run Samba servers on RHEL. The reliance on the unapproved MIT Kerberos compatibility for RHEL and Fedora based Samba is another problem I've tried to address.
Problem 1: package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2()(64bit), but none of the providers can be installed
- package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2(NDR_0.0.1)(64bit), but none of the providers can be installed
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.4-2.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.3-0.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.4-0.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-0.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-3.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-4.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-5.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.15.5-8.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.1-0.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.2-1.el8.x86_64
- cannot install both samba-client-libs-4.17.2-2.el8.x86_64 and samba-client-libs-4.16.4-1.el8.x86_64
- cannot install the best update candidate for package sssd-common-pac-2.7.3-4.el8.x86_64
- cannot install the best update candidate for package samba-client-libs-4.16.4-2.el8.x86_64
Problem 2: package sssd-idp-2.7.3-4.el8.x86_64 requires sssd-common = 2.7.3-4.el8, but none of the providers can be installed
- package libsss_autofs-2.7.3-5.el8.x86_64 conflicts with sssd-common < 2.7.3-5.el8 provided by sssd-common-2.7.3-4.el8.x86_64
- cannot install the best update candidate for package sssd-idp-2.7.3-4.el8.x86_64
- cannot install the best update candidate for package libsss_autofs-2.7.3-4.el8.x86_64
Problem 3: package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2()(64bit), but none of the providers can be installed
- package sssd-common-pac-2.7.3-5.el8.x86_64 requires libndr.so.2(NDR_0.0.1)(64bit), but none of the providers can be installed
Or it's just me? many thanks, L.
-
Alex Iribarren -
Alexander Bokovoy -
Johnny Hughes -
lejeczek -
Leon Fauster -
Nico Kadel-Garcia