On Tue, Mar 2, 2021 at 3:00 PM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: If you think the test failures are all due to infrastructure problems or false positives, you should be able to waive the gating tests: $ bodhi updates waive FEDORA-2021-667db9b546 "failed gating tests are false positives" or something like that. Fabio

Hi Richard, This is https://pagure.io/fedora-ci/general/issue/161, only know workaround is to rerun the test (by logging in to the Jenkins instance and hitting the Rebuild button). Not yet sure why this is happening, I will try to concentrate on it in next weeks, it is quite random. I believe you can now configure rpminspect do not run tests which are not interesting to you. I am looking for a documentation how to do that. Best regards, /M > > Rich.

On Tue, 2021-03-02 at 13:59 +0000, Richard W.M. Jones wrote: The test description does explain this to some extent: "Report changed files from the before build to the after build. Certain file changes will raise additional warnings if the concern is more critical than just reporting changes (e.g., a suspected security impact)." I suspect the types of files that changed here are flagged as being "critical" on the basis that they are effectively ABI, so this is telling you more or less the same thing as the abidiff failure: the update changes the ABI. Note that many other files in the package will have changed, but they're not *all* shown in the test results, just these specific ones. The question here is more "should ABI change-type issues be counted as failures on Rawhide 'updates'?", I think. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

On Tue, Mar 02, 2021 at 08:26:31AM -0800, Adam Williamson wrote: No, it shouldn't count. What I did yesterday is add a 'rawhide' profile to rpminspect-data-fedora: https://github.com/rpminspect/rpminspect-data-fedora/blob/master/profiles... This will be used by the rpminspect runner for all rawhide builds. It just turns off a lot of inspections that are not useful for active and ongoing development. Some context: what rpminspect does is largely based on what the internal rpmdiff tool did, unraveling that, and then building new inspections in rpminspect. About half of the rpmdiff checks were tied to stuff like this where the assumption is we are comparing builds in a maintenance release of RHEL. That is, we don't want any unexpected surprises in the packages. A file changing that we didn't want to change should raise some sort of alarm. Those checks have been implemented in rpminspect and broken out in to more logical sections, but rpminspect also has the ability to turn off entire inspections you don't want or need to run. For information on what can go in the rpminspect configuration file, see the generic template: https://github.com/rpminspect/rpminspect/blob/master/data/generic.yaml When rpminspect runs for Fedora builds it will first read in /usr/share/rpminspect/fedora.yaml, then if a profile is specified it reads that in and overlays that on the current configuration, and lastly if you have a local 'rpminspect.yaml' file in your dist-git branch then it reads that in last for any final overlays. To see the default Fedora config file: https://github.com/rpminspect/rpminspect-data-fedora/blob/master/fedora.yaml I keep promising a man page for the rpminspect.yaml file and I promise I will do it soon, I just haven't gotten around to it. The generic template fills the need for config file docs for the moment. Please let me know if you have any questions. Thanks, -- David Cantrell <dcantrell(a)redhat.com&gt; Red Hat, Inc. | Boston, MA | EST5EDT