When do you need this to be done by? (YYYY/MM/DD)

I waived it through the "master" waive button in bodhi, but it cannot be waived individually.

The rpminspect failure was not gating the update. We clearly need to improve the Bodhi UI as nobody understands this, but it does tell you what tests are gating: the ones with an asterisk in the left-most column of the results table. If you hover over the asterisk it gives you a tooltip explaining this.

The only gating test for https://bodhi.fedoraproject.org/updates/FEDORA-2024-d4f6616df7 is fedora-ci.koji-build./plans/public.functional, that's the one that was blocking the update. It seems you managed to waive it now.

The rpminspect failure was not gating the update. We clearly need to improve the Bodhi UI as nobody understands this, but it does tell you what tests are gating: the ones with an asterisk in the left-most column of the results table. If you hover over the asterisk it gives you a tooltip explaining this.

The only gating test for https://bodhi.fedoraproject.org/updates/FEDORA-2024-d4f6616df7 is fedora-ci.koji-build./plans/public.functional, that's the one that was blocking the update. It seems you managed to waive it now.

Sorry, I was confused by the "unwaivable" word on the rpminspect result page.

ah, I think that's a context problem :) I believe it's "unwaivable" within the context of rpminspect - rpminspect has its own configuration mechanism by which you can say "it's fine if this subtest fails for my package". the license check is exempted from that, apparently.

interesting issue with the license, @dcantrell PTAL pls

yeah, gating is only what you has the star, and that should match what you have in gating.yaml file in the component dist-git

A couple of things:

• Yes, SPDX license identifiers can be mixed case, however this is rarely happening in the wild and part of our work over the past few years migrating to SPDX identifiers involves using the identifiers as published by SPDX. Mixing case, IMHO, is going to just confuse people so my recommendation is to use the identifier as published by SPDX.

• I can modify rpminspect for this case insensitive match, but can you file an issue with rpminspect (https://github.com/rpminspect/rpminspect) so I don't forget. I am currently traveling for work and am not in the office.

• The severity levels that rpminspect reports are entirely arbitrary and come from rpminspect's ancestor (where the various findings and their type of severity were determined by QA and security teams and other groups). It's just information that rpminspect reports. Anything at the VERIFY reporting level or higher will cause rpminspect to exit non-zero indicating something it thinks is bad was found somewhere. If all findings are below VERIFY, it exits zero. All license tag findings that are not in the license database are failures and cannot be waived. rpminspect reads license data from the fedora-license-data project--this is not internal information in rpminspect. How the reporting levels are handled by the higher level tool that runs rpminspect is also up to that tool. There are likely areas where this integration can be improved; I just don't know all the integration points for rpminspect.

Thanks, the ticket:
https://github.com/rpminspect/rpminspect/issues/1335

Just to point out the license name is case insensitive, but the operators are case sensitive, e.g.: the following should match:

gpl-2.0-or-later AND mit

but the following shouldn't match:

gpl-2.0-or-later and mit

license-validate implements it correctly.

I am aware, thanks.

So, I don't think there's anything left for infrastructure to do here.

If I missed something, please feel free to reopen or file a new ticket.