package/mcelog: fix legal-info
PATCH 1/1 package/mcelog: fix legal-info
README was renamed to README.md
https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/commit/README.md?id=2fda0091a0628480a08cbf6ebe309fcb83aeae34
Fixes
http://autobuild.buildroot.net/results/02b/02b897a843b995bf5bf3f993f48689870a551dd5/
--- package/mcelog/mcelog.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/mcelog/mcelog.mk +1 -1
@@ -8,7 +8,7 @@ MCELOG_VERSION = v152 MCELOG_SITE = $(BR2_KERNEL_MIRROR)/scm/utils/cpu/mce/mcelog.git MCELOG_SITE_METHOD = git MCELOG_LICENSE = GPL-2.0 -MCELOG_LICENSE_FILES = README +MCELOG_LICENSE_FILES = README.md define MCELOG_BUILD_CMDS $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) all
Signature · 1 line
2.11.0
Thomas Petazzoni
AppliedPATCH 1/1 package/mcelog: fix legal-info
Hello,
Quoted 10 lines · Bernd Kuhls
README was renamed to README.md
https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/commit/README.md?id=2fda0091a0628480a08cbf6ebe309fcb83aeae34Fixes
http://autobuild.buildroot.net/results/02b/02b897a843b995bf5bf3f993f48689870a551dd5/Signed-off-by Bernd Kuhls <[email protected]>--- package/mcelog/mcelog.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to master, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/mcelog: fix legal-info
In reply to Bernd KuhlsQuoted 3 lines · Bernd Kuhls
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 ?
Regards,
Rahul
Quoted 29 lines
Fixes
http://autobuild.buildroot.net/results/02b/02b897a843b995bf5bf3f993f48689870a551dd5/Signed-off-by Bernd Kuhls <[email protected]>--- package/mcelog/mcelog.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)package/mcelog/mcelog.mk +1
-2@@ -8,7 +8,7 @@ MCELOG_VERSION = v152 MCELOG_SITE = $(BR2_KERNEL_MIRROR)/scm/utils/cpu/mce/mcelog.git MCELOG_SITE_METHOD = git MCELOG_LICENSE = GPL-2.0 -MCELOG_LICENSE_FILES = README +MCELOG_LICENSE_FILES = README.md define MCELOG_BUILD_CMDS $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) all --2.11.0
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
PATCH 1/1 package/mcelog: fix legal-info
Hello,
Quoted 7 lines · Rahul Bedarkar
Quoted 2 lines
README was renamed to README.md
https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/commit/README.md?id=2fda0091a0628480a08cbf6ebe309fcb83aeae34make <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.
Quoted 6 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 package/mcelog: fix legal-info
Hello,
Quoted 4 lines · Thomas Petazzoni
Hello,
Yocto/OE also has a hash for license files, specifically to check if the license file is changed.
Yes, my intention to suggest that is to check if license text gets changed. Preventing such build failure is added advantage out of this.
Quoted 4 lines
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.
If we use .hash file, then all hashes will be in one place but yes, it is for downloaded files. We can add hash of license file in .mk file under LICENSE_FILES_HASH variable. In that case, one to one mapping of license file and its hash needs to be maintained if there are multiple license files. If using .hash file for hashes of only downloaded files isn't a hard rule then adding hash of license file .hash file will be more convenient ?
Quoted 2 lines
Also, I'm a bit worried about the additional complexity and maintenance burden.
If this thing helps in maintaining legal info accurate and up-date then additional complexity is OK in my opinion. After all legal info is also important thing and we will be confident about it over a period of time.
Thanks,
Rahul
PATCH 1/1 package/mcelog: fix legal-info
In reply to Thomas PetazzoniQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 5 lines
Quoted 2 lines
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.
Exactly. I think it makes sense to do so. We provide legal info, and besides validating that the license files still exist we don't have any checks in place to ensure we catch license changes.
Quoted 4 lines
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.
I don't see it as a big issue. If we want hashes for license files then they need to be stored somewhere, so storing them together with the download hashes sounds OK to me.
Quoted 2 lines
Also, I'm a bit worried about the additional complexity and maintenance burden.
I don't think it will add any significant maintenance burden. The license files very rarely changes, so normally you don't need to update them (and when you do you want to get notified of it).
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 package/mcelog: fix legal-info
In reply to Rahul BedarkarQuoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Rahul" == Rahul Bedarkar <[email protected]> writes:
Quoted 3 lines · Bernd Kuhls
README was renamed to README.md
https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/commit/README.md?id=2fda0091a0628480a08cbf6ebe309fcb83aeae34make <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.
Quoted 6 lines
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 ?
Yes, this is something I have been thinking about as well (but not found time to implement yet). +1 from here!
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 package/mcelog: fix legal-info
Peter, Rahul, All,
On 2017-06-14 00:06 +0200, Peter Korsgaard spake thusly:
Quoted 15 lines
Quoted 14 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Rahul" == Rahul Bedarkar <[email protected]> writes:
Quoted 3 lines · Bernd Kuhls
README was renamed to README.md
https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/commit/README.md?id=2fda0091a0628480a08cbf6ebe309fcb83aeae34make <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.
Quoted 5 lines
Quoted 2 lines
Potentially, it will also help in keeping license string of packages up-to-date if it gets changed. What do you think ?
Yes, this is something I have been thinking about as well (but not found time to implement yet). +1 from here!
I've sent a propsal for that:
http://lists.busybox.net/pipermail/buildroot/2017-June/194820.html
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'