feat(build-debian): Run licenserecon #97
Conversation
|
Tested in:
|
adombeck
changed the title
adombeck
force-pushed
the
licenserecon
branch
10 times, most recently
from
ce316db to
eecab24
Compare
adombeck
force-pushed
the
licenserecon
branch
from
eecab24 to
061bc14
Compare
didrocks
left a comment
didrocks
left a comment
There was a problem hiding this comment.
Looks good to me! I always used licensecheck in the past which had a lot of false positives and negatives.
I am eager to use that tool (even if I have some opinion on the usefulness of debian/copyright itself, but that’s for another day and out of this requirement :))
Thanks!
We're about to merge a PR [1] which runs licenserecon aka lrc by default during the build-deb action to check the debian/copyright file. The motivation is that uploads to the archive can be rejected due to issues reported by lrc. [1] canonical/desktop-engineering#97 In this repo, it complains about a few differences between the debian/copyright file and the output of licensecheck: en: Versions: licenserecon '11.0' licensecheck '3.3.9-1ubuntu2' Parsing Source Tree .... Reading d/copyright .... Running licensecheck .... d/copyright | licensecheck GPL-3+ | CC0-1.0 gnome-shell/src/data/icons/scalable/status/wellbeing-symbolic.svg GPL-3+ | LGPL-2.1 gnome-shell/src/gnome-shell-sass/_common.scss GPL-3+ | CC0-1.0 gnome-shell/upstream/data/icons/scalable/status/wellbeing-symbolic.svg CC-BY-SA-4.0 | GPL-3+ icons/src/cursors/anicursorgen.py CC-BY-SA-4.0 | GPL-2 icons/src/cursors/render-cursors.py LGPL-3.0 | LGPL-3 icons/src/fullcolor/render-bitmaps.py LGPL-3.0 | LGPL-3 icons/src/scalable/extract-symbolic-icons.rb CC-BY-SA-4.0 | GPL-3 icons/src/symlinks/generate-symlinks.sh GPL-3+ | GPL-3 meson.build Since some of those are in the code from upstream gnome-shell, and yaru is already available in the archives, the easiest solution is to skip lrc when building yaru.
We've had an upload of authd to the archive rejected because of issues in the debian/copyright file reported by licenserecon aka lrc. Let's avoid that in the future by running lrc as part of the build-debian action. I had to change the package built in the tests to get them to pass, because lrc reports issues in the hello package. It also found issues in cowsay and some other packages I tried. The first package which passed was debianutils.
adombeck
force-pushed
the
licenserecon
branch
from
061bc14 to
7c0fa59
Compare
|
@adombeck Currently, the workflow is set up so that The user could manually vendor before calling the action, but then that'll reduce the effectiveness of the steps on source packing afterward. For example, if the vendoring script that is run during the building of the source package is broken, then we wouldn't catch it anymore. I'm wondering if we should move the |
|
@hk21702 Funny coincidence that you write that now, I just noticed that on Thursday evening while trying to make lrc run faster in CI (unsuccessfully so far, it takes 25 seconds there but only ~2 seconds on my local system). I pushed b44d1c9 to branch faster-lrc to run lrc on the extracted source package and tested it in canonical/authd#1247. Unfortunately, that results in a lot more issues found by lrc in the authd source, which makes me question how maintainable the approach is. I'll look into it more next week. |
3 participants
We've had an upload of authd to the archive rejected because of issues in the
debian/copyrightfile reported by licenserecon aka lrc. Let's avoid that in the future by running lrc as part of thebuild-debianaction.I had to change the package built in the tests to get them to pass because lrc reports issues in the
hellopackage. It also found issues incowsayand some other packages I tried. The first package which passed wasdebianutils.UDENG-8802