Hello,
an attempt to install IPA server currently fails:
# yum -y module enable idm:DL1 Failed to set locale, defaulting to C.UTF-8 CentOS-8 - AppStream 3.5 MB/s | 5.7 MB 00:01 CentOS-8 - Base 3.6 MB/s | 2.2 MB 00:00 CentOS-8 - Extras 69 kB/s | 8.1 kB 00:00 Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Enabling module streams: 389-ds 1.4 httpd 2.4 idm DL1 pki-core 10.6 pki-deps 10.6
Transaction Summary ================================================================================
Complete! # yum -y module install idm:DL1/server [...] (354/357): xmlrpc-c-1.51.0-5.el8.x86_64.rpm 1.6 MB/s | 212 kB 00:00 (355/357): xmlrpc-c-client-1.51.0-5.el8.x86_64. 1.3 MB/s | 40 kB 00:00 (356/357): words-3.0-28.el8.noarch.rpm 2.5 MB/s | 1.4 MB 00:00 (357/357): selinux-policy-targeted-3.14.3-41.el 3.2 MB/s | 15 MB 00:04 -------------------------------------------------------------------------------- Total 3.9 MB/s | 212 MB 00:53 warning: /var/cache/dnf/AppStream-02e86d1c976ab532/packages/389-ds-base-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8483c65d: NOKEY CentOS-8 - AppStream 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0x8483C65D: Userid : "CentOS (CentOS Official Signing Key) security@centos.org" Fingerprint: 99DB 70FA E1D7 CE22 7FB6 4882 05B5 55B3 8483 C65D From : /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial Key imported successfully Running transaction check No available modular metadata for modular package '389-ds-base-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64', it cannot be installed on the system No available modular metadata for modular package '389-ds-base-libs-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64', it cannot be installed on the system No available modular metadata for modular package 'python3-lib389-1.4.2.4-10.module_el8.2.0+489+38ed056a.noarch', it cannot be installed on the system The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. Error: No available modular metadata for modular package
What is the appropriate place to report this issue? I assume bugs.centos.org is not it because the package itself is likely built just fine. At least two days ago the installation passed.
On 18/09/2020 08:08, Jan Pazdziora wrote:
Hello,
an attempt to install IPA server currently fails:
# yum -y module enable idm:DL1 Failed to set locale, defaulting to C.UTF-8 CentOS-8 - AppStream 3.5 MB/s | 5.7 MB 00:01 CentOS-8 - Base 3.6 MB/s | 2.2 MB 00:00 CentOS-8 - Extras 69 kB/s | 8.1 kB 00:00 Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Enabling module streams: 389-ds 1.4 httpd 2.4 idm DL1 pki-core 10.6 pki-deps 10.6
Transaction Summary
Complete! # yum -y module install idm:DL1/server [...] (354/357): xmlrpc-c-1.51.0-5.el8.x86_64.rpm 1.6 MB/s | 212 kB 00:00 (355/357): xmlrpc-c-client-1.51.0-5.el8.x86_64. 1.3 MB/s | 40 kB 00:00 (356/357): words-3.0-28.el8.noarch.rpm 2.5 MB/s | 1.4 MB 00:00 (357/357): selinux-policy-targeted-3.14.3-41.el 3.2 MB/s | 15 MB 00:04
Total 3.9 MB/s | 212 MB 00:53 warning: /var/cache/dnf/AppStream-02e86d1c976ab532/packages/389-ds-base-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8483c65d: NOKEY CentOS-8 - AppStream 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0x8483C65D: Userid : "CentOS (CentOS Official Signing Key) security@centos.org" Fingerprint: 99DB 70FA E1D7 CE22 7FB6 4882 05B5 55B3 8483 C65D From : /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial Key imported successfully Running transaction check No available modular metadata for modular package '389-ds-base-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64', it cannot be installed on the system No available modular metadata for modular package '389-ds-base-libs-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64', it cannot be installed on the system No available modular metadata for modular package 'python3-lib389-1.4.2.4-10.module_el8.2.0+489+38ed056a.noarch', it cannot be installed on the system The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. Error: No available modular metadata for modular package
What is the appropriate place to report this issue? I assume bugs.centos.org is not it because the package itself is likely built just fine. At least two days ago the installation passed.
Ideally yes, a report on bugs.centos.org would be fine, but asking directly here or in #centos-devel would probably catch Johnny's attention faster than a report on bugs.centos.org ...
Some people reported also issues with other modules, so seems general issue with modules metadata.
Let's wait for Johnny or Brian to be "vertical" and so investigate the root cause and so kick another compose , test and then push out.
On Fri, Sep 18, 2020 at 08:31:28AM +0200, Fabian Arrotin wrote:
Let's wait for Johnny or Brian to be "vertical" and so investigate the root cause and so kick another compose , test and then push out.
As this potentially affects a rather large number of people perhaps waking them up is warranted.
John
On September 18, 2020 9:39:13 AM GMT+03:00, "John R. Dennison" jrd@gerdesas.com wrote:
On Fri, Sep 18, 2020 at 08:31:28AM +0200, Fabian Arrotin wrote:
Let's wait for Johnny or Brian to be "vertical" and so investigate
the
root cause and so kick another compose , test and then push out.
As this potentially affects a rather large number of people perhaps waking them up is warranted.
And maybe "we" can invent a system which does have the US based timezones and holidays as SPF
wolfy
On 9/18/20 2:19 AM, Manuel Wolfshant wrote:
On September 18, 2020 9:39:13 AM GMT+03:00, "John R. Dennison" jrd@gerdesas.com wrote:
On Fri, Sep 18, 2020 at 08:31:28AM +0200, Fabian Arrotin wrote:
Let's wait for Johnny or Brian to be "vertical" and so investigate
the
root cause and so kick another compose , test and then push out.
As this potentially affects a rather large number of people perhaps waking them up is warranted.
And maybe "we" can invent a system which does have the US based timezones and holidays as SPF
wolfy
That would be great .. who is going to pay for that. I would love to add about 30 people to my work group.
On 9/18/20 1:39 AM, John R. Dennison wrote:
On Fri, Sep 18, 2020 at 08:31:28AM +0200, Fabian Arrotin wrote:
Let's wait for Johnny or Brian to be "vertical" and so investigate the root cause and so kick another compose , test and then push out.
As this potentially affects a rather large number of people perhaps waking them up is warranted.
CentOS is a Free, best effort project. Not only do you thin you are entitled to perfectly working free stuff .. you think i should be on call at 1:00am as well to fix it. Got it.
On 9/18/20 1:08 AM, Jan Pazdziora wrote:
Hello,
an attempt to install IPA server currently fails:
# yum -y module enable idm:DL1 Failed to set locale, defaulting to C.UTF-8 CentOS-8 - AppStream 3.5 MB/s | 5.7 MB 00:01 CentOS-8 - Base 3.6 MB/s | 2.2 MB 00:00 CentOS-8 - Extras 69 kB/s | 8.1 kB 00:00 Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Enabling module streams: 389-ds 1.4 httpd 2.4 idm DL1 pki-core 10.6 pki-deps 10.6
Transaction Summary
Complete! # yum -y module install idm:DL1/server [...] (354/357): xmlrpc-c-1.51.0-5.el8.x86_64.rpm 1.6 MB/s | 212 kB 00:00 (355/357): xmlrpc-c-client-1.51.0-5.el8.x86_64. 1.3 MB/s | 40 kB 00:00 (356/357): words-3.0-28.el8.noarch.rpm 2.5 MB/s | 1.4 MB 00:00 (357/357): selinux-policy-targeted-3.14.3-41.el 3.2 MB/s | 15 MB 00:04
Total 3.9 MB/s | 212 MB 00:53 warning: /var/cache/dnf/AppStream-02e86d1c976ab532/packages/389-ds-base-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8483c65d: NOKEY CentOS-8 - AppStream 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0x8483C65D: Userid : "CentOS (CentOS Official Signing Key) security@centos.org" Fingerprint: 99DB 70FA E1D7 CE22 7FB6 4882 05B5 55B3 8483 C65D From : /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial Key imported successfully Running transaction check No available modular metadata for modular package '389-ds-base-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64', it cannot be installed on the system No available modular metadata for modular package '389-ds-base-libs-1.4.2.4-10.module_el8.2.0+489+38ed056a.x86_64', it cannot be installed on the system No available modular metadata for modular package 'python3-lib389-1.4.2.4-10.module_el8.2.0+489+38ed056a.noarch', it cannot be installed on the system The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. Error: No available modular metadata for modular package
What is the appropriate place to report this issue? I assume bugs.centos.org is not it because the package itself is likely built just fine. At least two days ago the installation passed.
There was an issue with the pungi compose for both the latest mysql module and the ds-389 module .. we are working on both of these now.
There seems to be a bug in module metadata (in the module build system) when reusing some of the older builds ... we are looking at it now.
So we are working on the actual issue, the cause of this issue, and some kind of test to properly check for this specific issue in the future.
BTW .. we run these open source tests to validate things are ready for release:
https://github.com/CentOS/sig-core-t_functional
Test and bugfix patches are accepted to make it better. The Community in CentOS is need to make these things work better. People seem to think that we need help building things .. but building is easy. We need help testing things (like tests for modulemd, obviously).
Please remember CentOS Linux 8 is very much more complicated with modules and 3 levels of builds, etc. The build system and testing system are both works in progress and this is going to happen from time to time while we get better.
Thanks, Johnny Hughes
On Fri, Sep 18, 2020 at 08:28:26AM -0500, Johnny Hughes wrote:
There was an issue with the pungi compose for both the latest mysql module and the ds-389 module .. we are working on both of these now.
There seems to be a bug in module metadata (in the module build system) when reusing some of the older builds ... we are looking at it now.
So we are working on the actual issue, the cause of this issue, and some kind of test to properly check for this specific issue in the future.
Great, thanks,
On 9/18/20 8:31 AM, Jan Pazdziora wrote:
On Fri, Sep 18, 2020 at 08:28:26AM -0500, Johnny Hughes wrote:
There was an issue with the pungi compose for both the latest mysql module and the ds-389 module .. we are working on both of these now.
There seems to be a bug in module metadata (in the module build system) when reusing some of the older builds ... we are looking at it now.
So we are working on the actual issue, the cause of this issue, and some kind of test to properly check for this specific issue in the future.
OK .. we created a check script that we can use at compose time to check the items that will be placed in the modulemd. This will let us get an update published in a few minutes that fixes mysql and 389-ds.
I still want / need something for the t_functional that specifically tests modules that exist in the release. I am going to start working on this test today .. but good ideas can be posted here in git am format or contact me on IRC (freenode: hughesjr)
Again .. here is the source code of the test suite that we run:
https://github.com/CentOS/sig-core-t_functional
In the next hour or so, after I run some more tests, I should release this compose. It only contains metadata at this point.
We are also working on a newer centos-release for CentOS 8 Linux (centos-release-8.2-2.2004.0.2.el8). This may also get into the release. It should let us use separate release files for CentOS Linux and CentOS Stream in the future.
Thanks, Johnny Hughes
On 9/18/20 10:45 AM, Johnny Hughes wrote:
On 9/18/20 8:31 AM, Jan Pazdziora wrote:
On Fri, Sep 18, 2020 at 08:28:26AM -0500, Johnny Hughes wrote:
There was an issue with the pungi compose for both the latest mysql module and the ds-389 module .. we are working on both of these now.
There seems to be a bug in module metadata (in the module build system) when reusing some of the older builds ... we are looking at it now.
So we are working on the actual issue, the cause of this issue, and some kind of test to properly check for this specific issue in the future.
OK .. we created a check script that we can use at compose time to check the items that will be placed in the modulemd. This will let us get an update published in a few minutes that fixes mysql and 389-ds.
I still want / need something for the t_functional that specifically tests modules that exist in the release. I am going to start working on this test today .. but good ideas can be posted here in git am format or contact me on IRC (freenode: hughesjr)
Again .. here is the source code of the test suite that we run:
https://github.com/CentOS/sig-core-t_functional
In the next hour or so, after I run some more tests, I should release this compose. It only contains metadata at this point.
We are also working on a newer centos-release for CentOS 8 Linux (centos-release-8.2-2.2004.0.2.el8). This may also get into the release. It should let us use separate release files for CentOS Linux and CentOS Stream in the future.
OK guys .. all the modules should be working now on mirror.centos.org .. and external mirrors should catch up soon (if you are using mirrorlist).
This was a bug where MBS did not copy over metadata for rpms that it reused in the module build process.. so the modulemd file was missing info for reused rpms.
If anyone else has any other issues with this problem .. post on this list or contact me on IRC (freenode: hughesjr).
We have done 2 things to try to prevent this in the future.
1) We have a post compose script that looks at modulemd of the new and last update .. if they contain a different set or rpms, it prints a warning to check it manually.
2) We are upgrading the MBS/Koji build system we use for CentOS Linux 8 / CentOS Stream to newer versions this quarter.
As a third thing .. I am working on some dnf module tests i can do in the t_functional suite .. but suggestions, patch requests welcome for this:
https://github.com/CentOS/sig-core-t_functional
Also, the new centos-release file did indeed also get in this update set.
Thanks, Johnny Hughes
-
Fabian Arrotin -
Jan Pazdziora -
John R. Dennison -
Johnny Hughes -
Manuel Wolfshant