<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 29, 2021 at 2:21 PM Ken Dreyer <<a href="mailto:kdreyer@redhat.com">kdreyer@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jul 29, 2021 at 11:37 AM Troy Dawson <<a href="mailto:tdawson@redhat.com" target="_blank">tdawson@redhat.com</a>> wrote:<br>
><br>
> 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.<br>
<br>
When I was looking at this earlier for python-virtualenv, I found that<br>
it depends on the command-line tool. For example "koji list-tagged"<br>
will not show it because it goes through listTagged -><br>
readTaggedBuilds , which considers "blocked" logic. On the other hand,<br>
"koji buildinfo" and "koji list-history --build" (and the buildinfo<br>
web UI) will show the tag as active on the individual build.<br>
<br></blockquote><div><br></div><div>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.</div><div>It's finding the problem packages that has me stuck.<br></div><div>I'd like something like "koji list-tagged --show-blocked", but there doesn't seem to be anything like that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Blocking packages is an advanced workflow in Koji, and it would be<br>
great to simplify this by removing package entries from tags<br>
altogether.<br>
<br>
I was looking again at<br>
<a href="https://github.com/ktdreyer/koji-ansible/issues/2" rel="noreferrer" target="_blank">https://github.com/ktdreyer/koji-ansible/issues/2</a> this week. I<br>
understand there are some situations where we have to configure a<br>
package block, but generally speaking, Ansible performs better if<br>
users only configure the exact packages they need, instead of blocking<br>
irrelevant packages.<br>
<br></blockquote><div><br></div><div>Now that you mention that, I believe that's what we do with packages on centos stream.  That would explain the list-history entry</div><div>  "package list entry revoked: pyOpenSSL in c9s-candidate"</div><div> and why my usual "unblock package, untag package-nvr, block package" steps aren't working.</div><div><br></div><div>Anyway, still working on getting that one pyOpenSSL build untagged.</div><div><br></div><div>Troy</div><div><br></div></div></div>