On Tue, Mar 02, 2021 at 08:26:31AM -0800, Adam Williamson wrote:
On Tue, 2021-03-02 at 13:59 +0000, Richard W.M. Jones wrote:
Other tests are kind of random. I mean, what does this mean?
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/12861/testReport/(root)/tests/
Stuff like:
1) File /usr/lib64/ocaml/cmdliner/cmdliner.a changed content on x86_64.
Amazing! The package was rebuilt, what did you expect?
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.
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/fedora/rawhide.yaml
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@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
