From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/mcelog: fix legal-info
Date: Mon, 12 Jun 2017 21:04:49 +0200 [thread overview]
Message-ID: <20170612210449.1f5e4bf9@windsurf.lan> (raw)
In-Reply-To: <CA+NV+V=d7D+-zZKO4NYVpGrsY2Uz0pqhrLqYPwGA2rXJZSq11g@mail.gmail.com>
Hello,
On Mon, 12 Jun 2017 22:38:17 +0530, Rahul Bedarkar wrote:
> > README was renamed to README.md
> > https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/commit/README.md?id=2fda0091a0628480a08cbf6ebe309fcb83aeae34
>
> make <pkg>-legal-info should have caught that after version bump as a
> part of testing. But it looks like we don't do that usually. In past,
> we have seen such failures after version bump.
>
> To avoid such failures, we can add hash of license file in <pkg>.hash
> and checking that after source is downloaded. If license file changes,
> it will be noticed while build test after version bump.
>
> Potentially, it will also help in keeping license string of packages
> up-to-date if it gets changed. What do you think ?
Yocto/OE also has a hash for license files, specifically to check if
the license file is changed.
However, I'm not sure if the .hash file is the appropriate location. In
the .hash file, we have the hash of the downloaded files (in the ones
in DL_DIR). Hashes for files inside the tarball is a quite different
thing.
Also, I'm a bit worried about the additional complexity and maintenance
burden.
But it's a discussion definitely worth having.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-06-12 19:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 4:15 [Buildroot] [PATCH 1/1] package/mcelog: fix legal-info Bernd Kuhls
2017-06-12 8:11 ` Thomas Petazzoni
2017-06-12 17:08 ` Rahul Bedarkar
2017-06-12 19:04 ` Thomas Petazzoni [this message]
2017-06-13 16:29 ` Rahul Bedarkar
2017-06-13 22:11 ` Peter Korsgaard
2017-06-13 22:06 ` Peter Korsgaard
2017-06-18 8:02 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170612210449.1f5e4bf9@windsurf.lan \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox