On Thu, Nov 04, 2021 at 06:51:23PM +0100, Florian Weimer wrote:
* Aleksei Bavshin:
On 11/4/21 09:17, Florian Weimer wrote:
Why is this VERIFY? The patch was generated as if by “git show”, and I
do not see anything wrong with it.
rpminspect thinks that the patch is suspiciously large and asks you to
confirm that it is intentional.
There's a test description in the beginning of the log:
Inspects all patches defined in the spec file and reports changes
between builds. At the INFO level, rpminspect reports diffstat(1) and
patch size changes. If thresholds are reached regarding a change in
the patch size or the number of files the patch touches, rpminspect
reports the change at the VERIFY level unless the comparison is for a
rebase. The configuration file can also list patch names that
rpminspect should ignore during the inspection.
Is this a new check? It was flagged as a regression in Jenkins.
I should also point out that rpminspect is configurable with regard to
what it considers a "large" patch. The intent of the inspection is to
provide a guard for packages in maintenance mode. For example, if a
maintainer wants to stay on a particular version even though a newer
release is available and then someone submits a PR that patches the
source and the patch is effectively the new version, something like
this patches inspection could provide the maintainer with a warning
that this is a large patch and that _may_ be something that needs
closer inspection.
It is entirely subjective and some maintainers don't really care for
it. I think in the case of maintenance builds, it can be helpful to
catch large patches that may introduce an unwanted change and provide
another guard for the maintainer to doublecheck the work.
If rpminspect is comparing builds and determines the comparison to be
a rebase (that is, the version numbers are different), it will report
all findings in the patches inspection at the INFO level. But if it
determines the builds compared are the same version but the release
numbers differ (that is, a maintenance update), it will report
findings in the patches inspection at the VERIFY level.
You can control the patches inspection with an rpminspect.yaml file in
your dist-git directory. First, you can exclude specific patches from
the inspection. You can also set the file_count_threshold (default is
20) which is the number of files a single patch modifies and you can
also set the line_count_threshold (default 5000) which is the number
of lines a single patch modifies.
Not all packages are the same, so these settings are configurable on a
per-package basis so the rpminspect results are more useful to package
maintainers. See this section in the upstream project for
documentation on what the patches section in rpminspect.yaml can look
like:
https://github.com/rpminspect/rpminspect/blob/master/data/generic.yaml#L646
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
