Agree it should be in Fedora CI. Maybe it can be added to the Zuul CI,
or the default scratch build.
But to run Fedora CI, the source would need to be in the look-aside
cache. I think it would be ok that if the packit run is
pull_from_upstream that a licensecheck is run (after the spectool -g and
before running the fedpkg new-sources) and report upstream if it fails.
Then the packager can check it and re-run via the cli command to "sign"
that they have verified it.
I don't think it is very necessary in the propose_downstream since the
project hosting it and the packager maintaining it there should be
responsible there. But if the check is not hard, might as well add it
for sanity.
I have tried to run locally licensecheck -r, but I think the output is a
bit too noisy for processing with so many "UNKNOWN". The
--merge-licenses doesn't seem to help either. But it should still be
doable to accumulate all detected licenses and continue if that is not
different. An edge-case issue would be if upstream changes a specific
section of the code to a specific license unknown to licensecheck, but I
don't think the regular maintainer is diligent enough to do that
rigorous check either.
On 2023/09/15 16:18, Frantisek Lachman wrote:
I quite like these checks but wouldn't it be better to have these as
part of Fedora CI? (Or any other CI system running on dist-git PRs?)
František
On Fri, Sep 15, 2023 at 4:13 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
If you wanted to be especially helpful, perhaps Packit could compare
the old and new tarballs, and present the maintainer a list of newly
added files as a BZ attachment. It could also run 'licensecheck -r'
on old and new tarballs and report any notable changes. Still needs
human review, but that might help nudge the maintainer to actually
do the license review, as I bet it is often skipped on rebases.
With regards,
Daniel
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
