Hi,
There was a package mentioned recently that is not in the composes for cs9 https://lists.centos.org/pipermail/centos-devel/2021-July/077184.html
I have another example, python3-pyOpenSSL https://kojihub.stream.centos.org/koji/buildinfo?buildID=6236
This package was built for cs9, but it is not in the composes. I noticed it because python3-pyOpenSSL is a requirement for some ansible modules, for example https://docs.ansible.com/ansible/2.7/modules/openssl_certificate_module.html
https://docs.centos.org/en-US/stream-contrib/quickstart/#_whats_going_on_wit... has some information about koji tags, but to me it is not clear to what it means if specific koji tags are missing, but it seems to me that it should have c9s-gate and possibly other tags too to land in the composes.
My question is: why is this?
best regards, markus
On Thu, Jul 29, 2021 at 8:20 AM Markus Falb markus.falb@mafalb.at wrote:
Hi,
There was a package mentioned recently that is not in the composes for cs9 https://lists.centos.org/pipermail/centos-devel/2021-July/077184.html
I have another example, python3-pyOpenSSL https://kojihub.stream.centos.org/koji/buildinfo?buildID=6236
This package was built for cs9, but it is not in the composes. I noticed it because python3-pyOpenSSL is a requirement for some ansible modules, for example
https://docs.ansible.com/ansible/2.7/modules/openssl_certificate_module.html
https://docs.centos.org/en-US/stream-contrib/quickstart/#_whats_going_on_wit... has some information about koji tags, but to me it is not clear to what it means if specific koji tags are missing, but it seems to me that it should have c9s-gate and possibly other tags too to land in the composes.
My question is: why is this?
best regards, markus
pyOpenSSL was removed completely from RHEL/CS 9.
Looking at the histories, it looks like it was back when we were still getting our untagging scripts/process setup and we missed untagging pyOpenSSL-20.0.1-3.el9 from c9s-candidate before we blocked the package. So it's currently in a weird state of being blocked from c9s-candidate while it's still tagged for it. This has happened before for a few packages, and it's fairly hard to find because command line tools say it isn't tagged, while web based tools say it is.
Anyway, pyOpenSSL is not part of RHEL9 / CS9, and we will get it properly untagged.
Troy
ok, thanks, that made it clear: python3-pyOpenSSL is not there by intention. about dependencies in ansible: it looks that modules dependencies can be handled by python3-cryptography instead, which is present in CentOS 9 Stream.
best regards, markus
On 29.07.2021, at 17:36, Troy Dawson tdawson@redhat.com wrote:
On Thu, Jul 29, 2021 at 8:20 AM Markus Falb markus.falb@mafalb.at wrote: Hi,
There was a package mentioned recently that is not in the composes for cs9 https://lists.centos.org/pipermail/centos-devel/2021-July/077184.html
I have another example, python3-pyOpenSSL https://kojihub.stream.centos.org/koji/buildinfo?buildID=6236
This package was built for cs9, but it is not in the composes. I noticed it because python3-pyOpenSSL is a requirement for some ansible modules, for example https://docs.ansible.com/ansible/2.7/modules/openssl_certificate_module.html
https://docs.centos.org/en-US/stream-contrib/quickstart/#_whats_going_on_wit... has some information about koji tags, but to me it is not clear to what it means if specific koji tags are missing, but it seems to me that it should have c9s-gate and possibly other tags too to land in the composes.
My question is: why is this?
best regards, markus
pyOpenSSL was removed completely from RHEL/CS 9.
Looking at the histories, it looks like it was back when we were still getting our untagging scripts/process setup and we missed untagging pyOpenSSL-20.0.1-3.el9 from c9s-candidate before we blocked the package. So it's currently in a weird state of being blocked from c9s-candidate while it's still tagged for it. This has happened before for a few packages, and it's fairly hard to find because command line tools say it isn't tagged, while web based tools say it is.
Anyway, pyOpenSSL is not part of RHEL9 / CS9, and we will get it properly untagged.
Troy
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 29, 2021 at 12:51 PM Markus Falb markus.falb@mafalb.at wrote:
ok, thanks, that made it clear: python3-pyOpenSSL is not there by intention. about dependencies in ansible: it looks that modules dependencies can be handled by python3-cryptography instead, which is present in CentOS 9 Stream.
Yeah, we need to port the last bits of Ceph that use pyOpenSSL over to cryptography as well. I opened https://tracker.ceph.com/issues/51946 for that. In the meantime, we've built it for el9 at https://copr.fedorainfracloud.org/coprs/ceph/el9
- Ken
On Thu, Jul 29, 2021 at 11:37 AM Troy Dawson tdawson@redhat.com wrote:
This has happened before for a few packages, and it's fairly hard to find because command line tools say it isn't tagged, while web based tools say it is.
When I was looking at this earlier for python-virtualenv, I found that it depends on the command-line tool. For example "koji list-tagged" will not show it because it goes through listTagged -> readTaggedBuilds , which considers "blocked" logic. On the other hand, "koji buildinfo" and "koji list-history --build" (and the buildinfo web UI) will show the tag as active on the individual build.
Blocking packages is an advanced workflow in Koji, and it would be great to simplify this by removing package entries from tags altogether.
I was looking again at https://github.com/ktdreyer/koji-ansible/issues/2 this week. I understand there are some situations where we have to configure a package block, but generally speaking, Ansible performs better if users only configure the exact packages they need, instead of blocking irrelevant packages.
- Ken
On Thu, Jul 29, 2021 at 2:21 PM Ken Dreyer kdreyer@redhat.com wrote:
On Thu, Jul 29, 2021 at 11:37 AM Troy Dawson tdawson@redhat.com wrote:
This has happened before for a few packages, and it's fairly hard to
find because command line tools say it isn't tagged, while web based tools say it is.
When I was looking at this earlier for python-virtualenv, I found that it depends on the command-line tool. For example "koji list-tagged" will not show it because it goes through listTagged -> readTaggedBuilds , which considers "blocked" logic. On the other hand, "koji buildinfo" and "koji list-history --build" (and the buildinfo web UI) will show the tag as active on the individual build.
Yes, those things will show that the package is tagged, but they are on individual packages. They work fine after you know the package has a problem. It's finding the problem packages that has me stuck. I'd like something like "koji list-tagged --show-blocked", but there doesn't seem to be anything like that.
Blocking packages is an advanced workflow in Koji, and it would be great to simplify this by removing package entries from tags altogether.
I was looking again at https://github.com/ktdreyer/koji-ansible/issues/2 this week. I understand there are some situations where we have to configure a package block, but generally speaking, Ansible performs better if users only configure the exact packages they need, instead of blocking irrelevant packages.
Now that you mention that, I believe that's what we do with packages on centos stream. That would explain the list-history entry "package list entry revoked: pyOpenSSL in c9s-candidate" and why my usual "unblock package, untag package-nvr, block package" steps aren't working.
Anyway, still working on getting that one pyOpenSSL build untagged.
Troy
-
Ken Dreyer -
Markus Falb -
Troy Dawson