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