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