[PATCH v2] bzip2: Add test suite for bzip2

[PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

Source: git://sourceware.org/git/bzip2-tests.git
Type: Enhancement
Description:
bzip2 now has a test suite available at git://sourceware.org/git/bzip2-tests.git.

This is a collection of "interesting" .bz2 files that can be used to
test bzip2 works correctly. They come from different projects.

Some files are deliberately bad, and are use to see how bzip2 handles
corrupt files. They are explicitly not intended to decompress correctly,
but to catch errors in bzip2 trying to deal with deliberately bad data.
All such files have a name ending in .bz2.bad.

All non-bad files end in bz2. And should come with a .md5 file for
the original input file. The .md5 file is used to check that bzip2
could correctly decompress the file. The original (non-compressed)
files are deliberately not checked in.

It will by default test with the command 'bzip2', running under
valgrind (if installed on the system).

For each .bz2 file found it is decompressed, recompressed and
decompressed again. Once with the default bzip2 settings and
once in --small (-s) mode.

For each .bz2.bad file decompression is tried twice also. In
default mode and small mode. The bzip2 binary is expected to
return either 1 or 2 as exit status. Any other exit code is
interpreted as failure.

License:
   In bzip2-tests source code Each directory should contain a README
   file explaining where the .bz2 files originally came from.
   Plus a reference to the (Free Software) license that the project
   files were distributed under.

   Adding GPLv3+ License to the bzip2 recipe. Since we modify the
   bzip2-tests.git/run-tests.sh script and we can redistribute it and/or
   modify it under the terms of the GNU General Public License (GPL);
   either version 3, or (at your option) any later version.

   since all other files and directories are unchanged and We are simply
   using the compressed files as data so we are ignoring the license info for
   these files and directories in bzip2-tests.git

Test Summery:
   On qemux86-64/kvm the ptest results with extra filesystem space (atleast 114688) are:

TOTAL: 	396
PASS: 	396
SKIP: 	0
XFAIL: 	0
FAIL: 	0
XPASS: 	0
ERROR: 	0

All tests passed
DURATION: 517

[YOCTO #13444]

Signed-off-by: Rahul Kumar <rahulk@mvista.com>
---
 .../bzip2/0001-bzip2-modify-run-tests-script.patch | 188 +++++++++++++++++++++
 meta/recipes-extended/bzip2/bzip2/Makefile.am      |   2 +
 meta/recipes-extended/bzip2/bzip2_1.0.8.bb         |   9 +-
 3 files changed, 197 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-run-tests-script.patch

diff --git a/meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-run-tests-script.patch b/meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-run-tests-script.patch
new file mode 100644
index 0000000..900a9aa
--- /dev/null
+++ b/meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-run-tests-script.patch
@@ -0,0 +1,188 @@
+From 8e704bc7bf25f892968eac8bcb40a205248ff5b2 Mon Sep 17 00:00:00 2001
+From: Rahul Kumar <rahulk@mvista.com>
+Date: Mon, 30 Mar 2020 12:17:00 +0530
+Subject: [PATCH] bzip2: modify run-tests script
+
+1) modify run-tests script to write PASS/FAIL as expected by the ptest infrastructure
+
+2) Since the discrete md5sum does not have a short form of --status.And minimal base
+   images does not support commands with long form arguments so dropping this
+   argument
+
+Upstream-Status: Submitted [bzip2-devel@sourceware.org]
+- Submitted to bzip2 mailing list and waiting approval
+
+Signed-off-by: Rahul Kumar <rahulk@mvista.com>
+---
+ run-tests.sh | 62 ++++++++++++++++++++++++++++++++----------------------------
+ 1 file changed, 33 insertions(+), 29 deletions(-)
+
+diff --git a/run-tests.sh b/run-tests.sh
+index 1ba8c27..771584d 100755
+--- a/run-tests.sh
++++ b/run-tests.sh
+@@ -40,21 +40,21 @@ case $i in
+ esac
+ done
+
+-if ! type "valgrind" > /dev/null; then
++if ! type "valgrind" > /dev/null 2>&1; then
+   VALGRIND=""
+   VALGRIND_ARGS=""
+ fi
+
+ echo "Testing ${BZIP2} in directory ${TESTS_DIR}"
+ if [ "$VALGRIND" != "" ]; then
+-  echo "  using valgrind"
++  echo "Using valgrind: Yes"
+ else
+-  echo "  NOT using valgrind"
++  echo "Using valgrind: No"
+ fi
+ if [[ ${IGNORE_MD5} -eq 0 ]]; then
+-  echo "  checking md5 sums"
++  echo "Checking md5 sums: Yes"
+ else
+-  echo "  NOT checking md5 sums"
++  echo "Checking md5 sums: No"
+ fi
+
+ # Remove any left over tesfilecopies from previous runs first.
+@@ -78,14 +78,14 @@ while IFS= read -r -d '' bzfile; do
+   # Decompress it.
+   echo "  Decompress..."
+   rm -f "${file}"
+-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q ${bzfile} \
+-    || { echo "!!! bad decompress result $?";
++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q ${bzfile} && { echo "PASS: ${bzfile} Decompress"; } \
++    || { echo "FAIL: ${bzfile} Decompress";
+          badtests=("${badtests[@]}" $"${bzfile} bad decompress result")
+          nogood=$[${nogood}+1]; continue; }
+
+   if [[ ${IGNORE_MD5} -ne 1 ]]; then
+-    md5sum --check --status ${md5file} < ${file} \
+-      || { echo "!!! md5sum doesn't match decompressed file";
++    md5sum -c ${md5file} < ${file} && { echo "PASS: ${bzfile} md5sum Matched"; } \
++      || { echo "FAIL: ${bzfile} md5sum Matched";
+            badtests=("${badtests[@]}" $"${file} md5sum doesn't match")
+            nogood=$[${nogood}+1]; continue; }
+   fi
+@@ -94,19 +94,19 @@ while IFS= read -r -d '' bzfile; do
+   mv "${file}" "${copy}"
+   rm -f "${bzcopy}"
+   echo "  Recompress..."
+-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} \
+-    || { echo "!!! bad compress result $?";
++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} && { echo "PASS: ${bzfile} Recompress "; } \
++    || { echo "FAIL: ${bzfile} Recompress";
+          badtests=("${badtests[@]}" $"${copy} bad result")
+          nogood=$[${nogood}+1]; continue; }
+   echo "  Redecompress..."
+-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} \
+-    || { echo "!!! bad (re)decompress result $?";
++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} && { echo "PASS: ${bzfile} Redecompress"; } \
++    || { echo "FAIL: ${bzfile} Redecompress";
+          badtests=("${badtests[@]}" $"${bzcopy} bad result")
+          nogood=$[${nogood}+1]; continue; }
+
+   if [[ ${IGNORE_MD5} -ne 1 ]]; then
+-    md5sum --check --status ${md5file} < ${copy} \
+-      || { echo "!!! md5sum doesn't match (re)decompressed file";
++    md5sum -c ${md5file} < ${copy} && { echo "PASS: ${bzfile} md5sum Matched"; } \
++      || { echo "FAIL: ${bzfile} md5sum Matched";
+            badtests=("${badtests[@]}" $"${copy} md5sum doesn't match")
+            nogood=$[${nogood}+1]; continue; }
+   fi
+@@ -116,14 +116,14 @@ while IFS= read -r -d '' bzfile; do
+   # Now do it all again in "small" mode.
+   echo "  Decompress (small)..."
+   rm -f "${file}"
+-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q -s ${bzfile} \
+-    || { echo "!!! bad decompress result $?";
++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q -s ${bzfile} &&{ echo "PASS: ${bzfile} Decompress (small)"; } \
++    || { echo "FAIL: ${bzfile} Decompress (small)";
+          badtests=("${badtests[@]}" $"${bzfile} bad decompress result")
+          nogood=$[${nogood}+1]; continue; }
+
+   if [[ ${IGNORE_MD5} -ne 1 ]]; then
+-    md5sum --check --status ${md5file} < ${file} \
+-      || { echo "!!! md5sum doesn't match decompressed file";
++    md5sum -c ${md5file} < ${file} && { echo "PASS: ${bzfile} Md5sum Matched"; } \
++      || { echo "FAIL: ${bzfile} Md5sum Matched";
+            badtests=("${badtests[@]}" $"${file} md5sum doesn't match")
+            nogood=$[${nogood}+1]; continue; }
+   fi
+@@ -132,19 +132,19 @@ while IFS= read -r -d '' bzfile; do
+   mv "${file}" "${copy}"
+   rm -f "${bzcopy}"
+   echo "  Recompress (small)..."
+-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} \
+-    || { echo "!!! bad compress result $?";
++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} && { echo "PASS: ${bzfile} Recompress (small)"; } \
++    || { echo "FAIL: ${bzfile} Recompress (small)";
+          badtests=("${badtests[@]}" $"${copy} bad result")
+          nogood=$[${nogood}+1]; continue; }
+   echo "  Redecompress (small)..."
+-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} \
+-    || { echo "!!! bad (re)decompress result $?";
++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} && { echo "PASS: ${bzfile} Redecompress (small)"; } \
++    || { echo "FAIL: ${bzfile} Redecompress (small)";
+          badtests=("${badtests[@]}" $"${bzcopy} bad result")
+          nogood=$[${nogood}+1]; continue; }
+
+   if [[ ${IGNORE_MD5} -ne 1 ]]; then
+-    md5sum --check --status ${md5file} < ${copy} \
+-      || { echo "!!! md5sum doesn't match (re)decompressed file";
++    md5sum -c ${md5file} < ${copy} && { echo "PASS: ${bzfile} md5sum Matched"; } \
++      || { echo "FAIL: ${bzfile} md5sum : Miss Matched";
+            badtests=("${badtests[@]}" $"${copy} md5sum doesn't match")
+            nogood=$[${nogood}+1]; continue; }
+   fi
+@@ -176,7 +176,7 @@ while IFS= read -r -d '' badfile; do
+   ret=$?
+
+   if [[ ${ret} -eq 0 ]]; then
+-    echo "!!! badness not detected"
++    echo "FAIL: badness not detected"
+     nobad=$[${nobad}+1]
+     badtests=("${badtests[@]}" $"${badfile} badness not detected")
+     continue
+@@ -185,10 +185,12 @@ while IFS= read -r -d '' badfile; do
+   # Assumes "normal" badness is detected by exit code 1 or 2.
+   # A crash or valgrind issue will be reported with something else.
+   if [[ ${ret} != 1 ]] && [[ ${ret} != 2 ]]; then
+-    echo "!!! baddness caused baddness in ${BZIP2}"
++    echo "FAIL: baddness caused baddness in ${BZIP2}"
+     badbad=$[${badbad}+1]
+     badtests=("${badtests[@]}" $"${badfile} badness caused baddness")
+     continue
++  else
++    echo "PASS: Correctly found data integrity errors in ${badfile} during decompress."
+   fi
+
+   echo "  Trying to decompress (small)..."
+@@ -196,7 +198,7 @@ while IFS= read -r -d '' badfile; do
+   ret=$?
+
+   if [[ ${ret} -eq 0 ]]; then
+-    echo "!!! badness not detected"
++    echo "FAIL: badness not detected "
+     nobad=$[${nobad}+1]
+     badtests=("${badtests[@]}" $"${badfile} badness not detected")
+     continue
+@@ -205,10 +207,12 @@ while IFS= read -r -d '' badfile; do
+   # Assumes "normal" badness is detected by exit code 1 or 2.
+   # A crash or valgrind issue will be reported with something else.
+   if [[ ${ret} != 1 ]] && [[ ${ret} != 2 ]]; then
+-    echo "!!! baddness caused baddness in ${BZIP2}"
++    echo "FAIL: baddness caused baddness in ${BZIP2}"
+     badbad=$[${badbad}+1]
+     badtests=("${badtests[@]}" $"${badfile} badness caused baddness")
+     continue
++  else
++    echo "PASS: Correctly found data integrity errors in ${badfile} during decompress (small)"
+   fi
+
+ done < <(find ${TESTS_DIR} -type f -name \*\.bz2.bad -print0)
+--
+2.7.4
diff --git a/meta/recipes-extended/bzip2/bzip2/Makefile.am b/meta/recipes-extended/bzip2/bzip2/Makefile.am
index dcf6458..aab6558 100644
--- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
+++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
@@ -46,6 +46,7 @@ runtest:
 	else echo "FAIL: sample2 decompress"; fi
 	@if cmp sample3.tst sample3.ref; then echo "PASS: sample3 decompress";\
 	else echo "FAIL: sample3 decompress"; fi
+	./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
 
 install-ptest:
 	sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
@@ -56,6 +57,7 @@ install-ptest:
 	cp $(srcdir)/sample1.bz2	$(DESTDIR)/
 	cp $(srcdir)/sample2.bz2	$(DESTDIR)/
 	cp $(srcdir)/sample3.bz2	$(DESTDIR)/
+	cp -rf $(srcdir)/../git		$(DESTDIR)/bzip2-tests
 	ln -s $(bindir)/bzip2		$(DESTDIR)/bzip2
 
 install-exec-hook:
diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
index 8e9b779..983fabd 100644
--- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
+++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
@@ -4,17 +4,22 @@ Huffman coding. Compression is generally considerably better than that achieved
 LZ77/LZ78-based compressors, and approaches the performance of the PPM family of statistical compressors."
 HOMEPAGE = "https://sourceware.org/bzip2/"
 SECTION = "console/utils"
-LICENSE = "bzip2"
+LICENSE = "bzip2 & GPLv3+"
 LIC_FILES_CHKSUM = "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"
 
 SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \
+           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests \
            file://configure.ac;subdir=${BP} \
            file://Makefile.am;subdir=${BP} \
            file://run-ptest \
+           file://0001-bzip2-modify-run-tests-script.patch;patchdir=${WORKDIR}/git \
            "
+
 SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
 SRC_URI[sha256sum] = "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
 
+SRCREV_bzip2-tests = "8b0198efda1603cf81fa2c7a9bb673dd22ae1661"
+
 UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
 
 PACKAGES =+ "libbz2"
@@ -39,7 +44,7 @@ do_install_ptest () {
 
 FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
 
-RDEPENDS_${PN}-ptest += "make"
+RDEPENDS_${PN}-ptest += "make bash"
 
 PROVIDES_append_class-native = " bzip2-replacement-native"
 BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Richard Purdie]

On Fri, 2020-04-24 at 00:09 +0530, Rahul Kumar wrote:
> Source: git://sourceware.org/git/bzip2-tests.git
> Type: Enhancement
> Description:
> bzip2 now has a test suite available at
> git://sourceware.org/git/bzip2-tests.git.
> 
> This is a collection of "interesting" .bz2 files that can be used to
> test bzip2 works correctly. They come from different projects.
> 
> Some files are deliberately bad, and are use to see how bzip2 handles
> corrupt files. They are explicitly not intended to decompress
> correctly,
> but to catch errors in bzip2 trying to deal with deliberately bad
> data.
> All such files have a name ending in .bz2.bad.
> 
> All non-bad files end in bz2. And should come with a .md5 file for
> the original input file. The .md5 file is used to check that bzip2
> could correctly decompress the file. The original (non-compressed)
> files are deliberately not checked in.
> 
> It will by default test with the command 'bzip2', running under
> valgrind (if installed on the system).
> 
> For each .bz2 file found it is decompressed, recompressed and
> decompressed again. Once with the default bzip2 settings and
> once in --small (-s) mode.
> 
> For each .bz2.bad file decompression is tried twice also. In
> default mode and small mode. The bzip2 binary is expected to
> return either 1 or 2 as exit status. Any other exit code is
> interpreted as failure.

I did try running this on the autobuilder. There are a few issues.

https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue: /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample contained in package bzip2-ptest requires /usr/bin/perl, but no providers found in RDEPENDS_bzip2-ptest? [file-rdeps]
step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

also, the new license (GPLv3) causes problems:

https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814

Cheers,

Richard

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]

Hi Richard,

With this patch I am able to build core-image-minimal without any
Error/Warning in my system.
Can you please suggest to me, how can i reproduce this issue in my system
during build?

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Mon, Apr 27, 2020 at 8:39 PM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Fri, 2020-04-24 at 00:09 +0530, Rahul Kumar wrote:
> > Source: git://sourceware.org/git/bzip2-tests.git
> > Type: Enhancement
> > Description:
> > bzip2 now has a test suite available at
> > git://sourceware.org/git/bzip2-tests.git.
> >
> > This is a collection of "interesting" .bz2 files that can be used to
> > test bzip2 works correctly. They come from different projects.
> >
> > Some files are deliberately bad, and are use to see how bzip2 handles
> > corrupt files. They are explicitly not intended to decompress
> > correctly,
> > but to catch errors in bzip2 trying to deal with deliberately bad
> > data.
> > All such files have a name ending in .bz2.bad.
> >
> > All non-bad files end in bz2. And should come with a .md5 file for
> > the original input file. The .md5 file is used to check that bzip2
> > could correctly decompress the file. The original (non-compressed)
> > files are deliberately not checked in.
> >
> > It will by default test with the command 'bzip2', running under
> > valgrind (if installed on the system).
> >
> > For each .bz2 file found it is decompressed, recompressed and
> > decompressed again. Once with the default bzip2 settings and
> > once in --small (-s) mode.
> >
> > For each .bz2.bad file decompression is tried twice also. In
> > default mode and small mode. The bzip2 binary is expected to
> > return either 1 or 2 as exit status. Any other exit code is
> > interpreted as failure.
>
> I did try running this on the autobuilder. There are a few issues.
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
> step1b
> <https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816step1b>:
> ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
> /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample
> contained in package bzip2-ptest requires /usr/bin/perl, but no providers
> found in RDEPENDS_bzip2-ptest? [file-rdeps]
> step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal errors.
> Please consider fixing them.
>
> also, the new license (GPLv3) causes problems:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
>
> Cheers,
>
> Richard
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4727 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]

You need to look at configurations defined here:
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
and replicate them locally. Then you can reproduce the failures that the AB
gets in those configurations.

Alex

On Mon, 27 Apr 2020 at 18:25, Rahul Kumar <rahulk@mvista.com> wrote:

> Hi Richard,
>
> With this patch I am able to build core-image-minimal without any
> Error/Warning in my system.
> Can you please suggest to me, how can i reproduce this issue in my system
> during build?
>
> *Thanks & Regards,*
> Rahul Kumar
> Software Engineer,Linux Solutions Engineering
> Group,Montavista Software LLC
> Email Id: rahulk@mvista.com
> <https://plus.google.com/+CodeTwoSoftware>
>
>
> On Mon, Apr 27, 2020 at 8:39 PM Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
>> On Fri, 2020-04-24 at 00:09 +0530, Rahul Kumar wrote:
>> > Source: git://sourceware.org/git/bzip2-tests.git
>> > Type: Enhancement
>> > Description:
>> > bzip2 now has a test suite available at
>> > git://sourceware.org/git/bzip2-tests.git.
>> >
>> > This is a collection of "interesting" .bz2 files that can be used to
>> > test bzip2 works correctly. They come from different projects.
>> >
>> > Some files are deliberately bad, and are use to see how bzip2 handles
>> > corrupt files. They are explicitly not intended to decompress
>> > correctly,
>> > but to catch errors in bzip2 trying to deal with deliberately bad
>> > data.
>> > All such files have a name ending in .bz2.bad.
>> >
>> > All non-bad files end in bz2. And should come with a .md5 file for
>> > the original input file. The .md5 file is used to check that bzip2
>> > could correctly decompress the file. The original (non-compressed)
>> > files are deliberately not checked in.
>> >
>> > It will by default test with the command 'bzip2', running under
>> > valgrind (if installed on the system).
>> >
>> > For each .bz2 file found it is decompressed, recompressed and
>> > decompressed again. Once with the default bzip2 settings and
>> > once in --small (-s) mode.
>> >
>> > For each .bz2.bad file decompression is tried twice also. In
>> > default mode and small mode. The bzip2 binary is expected to
>> > return either 1 or 2 as exit status. Any other exit code is
>> > interpreted as failure.
>>
>> I did try running this on the autobuilder. There are a few issues.
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
>> step1b
>> <https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816step1b>:
>> ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
>> /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample
>> contained in package bzip2-ptest requires /usr/bin/perl, but no providers
>> found in RDEPENDS_bzip2-ptest? [file-rdeps]
>> step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal errors.
>> Please consider fixing them.
>>
>> also, the new license (GPLv3) causes problems:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> 
>

[-- Attachment #2: Type: text/html, Size: 5455 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Richard Purdie]

On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
> You need to look at configurations defined here:
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> and replicate them locally. Then you can reproduce the failures that
> the AB gets in those configurations.

That start of the failing logs on the autobuilder also list out the
configuration options for that build.

Cheers,

Richard

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

Hi Richard/Alexander,

I am not able to understand how I can use the below file.
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json

did you mean to say that i have to set MACRO in local.conf based on this
file.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
> > You need to look at configurations defined here:
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> > and replicate them locally. Then you can reproduce the failures that
> > the AB gets in those configurations.
>
> That start of the failing logs on the autobuilder also list out the
> configuration options for that build.
>
> Cheers,
>
> Richard
>
>

[-- Attachment #2: Type: text/html, Size: 2827 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

You need to first see from the failure page which configuration is failing,
for example non-gpl3 is one such.

Then you find that configuration in config.json. The below should hopefully
be self-explanatory in how you should set up the build?

        "non-gpl3" : {
            "NEEDREPOS" : ["poky", "meta-gplv2"],
            "MACHINE" : "qemux86",
            "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
            "extravars" : [
                "INCOMPATIBLE_LICENSE = '*GPLv3'",
                "WARN_QA_remove = 'incompatible-license'"
            ],
            "EXTRACMDS" : [
                "../../yocto-autobuilder-helper/scripts/check-gplv3"
            ]
        },


Alex


On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com> wrote:

> Hi Richard/Alexander,
>
> I am not able to understand how I can use the below file.
>
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>
> did you mean to say that i have to set MACRO in local.conf based on this
> file.
>
> *Thanks & Regards,*
> Rahul Kumar
> Software Engineer,Linux Solutions Engineering
> Group,Montavista Software LLC
> Email Id: rahulk@mvista.com
> <https://plus.google.com/+CodeTwoSoftware>
>
>
> On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
>> On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
>> > You need to look at configurations defined here:
>> >
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>> > and replicate them locally. Then you can reproduce the failures that
>> > the AB gets in those configurations.
>>
>> That start of the failing logs on the autobuilder also list out the
>> configuration options for that build.
>>
>> Cheers,
>>
>> Richard
>>
>>

[-- Attachment #2: Type: text/html, Size: 4224 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Randy MacLeod]

On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> You need to first see from the failure page which configuration is 
> failing, for example non-gpl3 is one such.
> 
> Then you find that configuration in config.json. The below should 
> hopefully be self-explanatory in how you should set up the build?
> 
> |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" : 
> "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline", 
> "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove = 
> 'incompatible-license'" ], "EXTRACMDS" : [ 
> "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> 
> |
> 
> |
> |
> 
> |Alex

Hi Rahul,

Sorry for my late reply.

The commit log for v2 is very good now!
Thanks for incorporating my --pedantic suggestions. ;-)

It seems that you need a perl dependency for something (docs?
    $ cd .../bzip2.git
    $ grep -r "perl " *
    format.pl:#!/usr/bin/perl -w
    README.XML.STUFF:It uses format.pl, a perl script...

Then we need to figure out how to deal with the GPLv3 issue.

The buildbot output can be tedious to figure out. I haven't really
spent enough time plugging away at it to be proficient yet either.
Have you been able to reproduce the problems that Richard reported?
If not, and you've tried for a bit, then just say so and I'll try to
help tomorrow or early next week.

It looks like you are packaging the test code/data with the main package 
not in bzip2-ptest. Have a look at:
    meta/recipes-support/libpcre/libpcre_8.44.bb
for an example. There are many more.
Also, if you look at oe-core.git:
    $ rgrep LICENSE_ *  | grep PN
you can see many examples of sub-packages with different licenses
than the main package. One example is:
    meta/recipes-support/gnutls/gnutls_3.6.13.bb
I hope that can address the buildbot problem but I haven't tried it
myself yet.

BTW, Trevor has gotten the YP autobuilder going at Wind River and
he'll be sending a few documentation updates next week or so.
That may help in case you want to reproduce the YP AB test
infrastructure. I expect that you don't _have_ to do so but
I think it would be good if more contributing organizations did
have an instance with only limited builders of the YP AB so that
we can do more testing before Richard runs our changes through
the main system. Richard has cautioned that the YP AB has lots of
builders each of which has many cores but I hope that we can at least
do some AB checking ourselves.

../Randy


> |
> 
> 
> On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com 
> <mailto:rahulk@mvista.com>> wrote:
> 
>     Hi Richard/Alexander,
> 
>     I am not able to understand how I can use the below file.
>     http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> 
>     did you mean to say that i have to set MACRO in local.conf based on
>     this file.
> 
>     *Thanks & Regards,*
>     Rahul Kumar
>     Software Engineer,Linux Solutions Engineering
>     Group,Montavista Software LLC
>     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>     <https://plus.google.com/+CodeTwoSoftware>
> 
> 
>     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>     <richard.purdie@linuxfoundation.org
>     <mailto:richard.purdie@linuxfoundation.org>> wrote:
> 
>         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
>          > You need to look at configurations defined here:
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          > and replicate them locally. Then you can reproduce the
>         failures that
>          > the AB gets in those configurations.
> 
>         That start of the failing logs on the autobuilder also list out the
>         configuration options for that build.
> 
>         Cheers,
> 
>         Richard
> 
> 
> 
> 


-- 
# Randy MacLeod
# Wind River Linux

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 9431 bytes --]

Hi Randy,

As per your suggestion I did some progress.

Issue 1:
========

Configuration for this issue:
=============================
  MACHINE = "edgerouter"
  DISTRO = "poky"
  SDKMACHINE = "i686"
  PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
  INHERIT += 'image-buildinfo'
  IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
  QEMU_USE_KVM = 'True'
  INHERIT += 'report-error'
  PREMIRRORS = ''
  BB_GENERATE_MIRROR_TARBALLS = '1'
  BB_NUMBER_THREADS = '16'
  PARALLEL_MAKE = '-j 16'
  BB_TASK_NICE_LEVEL = '5'
  BB_TASK_NICE_LEVEL_task-testimage = '0'
  BB_TASK_IONICE_LEVEL = '2.7'
  BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
  INHERIT += 'testimage'
  TEST_QEMUBOOT_TIMEOUT = '1500'
  SANITY_TESTED_DISTROS = ''
  SDK_EXT_TYPE = 'minimal'
  SDK_INCLUDE_TOOLCHAIN = '1'
Command:
========
bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
core-image-minimal core-image-minimal-dev core-image-sato-ptest
core-image-sato:do_populate_sdk -k

but could not reproduce the issue.

work-around to reproduce this issue.
====================================
I am observing since bzip2-tests is a git repo and
fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is perl
script.
that's why I got this error.
 so manually I copied fsmonitor-watchman.sample file into the
bzip2-tests/.git/hooks and able to reproduce the issue.
Error:
https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
/usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample
contained in package bzip2-ptest requires /usr/bin/perl, but no providers
found in RDEPENDS_bzip2-ptest? [file-rdeps]
step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal errors.
Please consider fixing them.

I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
RDEPENDS_${PN}-ptest += "make bash perl"

so this issue got resolved.

Issue2:
=======
Configuration for this issue
============================
  MACHINE = "qemux86"
  DISTRO = "poky"
  SDKMACHINE = "i686"
  PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
  INCOMPATIBLE_LICENSE = '*GPLv3'
  WARN_QA_remove = 'incompatible-license'
  QEMU_USE_KVM = 'True'
  INHERIT += 'report-error'
  PREMIRRORS = ''
  BB_GENERATE_MIRROR_TARBALLS = '1'
  BB_NUMBER_THREADS = '16'
  PARALLEL_MAKE = '-j 16'
  BB_TASK_NICE_LEVEL = '5'
  BB_TASK_NICE_LEVEL_task-testimage = '0'
  BB_TASK_IONICE_LEVEL = '2.7'
  BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
  INHERIT += 'testimage'
  TEST_QEMUBOOT_TIMEOUT = '1500'
  SANITY_TESTED_DISTROS = ''
  SDK_EXT_TYPE = 'minimal'
  SDK_INCLUDE_TOOLCHAIN = '1'
Command
=======
bitbake core-image-minimal core-image-full-cmdline -k


INCOMPATIBLE_LICENSE = '*GPLv3'
WARN_QA_remove = 'incompatible-license'
My doubt is since above configuration is using during build and we are
using GPLv3+ license then definetly it will report error.

It looks like you are packaging the test code/data with the main package
not in bzip2-ptest. Have a look at:
    meta/recipes-support/libpcre/libpcre_8.44.bb
for an example. There are many more.
Also, if you look at oe-core.git:
    $ rgrep LICENSE_ *  | grep PN
you can see many examples of sub-packages with different licenses
than the main package. One example is:
    meta/recipes-support/gnutls/gnutls_3.6.13.bb
I hope that can address the buildbot problem but I haven't tried it
myself yet.

Explanation:
I checked, Here is packaging the test code/data in bzip2-ptest.
/opt/opensource/build/tmp/work/mips64-poky-linux/bzip2/1.0.8-r0/packages-split/bzip2-ptest

I tried with the changes below  in the bzip2_1.0.8.bb file.
LICENSE = "bzip2"
LICENSE_${PN}-ptest = "GPLv3+"

WARNING: LICENSE_bzip2-ptest includes licenses (GPLv3+) that are not listed
in LICENSE
To resolve this warning i did below changes.
LICENSE = "bzip2 & GPLv3+"
LICENSE_${PN}-ptest = "GPLv3+"

But I am getting below error in both case

ERROR: Nothing RPROVIDES 'bzip2' (but
/opt/opensource/poky/meta/recipes-extended/packagegroups/
packagegroup-core-full-cmdline.bb,
/opt/opensource/poky/meta/recipes-devtools/python/python3_3.8.2.bb RDEPENDS
on or otherwise requires it)
bzip2 was skipped: it has incompatible license(s): GPL-3.0+
NOTE: Runtime target 'bzip2' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['bzip2']

So as per my understanding, if we are splitting the package and assigning
Licence to it.
example:
LICENSE = "bzip2"
LICENSE_${PN}-ptest = "GPLv3+"

In this case I have to set LICENSE_PATH where your license file is located.
or if I am using standard license, I have to set LICENSE first then we can
set LICENSE_${PN}-ptest.

Example:
LICENSE = "bzip2 & GPLv3+"
LICENSE_${PN}-ptest = "GPLv3+"

Kindly comment on it and feel free to point out if i am wrong at any point.


*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com>
wrote:

> On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> > You need to first see from the failure page which configuration is
> > failing, for example non-gpl3 is one such.
> >
> > Then you find that configuration in config.json. The below should
> > hopefully be self-explanatory in how you should set up the build?
> >
> > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
> > "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
> > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
> > 'incompatible-license'" ], "EXTRACMDS" : [
> > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >
> > |
> >
> > |
> > |
> >
> > |Alex
>
> Hi Rahul,
>
> Sorry for my late reply.
>
> The commit log for v2 is very good now!
> Thanks for incorporating my --pedantic suggestions. ;-)
>
> It seems that you need a perl dependency for something (docs?
>     $ cd .../bzip2.git
>     $ grep -r "perl " *
>     format.pl:#!/usr/bin/perl -w
>     README.XML.STUFF:It uses format.pl, a perl script...
>
> Then we need to figure out how to deal with the GPLv3 issue.
>
> The buildbot output can be tedious to figure out. I haven't really
> spent enough time plugging away at it to be proficient yet either.
> Have you been able to reproduce the problems that Richard reported?
> If not, and you've tried for a bit, then just say so and I'll try to
> help tomorrow or early next week.
>
> It looks like you are packaging the test code/data with the main package
> not in bzip2-ptest. Have a look at:
>     meta/recipes-support/libpcre/libpcre_8.44.bb
> for an example. There are many more.
> Also, if you look at oe-core.git:
>     $ rgrep LICENSE_ *  | grep PN
> you can see many examples of sub-packages with different licenses
> than the main package. One example is:
>     meta/recipes-support/gnutls/gnutls_3.6.13.bb
> I hope that can address the buildbot problem but I haven't tried it
> myself yet.
>
> BTW, Trevor has gotten the YP autobuilder going at Wind River and
> he'll be sending a few documentation updates next week or so.
> That may help in case you want to reproduce the YP AB test
> infrastructure. I expect that you don't _have_ to do so but
> I think it would be good if more contributing organizations did
> have an instance with only limited builders of the YP AB so that
> we can do more testing before Richard runs our changes through
> the main system. Richard has cautioned that the YP AB has lots of
> builders each of which has many cores but I hope that we can at least
> do some AB checking ourselves.
>
> ../Randy
>
>
> > |
> >
> >
> > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> > <mailto:rahulk@mvista.com>> wrote:
> >
> >     Hi Richard/Alexander,
> >
> >     I am not able to understand how I can use the below file.
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >
> >     did you mean to say that i have to set MACRO in local.conf based on
> >     this file.
> >
> >     *Thanks & Regards,*
> >     Rahul Kumar
> >     Software Engineer,Linux Solutions Engineering
> >     Group,Montavista Software LLC
> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >     <https://plus.google.com/+CodeTwoSoftware>
> >
> >
> >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >     <richard.purdie@linuxfoundation.org
> >     <mailto:richard.purdie@linuxfoundation.org>> wrote:
> >
> >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
> >          > You need to look at configurations defined here:
> >          >
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >          > and replicate them locally. Then you can reproduce the
> >         failures that
> >          > the AB gets in those configurations.
> >
> >         That start of the failing logs on the autobuilder also list out
> the
> >         configuration options for that build.
> >
> >         Cheers,
> >
> >         Richard
> >
> >
> > 
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>

[-- Attachment #2: Type: text/html, Size: 14014 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 10466 bytes --]

Hi,

Can any one please help me to figure out how to deal with the GPLv3+ issue.

you can see my Patch at below link
https://patchwork.openembedded.org/patch/172134/

*Issue:*
the new license (GPLv3) causes problems:
https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814

Thanks & Regards,
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org
<rahulk=mvista.com@lists.openembedded.org> wrote:

> Hi Randy,
>
> As per your suggestion I did some progress.
>
> Issue 1:
> ========
>
> Configuration for this issue:
> =============================
>   MACHINE = "edgerouter"
>   DISTRO = "poky"
>   SDKMACHINE = "i686"
>   PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>   INHERIT += 'image-buildinfo'
>   IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
>   QEMU_USE_KVM = 'True'
>   INHERIT += 'report-error'
>   PREMIRRORS = ''
>   BB_GENERATE_MIRROR_TARBALLS = '1'
>   BB_NUMBER_THREADS = '16'
>   PARALLEL_MAKE = '-j 16'
>   BB_TASK_NICE_LEVEL = '5'
>   BB_TASK_NICE_LEVEL_task-testimage = '0'
>   BB_TASK_IONICE_LEVEL = '2.7'
>   BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
>   INHERIT += 'testimage'
>   TEST_QEMUBOOT_TIMEOUT = '1500'
>   SANITY_TESTED_DISTROS = ''
>   SDK_EXT_TYPE = 'minimal'
>   SDK_INCLUDE_TOOLCHAIN = '1'
> Command:
> ========
> bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
> core-image-minimal core-image-minimal-dev core-image-sato-ptest
> core-image-sato:do_populate_sdk -k
>
> but could not reproduce the issue.
>
> work-around to reproduce this issue.
> ====================================
> I am observing since bzip2-tests is a git repo and
> fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is perl
> script.
> that's why I got this error.
>  so manually I copied fsmonitor-watchman.sample file into the
> bzip2-tests/.git/hooks and able to reproduce the issue.
> Error:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
> step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
> /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample
> contained in package bzip2-ptest requires /usr/bin/perl, but no providers
> found in RDEPENDS_bzip2-ptest? [file-rdeps]
> step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal errors.
> Please consider fixing them.
>
> I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
> RDEPENDS_${PN}-ptest += "make bash perl"
>
> so this issue got resolved.
>
> Issue2:
> =======
> Configuration for this issue
> ============================
>   MACHINE = "qemux86"
>   DISTRO = "poky"
>   SDKMACHINE = "i686"
>   PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>   INCOMPATIBLE_LICENSE = '*GPLv3'
>   WARN_QA_remove = 'incompatible-license'
>   QEMU_USE_KVM = 'True'
>   INHERIT += 'report-error'
>   PREMIRRORS = ''
>   BB_GENERATE_MIRROR_TARBALLS = '1'
>   BB_NUMBER_THREADS = '16'
>   PARALLEL_MAKE = '-j 16'
>   BB_TASK_NICE_LEVEL = '5'
>   BB_TASK_NICE_LEVEL_task-testimage = '0'
>   BB_TASK_IONICE_LEVEL = '2.7'
>   BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
>   INHERIT += 'testimage'
>   TEST_QEMUBOOT_TIMEOUT = '1500'
>   SANITY_TESTED_DISTROS = ''
>   SDK_EXT_TYPE = 'minimal'
>   SDK_INCLUDE_TOOLCHAIN = '1'
> Command
> =======
> bitbake core-image-minimal core-image-full-cmdline -k
>
>
> INCOMPATIBLE_LICENSE = '*GPLv3'
> WARN_QA_remove = 'incompatible-license'
> My doubt is since above configuration is using during build and we are
> using GPLv3+ license then definetly it will report error.
>
> It looks like you are packaging the test code/data with the main package
> not in bzip2-ptest. Have a look at:
>     meta/recipes-support/libpcre/libpcre_8.44.bb
> for an example. There are many more.
> Also, if you look at oe-core.git:
>     $ rgrep LICENSE_ *  | grep PN
> you can see many examples of sub-packages with different licenses
> than the main package. One example is:
>     meta/recipes-support/gnutls/gnutls_3.6.13.bb
> I hope that can address the buildbot problem but I haven't tried it
> myself yet.
>
> Explanation:
> I checked, Here is packaging the test code/data in bzip2-ptest.
>
> /opt/opensource/build/tmp/work/mips64-poky-linux/bzip2/1.0.8-r0/packages-split/bzip2-ptest
>
> I tried with the changes below  in the bzip2_1.0.8.bb file.
> LICENSE = "bzip2"
> LICENSE_${PN}-ptest = "GPLv3+"
>
> WARNING: LICENSE_bzip2-ptest includes licenses (GPLv3+) that are not
> listed in LICENSE
> To resolve this warning i did below changes.
> LICENSE = "bzip2 & GPLv3+"
> LICENSE_${PN}-ptest = "GPLv3+"
>
> But I am getting below error in both case
>
> ERROR: Nothing RPROVIDES 'bzip2' (but
> /opt/opensource/poky/meta/recipes-extended/packagegroups/
> packagegroup-core-full-cmdline.bb,
> /opt/opensource/poky/meta/recipes-devtools/python/python3_3.8.2.bb
> RDEPENDS on or otherwise requires it)
> bzip2 was skipped: it has incompatible license(s): GPL-3.0+
> NOTE: Runtime target 'bzip2' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['bzip2']
>
> So as per my understanding, if we are splitting the package and assigning
> Licence to it.
> example:
> LICENSE = "bzip2"
> LICENSE_${PN}-ptest = "GPLv3+"
>
> In this case I have to set LICENSE_PATH where your license file is located.
> or if I am using standard license, I have to set LICENSE first then we can
> set LICENSE_${PN}-ptest.
>
> Example:
> LICENSE = "bzip2 & GPLv3+"
> LICENSE_${PN}-ptest = "GPLv3+"
>
> Kindly comment on it and feel free to point out if i am wrong at any point.
>
>
> *Thanks & Regards,*
> Rahul Kumar
> Software Engineer,Linux Solutions Engineering
> Group,Montavista Software LLC
> Email Id: rahulk@mvista.com
> <https://plus.google.com/+CodeTwoSoftware>
>
>
> On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com>
> wrote:
>
>> On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
>> > You need to first see from the failure page which configuration is
>> > failing, for example non-gpl3 is one such.
>> >
>> > Then you find that configuration in config.json. The below should
>> > hopefully be self-explanatory in how you should set up the build?
>> >
>> > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
>> > "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
>> > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
>> > 'incompatible-license'" ], "EXTRACMDS" : [
>> > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>> >
>> > |
>> >
>> > |
>> > |
>> >
>> > |Alex
>>
>> Hi Rahul,
>>
>> Sorry for my late reply.
>>
>> The commit log for v2 is very good now!
>> Thanks for incorporating my --pedantic suggestions. ;-)
>>
>> It seems that you need a perl dependency for something (docs?
>>     $ cd .../bzip2.git
>>     $ grep -r "perl " *
>>     format.pl:#!/usr/bin/perl -w
>>     README.XML.STUFF:It uses format.pl, a perl script...
>>
>> Then we need to figure out how to deal with the GPLv3 issue.
>>
>> The buildbot output can be tedious to figure out. I haven't really
>> spent enough time plugging away at it to be proficient yet either.
>> Have you been able to reproduce the problems that Richard reported?
>> If not, and you've tried for a bit, then just say so and I'll try to
>> help tomorrow or early next week.
>>
>> It looks like you are packaging the test code/data with the main package
>> not in bzip2-ptest. Have a look at:
>>     meta/recipes-support/libpcre/libpcre_8.44.bb
>> for an example. There are many more.
>> Also, if you look at oe-core.git:
>>     $ rgrep LICENSE_ *  | grep PN
>> you can see many examples of sub-packages with different licenses
>> than the main package. One example is:
>>     meta/recipes-support/gnutls/gnutls_3.6.13.bb
>> I hope that can address the buildbot problem but I haven't tried it
>> myself yet.
>>
>> BTW, Trevor has gotten the YP autobuilder going at Wind River and
>> he'll be sending a few documentation updates next week or so.
>> That may help in case you want to reproduce the YP AB test
>> infrastructure. I expect that you don't _have_ to do so but
>> I think it would be good if more contributing organizations did
>> have an instance with only limited builders of the YP AB so that
>> we can do more testing before Richard runs our changes through
>> the main system. Richard has cautioned that the YP AB has lots of
>> builders each of which has many cores but I hope that we can at least
>> do some AB checking ourselves.
>>
>> ../Randy
>>
>>
>> > |
>> >
>> >
>> > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
>> > <mailto:rahulk@mvista.com>> wrote:
>> >
>> >     Hi Richard/Alexander,
>> >
>> >     I am not able to understand how I can use the below file.
>> >
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>> >
>> >     did you mean to say that i have to set MACRO in local.conf based on
>> >     this file.
>> >
>> >     *Thanks & Regards,*
>> >     Rahul Kumar
>> >     Software Engineer,Linux Solutions Engineering
>> >     Group,Montavista Software LLC
>> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>> >     <https://plus.google.com/+CodeTwoSoftware>
>> >
>> >
>> >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>> >     <richard.purdie@linuxfoundation.org
>> >     <mailto:richard.purdie@linuxfoundation.org>> wrote:
>> >
>> >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
>> >          > You need to look at configurations defined here:
>> >          >
>> >
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>> >          > and replicate them locally. Then you can reproduce the
>> >         failures that
>> >          > the AB gets in those configurations.
>> >
>> >         That start of the failing logs on the autobuilder also list out
>> the
>> >         configuration options for that build.
>> >
>> >         Cheers,
>> >
>> >         Richard
>> >
>> >
>> >
>> >
>>
>>
>> --
>> # Randy MacLeod
>> # Wind River Linux
>>
> 
>

[-- Attachment #2: Type: text/html, Size: 17195 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Randy MacLeod]

On 2020-05-12 12:58 a.m., Rahul Kumar wrote:
> Hi,
> 
> Can any one please help me to figure out how to deal with the GPLv3+ issue.
> 
> you can see my Patch at below link
> https://patchwork.openembedded.org/patch/172134/
> 
> *Issue:*
> the new license (GPLv3) causes problems:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
> *
> *

Hi Rahul,

I'm having some email problems with the oe-core list so apologies
if this is redundant.

What happens if you split the license info into two parts like:

$ grep "^LICENSE" recipes-extended/libvirt/libvirt_6.1.0.bb
LICENSE = "LGPLv2.1+ & GPLv2+"
LICENSE_${PN}-ptest = "GPLv2+ & LGPLv2.1+"
except of course with GPLv3.

I might try that tomorrow on our local instance of the YP autobuilder.
If you'd like to set one up @ mvista, I hear from Trevor that it doesn't
take all that much time. As others have explained, you can also dig
through the yocto-autobuilder2/yocto-autobuilder-helper git repos.

../Randy

> Thanks & Regards,
> Rahul Kumar
> Software Engineer,Linux Solutions Engineering
> Group,Montavista Software LLC
> Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> <https://plus.google.com/+CodeTwoSoftware>
> 
> 
> On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org 
> <http://lists.openembedded.org> 
> <rahulk=mvista.com@lists.openembedded.org 
> <mailto:mvista.com@lists.openembedded.org>> wrote:
> 
>     Hi Randy,
> 
>     As per your suggestion I did some progress.
> 
>     Issue 1:
>     ========
> 
>     Configuration for this issue:
>     =============================
>        MACHINE = "edgerouter"
>        DISTRO = "poky"
>        SDKMACHINE = "i686"
>        PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>        INHERIT += 'image-buildinfo'
>        IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
>        QEMU_USE_KVM = 'True'
>        INHERIT += 'report-error'
>        PREMIRRORS = ''
>        BB_GENERATE_MIRROR_TARBALLS = '1'
>        BB_NUMBER_THREADS = '16'
>        PARALLEL_MAKE = '-j 16'
>        BB_TASK_NICE_LEVEL = '5'
>        BB_TASK_NICE_LEVEL_task-testimage = '0'
>        BB_TASK_IONICE_LEVEL = '2.7'
>        BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
>        INHERIT += 'testimage'
>        TEST_QEMUBOOT_TIMEOUT = '1500'
>        SANITY_TESTED_DISTROS = ''
>        SDK_EXT_TYPE = 'minimal'
>        SDK_INCLUDE_TOOLCHAIN = '1'
>     Command:
>     ========
>     bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
>     core-image-minimal core-image-minimal-dev core-image-sato-ptest
>     core-image-sato:do_populate_sdk -k
> 
>     but could not reproduce the issue.
> 
>     work-around to reproduce this issue.
>     ====================================
>     I am observing since bzip2-tests is a git repo and
>     fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is
>     perl script.
>     that's why I got this error.
>       so manually I copied fsmonitor-watchman.sample file into the
>     bzip2-tests/.git/hooks and able to reproduce the issue.
>     Error:
>     https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
>     step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
>     /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample contained
>     in package bzip2-ptest requires /usr/bin/perl, but no providers
>     found in RDEPENDS_bzip2-ptest? [file-rdeps]
>     step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal
>     errors. Please consider fixing them.
> 
>     I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
>     RDEPENDS_${PN}-ptest += "make bash perl"
> 
>     so this issue got resolved.
> 
>     Issue2:
>     =======
>     Configuration for this issue
>     ============================
>        MACHINE = "qemux86"
>        DISTRO = "poky"
>        SDKMACHINE = "i686"
>        PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>        INCOMPATIBLE_LICENSE = '*GPLv3'
>        WARN_QA_remove = 'incompatible-license'
>        QEMU_USE_KVM = 'True'
>        INHERIT += 'report-error'
>        PREMIRRORS = ''
>        BB_GENERATE_MIRROR_TARBALLS = '1'
>        BB_NUMBER_THREADS = '16'
>        PARALLEL_MAKE = '-j 16'
>        BB_TASK_NICE_LEVEL = '5'
>        BB_TASK_NICE_LEVEL_task-testimage = '0'
>        BB_TASK_IONICE_LEVEL = '2.7'
>        BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
>        INHERIT += 'testimage'
>        TEST_QEMUBOOT_TIMEOUT = '1500'
>        SANITY_TESTED_DISTROS = ''
>        SDK_EXT_TYPE = 'minimal'
>        SDK_INCLUDE_TOOLCHAIN = '1'
>     Command
>     =======
>     bitbake core-image-minimal core-image-full-cmdline -k
> 
> 
>     INCOMPATIBLE_LICENSE = '*GPLv3'
>     WARN_QA_remove = 'incompatible-license'
>     My doubt is since above configuration is using during build and we
>     are using GPLv3+ license then definetly it will report error.
> 
>     It looks like you are packaging the test code/data with the main package
>     not in bzip2-ptest. Have a look at:
>          meta/recipes-support/libpcre/libpcre_8.44.bb
>     <http://libpcre_8.44.bb>
>     for an example. There are many more.
>     Also, if you look at oe-core.git:
>          $ rgrep LICENSE_ *  | grep PN
>     you can see many examples of sub-packages with different licenses
>     than the main package. One example is:
>          meta/recipes-support/gnutls/gnutls_3.6.13.bb
>     <http://gnutls_3.6.13.bb>
>     I hope that can address the buildbot problem but I haven't tried it
>     myself yet.
> 
>     Explanation:
>     I checked, Here is packaging the test code/data in bzip2-ptest.
>     /opt/opensource/build/tmp/work/mips64-poky-linux/bzip2/1.0.8-r0/packages-split/bzip2-ptest
> 
>     I tried with the changes below  in the bzip2_1.0.8.bb
>     <http://bzip2_1.0.8.bb> file.
>     LICENSE = "bzip2"
>     LICENSE_${PN}-ptest = "GPLv3+"
> 
>     WARNING: LICENSE_bzip2-ptest includes licenses (GPLv3+) that are not
>     listed in LICENSE
>     To resolve this warning i did below changes.
>     LICENSE = "bzip2 & GPLv3+"
>     LICENSE_${PN}-ptest = "GPLv3+"
> 
>     But I am getting below error in both case
> 
>     ERROR: Nothing RPROVIDES 'bzip2' (but
>     /opt/opensource/poky/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
>     <http://packagegroup-core-full-cmdline.bb>,
>     /opt/opensource/poky/meta/recipes-devtools/python/python3_3.8.2.bb
>     <http://python3_3.8.2.bb> RDEPENDS on or otherwise requires it)
>     bzip2 was skipped: it has incompatible license(s): GPL-3.0+
>     NOTE: Runtime target 'bzip2' is unbuildable, removing...
>     Missing or unbuildable dependency chain was: ['bzip2']
> 
>     So as per my understanding, if we are splitting the package and
>     assigning Licence to it.
>     example:
>     LICENSE = "bzip2"
>     LICENSE_${PN}-ptest = "GPLv3+"
> 
>     In this case I have to set LICENSE_PATH where your license file is
>     located.
>     or if I am using standard license, I have to set LICENSE first then
>     we can set LICENSE_${PN}-ptest.
> 
>     Example:
>     LICENSE = "bzip2 & GPLv3+"
>     LICENSE_${PN}-ptest = "GPLv3+"
> 
>     Kindly comment on it and feel free to point out if i am wrong at any
>     point.
> 
> 
>     *Thanks & Regards,*
>     Rahul Kumar
>     Software Engineer,Linux Solutions Engineering
>     Group,Montavista Software LLC
>     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>     <https://plus.google.com/+CodeTwoSoftware>
> 
> 
>     On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
>     <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
>     wrote:
> 
>         On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
>          > You need to first see from the failure page which
>         configuration is
>          > failing, for example non-gpl3 is one such.
>          >
>          > Then you find that configuration in config.json. The below
>         should
>          > hopefully be self-explanatory in how you should set up the build?
>          >
>          > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
>         "MACHINE" :
>          > "qemux86", "BBTARGETS" : "core-image-minimal
>         core-image-full-cmdline",
>          > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
>         "WARN_QA_remove =
>          > 'incompatible-license'" ], "EXTRACMDS" : [
>          > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>          >
>          > |
>          >
>          > |
>          > |
>          >
>          > |Alex
> 
>         Hi Rahul,
> 
>         Sorry for my late reply.
> 
>         The commit log for v2 is very good now!
>         Thanks for incorporating my --pedantic suggestions. ;-)
> 
>         It seems that you need a perl dependency for something (docs?
>              $ cd .../bzip2.git
>              $ grep -r "perl " *
>              format.pl:#!/usr/bin/perl -w
>              README.XML.STUFF:It uses format.pl <http://format.pl>, a
>         perl script...
> 
>         Then we need to figure out how to deal with the GPLv3 issue.
> 
>         The buildbot output can be tedious to figure out. I haven't really
>         spent enough time plugging away at it to be proficient yet either.
>         Have you been able to reproduce the problems that Richard reported?
>         If not, and you've tried for a bit, then just say so and I'll try to
>         help tomorrow or early next week.
> 
>         It looks like you are packaging the test code/data with the main
>         package
>         not in bzip2-ptest. Have a look at:
>              meta/recipes-support/libpcre/libpcre_8.44.bb
>         <http://libpcre_8.44.bb>
>         for an example. There are many more.
>         Also, if you look at oe-core.git:
>              $ rgrep LICENSE_ *  | grep PN
>         you can see many examples of sub-packages with different licenses
>         than the main package. One example is:
>              meta/recipes-support/gnutls/gnutls_3.6.13.bb
>         <http://gnutls_3.6.13.bb>
>         I hope that can address the buildbot problem but I haven't tried it
>         myself yet.
> 
>         BTW, Trevor has gotten the YP autobuilder going at Wind River and
>         he'll be sending a few documentation updates next week or so.
>         That may help in case you want to reproduce the YP AB test
>         infrastructure. I expect that you don't _have_ to do so but
>         I think it would be good if more contributing organizations did
>         have an instance with only limited builders of the YP AB so that
>         we can do more testing before Richard runs our changes through
>         the main system. Richard has cautioned that the YP AB has lots of
>         builders each of which has many cores but I hope that we can at
>         least
>         do some AB checking ourselves.
> 
>         ../Randy
> 
> 
>          > |
>          >
>          >
>          > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
>         <mailto:rahulk@mvista.com>
>          > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>> wrote:
>          >
>          >     Hi Richard/Alexander,
>          >
>          >     I am not able to understand how I can use the below file.
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          >
>          >     did you mean to say that i have to set MACRO in
>         local.conf based on
>          >     this file.
>          >
>          >     *Thanks & Regards,*
>          >     Rahul Kumar
>          >     Software Engineer,Linux Solutions Engineering
>          >     Group,Montavista Software LLC
>          >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>         <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
>          >     <https://plus.google.com/+CodeTwoSoftware>
>          >
>          >
>          >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>          >     <richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>
>          >     <mailto:richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>>> wrote:
>          >
>          >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
>         wrote:
>          >          > You need to look at configurations defined here:
>          >          >
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          >          > and replicate them locally. Then you can reproduce the
>          >         failures that
>          >          > the AB gets in those configurations.
>          >
>          >         That start of the failing logs on the autobuilder
>         also list out the
>          >         configuration options for that build.
>          >
>          >         Cheers,
>          >
>          >         Richard
>          >
>          >
>          >
>          >
> 
> 
>         -- 
>         # Randy MacLeod
>         # Wind River Linux
> 
>     
> 


-- 
# Randy MacLeod
# Wind River Linux

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Trevor Gamblin]

On 5/12/20 7:22 PM, Randy MacLeod wrote:
> On 2020-05-12 12:58 a.m., Rahul Kumar wrote:
>> Hi,
>>
>> Can any one please help me to figure out how to deal with the GPLv3+ 
>> issue.
>>
>> you can see my Patch at below link
>> https://patchwork.openembedded.org/patch/172134/
>>
>> *Issue:*
>> the new license (GPLv3) causes problems:
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
>> *
>> *
>
> Hi Rahul,
>
> I'm having some email problems with the oe-core list so apologies
> if this is redundant.
>
> What happens if you split the license info into two parts like:
>
> $ grep "^LICENSE" recipes-extended/libvirt/libvirt_6.1.0.bb
> LICENSE = "LGPLv2.1+ & GPLv2+"
> LICENSE_${PN}-ptest = "GPLv2+ & LGPLv2.1+"
> except of course with GPLv3.
>
> I might try that tomorrow on our local instance of the YP autobuilder.
> If you'd like to set one up @ mvista, I hear from Trevor that it doesn't
> take all that much time. As others have explained, you can also dig
> through the yocto-autobuilder2/yocto-autobuilder-helper git repos.

Hi Rahul, I can definitely help you get an autobuilder instance running 
locally, if you'd like. At the moment I'd suggest doing so on a host 
that's running Fedora, as that's where I've had the most success 
(Richard has explained to me how they run it on Ubuntu, but I haven't 
gotten it fully functional there yet).

Are you on either the #yocto and/or #oe IRC channels?

>
> ../Randy
>
>> Thanks & Regards,
>> Rahul Kumar
>> Software Engineer,Linux Solutions Engineering
>> Group,Montavista Software LLC
>> Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>> <https://plus.google.com/+CodeTwoSoftware>
>>
>>
>> On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org 
>> <http://lists.openembedded.org> 
>> <rahulk=mvista.com@lists.openembedded.org 
>> <mailto:mvista.com@lists.openembedded.org>> wrote:
>>
>>     Hi Randy,
>>
>>     As per your suggestion I did some progress.
>>
>>     Issue 1:
>>     ========
>>
>>     Configuration for this issue:
>>     =============================
>>        MACHINE = "edgerouter"
>>        DISTRO = "poky"
>>        SDKMACHINE = "i686"
>>        PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>>        INHERIT += 'image-buildinfo'
>>        IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
>>        QEMU_USE_KVM = 'True'
>>        INHERIT += 'report-error'
>>        PREMIRRORS = ''
>>        BB_GENERATE_MIRROR_TARBALLS = '1'
>>        BB_NUMBER_THREADS = '16'
>>        PARALLEL_MAKE = '-j 16'
>>        BB_TASK_NICE_LEVEL = '5'
>>        BB_TASK_NICE_LEVEL_task-testimage = '0'
>>        BB_TASK_IONICE_LEVEL = '2.7'
>>        BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
>>        INHERIT += 'testimage'
>>        TEST_QEMUBOOT_TIMEOUT = '1500'
>>        SANITY_TESTED_DISTROS = ''
>>        SDK_EXT_TYPE = 'minimal'
>>        SDK_INCLUDE_TOOLCHAIN = '1'
>>     Command:
>>     ========
>>     bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
>>     core-image-minimal core-image-minimal-dev core-image-sato-ptest
>>     core-image-sato:do_populate_sdk -k
>>
>>     but could not reproduce the issue.
>>
>>     work-around to reproduce this issue.
>>     ====================================
>>     I am observing since bzip2-tests is a git repo and
>>     fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is
>>     perl script.
>>     that's why I got this error.
>>       so manually I copied fsmonitor-watchman.sample file into the
>>     bzip2-tests/.git/hooks and able to reproduce the issue.
>>     Error:
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
>>     step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
>> /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample 
>> contained
>>     in package bzip2-ptest requires /usr/bin/perl, but no providers
>>     found in RDEPENDS_bzip2-ptest? [file-rdeps]
>>     step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal
>>     errors. Please consider fixing them.
>>
>>     I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
>>     RDEPENDS_${PN}-ptest += "make bash perl"
>>
>>     so this issue got resolved.
>>
>>     Issue2:
>>     =======
>>     Configuration for this issue
>>     ============================
>>        MACHINE = "qemux86"
>>        DISTRO = "poky"
>>        SDKMACHINE = "i686"
>>        PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>>        INCOMPATIBLE_LICENSE = '*GPLv3'
>>        WARN_QA_remove = 'incompatible-license'
>>        QEMU_USE_KVM = 'True'
>>        INHERIT += 'report-error'
>>        PREMIRRORS = ''
>>        BB_GENERATE_MIRROR_TARBALLS = '1'
>>        BB_NUMBER_THREADS = '16'
>>        PARALLEL_MAKE = '-j 16'
>>        BB_TASK_NICE_LEVEL = '5'
>>        BB_TASK_NICE_LEVEL_task-testimage = '0'
>>        BB_TASK_IONICE_LEVEL = '2.7'
>>        BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
>>        INHERIT += 'testimage'
>>        TEST_QEMUBOOT_TIMEOUT = '1500'
>>        SANITY_TESTED_DISTROS = ''
>>        SDK_EXT_TYPE = 'minimal'
>>        SDK_INCLUDE_TOOLCHAIN = '1'
>>     Command
>>     =======
>>     bitbake core-image-minimal core-image-full-cmdline -k
>>
>>
>>     INCOMPATIBLE_LICENSE = '*GPLv3'
>>     WARN_QA_remove = 'incompatible-license'
>>     My doubt is since above configuration is using during build and we
>>     are using GPLv3+ license then definetly it will report error.
>>
>>     It looks like you are packaging the test code/data with the main 
>> package
>>     not in bzip2-ptest. Have a look at:
>>          meta/recipes-support/libpcre/libpcre_8.44.bb
>>     <http://libpcre_8.44.bb>
>>     for an example. There are many more.
>>     Also, if you look at oe-core.git:
>>          $ rgrep LICENSE_ *  | grep PN
>>     you can see many examples of sub-packages with different licenses
>>     than the main package. One example is:
>>          meta/recipes-support/gnutls/gnutls_3.6.13.bb
>>     <http://gnutls_3.6.13.bb>
>>     I hope that can address the buildbot problem but I haven't tried it
>>     myself yet.
>>
>>     Explanation:
>>     I checked, Here is packaging the test code/data in bzip2-ptest.
>> /opt/opensource/build/tmp/work/mips64-poky-linux/bzip2/1.0.8-r0/packages-split/bzip2-ptest
>>
>>     I tried with the changes below  in the bzip2_1.0.8.bb
>>     <http://bzip2_1.0.8.bb> file.
>>     LICENSE = "bzip2"
>>     LICENSE_${PN}-ptest = "GPLv3+"
>>
>>     WARNING: LICENSE_bzip2-ptest includes licenses (GPLv3+) that are not
>>     listed in LICENSE
>>     To resolve this warning i did below changes.
>>     LICENSE = "bzip2 & GPLv3+"
>>     LICENSE_${PN}-ptest = "GPLv3+"
>>
>>     But I am getting below error in both case
>>
>>     ERROR: Nothing RPROVIDES 'bzip2' (but
>> /opt/opensource/poky/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
>>     <http://packagegroup-core-full-cmdline.bb>,
>> /opt/opensource/poky/meta/recipes-devtools/python/python3_3.8.2.bb
>>     <http://python3_3.8.2.bb> RDEPENDS on or otherwise requires it)
>>     bzip2 was skipped: it has incompatible license(s): GPL-3.0+
>>     NOTE: Runtime target 'bzip2' is unbuildable, removing...
>>     Missing or unbuildable dependency chain was: ['bzip2']
>>
>>     So as per my understanding, if we are splitting the package and
>>     assigning Licence to it.
>>     example:
>>     LICENSE = "bzip2"
>>     LICENSE_${PN}-ptest = "GPLv3+"
>>
>>     In this case I have to set LICENSE_PATH where your license file is
>>     located.
>>     or if I am using standard license, I have to set LICENSE first then
>>     we can set LICENSE_${PN}-ptest.
>>
>>     Example:
>>     LICENSE = "bzip2 & GPLv3+"
>>     LICENSE_${PN}-ptest = "GPLv3+"
>>
>>     Kindly comment on it and feel free to point out if i am wrong at any
>>     point.
>>
>>
>>     *Thanks & Regards,*
>>     Rahul Kumar
>>     Software Engineer,Linux Solutions Engineering
>>     Group,Montavista Software LLC
>>     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>>     <https://plus.google.com/+CodeTwoSoftware>
>>
>>
>>     On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
>>     <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
>>     wrote:
>>
>>         On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
>>          > You need to first see from the failure page which
>>         configuration is
>>          > failing, for example non-gpl3 is one such.
>>          >
>>          > Then you find that configuration in config.json. The below
>>         should
>>          > hopefully be self-explanatory in how you should set up the 
>> build?
>>          >
>>          > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
>>         "MACHINE" :
>>          > "qemux86", "BBTARGETS" : "core-image-minimal
>>         core-image-full-cmdline",
>>          > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
>>         "WARN_QA_remove =
>>          > 'incompatible-license'" ], "EXTRACMDS" : [
>>          > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>>          >
>>          > |
>>          >
>>          > |
>>          > |
>>          >
>>          > |Alex
>>
>>         Hi Rahul,
>>
>>         Sorry for my late reply.
>>
>>         The commit log for v2 is very good now!
>>         Thanks for incorporating my --pedantic suggestions. ;-)
>>
>>         It seems that you need a perl dependency for something (docs?
>>              $ cd .../bzip2.git
>>              $ grep -r "perl " *
>>              format.pl:#!/usr/bin/perl -w
>>              README.XML.STUFF:It uses format.pl <http://format.pl>, a
>>         perl script...
>>
>>         Then we need to figure out how to deal with the GPLv3 issue.
>>
>>         The buildbot output can be tedious to figure out. I haven't 
>> really
>>         spent enough time plugging away at it to be proficient yet 
>> either.
>>         Have you been able to reproduce the problems that Richard 
>> reported?
>>         If not, and you've tried for a bit, then just say so and I'll 
>> try to
>>         help tomorrow or early next week.
>>
>>         It looks like you are packaging the test code/data with the main
>>         package
>>         not in bzip2-ptest. Have a look at:
>>              meta/recipes-support/libpcre/libpcre_8.44.bb
>>         <http://libpcre_8.44.bb>
>>         for an example. There are many more.
>>         Also, if you look at oe-core.git:
>>              $ rgrep LICENSE_ *  | grep PN
>>         you can see many examples of sub-packages with different 
>> licenses
>>         than the main package. One example is:
>>              meta/recipes-support/gnutls/gnutls_3.6.13.bb
>>         <http://gnutls_3.6.13.bb>
>>         I hope that can address the buildbot problem but I haven't 
>> tried it
>>         myself yet.
>>
>>         BTW, Trevor has gotten the YP autobuilder going at Wind River 
>> and
>>         he'll be sending a few documentation updates next week or so.
>>         That may help in case you want to reproduce the YP AB test
>>         infrastructure. I expect that you don't _have_ to do so but
>>         I think it would be good if more contributing organizations did
>>         have an instance with only limited builders of the YP AB so that
>>         we can do more testing before Richard runs our changes through
>>         the main system. Richard has cautioned that the YP AB has 
>> lots of
>>         builders each of which has many cores but I hope that we can at
>>         least
>>         do some AB checking ourselves.
>>
>>         ../Randy
>>
>>
>>          > |
>>          >
>>          >
>>          > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
>>         <mailto:rahulk@mvista.com>
>>          > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>> wrote:
>>          >
>>          >     Hi Richard/Alexander,
>>          >
>>          >     I am not able to understand how I can use the below file.
>>          >
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>>          >
>>          >     did you mean to say that i have to set MACRO in
>>         local.conf based on
>>          >     this file.
>>          >
>>          >     *Thanks & Regards,*
>>          >     Rahul Kumar
>>          >     Software Engineer,Linux Solutions Engineering
>>          >     Group,Montavista Software LLC
>>          >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>>         <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
>>          >  <https://plus.google.com/+CodeTwoSoftware>
>>          >
>>          >
>>          >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>>          >     <richard.purdie@linuxfoundation.org
>>         <mailto:richard.purdie@linuxfoundation.org>
>>          >     <mailto:richard.purdie@linuxfoundation.org
>> <mailto:richard.purdie@linuxfoundation.org>>> wrote:
>>          >
>>          >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
>>         wrote:
>>          >          > You need to look at configurations defined here:
>>          >          >
>>          >
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>>          >          > and replicate them locally. Then you can 
>> reproduce the
>>          >         failures that
>>          >          > the AB gets in those configurations.
>>          >
>>          >         That start of the failing logs on the autobuilder
>>         also list out the
>>          >         configuration options for that build.
>>          >
>>          >         Cheers,
>>          >
>>          >         Richard
>>          >
>>          >
>>          >
>>          >
>>
>>
>>         --         # Randy MacLeod
>>         # Wind River Linux
>>
>>     
>>
>
>

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 15376 bytes --]

Hi Trevor,

It will be really helpful to me.But I don't have a Fedora system with me.
I have only Ubuntu System.

I am available on #oe IRC Channels.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Wed, May 13, 2020 at 7:58 PM Trevor Gamblin <trevor.gamblin@windriver.com>
wrote:

>
> On 5/12/20 7:22 PM, Randy MacLeod wrote:
> > On 2020-05-12 12:58 a.m., Rahul Kumar wrote:
> >> Hi,
> >>
> >> Can any one please help me to figure out how to deal with the GPLv3+
> >> issue.
> >>
> >> you can see my Patch at below link
> >> https://patchwork.openembedded.org/patch/172134/
> >>
> >> *Issue:*
> >> the new license (GPLv3) causes problems:
> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
> >> *
> >> *
> >
> > Hi Rahul,
> >
> > I'm having some email problems with the oe-core list so apologies
> > if this is redundant.
> >
> > What happens if you split the license info into two parts like:
> >
> > $ grep "^LICENSE" recipes-extended/libvirt/libvirt_6.1.0.bb
> > LICENSE = "LGPLv2.1+ & GPLv2+"
> > LICENSE_${PN}-ptest = "GPLv2+ & LGPLv2.1+"
> > except of course with GPLv3.
> >
> > I might try that tomorrow on our local instance of the YP autobuilder.
> > If you'd like to set one up @ mvista, I hear from Trevor that it doesn't
> > take all that much time. As others have explained, you can also dig
> > through the yocto-autobuilder2/yocto-autobuilder-helper git repos.
>
> Hi Rahul, I can definitely help you get an autobuilder instance running
> locally, if you'd like. At the moment I'd suggest doing so on a host
> that's running Fedora, as that's where I've had the most success
> (Richard has explained to me how they run it on Ubuntu, but I haven't
> gotten it fully functional there yet).
>
> Are you on either the #yocto and/or #oe IRC channels?
>
> >
> > ../Randy
> >
> >> Thanks & Regards,
> >> Rahul Kumar
> >> Software Engineer,Linux Solutions Engineering
> >> Group,Montavista Software LLC
> >> Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >> <https://plus.google.com/+CodeTwoSoftware>
> >>
> >>
> >> On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org
> >> <http://lists.openembedded.org>
> >> <rahulk=mvista.com@lists.openembedded.org
> >> <mailto:mvista.com@lists.openembedded.org>> wrote:
> >>
> >>     Hi Randy,
> >>
> >>     As per your suggestion I did some progress.
> >>
> >>     Issue 1:
> >>     ========
> >>
> >>     Configuration for this issue:
> >>     =============================
> >>        MACHINE = "edgerouter"
> >>        DISTRO = "poky"
> >>        SDKMACHINE = "i686"
> >>        PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
> >>        INHERIT += 'image-buildinfo'
> >>        IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
> >>        QEMU_USE_KVM = 'True'
> >>        INHERIT += 'report-error'
> >>        PREMIRRORS = ''
> >>        BB_GENERATE_MIRROR_TARBALLS = '1'
> >>        BB_NUMBER_THREADS = '16'
> >>        PARALLEL_MAKE = '-j 16'
> >>        BB_TASK_NICE_LEVEL = '5'
> >>        BB_TASK_NICE_LEVEL_task-testimage = '0'
> >>        BB_TASK_IONICE_LEVEL = '2.7'
> >>        BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
> >>        INHERIT += 'testimage'
> >>        TEST_QEMUBOOT_TIMEOUT = '1500'
> >>        SANITY_TESTED_DISTROS = ''
> >>        SDK_EXT_TYPE = 'minimal'
> >>        SDK_INCLUDE_TOOLCHAIN = '1'
> >>     Command:
> >>     ========
> >>     bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
> >>     core-image-minimal core-image-minimal-dev core-image-sato-ptest
> >>     core-image-sato:do_populate_sdk -k
> >>
> >>     but could not reproduce the issue.
> >>
> >>     work-around to reproduce this issue.
> >>     ====================================
> >>     I am observing since bzip2-tests is a git repo and
> >>     fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is
> >>     perl script.
> >>     that's why I got this error.
> >>       so manually I copied fsmonitor-watchman.sample file into the
> >>     bzip2-tests/.git/hooks and able to reproduce the issue.
> >>     Error:
> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
> >>     step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
> >> /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample
> >> contained
> >>     in package bzip2-ptest requires /usr/bin/perl, but no providers
> >>     found in RDEPENDS_bzip2-ptest? [file-rdeps]
> >>     step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal
> >>     errors. Please consider fixing them.
> >>
> >>     I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
> >>     RDEPENDS_${PN}-ptest += "make bash perl"
> >>
> >>     so this issue got resolved.
> >>
> >>     Issue2:
> >>     =======
> >>     Configuration for this issue
> >>     ============================
> >>        MACHINE = "qemux86"
> >>        DISTRO = "poky"
> >>        SDKMACHINE = "i686"
> >>        PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
> >>        INCOMPATIBLE_LICENSE = '*GPLv3'
> >>        WARN_QA_remove = 'incompatible-license'
> >>        QEMU_USE_KVM = 'True'
> >>        INHERIT += 'report-error'
> >>        PREMIRRORS = ''
> >>        BB_GENERATE_MIRROR_TARBALLS = '1'
> >>        BB_NUMBER_THREADS = '16'
> >>        PARALLEL_MAKE = '-j 16'
> >>        BB_TASK_NICE_LEVEL = '5'
> >>        BB_TASK_NICE_LEVEL_task-testimage = '0'
> >>        BB_TASK_IONICE_LEVEL = '2.7'
> >>        BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
> >>        INHERIT += 'testimage'
> >>        TEST_QEMUBOOT_TIMEOUT = '1500'
> >>        SANITY_TESTED_DISTROS = ''
> >>        SDK_EXT_TYPE = 'minimal'
> >>        SDK_INCLUDE_TOOLCHAIN = '1'
> >>     Command
> >>     =======
> >>     bitbake core-image-minimal core-image-full-cmdline -k
> >>
> >>
> >>     INCOMPATIBLE_LICENSE = '*GPLv3'
> >>     WARN_QA_remove = 'incompatible-license'
> >>     My doubt is since above configuration is using during build and we
> >>     are using GPLv3+ license then definetly it will report error.
> >>
> >>     It looks like you are packaging the test code/data with the main
> >> package
> >>     not in bzip2-ptest. Have a look at:
> >>          meta/recipes-support/libpcre/libpcre_8.44.bb
> >>     <http://libpcre_8.44.bb>
> >>     for an example. There are many more.
> >>     Also, if you look at oe-core.git:
> >>          $ rgrep LICENSE_ *  | grep PN
> >>     you can see many examples of sub-packages with different licenses
> >>     than the main package. One example is:
> >>          meta/recipes-support/gnutls/gnutls_3.6.13.bb
> >>     <http://gnutls_3.6.13.bb>
> >>     I hope that can address the buildbot problem but I haven't tried it
> >>     myself yet.
> >>
> >>     Explanation:
> >>     I checked, Here is packaging the test code/data in bzip2-ptest.
> >>
> /opt/opensource/build/tmp/work/mips64-poky-linux/bzip2/1.0.8-r0/packages-split/bzip2-ptest
> >>
> >>     I tried with the changes below  in the bzip2_1.0.8.bb
> >>     <http://bzip2_1.0.8.bb> file.
> >>     LICENSE = "bzip2"
> >>     LICENSE_${PN}-ptest = "GPLv3+"
> >>
> >>     WARNING: LICENSE_bzip2-ptest includes licenses (GPLv3+) that are not
> >>     listed in LICENSE
> >>     To resolve this warning i did below changes.
> >>     LICENSE = "bzip2 & GPLv3+"
> >>     LICENSE_${PN}-ptest = "GPLv3+"
> >>
> >>     But I am getting below error in both case
> >>
> >>     ERROR: Nothing RPROVIDES 'bzip2' (but
> >> /opt/opensource/poky/meta/recipes-extended/packagegroups/
> packagegroup-core-full-cmdline.bb
> >>     <http://packagegroup-core-full-cmdline.bb>,
> >> /opt/opensource/poky/meta/recipes-devtools/python/python3_3.8.2.bb
> >>     <http://python3_3.8.2.bb> RDEPENDS on or otherwise requires it)
> >>     bzip2 was skipped: it has incompatible license(s): GPL-3.0+
> >>     NOTE: Runtime target 'bzip2' is unbuildable, removing...
> >>     Missing or unbuildable dependency chain was: ['bzip2']
> >>
> >>     So as per my understanding, if we are splitting the package and
> >>     assigning Licence to it.
> >>     example:
> >>     LICENSE = "bzip2"
> >>     LICENSE_${PN}-ptest = "GPLv3+"
> >>
> >>     In this case I have to set LICENSE_PATH where your license file is
> >>     located.
> >>     or if I am using standard license, I have to set LICENSE first then
> >>     we can set LICENSE_${PN}-ptest.
> >>
> >>     Example:
> >>     LICENSE = "bzip2 & GPLv3+"
> >>     LICENSE_${PN}-ptest = "GPLv3+"
> >>
> >>     Kindly comment on it and feel free to point out if i am wrong at any
> >>     point.
> >>
> >>
> >>     *Thanks & Regards,*
> >>     Rahul Kumar
> >>     Software Engineer,Linux Solutions Engineering
> >>     Group,Montavista Software LLC
> >>     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >>     <https://plus.google.com/+CodeTwoSoftware>
> >>
> >>
> >>     On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
> >>     <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
> >>     wrote:
> >>
> >>         On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> >>          > You need to first see from the failure page which
> >>         configuration is
> >>          > failing, for example non-gpl3 is one such.
> >>          >
> >>          > Then you find that configuration in config.json. The below
> >>         should
> >>          > hopefully be self-explanatory in how you should set up the
> >> build?
> >>          >
> >>          > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
> >>         "MACHINE" :
> >>          > "qemux86", "BBTARGETS" : "core-image-minimal
> >>         core-image-full-cmdline",
> >>          > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
> >>         "WARN_QA_remove =
> >>          > 'incompatible-license'" ], "EXTRACMDS" : [
> >>          > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >>          >
> >>          > |
> >>          >
> >>          > |
> >>          > |
> >>          >
> >>          > |Alex
> >>
> >>         Hi Rahul,
> >>
> >>         Sorry for my late reply.
> >>
> >>         The commit log for v2 is very good now!
> >>         Thanks for incorporating my --pedantic suggestions. ;-)
> >>
> >>         It seems that you need a perl dependency for something (docs?
> >>              $ cd .../bzip2.git
> >>              $ grep -r "perl " *
> >>              format.pl:#!/usr/bin/perl -w
> >>              README.XML.STUFF:It uses format.pl <http://format.pl>, a
> >>         perl script...
> >>
> >>         Then we need to figure out how to deal with the GPLv3 issue.
> >>
> >>         The buildbot output can be tedious to figure out. I haven't
> >> really
> >>         spent enough time plugging away at it to be proficient yet
> >> either.
> >>         Have you been able to reproduce the problems that Richard
> >> reported?
> >>         If not, and you've tried for a bit, then just say so and I'll
> >> try to
> >>         help tomorrow or early next week.
> >>
> >>         It looks like you are packaging the test code/data with the main
> >>         package
> >>         not in bzip2-ptest. Have a look at:
> >>              meta/recipes-support/libpcre/libpcre_8.44.bb
> >>         <http://libpcre_8.44.bb>
> >>         for an example. There are many more.
> >>         Also, if you look at oe-core.git:
> >>              $ rgrep LICENSE_ *  | grep PN
> >>         you can see many examples of sub-packages with different
> >> licenses
> >>         than the main package. One example is:
> >>              meta/recipes-support/gnutls/gnutls_3.6.13.bb
> >>         <http://gnutls_3.6.13.bb>
> >>         I hope that can address the buildbot problem but I haven't
> >> tried it
> >>         myself yet.
> >>
> >>         BTW, Trevor has gotten the YP autobuilder going at Wind River
> >> and
> >>         he'll be sending a few documentation updates next week or so.
> >>         That may help in case you want to reproduce the YP AB test
> >>         infrastructure. I expect that you don't _have_ to do so but
> >>         I think it would be good if more contributing organizations did
> >>         have an instance with only limited builders of the YP AB so that
> >>         we can do more testing before Richard runs our changes through
> >>         the main system. Richard has cautioned that the YP AB has
> >> lots of
> >>         builders each of which has many cores but I hope that we can at
> >>         least
> >>         do some AB checking ourselves.
> >>
> >>         ../Randy
> >>
> >>
> >>          > |
> >>          >
> >>          >
> >>          > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> >>         <mailto:rahulk@mvista.com>
> >>          > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>>
> wrote:
> >>          >
> >>          >     Hi Richard/Alexander,
> >>          >
> >>          >     I am not able to understand how I can use the below file.
> >>          >
> >>
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >>          >
> >>          >     did you mean to say that i have to set MACRO in
> >>         local.conf based on
> >>          >     this file.
> >>          >
> >>          >     *Thanks & Regards,*
> >>          >     Rahul Kumar
> >>          >     Software Engineer,Linux Solutions Engineering
> >>          >     Group,Montavista Software LLC
> >>          >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >>         <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
> >>          >  <https://plus.google.com/+CodeTwoSoftware>
> >>          >
> >>          >
> >>          >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >>          >     <richard.purdie@linuxfoundation.org
> >>         <mailto:richard.purdie@linuxfoundation.org>
> >>          >     <mailto:richard.purdie@linuxfoundation.org
> >> <mailto:richard.purdie@linuxfoundation.org>>> wrote:
> >>          >
> >>          >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
> >>         wrote:
> >>          >          > You need to look at configurations defined here:
> >>          >          >
> >>          >
> >>
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >>          >          > and replicate them locally. Then you can
> >> reproduce the
> >>          >         failures that
> >>          >          > the AB gets in those configurations.
> >>          >
> >>          >         That start of the failing logs on the autobuilder
> >>         also list out the
> >>          >         configuration options for that build.
> >>          >
> >>          >         Cheers,
> >>          >
> >>          >         Richard
> >>          >
> >>          >
> >>          >
> >>          >
> >>
> >>
> >>         --         # Randy MacLeod
> >>         # Wind River Linux
> >>
> >>     
> >>
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 26298 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 7461 bytes --]

Hi Randy,

patch has been accepted by bzip2 community with additional changes.
https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0

So I need your suggestion with respect to Yocto.

Since required changes for ptest infrastructure is integrated to the
bzip2-tests.git source code.
So now we can just change the SRCREV with the latest commit instead of
applying the patch to the bzip2-tests.git source code.

And since we are just integrating the bzip2-tests source to the bzip2
recipe and not modifying any file so i think no need to add any License for
it.


Now patch will look like
=====================================================================
--- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
+++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
@@ -46,6 +46,7 @@ runtest:
        else echo "FAIL: sample2 decompress"; fi
        @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
decompress";\
        else echo "FAIL: sample3 decompress"; fi
+       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"

 install-ptest:
        sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
@@ -56,6 +57,7 @@ install-ptest:
        cp $(srcdir)/sample1.bz2        $(DESTDIR)/
        cp $(srcdir)/sample2.bz2        $(DESTDIR)/
        cp $(srcdir)/sample3.bz2        $(DESTDIR)/
+       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
        ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2

 install-exec-hook:
diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
index d58f553..c5aa690 100644
--- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
+++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
@@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
 LIC_FILES_CHKSUM =
"file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"

 SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \
+           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests \
            file://configure.ac;subdir=${BP} \
            file://Makefile.am;subdir=${BP} \
            file://run-ptest \
            "
+
 SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
 SRC_URI[sha256sum] =
"ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"

+SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"  *<< this
commit Id includes latest charges for ptest infrastruct.*
+
 UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"

 PACKAGES =+ "libbz2"
@@ -39,7 +43,7 @@ do_install_ptest () {

 FILES_libbz2 = "${libdir}/lib*${SOLIBS}"

-RDEPENDS_${PN}-ptest += "make"
+RDEPENDS_${PN}-ptest += "make bash"

 PROVIDES_append_class-native = " bzip2-replacement-native"
 BBCLASSEXTEND = "native nativesdk"
=================================================================================

Kindly comment on it and feel free to point out, if i am wrong at any place.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com>
wrote:

> On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> > You need to first see from the failure page which configuration is
> > failing, for example non-gpl3 is one such.
> >
> > Then you find that configuration in config.json. The below should
> > hopefully be self-explanatory in how you should set up the build?
> >
> > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
> > "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
> > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
> > 'incompatible-license'" ], "EXTRACMDS" : [
> > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >
> > |
> >
> > |
> > |
> >
> > |Alex
>
> Hi Rahul,
>
> Sorry for my late reply.
>
> The commit log for v2 is very good now!
> Thanks for incorporating my --pedantic suggestions. ;-)
>
> It seems that you need a perl dependency for something (docs?
>     $ cd .../bzip2.git
>     $ grep -r "perl " *
>     format.pl:#!/usr/bin/perl -w
>     README.XML.STUFF:It uses format.pl, a perl script...
>
> Then we need to figure out how to deal with the GPLv3 issue.
>
> The buildbot output can be tedious to figure out. I haven't really
> spent enough time plugging away at it to be proficient yet either.
> Have you been able to reproduce the problems that Richard reported?
> If not, and you've tried for a bit, then just say so and I'll try to
> help tomorrow or early next week.
>
> It looks like you are packaging the test code/data with the main package
> not in bzip2-ptest. Have a look at:
>     meta/recipes-support/libpcre/libpcre_8.44.bb
> for an example. There are many more.
> Also, if you look at oe-core.git:
>     $ rgrep LICENSE_ *  | grep PN
> you can see many examples of sub-packages with different licenses
> than the main package. One example is:
>     meta/recipes-support/gnutls/gnutls_3.6.13.bb
> I hope that can address the buildbot problem but I haven't tried it
> myself yet.
>
> BTW, Trevor has gotten the YP autobuilder going at Wind River and
> he'll be sending a few documentation updates next week or so.
> That may help in case you want to reproduce the YP AB test
> infrastructure. I expect that you don't _have_ to do so but
> I think it would be good if more contributing organizations did
> have an instance with only limited builders of the YP AB so that
> we can do more testing before Richard runs our changes through
> the main system. Richard has cautioned that the YP AB has lots of
> builders each of which has many cores but I hope that we can at least
> do some AB checking ourselves.
>
> ../Randy
>
>
> > |
> >
> >
> > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> > <mailto:rahulk@mvista.com>> wrote:
> >
> >     Hi Richard/Alexander,
> >
> >     I am not able to understand how I can use the below file.
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >
> >     did you mean to say that i have to set MACRO in local.conf based on
> >     this file.
> >
> >     *Thanks & Regards,*
> >     Rahul Kumar
> >     Software Engineer,Linux Solutions Engineering
> >     Group,Montavista Software LLC
> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >     <https://plus.google.com/+CodeTwoSoftware>
> >
> >
> >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >     <richard.purdie@linuxfoundation.org
> >     <mailto:richard.purdie@linuxfoundation.org>> wrote:
> >
> >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
> >          > You need to look at configurations defined here:
> >          >
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >          > and replicate them locally. Then you can reproduce the
> >         failures that
> >          > the AB gets in those configurations.
> >
> >         That start of the failing logs on the autobuilder also list out
> the
> >         configuration options for that build.
> >
> >         Cheers,
> >
> >         Richard
> >
> >
> > 
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>

[-- Attachment #2: Type: text/html, Size: 11714 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 8606 bytes --]

As I wrote in my previous mail, when it comes to licenses, it is the distribution that is important. So if you build a package (bzip2-ptest) that includes code that is GPL-3.0, it does not matter if that code is only used as a binary blob, it is still distributed in the package, and thus the package needs to be covered by the GPL-3.0 license.

//Peter

From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Rahul Kumar
Sent: den 17 maj 2020 21:18
To: Randy MacLeod <randy.macleod@windriver.com>
Cc: Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie <richard.purdie@linuxfoundation.org>; OE-core <openembedded-core@lists.openembedded.org>; Trevor Gamblin <trevor.gamblin@windriver.com>
Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

Hi Randy,

patch has been accepted by bzip2 community with additional changes.
https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0

So I need your suggestion with respect to Yocto.

Since required changes for ptest infrastructure is integrated to the bzip2-tests.git source code.
So now we can just change the SRCREV with the latest commit instead of applying the patch to the bzip2-tests.git source code.

And since we are just integrating the bzip2-tests source to the bzip2 recipe and not modifying any file so i think no need to add any License for it.


Now patch will look like
=====================================================================
--- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
+++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
@@ -46,6 +46,7 @@ runtest:
        else echo "FAIL: sample2 decompress"; fi
        @if cmp sample3.tst sample3.ref; then echo "PASS: sample3 decompress";\
        else echo "FAIL: sample3 decompress"; fi
+       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"

 install-ptest:
        sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
@@ -56,6 +57,7 @@ install-ptest:
        cp $(srcdir)/sample1.bz2        $(DESTDIR)/
        cp $(srcdir)/sample2.bz2        $(DESTDIR)/
        cp $(srcdir)/sample3.bz2        $(DESTDIR)/
+       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
        ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2

 install-exec-hook:
diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb> b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb>
index d58f553..c5aa690 100644
--- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb>
+++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb>
@@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
 LIC_FILES_CHKSUM = "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"

 SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz<https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz> \
+           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests<http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
            file://configure.ac<http://configure.ac>;subdir=${BP} \
            file://Makefile.am;subdir=${BP} \
            file://run-ptest \
            "
+
 SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
 SRC_URI[sha256sum] = "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"

+SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"  << this commit Id includes latest charges for ptest infrastruct.
+
 UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"

 PACKAGES =+ "libbz2"
@@ -39,7 +43,7 @@ do_install_ptest () {

 FILES_libbz2 = "${libdir}/lib*${SOLIBS}"

-RDEPENDS_${PN}-ptest += "make"
+RDEPENDS_${PN}-ptest += "make bash"

 PROVIDES_append_class-native = " bzip2-replacement-native"
 BBCLASSEXTEND = "native nativesdk"
=================================================================================

Kindly comment on it and feel free to point out, if i am wrong at any place.

Thanks & Regards,
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com<mailto:rahulk@mvista.com>
<https://plus.google.com/+CodeTwoSoftware>


On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com<mailto:randy.macleod@windriver.com>> wrote:
On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> You need to first see from the failure page which configuration is
> failing, for example non-gpl3 is one such.
>
> Then you find that configuration in config.json. The below should
> hopefully be self-explanatory in how you should set up the build?
>
> |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
> "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
> "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
> 'incompatible-license'" ], "EXTRACMDS" : [
> "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>
> |
>
> |
> |
>
> |Alex

Hi Rahul,

Sorry for my late reply.

The commit log for v2 is very good now!
Thanks for incorporating my --pedantic suggestions. ;-)

It seems that you need a perl dependency for something (docs?
    $ cd .../bzip2.git
    $ grep -r "perl " *
    format.pl:#!/usr/bin/perl -w
    README.XML.STUFF:It uses format.pl<http://format.pl>, a perl script...

Then we need to figure out how to deal with the GPLv3 issue.

The buildbot output can be tedious to figure out. I haven't really
spent enough time plugging away at it to be proficient yet either.
Have you been able to reproduce the problems that Richard reported?
If not, and you've tried for a bit, then just say so and I'll try to
help tomorrow or early next week.

It looks like you are packaging the test code/data with the main package
not in bzip2-ptest. Have a look at:
    meta/recipes-support/libpcre/libpcre_8.44.bb<http://libpcre_8.44.bb>
for an example. There are many more.
Also, if you look at oe-core.git:
    $ rgrep LICENSE_ *  | grep PN
you can see many examples of sub-packages with different licenses
than the main package. One example is:
    meta/recipes-support/gnutls/gnutls_3.6.13.bb<http://gnutls_3.6.13.bb>
I hope that can address the buildbot problem but I haven't tried it
myself yet.

BTW, Trevor has gotten the YP autobuilder going at Wind River and
he'll be sending a few documentation updates next week or so.
That may help in case you want to reproduce the YP AB test
infrastructure. I expect that you don't _have_ to do so but
I think it would be good if more contributing organizations did
have an instance with only limited builders of the YP AB so that
we can do more testing before Richard runs our changes through
the main system. Richard has cautioned that the YP AB has lots of
builders each of which has many cores but I hope that we can at least
do some AB checking ourselves.

../Randy


> |
>
>
> On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com<mailto:rahulk@mvista.com>
> <mailto:rahulk@mvista.com<mailto:rahulk@mvista.com>>> wrote:
>
>     Hi Richard/Alexander,
>
>     I am not able to understand how I can use the below file.
>     http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>
>     did you mean to say that i have to set MACRO in local.conf based on
>     this file.
>
>     *Thanks & Regards,*
>     Rahul Kumar
>     Software Engineer,Linux Solutions Engineering
>     Group,Montavista Software LLC
>     Email Id: rahulk@mvista.com<mailto:rahulk@mvista.com> <mailto:rahulk@mvista.com<mailto:rahulk@mvista.com>>
>     <https://plus.google.com/+CodeTwoSoftware>
>
>
>     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>     <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>
>     <mailto:richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>>> wrote:
>
>         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
>          > You need to look at configurations defined here:
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          > and replicate them locally. Then you can reproduce the
>         failures that
>          > the AB gets in those configurations.
>
>         That start of the failing logs on the autobuilder also list out the
>         configuration options for that build.
>
>         Cheers,
>
>         Richard
>
>
>
>


--
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 16506 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 11836 bytes --]

Hi Peter,

I am sharing a few information related to bzip2-test source and licensing
information.
As per your suggestion and as per my understanding I added License to the
bzip2 recipe file.

bzip2-tests.git source tree structure is given below
(here showing licence related fle, removed other file names )

bzip2-tests.git/
├── commons-compress
│   ├── LICENSE.txt
│
├── dotnetzip
│   ├── License.txt
│   ├── License.zlib.txt
|
├── go
│   ├── LICENSE
│
├── lbzip2
├── pyflate
├── README
└── run-tests.sh

source code link:
https://sourceware.org/git/bzip2-tests.git

bzip2-tests.git source contains
1) comman-commpress: which is Originally distributed under the Apache
License Version 2.0.
See LICENSE.txt

2) dotnetzip:
(i)  The DotNetZip Library is distributed under the MicroSoft Public License
    (Ms-PL) see the License.txt file.
(ii) The BZ2 related resources are distributed under the licenses in
License.zlib.txt.

3) go:
 Go is distributed under a BSD-style license.
 See the LICENSE file.

4) lbzip2:
lbzip2 is free software: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version

5) pyflate: You may use and distribute this code and documentation under any
            DFSG-compatible license (eg. BSD, GNU GPLv2).

6) run-tests.sh: you can redistribute it and/or modify it under the terms
of the GNU General Public License (GPL); either
                 version 3, or (at your option) any later version.


SO in recipe I added the License like below
LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
LIC_FILES_CHKSUM =
"file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
\

file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
\ # For comman-commpress (Apache-2.0)

file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f
\      # For dotnetzip (Ms-PL)

file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f
\   # For dotnetzip  (jzlib +zlib)

file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
 # For go (BSD-style license)

here I need few suggestion:

1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
   but not added LIC_FILES_CHKSUM for GPLv3 and BSD because bzip2-tests.git
source code doesn't have GPLv3 and BSD License text file like other
   directories.

2) License.zlib.txt: This is a combination of two licence jzlib and zlib.
In meta/files/common-licenses Zlib license is available but not jzlib.
   In this case how can I proceed?

Kindly comment on this and feel free to point out if i am wrong at any
place.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

> As I wrote in my previous mail, when it comes to licenses, it is the
> distribution that is important. So if you build a package (bzip2-ptest)
> that includes code that is GPL-3.0, it does not matter if that code is only
> used as a binary blob, it is still distributed in the package, and thus the
> package needs to be covered by the GPL-3.0 license.
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org> *On Behalf Of *Rahul Kumar
> *Sent:* den 17 maj 2020 21:18
> *To:* Randy MacLeod <randy.macleod@windriver.com>
> *Cc:* Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie <
> richard.purdie@linuxfoundation.org>; OE-core <
> openembedded-core@lists.openembedded.org>; Trevor Gamblin <
> trevor.gamblin@windriver.com>
> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>
>
>
> Hi Randy,
>
> patch has been accepted by bzip2 community with additional changes.
>
> https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
>
>
> So I need your suggestion with respect to Yocto.
>
> Since required changes for ptest infrastructure is integrated to the
> bzip2-tests.git source code.
> So now we can just change the SRCREV with the latest commit instead of
> applying the patch to the bzip2-tests.git source code.
>
> And since we are just integrating the bzip2-tests source to the bzip2
> recipe and not modifying any file so i think no need to add any License for
> it.
>
>
> Now patch will look like
> =====================================================================
> --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> @@ -46,6 +46,7 @@ runtest:
>         else echo "FAIL: sample2 decompress"; fi
>         @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> decompress";\
>         else echo "FAIL: sample3 decompress"; fi
> +       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
>
>  install-ptest:
>         sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
> @@ -56,6 +57,7 @@ install-ptest:
>         cp $(srcdir)/sample1.bz2        $(DESTDIR)/
>         cp $(srcdir)/sample2.bz2        $(DESTDIR)/
>         cp $(srcdir)/sample3.bz2        $(DESTDIR)/
> +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
>         ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
>
>  install-exec-hook:
> diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> index d58f553..c5aa690 100644
> --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
>  LIC_FILES_CHKSUM = "
> file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
> "
>
>  SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \
> +           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests \
>             file://configure.ac;subdir=${BP} \
>             file://Makefile.am;subdir=${BP} \
>             file://run-ptest \
>             "
> +
>  SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
>  SRC_URI[sha256sum] =
> "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
>
> +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"  *<<
> this commit Id includes latest charges for ptest infrastruct.*
> +
>  UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
>
>  PACKAGES =+ "libbz2"
> @@ -39,7 +43,7 @@ do_install_ptest () {
>
>  FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
>
> -RDEPENDS_${PN}-ptest += "make"
> +RDEPENDS_${PN}-ptest += "make bash"
>
>  PROVIDES_append_class-native = " bzip2-replacement-native"
>  BBCLASSEXTEND = "native nativesdk"
>
> =================================================================================
>
> Kindly comment on it and feel free to point out, if i am wrong at any
> place.
>
>
>
> *Thanks & Regards,*
>
> Rahul Kumar
>
> Software Engineer,Linux Solutions Engineering
>
> Group,Montavista Software LLC
>
> Email Id: rahulk@mvista.com
> <https://plus.google.com/+CodeTwoSoftware>
>
>
>
>
>
> On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com>
> wrote:
>
> On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> > You need to first see from the failure page which configuration is
> > failing, for example non-gpl3 is one such.
> >
> > Then you find that configuration in config.json. The below should
> > hopefully be self-explanatory in how you should set up the build?
> >
> > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
> > "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
> > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
> > 'incompatible-license'" ], "EXTRACMDS" : [
> > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >
> > |
> >
> > |
> > |
> >
> > |Alex
>
> Hi Rahul,
>
> Sorry for my late reply.
>
> The commit log for v2 is very good now!
> Thanks for incorporating my --pedantic suggestions. ;-)
>
> It seems that you need a perl dependency for something (docs?
>     $ cd .../bzip2.git
>     $ grep -r "perl " *
>     format.pl:#!/usr/bin/perl -w
>     README.XML.STUFF:It uses format.pl, a perl script...
>
> Then we need to figure out how to deal with the GPLv3 issue.
>
> The buildbot output can be tedious to figure out. I haven't really
> spent enough time plugging away at it to be proficient yet either.
> Have you been able to reproduce the problems that Richard reported?
> If not, and you've tried for a bit, then just say so and I'll try to
> help tomorrow or early next week.
>
> It looks like you are packaging the test code/data with the main package
> not in bzip2-ptest. Have a look at:
>     meta/recipes-support/libpcre/libpcre_8.44.bb
> for an example. There are many more.
> Also, if you look at oe-core.git:
>     $ rgrep LICENSE_ *  | grep PN
> you can see many examples of sub-packages with different licenses
> than the main package. One example is:
>     meta/recipes-support/gnutls/gnutls_3.6.13.bb
> I hope that can address the buildbot problem but I haven't tried it
> myself yet.
>
> BTW, Trevor has gotten the YP autobuilder going at Wind River and
> he'll be sending a few documentation updates next week or so.
> That may help in case you want to reproduce the YP AB test
> infrastructure. I expect that you don't _have_ to do so but
> I think it would be good if more contributing organizations did
> have an instance with only limited builders of the YP AB so that
> we can do more testing before Richard runs our changes through
> the main system. Richard has cautioned that the YP AB has lots of
> builders each of which has many cores but I hope that we can at least
> do some AB checking ourselves.
>
> ../Randy
>
>
> > |
> >
> >
> > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> > <mailto:rahulk@mvista.com>> wrote:
> >
> >     Hi Richard/Alexander,
> >
> >     I am not able to understand how I can use the below file.
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >
> >     did you mean to say that i have to set MACRO in local.conf based on
> >     this file.
> >
> >     *Thanks & Regards,*
> >     Rahul Kumar
> >     Software Engineer,Linux Solutions Engineering
> >     Group,Montavista Software LLC
> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >     <https://plus.google.com/+CodeTwoSoftware>
> >
> >
> >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >     <richard.purdie@linuxfoundation.org
> >     <mailto:richard.purdie@linuxfoundation.org>> wrote:
> >
> >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
> >          > You need to look at configurations defined here:
> >          >
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >          > and replicate them locally. Then you can reproduce the
> >         failures that
> >          > the AB gets in those configurations.
> >
> >         That start of the failing logs on the autobuilder also list out
> the
> >         configuration options for that build.
> >
> >         Cheers,
> >
> >         Richard
> >
> >
> >
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
>

[-- Attachment #2: Type: text/html, Size: 20017 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 13249 bytes --]

The jzlib license is a three clause BSD license, and so is the go/LICENSE, so you should be able to set LICENSE as:

LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"

You also need to add:

LICENSE_${PN} = "bzip2-1.0.6"
LICENSE_${PN}-dev = "bzip2-1.0.6"
LICENSE_${PN}-dbg = "bzip2-1.0.6"
LICENSE_${PN}-doc = "bzip2-1.0.6"
LICENSE_${PN}-src = "bzip2-1.0.6"
LICENSE_libbz2 = "bzip2-1.0.6"

so the non-ptest packages are not affected by the licenses for the ptest package.

//Peter

From: Rahul Kumar <rahulk@mvista.com>
Sent: den 19 maj 2020 13:58
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Cc: Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie <richard.purdie@linuxfoundation.org>; OE-core <openembedded-core@lists.openembedded.org>; Trevor Gamblin <trevor.gamblin@windriver.com>
Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

Hi Peter,

I am sharing a few information related to bzip2-test source and licensing information.
As per your suggestion and as per my understanding I added License to the bzip2 recipe file.
bzip2-tests.git source tree structure is given below
(here showing licence related fle, removed other file names )
bzip2-tests.git/
├── commons-compress
│   ├── LICENSE.txt
│
├── dotnetzip
│   ├── License.txt
│   ├── License.zlib.txt
|
├── go
│   ├── LICENSE
│
├── lbzip2
├── pyflate
├── README
└── run-tests.sh

source code link:
https://sourceware.org/git/bzip2-tests.git

bzip2-tests.git source contains
1) comman-commpress: which is Originally distributed under the Apache License Version 2.0.
See LICENSE.txt

2) dotnetzip:
(i)  The DotNetZip Library is distributed under the MicroSoft Public License
    (Ms-PL) see the License.txt file.
(ii) The BZ2 related resources are distributed under the licenses in License.zlib.txt.

3) go:
 Go is distributed under a BSD-style license.
 See the LICENSE file.

4) lbzip2:
lbzip2 is free software: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version

5) pyflate: You may use and distribute this code and documentation under any
            DFSG-compatible license (eg. BSD, GNU GPLv2).

6) run-tests.sh: you can redistribute it and/or modify it under the terms of the GNU General Public License (GPL); either
                 version 3, or (at your option) any later version.


SO in recipe I added the License like below
LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664 \
                    file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327 \ # For comman-commpress (Apache-2.0)
                    file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f \      # For dotnetzip (Ms-PL)
                    file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f \   # For dotnetzip  (jzlib +zlib)
                    file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \      # For go (BSD-style license)

here I need few suggestion:

1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
   but not added LIC_FILES_CHKSUM for GPLv3 and BSD because bzip2-tests.git source code doesn't have GPLv3 and BSD License text file like other
   directories.

2) License.zlib.txt: This is a combination of two licence jzlib and zlib. In meta/files/common-licenses Zlib license is available but not jzlib.
   In this case how can I proceed?

Kindly comment on this and feel free to point out if i am wrong at any place.

Thanks & Regards,
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com<mailto:rahulk@mvista.com>
<https://plus.google.com/+CodeTwoSoftware>


On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt <peter.kjellerstedt@axis.com<mailto:peter.kjellerstedt@axis.com>> wrote:
As I wrote in my previous mail, when it comes to licenses, it is the distribution that is important. So if you build a package (bzip2-ptest) that includes code that is GPL-3.0, it does not matter if that code is only used as a binary blob, it is still distributed in the package, and thus the package needs to be covered by the GPL-3.0 license.

//Peter

From: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>> On Behalf Of Rahul Kumar
Sent: den 17 maj 2020 21:18
To: Randy MacLeod <randy.macleod@windriver.com<mailto:randy.macleod@windriver.com>>
Cc: Alexander Kanavin <alex.kanavin@gmail.com<mailto:alex.kanavin@gmail.com>>; Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>>; OE-core <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>; Trevor Gamblin <trevor.gamblin@windriver.com<mailto:trevor.gamblin@windriver.com>>
Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

Hi Randy,

patch has been accepted by bzip2 community with additional changes.
https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0

So I need your suggestion with respect to Yocto.

Since required changes for ptest infrastructure is integrated to the bzip2-tests.git source code.
So now we can just change the SRCREV with the latest commit instead of applying the patch to the bzip2-tests.git source code.

And since we are just integrating the bzip2-tests source to the bzip2 recipe and not modifying any file so i think no need to add any License for it.


Now patch will look like
=====================================================================
--- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
+++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
@@ -46,6 +46,7 @@ runtest:
        else echo "FAIL: sample2 decompress"; fi
        @if cmp sample3.tst sample3.ref; then echo "PASS: sample3 decompress";\
        else echo "FAIL: sample3 decompress"; fi
+       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"

 install-ptest:
        sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
@@ -56,6 +57,7 @@ install-ptest:
        cp $(srcdir)/sample1.bz2        $(DESTDIR)/
        cp $(srcdir)/sample2.bz2        $(DESTDIR)/
        cp $(srcdir)/sample3.bz2        $(DESTDIR)/
+       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
        ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2

 install-exec-hook:
diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb> b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb>
index d58f553..c5aa690 100644
--- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb>
+++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb<http://bzip2_1.0.8.bb>
@@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
 LIC_FILES_CHKSUM = "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"

 SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz<https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz> \
+           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests<http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
            file://configure.ac<http://configure.ac>;subdir=${BP} \
            file://Makefile.am;subdir=${BP} \
            file://run-ptest \
            "
+
 SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
 SRC_URI[sha256sum] = "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"

+SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"  << this commit Id includes latest charges for ptest infrastruct.
+
 UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"

 PACKAGES =+ "libbz2"
@@ -39,7 +43,7 @@ do_install_ptest () {

 FILES_libbz2 = "${libdir}/lib*${SOLIBS}"

-RDEPENDS_${PN}-ptest += "make"
+RDEPENDS_${PN}-ptest += "make bash"

 PROVIDES_append_class-native = " bzip2-replacement-native"
 BBCLASSEXTEND = "native nativesdk"
=================================================================================

Kindly comment on it and feel free to point out, if i am wrong at any place.

Thanks & Regards,
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com<mailto:rahulk@mvista.com>
<https://plus.google.com/+CodeTwoSoftware>


On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com<mailto:randy.macleod@windriver.com>> wrote:
On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> You need to first see from the failure page which configuration is
> failing, for example non-gpl3 is one such.
>
> Then you find that configuration in config.json. The below should
> hopefully be self-explanatory in how you should set up the build?
>
> |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
> "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
> "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
> 'incompatible-license'" ], "EXTRACMDS" : [
> "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>
> |
>
> |
> |
>
> |Alex

Hi Rahul,

Sorry for my late reply.

The commit log for v2 is very good now!
Thanks for incorporating my --pedantic suggestions. ;-)

It seems that you need a perl dependency for something (docs?
    $ cd .../bzip2.git
    $ grep -r "perl " *
    format.pl:#!/usr/bin/perl -w
    README.XML.STUFF:It uses format.pl<http://format.pl>, a perl script...

Then we need to figure out how to deal with the GPLv3 issue.

The buildbot output can be tedious to figure out. I haven't really
spent enough time plugging away at it to be proficient yet either.
Have you been able to reproduce the problems that Richard reported?
If not, and you've tried for a bit, then just say so and I'll try to
help tomorrow or early next week.

It looks like you are packaging the test code/data with the main package
not in bzip2-ptest. Have a look at:
    meta/recipes-support/libpcre/libpcre_8.44.bb<http://libpcre_8.44.bb>
for an example. There are many more.
Also, if you look at oe-core.git:
    $ rgrep LICENSE_ *  | grep PN
you can see many examples of sub-packages with different licenses
than the main package. One example is:
    meta/recipes-support/gnutls/gnutls_3.6.13.bb<http://gnutls_3.6.13.bb>
I hope that can address the buildbot problem but I haven't tried it
myself yet.

BTW, Trevor has gotten the YP autobuilder going at Wind River and
he'll be sending a few documentation updates next week or so.
That may help in case you want to reproduce the YP AB test
infrastructure. I expect that you don't _have_ to do so but
I think it would be good if more contributing organizations did
have an instance with only limited builders of the YP AB so that
we can do more testing before Richard runs our changes through
the main system. Richard has cautioned that the YP AB has lots of
builders each of which has many cores but I hope that we can at least
do some AB checking ourselves.

../Randy


> |
>
>
> On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com<mailto:rahulk@mvista.com>
> <mailto:rahulk@mvista.com<mailto:rahulk@mvista.com>>> wrote:
>
>     Hi Richard/Alexander,
>
>     I am not able to understand how I can use the below file.
>     http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>
>     did you mean to say that i have to set MACRO in local.conf based on
>     this file.
>
>     *Thanks & Regards,*
>     Rahul Kumar
>     Software Engineer,Linux Solutions Engineering
>     Group,Montavista Software LLC
>     Email Id: rahulk@mvista.com<mailto:rahulk@mvista.com> <mailto:rahulk@mvista.com<mailto:rahulk@mvista.com>>
>     <https://plus.google.com/+CodeTwoSoftware>
>
>
>     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>     <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>
>     <mailto:richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>>> wrote:
>
>         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
>          > You need to look at configurations defined here:
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          > and replicate them locally. Then you can reproduce the
>         failures that
>          > the AB gets in those configurations.
>
>         That start of the failing logs on the autobuilder also list out the
>         configuration options for that build.
>
>         Cheers,
>
>         Richard
>
>
>
>


--
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 30459 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 13573 bytes --]

Hi Peter,

Thank you for the quick response.
I will work on your suggestion.but I need your confirmation on
LIC_FILES_CHKSUM also.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Tue, May 19, 2020 at 9:59 PM Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

> The jzlib license is a three clause BSD license, and so is the go/LICENSE,
> so you should be able to set LICENSE as:
>
>
>
> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>
>
>
> You also need to add:
>
>
>
> LICENSE_${PN} = "bzip2-1.0.6"
>
> LICENSE_${PN}-dev = "bzip2-1.0.6"
>
> LICENSE_${PN}-dbg = "bzip2-1.0.6"
>
> LICENSE_${PN}-doc = "bzip2-1.0.6"
>
> LICENSE_${PN}-src = "bzip2-1.0.6"
>
> LICENSE_libbz2 = "bzip2-1.0.6"
>
>
>
> so the non-ptest packages are not affected by the licenses for the ptest
> package.
>
>
>
> //Peter
>
>
>
> *From:* Rahul Kumar <rahulk@mvista.com>
> *Sent:* den 19 maj 2020 13:58
> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> *Cc:* Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin <
> alex.kanavin@gmail.com>; Richard Purdie <
> richard.purdie@linuxfoundation.org>; OE-core <
> openembedded-core@lists.openembedded.org>; Trevor Gamblin <
> trevor.gamblin@windriver.com>
> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>
>
>
> Hi Peter,
>
> I am sharing a few information related to bzip2-test source and licensing
> information.
> As per your suggestion and as per my understanding I added License to the
> bzip2 recipe file.
>
> bzip2-tests.git source tree structure is given below
> (here showing licence related fle, removed other file names )
>
> bzip2-tests.git/
> ├── commons-compress
> │   ├── LICENSE.txt
> │
> ├── dotnetzip
> │   ├── License.txt
> │   ├── License.zlib.txt
> |
> ├── go
> │   ├── LICENSE
> │
> ├── lbzip2
> ├── pyflate
> ├── README
> └── run-tests.sh
>
> source code link:
> https://sourceware.org/git/bzip2-tests.git
>
> bzip2-tests.git source contains
> 1) comman-commpress: which is Originally distributed under the Apache
> License Version 2.0.
>
> See LICENSE.txt
>
>
> 2) dotnetzip:
> (i)  The DotNetZip Library is distributed under the MicroSoft Public
> License
>     (Ms-PL) see the License.txt file.
> (ii) The BZ2 related resources are distributed under the licenses in
> License.zlib.txt.
>
> 3) go:
>
>  Go is distributed under a BSD-style license.
>  See the LICENSE file.
>
> 4) lbzip2:
> lbzip2 is free software: you can redistribute it and/or modify it under the
> terms of the GNU General Public License as published by the Free Software
> Foundation, either version 3 of the License, or (at your option) any later
> version
>
> 5) pyflate: You may use and distribute this code and documentation under
> any
>             DFSG-compatible license (eg. BSD, GNU GPLv2).
>
> 6) run-tests.sh: you can redistribute it and/or modify it under the terms
> of the GNU General Public License (GPL); either
>                  version 3, or (at your option) any later version.
>
>
> SO in recipe I added the License like below
> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> LIC_FILES_CHKSUM =
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
> \
>
> file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
> \ # For comman-commpress (Apache-2.0)
>
> file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f
> \      # For dotnetzip (Ms-PL)
>
> file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f
> \   # For dotnetzip  (jzlib +zlib)
>
> file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
>  # For go (BSD-style license)
>
> here I need few suggestion:
>
> 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
>    but not added LIC_FILES_CHKSUM for GPLv3 and BSD because
> bzip2-tests.git source code doesn't have GPLv3 and BSD License text file
> like other
>    directories.
>
> 2) License.zlib.txt: This is a combination of two licence jzlib and zlib.
> In meta/files/common-licenses Zlib license is available but not jzlib.
>    In this case how can I proceed?
>
> Kindly comment on this and feel free to point out if i am wrong at any
> place.
>
>
>
> *Thanks & Regards,*
>
> Rahul Kumar
>
> Software Engineer,Linux Solutions Engineering
>
> Group,Montavista Software LLC
>
> Email Id: rahulk@mvista.com
> <https://plus.google.com/+CodeTwoSoftware>
>
>
>
>
>
> On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt <
> peter.kjellerstedt@axis.com> wrote:
>
> As I wrote in my previous mail, when it comes to licenses, it is the
> distribution that is important. So if you build a package (bzip2-ptest)
> that includes code that is GPL-3.0, it does not matter if that code is only
> used as a binary blob, it is still distributed in the package, and thus the
> package needs to be covered by the GPL-3.0 license.
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org> *On Behalf Of *Rahul Kumar
> *Sent:* den 17 maj 2020 21:18
> *To:* Randy MacLeod <randy.macleod@windriver.com>
> *Cc:* Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie <
> richard.purdie@linuxfoundation.org>; OE-core <
> openembedded-core@lists.openembedded.org>; Trevor Gamblin <
> trevor.gamblin@windriver.com>
> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>
>
>
> Hi Randy,
>
> patch has been accepted by bzip2 community with additional changes.
>
> https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
>
>
> So I need your suggestion with respect to Yocto.
>
> Since required changes for ptest infrastructure is integrated to the
> bzip2-tests.git source code.
> So now we can just change the SRCREV with the latest commit instead of
> applying the patch to the bzip2-tests.git source code.
>
> And since we are just integrating the bzip2-tests source to the bzip2
> recipe and not modifying any file so i think no need to add any License for
> it.
>
>
> Now patch will look like
> =====================================================================
> --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> @@ -46,6 +46,7 @@ runtest:
>         else echo "FAIL: sample2 decompress"; fi
>         @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> decompress";\
>         else echo "FAIL: sample3 decompress"; fi
> +       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
>
>  install-ptest:
>         sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
> @@ -56,6 +57,7 @@ install-ptest:
>         cp $(srcdir)/sample1.bz2        $(DESTDIR)/
>         cp $(srcdir)/sample2.bz2        $(DESTDIR)/
>         cp $(srcdir)/sample3.bz2        $(DESTDIR)/
> +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
>         ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
>
>  install-exec-hook:
> diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> index d58f553..c5aa690 100644
> --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
>  LIC_FILES_CHKSUM = "
> file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
> "
>
>  SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \
> +           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests \
>             file://configure.ac;subdir=${BP} \
>             file://Makefile.am;subdir=${BP} \
>             file://run-ptest \
>             "
> +
>  SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
>  SRC_URI[sha256sum] =
> "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
>
> +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"  *<<
> this commit Id includes latest charges for ptest infrastruct.*
> +
>  UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
>
>  PACKAGES =+ "libbz2"
> @@ -39,7 +43,7 @@ do_install_ptest () {
>
>  FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
>
> -RDEPENDS_${PN}-ptest += "make"
> +RDEPENDS_${PN}-ptest += "make bash"
>
>  PROVIDES_append_class-native = " bzip2-replacement-native"
>  BBCLASSEXTEND = "native nativesdk"
>
> =================================================================================
>
> Kindly comment on it and feel free to point out, if i am wrong at any
> place.
>
>
>
> *Thanks & Regards,*
>
> Rahul Kumar
>
> Software Engineer,Linux Solutions Engineering
>
> Group,Montavista Software LLC
>
> Email Id: rahulk@mvista.com
> <https://plus.google.com/+CodeTwoSoftware>
>
>
>
>
>
> On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <randy.macleod@windriver.com>
> wrote:
>
> On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> > You need to first see from the failure page which configuration is
> > failing, for example non-gpl3 is one such.
> >
> > Then you find that configuration in config.json. The below should
> > hopefully be self-explanatory in how you should set up the build?
> >
> > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"], "MACHINE" :
> > "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
> > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'", "WARN_QA_remove =
> > 'incompatible-license'" ], "EXTRACMDS" : [
> > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >
> > |
> >
> > |
> > |
> >
> > |Alex
>
> Hi Rahul,
>
> Sorry for my late reply.
>
> The commit log for v2 is very good now!
> Thanks for incorporating my --pedantic suggestions. ;-)
>
> It seems that you need a perl dependency for something (docs?
>     $ cd .../bzip2.git
>     $ grep -r "perl " *
>     format.pl:#!/usr/bin/perl -w
>     README.XML.STUFF:It uses format.pl, a perl script...
>
> Then we need to figure out how to deal with the GPLv3 issue.
>
> The buildbot output can be tedious to figure out. I haven't really
> spent enough time plugging away at it to be proficient yet either.
> Have you been able to reproduce the problems that Richard reported?
> If not, and you've tried for a bit, then just say so and I'll try to
> help tomorrow or early next week.
>
> It looks like you are packaging the test code/data with the main package
> not in bzip2-ptest. Have a look at:
>     meta/recipes-support/libpcre/libpcre_8.44.bb
> for an example. There are many more.
> Also, if you look at oe-core.git:
>     $ rgrep LICENSE_ *  | grep PN
> you can see many examples of sub-packages with different licenses
> than the main package. One example is:
>     meta/recipes-support/gnutls/gnutls_3.6.13.bb
> I hope that can address the buildbot problem but I haven't tried it
> myself yet.
>
> BTW, Trevor has gotten the YP autobuilder going at Wind River and
> he'll be sending a few documentation updates next week or so.
> That may help in case you want to reproduce the YP AB test
> infrastructure. I expect that you don't _have_ to do so but
> I think it would be good if more contributing organizations did
> have an instance with only limited builders of the YP AB so that
> we can do more testing before Richard runs our changes through
> the main system. Richard has cautioned that the YP AB has lots of
> builders each of which has many cores but I hope that we can at least
> do some AB checking ourselves.
>
> ../Randy
>
>
> > |
> >
> >
> > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> > <mailto:rahulk@mvista.com>> wrote:
> >
> >     Hi Richard/Alexander,
> >
> >     I am not able to understand how I can use the below file.
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >
> >     did you mean to say that i have to set MACRO in local.conf based on
> >     this file.
> >
> >     *Thanks & Regards,*
> >     Rahul Kumar
> >     Software Engineer,Linux Solutions Engineering
> >     Group,Montavista Software LLC
> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >     <https://plus.google.com/+CodeTwoSoftware>
> >
> >
> >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >     <richard.purdie@linuxfoundation.org
> >     <mailto:richard.purdie@linuxfoundation.org>> wrote:
> >
> >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin wrote:
> >          > You need to look at configurations defined here:
> >          >
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >          > and replicate them locally. Then you can reproduce the
> >         failures that
> >          > the AB gets in those configurations.
> >
> >         That start of the failing logs on the autobuilder also list out
> the
> >         configuration options for that build.
> >
> >         Cheers,
> >
> >         Richard
> >
> >
> >
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
> 
>

[-- Attachment #2: Type: text/html, Size: 28652 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Randy MacLeod]

On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> The jzlib license is a three clause BSD license, and so is the 
> go/LICENSE, so you should be able to set LICENSE as:
> 
> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"

Peter,

I respectfully disagree.

The only source that is _executed_ in normal use by bzip2-test is
the run-tests.sh script that is licensed as GPLv3+

The other files, although they came from source packages,
are *only* used as  test data. The source code has been completely
stripped out, hasn't it?

If, instead of compressed data,
someone were to give me an image file covered by a creative common's
license and the image had a watermark that when extracted produced
file with source code with a FOO license, would you change the
package license to include FOO? In fact, we don't even look at
image file licensing let alone at embedded watermarks.


I'm not a lawyer so this is simply my opinion on the matter.
How do we come to an agreement?
I'd be happy to add a comment in the recipe explaining our position:

# This package contains a script and test data this is derived from
# other software packages as explained in the top level README.
# Although there are COPYING files explaining the license terms
# for each sub-directory, the files in each directory are only used
# as test data so the LICENSING terms do not appear to apply to
# the recipe as we ship it and have therefore NOT been incorporated
# into the bzip2-ptests recipe licensing tags.

I can consult with some intellectual property experts that I know
about this particular case if you like.

../Randy


> 
> You also need to add:
> 
> LICENSE_${PN} = "bzip2-1.0.6"
> 
> LICENSE_${PN}-dev = "bzip2-1.0.6"
> 
> LICENSE_${PN}-dbg = "bzip2-1.0.6"
> 
> LICENSE_${PN}-doc = "bzip2-1.0.6"
> 
> LICENSE_${PN}-src = "bzip2-1.0.6"
> 
> LICENSE_libbz2 = "bzip2-1.0.6"
> 
> so the non-ptest packages are not affected by the licenses for the ptest 
> package.
> 
> //Peter
> 
> *From:*Rahul Kumar <rahulk@mvista.com>
> *Sent:* den 19 maj 2020 13:58
> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> *Cc:* Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin 
> <alex.kanavin@gmail.com>; Richard Purdie 
> <richard.purdie@linuxfoundation.org>; OE-core 
> <openembedded-core@lists.openembedded.org>; Trevor Gamblin 
> <trevor.gamblin@windriver.com>
> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> 
> Hi Peter,
> 
> I am sharing a few information related to bzip2-test source and 
> licensing information.
> As per your suggestion and as per my understanding I added License to 
> the bzip2 recipe file.
> 
> bzip2-tests.git source tree structure is given below
> (here showing licence related fle, removed other file names )
> 
> bzip2-tests.git/
> ├──commons-compress
> │ ├──LICENSE.txt
> │
> ├──dotnetzip
> │ ├──License.txt
> │ ├──License.zlib.txt
> |
> ├──go
> │ ├──LICENSE
> │
> ├──lbzip2
> ├──pyflate
> ├──README
> └── run-tests.sh
> 
> source code link:
> https://sourceware.org/git/bzip2-tests.git
> 
> bzip2-tests.git source contains
> 1) comman-commpress: which is Originally distributed under the Apache 
> License Version 2.0.
> 
> See LICENSE.txt
> 
> 
> 2) dotnetzip:
> (i)  The DotNetZip Library is distributed under the MicroSoft Public License
>      (Ms-PL) see the License.txt file.
> (ii) The BZ2 related resources are distributed under the licenses in 
> License.zlib.txt.
> 
> 3) go:
> 
>   Go is distributed under a BSD-style license.
>   See the LICENSE file.
> 
> 4) lbzip2:
> lbzip2 is free software: you can redistribute it and/or modify it under the
> terms of the GNU General Public License as published by the Free Software
> Foundation, either version 3 of the License, or (at your option) any later
> version
> 
> 5) pyflate: You may use and distribute this code and documentation under any
>              DFSG-compatible license (eg. BSD, GNU GPLv2).
> 
> 6) run-tests.sh: you can redistribute it and/or modify it under the 
> terms of the GNU General Public License (GPL); either
>                   version 3, or (at your option) any later version.
> 
> 
> SO in recipe I added the License like below
> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> LIC_FILES_CHKSUM = 
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664 
> \
>                      
> file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327 
> \ # For comman-commpress (Apache-2.0)
>                      
> file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f 
> \      # For dotnetzip (Ms-PL)
>                      
> file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f 
> \   # For dotnetzip  (jzlib +zlib)
>                      
> file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \ 
>       # For go (BSD-style license)
> 
> here I need few suggestion:
> 
> 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
>     but not added LIC_FILES_CHKSUM for GPLv3 and BSD because 
> bzip2-tests.git source code doesn't have GPLv3 and BSD License text file 
> like other
>     directories.
> 
> 2) License.zlib.txt: This is a combination of two licence jzlib and 
> zlib. In meta/files/common-licenses Zlib license is available but not jzlib.
>     In this case how can I proceed?
> 
> Kindly comment on this and feel free to point out if i am wrong at any 
> place.
> 
> *Thanks & Regards,*
> 
> Rahul Kumar
> 
> Software Engineer,Linux Solutions Engineering
> 
> Group,Montavista Software LLC
> 
> Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> <https://plus.google.com/+CodeTwoSoftware>
> 
> On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt 
> <peter.kjellerstedt@axis.com <mailto:peter.kjellerstedt@axis.com>> wrote:
> 
>     As I wrote in my previous mail, when it comes to licenses, it is the
>     distribution that is important. So if you build a package
>     (bzip2-ptest) that includes code that is GPL-3.0, it does not matter
>     if that code is only used as a binary blob, it is still distributed
>     in the package, and thus the package needs to be covered by the
>     GPL-3.0 license.
> 
>     //Peter
> 
>     *From:*openembedded-core@lists.openembedded.org
>     <mailto:openembedded-core@lists.openembedded.org>
>     <openembedded-core@lists.openembedded.org
>     <mailto:openembedded-core@lists.openembedded.org>> *On Behalf Of
>     *Rahul Kumar
>     *Sent:* den 17 maj 2020 21:18
>     *To:* Randy MacLeod <randy.macleod@windriver.com
>     <mailto:randy.macleod@windriver.com>>
>     *Cc:* Alexander Kanavin <alex.kanavin@gmail.com
>     <mailto:alex.kanavin@gmail.com>>; Richard Purdie
>     <richard.purdie@linuxfoundation.org
>     <mailto:richard.purdie@linuxfoundation.org>>; OE-core
>     <openembedded-core@lists.openembedded.org
>     <mailto:openembedded-core@lists.openembedded.org>>; Trevor Gamblin
>     <trevor.gamblin@windriver.com <mailto:trevor.gamblin@windriver.com>>
>     *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> 
>     Hi Randy,
> 
>     patch has been accepted by bzip2 community with additional changes.
>     https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
> 
> 
>     So I need your suggestion with respect to Yocto.
> 
>     Since required changes for ptest infrastructure is integrated to the
>     bzip2-tests.git source code.
>     So now we can just change the SRCREV with the latest commit instead
>     of applying the patch to the bzip2-tests.git source code.
> 
>     And since we are just integrating the bzip2-tests source to the
>     bzip2 recipe and not modifying any file so i think no need to add
>     any License for it.
> 
> 
>     Now patch will look like
>     =====================================================================
>     --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
>     +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
>     @@ -46,6 +46,7 @@ runtest:
>              else echo "FAIL: sample2 decompress"; fi
>              @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
>     decompress";\
>              else echo "FAIL: sample3 decompress"; fi
>     +       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
> 
>       install-ptest:
>              sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
>     @@ -56,6 +57,7 @@ install-ptest:
>              cp $(srcdir)/sample1.bz2        $(DESTDIR)/
>              cp $(srcdir)/sample2.bz2        $(DESTDIR)/
>              cp $(srcdir)/sample3.bz2        $(DESTDIR)/
>     +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
>              ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
> 
>       install-exec-hook:
>     diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
>     <http://bzip2_1.0.8.bb> b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
>     <http://bzip2_1.0.8.bb>
>     index d58f553..c5aa690 100644
>     --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb <http://bzip2_1.0.8.bb>
>     +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb <http://bzip2_1.0.8.bb>
>     @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
>       LIC_FILES_CHKSUM =
>     "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"
> 
>       SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz
>     <https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz> \
>     +          
>     git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests
>     <http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
>                  file://configure.ac <http://configure.ac>;subdir=${BP} \
>                  file://Makefile.am;subdir=${BP} \
>                  file://run-ptest \
>                  "
>     +
>       SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
>       SRC_URI[sha256sum] =
>     "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
> 
>     +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0" *<<
>     this commit Id includes latest charges for ptest infrastruct.*
>     +
>       UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
> 
>       PACKAGES =+ "libbz2"
>     @@ -39,7 +43,7 @@ do_install_ptest () {
> 
>       FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
> 
>     -RDEPENDS_${PN}-ptest += "make"
>     +RDEPENDS_${PN}-ptest += "make bash"
> 
>       PROVIDES_append_class-native = " bzip2-replacement-native"
>       BBCLASSEXTEND = "native nativesdk"
>     =================================================================================
> 
>     Kindly comment on it and feel free to point out, if i am wrong at
>     any place.
> 
>     *Thanks & Regards,*
> 
>     Rahul Kumar
> 
>     Software Engineer,Linux Solutions Engineering
> 
>     Group,Montavista Software LLC
> 
>     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>     <https://plus.google.com/+CodeTwoSoftware>
> 
>     On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
>     <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
>     wrote:
> 
>         On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
>          > You need to first see from the failure page which
>         configuration is
>          > failing, for example non-gpl3 is one such.
>          >
>          > Then you find that configuration in config.json. The below
>         should
>          > hopefully be self-explanatory in how you should set up the build?
>          >
>          > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
>         "MACHINE" :
>          > "qemux86", "BBTARGETS" : "core-image-minimal
>         core-image-full-cmdline",
>          > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
>         "WARN_QA_remove =
>          > 'incompatible-license'" ], "EXTRACMDS" : [
>          > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>          >
>          > |
>          >
>          > |
>          > |
>          >
>          > |Alex
> 
>         Hi Rahul,
> 
>         Sorry for my late reply.
> 
>         The commit log for v2 is very good now!
>         Thanks for incorporating my --pedantic suggestions. ;-)
> 
>         It seems that you need a perl dependency for something (docs?
>              $ cd .../bzip2.git
>              $ grep -r "perl " *
>              format.pl:#!/usr/bin/perl -w
>              README.XML.STUFF:It uses format.pl <http://format.pl>, a
>         perl script...
> 
>         Then we need to figure out how to deal with the GPLv3 issue.
> 
>         The buildbot output can be tedious to figure out. I haven't really
>         spent enough time plugging away at it to be proficient yet either.
>         Have you been able to reproduce the problems that Richard reported?
>         If not, and you've tried for a bit, then just say so and I'll try to
>         help tomorrow or early next week.
> 
>         It looks like you are packaging the test code/data with the main
>         package
>         not in bzip2-ptest. Have a look at:
>              meta/recipes-support/libpcre/libpcre_8.44.bb
>         <http://libpcre_8.44.bb>
>         for an example. There are many more.
>         Also, if you look at oe-core.git:
>              $ rgrep LICENSE_ *  | grep PN
>         you can see many examples of sub-packages with different licenses
>         than the main package. One example is:
>              meta/recipes-support/gnutls/gnutls_3.6.13.bb
>         <http://gnutls_3.6.13.bb>
>         I hope that can address the buildbot problem but I haven't tried it
>         myself yet.
> 
>         BTW, Trevor has gotten the YP autobuilder going at Wind River and
>         he'll be sending a few documentation updates next week or so.
>         That may help in case you want to reproduce the YP AB test
>         infrastructure. I expect that you don't _have_ to do so but
>         I think it would be good if more contributing organizations did
>         have an instance with only limited builders of the YP AB so that
>         we can do more testing before Richard runs our changes through
>         the main system. Richard has cautioned that the YP AB has lots of
>         builders each of which has many cores but I hope that we can at
>         least
>         do some AB checking ourselves.
> 
>         ../Randy
> 
> 
>          > |
>          >
>          >
>          > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
>         <mailto:rahulk@mvista.com>
>          > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>> wrote:
>          >
>          >     Hi Richard/Alexander,
>          >
>          >     I am not able to understand how I can use the below file.
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          >
>          >     did you mean to say that i have to set MACRO in
>         local.conf based on
>          >     this file.
>          >
>          >     *Thanks & Regards,*
>          >     Rahul Kumar
>          >     Software Engineer,Linux Solutions Engineering
>          >     Group,Montavista Software LLC
>          >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>         <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
>          >     <https://plus.google.com/+CodeTwoSoftware>
>          >
>          >
>          >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>          >     <richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>
>          >     <mailto:richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>>> wrote:
>          >
>          >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
>         wrote:
>          >          > You need to look at configurations defined here:
>          >          >
>          >
>         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
>          >          > and replicate them locally. Then you can reproduce the
>          >         failures that
>          >          > the AB gets in those configurations.
>          >
>          >         That start of the failing logs on the autobuilder
>         also list out the
>          >         configuration options for that build.
>          >
>          >         Cheers,
>          >
>          >         Richard
>          >
>          >
>          >
>          >
> 
> 
>         -- 
>         # Randy MacLeod
>         # Wind River Linux
> 


-- 
# Randy MacLeod
# Wind River Linux

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Khem Raj]

On Tue, May 19, 2020 at 2:46 PM Randy MacLeod
<randy.macleod@windriver.com> wrote:
>
> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> > The jzlib license is a three clause BSD license, and so is the
> > go/LICENSE, so you should be able to set LICENSE as:
> >
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>
> Peter,
>
> I respectfully disagree.
>
> The only source that is _executed_ in normal use by bzip2-test is
> the run-tests.sh script that is licensed as GPLv3+
>
> The other files, although they came from source packages,
> are *only* used as  test data. The source code has been completely
> stripped out, hasn't it?
>
> If, instead of compressed data,
> someone were to give me an image file covered by a creative common's
> license and the image had a watermark that when extracted produced
> file with source code with a FOO license, would you change the
> package license to include FOO? In fact, we don't even look at
> image file licensing let alone at embedded watermarks.
>
>
> I'm not a lawyer so this is simply my opinion on the matter.
> How do we come to an agreement?
> I'd be happy to add a comment in the recipe explaining our position:
>
> # This package contains a script and test data this is derived from
> # other software packages as explained in the top level README.
> # Although there are COPYING files explaining the license terms
> # for each sub-directory, the files in each directory are only used
> # as test data so the LICENSING terms do not appear to apply to
> # the recipe as we ship it and have therefore NOT been incorporated
> # into the bzip2-ptests recipe licensing tags.

a simple question is, are you distributing this shell script or not.
If you are then you will fall under
the all of the license obligations of the governing license for
distributing it.

As far as image license it concerned, then we generate a separate
license manifest for images
which comprise of package licenses that form the image.

>
> I can consult with some intellectual property experts that I know
> about this particular case if you like.
>
> ../Randy
>
>
> >
> > You also need to add:
> >
> > LICENSE_${PN} = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dev = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dbg = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-doc = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-src = "bzip2-1.0.6"
> >
> > LICENSE_libbz2 = "bzip2-1.0.6"
> >
> > so the non-ptest packages are not affected by the licenses for the ptest
> > package.
> >
> > //Peter
> >
> > *From:*Rahul Kumar <rahulk@mvista.com>
> > *Sent:* den 19 maj 2020 13:58
> > *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > *Cc:* Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin
> > <alex.kanavin@gmail.com>; Richard Purdie
> > <richard.purdie@linuxfoundation.org>; OE-core
> > <openembedded-core@lists.openembedded.org>; Trevor Gamblin
> > <trevor.gamblin@windriver.com>
> > *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >
> > Hi Peter,
> >
> > I am sharing a few information related to bzip2-test source and
> > licensing information.
> > As per your suggestion and as per my understanding I added License to
> > the bzip2 recipe file.
> >
> > bzip2-tests.git source tree structure is given below
> > (here showing licence related fle, removed other file names )
> >
> > bzip2-tests.git/
> > ├──commons-compress
> > │ ├──LICENSE.txt
> > │
> > ├──dotnetzip
> > │ ├──License.txt
> > │ ├──License.zlib.txt
> > |
> > ├──go
> > │ ├──LICENSE
> > │
> > ├──lbzip2
> > ├──pyflate
> > ├──README
> > └── run-tests.sh
> >
> > source code link:
> > https://sourceware.org/git/bzip2-tests.git
> >
> > bzip2-tests.git source contains
> > 1) comman-commpress: which is Originally distributed under the Apache
> > License Version 2.0.
> >
> > See LICENSE.txt
> >
> >
> > 2) dotnetzip:
> > (i)  The DotNetZip Library is distributed under the MicroSoft Public License
> >      (Ms-PL) see the License.txt file.
> > (ii) The BZ2 related resources are distributed under the licenses in
> > License.zlib.txt.
> >
> > 3) go:
> >
> >   Go is distributed under a BSD-style license.
> >   See the LICENSE file.
> >
> > 4) lbzip2:
> > lbzip2 is free software: you can redistribute it and/or modify it under the
> > terms of the GNU General Public License as published by the Free Software
> > Foundation, either version 3 of the License, or (at your option) any later
> > version
> >
> > 5) pyflate: You may use and distribute this code and documentation under any
> >              DFSG-compatible license (eg. BSD, GNU GPLv2).
> >
> > 6) run-tests.sh: you can redistribute it and/or modify it under the
> > terms of the GNU General Public License (GPL); either
> >                   version 3, or (at your option) any later version.
> >
> >
> > SO in recipe I added the License like below
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> > LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> > LIC_FILES_CHKSUM =
> > "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
> > \
> >
> > file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
> > \ # For comman-commpress (Apache-2.0)
> >
> > file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f
> > \      # For dotnetzip (Ms-PL)
> >
> > file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f
> > \   # For dotnetzip  (jzlib +zlib)
> >
> > file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
> >       # For go (BSD-style license)
> >
> > here I need few suggestion:
> >
> > 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
> >     but not added LIC_FILES_CHKSUM for GPLv3 and BSD because
> > bzip2-tests.git source code doesn't have GPLv3 and BSD License text file
> > like other
> >     directories.
> >
> > 2) License.zlib.txt: This is a combination of two licence jzlib and
> > zlib. In meta/files/common-licenses Zlib license is available but not jzlib.
> >     In this case how can I proceed?
> >
> > Kindly comment on this and feel free to point out if i am wrong at any
> > place.
> >
> > *Thanks & Regards,*
> >
> > Rahul Kumar
> >
> > Software Engineer,Linux Solutions Engineering
> >
> > Group,Montavista Software LLC
> >
> > Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> > <https://plus.google.com/+CodeTwoSoftware>
> >
> > On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt
> > <peter.kjellerstedt@axis.com <mailto:peter.kjellerstedt@axis.com>> wrote:
> >
> >     As I wrote in my previous mail, when it comes to licenses, it is the
> >     distribution that is important. So if you build a package
> >     (bzip2-ptest) that includes code that is GPL-3.0, it does not matter
> >     if that code is only used as a binary blob, it is still distributed
> >     in the package, and thus the package needs to be covered by the
> >     GPL-3.0 license.
> >
> >     //Peter
> >
> >     *From:*openembedded-core@lists.openembedded.org
> >     <mailto:openembedded-core@lists.openembedded.org>
> >     <openembedded-core@lists.openembedded.org
> >     <mailto:openembedded-core@lists.openembedded.org>> *On Behalf Of
> >     *Rahul Kumar
> >     *Sent:* den 17 maj 2020 21:18
> >     *To:* Randy MacLeod <randy.macleod@windriver.com
> >     <mailto:randy.macleod@windriver.com>>
> >     *Cc:* Alexander Kanavin <alex.kanavin@gmail.com
> >     <mailto:alex.kanavin@gmail.com>>; Richard Purdie
> >     <richard.purdie@linuxfoundation.org
> >     <mailto:richard.purdie@linuxfoundation.org>>; OE-core
> >     <openembedded-core@lists.openembedded.org
> >     <mailto:openembedded-core@lists.openembedded.org>>; Trevor Gamblin
> >     <trevor.gamblin@windriver.com <mailto:trevor.gamblin@windriver.com>>
> >     *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >
> >     Hi Randy,
> >
> >     patch has been accepted by bzip2 community with additional changes.
> >     https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
> >
> >
> >     So I need your suggestion with respect to Yocto.
> >
> >     Since required changes for ptest infrastructure is integrated to the
> >     bzip2-tests.git source code.
> >     So now we can just change the SRCREV with the latest commit instead
> >     of applying the patch to the bzip2-tests.git source code.
> >
> >     And since we are just integrating the bzip2-tests source to the
> >     bzip2 recipe and not modifying any file so i think no need to add
> >     any License for it.
> >
> >
> >     Now patch will look like
> >     =====================================================================
> >     --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> >     +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> >     @@ -46,6 +46,7 @@ runtest:
> >              else echo "FAIL: sample2 decompress"; fi
> >              @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> >     decompress";\
> >              else echo "FAIL: sample3 decompress"; fi
> >     +       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
> >
> >       install-ptest:
> >              sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
> >     @@ -56,6 +57,7 @@ install-ptest:
> >              cp $(srcdir)/sample1.bz2        $(DESTDIR)/
> >              cp $(srcdir)/sample2.bz2        $(DESTDIR)/
> >              cp $(srcdir)/sample3.bz2        $(DESTDIR)/
> >     +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
> >              ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
> >
> >       install-exec-hook:
> >     diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> >     <http://bzip2_1.0.8.bb> b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> >     <http://bzip2_1.0.8.bb>
> >     index d58f553..c5aa690 100644
> >     --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb <http://bzip2_1.0.8.bb>
> >     +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb <http://bzip2_1.0.8.bb>
> >     @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
> >       LIC_FILES_CHKSUM =
> >     "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"
> >
> >       SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz
> >     <https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz> \
> >     +
> >     git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests
> >     <http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
> >                  file://configure.ac <http://configure.ac>;subdir=${BP} \
> >                  file://Makefile.am;subdir=${BP} \
> >                  file://run-ptest \
> >                  "
> >     +
> >       SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
> >       SRC_URI[sha256sum] =
> >     "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
> >
> >     +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0" *<<
> >     this commit Id includes latest charges for ptest infrastruct.*
> >     +
> >       UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
> >
> >       PACKAGES =+ "libbz2"
> >     @@ -39,7 +43,7 @@ do_install_ptest () {
> >
> >       FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
> >
> >     -RDEPENDS_${PN}-ptest += "make"
> >     +RDEPENDS_${PN}-ptest += "make bash"
> >
> >       PROVIDES_append_class-native = " bzip2-replacement-native"
> >       BBCLASSEXTEND = "native nativesdk"
> >     =================================================================================
> >
> >     Kindly comment on it and feel free to point out, if i am wrong at
> >     any place.
> >
> >     *Thanks & Regards,*
> >
> >     Rahul Kumar
> >
> >     Software Engineer,Linux Solutions Engineering
> >
> >     Group,Montavista Software LLC
> >
> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >     <https://plus.google.com/+CodeTwoSoftware>
> >
> >     On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
> >     <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
> >     wrote:
> >
> >         On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> >          > You need to first see from the failure page which
> >         configuration is
> >          > failing, for example non-gpl3 is one such.
> >          >
> >          > Then you find that configuration in config.json. The below
> >         should
> >          > hopefully be self-explanatory in how you should set up the build?
> >          >
> >          > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
> >         "MACHINE" :
> >          > "qemux86", "BBTARGETS" : "core-image-minimal
> >         core-image-full-cmdline",
> >          > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
> >         "WARN_QA_remove =
> >          > 'incompatible-license'" ], "EXTRACMDS" : [
> >          > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >          >
> >          > |
> >          >
> >          > |
> >          > |
> >          >
> >          > |Alex
> >
> >         Hi Rahul,
> >
> >         Sorry for my late reply.
> >
> >         The commit log for v2 is very good now!
> >         Thanks for incorporating my --pedantic suggestions. ;-)
> >
> >         It seems that you need a perl dependency for something (docs?
> >              $ cd .../bzip2.git
> >              $ grep -r "perl " *
> >              format.pl:#!/usr/bin/perl -w
> >              README.XML.STUFF:It uses format.pl <http://format.pl>, a
> >         perl script...
> >
> >         Then we need to figure out how to deal with the GPLv3 issue.
> >
> >         The buildbot output can be tedious to figure out. I haven't really
> >         spent enough time plugging away at it to be proficient yet either.
> >         Have you been able to reproduce the problems that Richard reported?
> >         If not, and you've tried for a bit, then just say so and I'll try to
> >         help tomorrow or early next week.
> >
> >         It looks like you are packaging the test code/data with the main
> >         package
> >         not in bzip2-ptest. Have a look at:
> >              meta/recipes-support/libpcre/libpcre_8.44.bb
> >         <http://libpcre_8.44.bb>
> >         for an example. There are many more.
> >         Also, if you look at oe-core.git:
> >              $ rgrep LICENSE_ *  | grep PN
> >         you can see many examples of sub-packages with different licenses
> >         than the main package. One example is:
> >              meta/recipes-support/gnutls/gnutls_3.6.13.bb
> >         <http://gnutls_3.6.13.bb>
> >         I hope that can address the buildbot problem but I haven't tried it
> >         myself yet.
> >
> >         BTW, Trevor has gotten the YP autobuilder going at Wind River and
> >         he'll be sending a few documentation updates next week or so.
> >         That may help in case you want to reproduce the YP AB test
> >         infrastructure. I expect that you don't _have_ to do so but
> >         I think it would be good if more contributing organizations did
> >         have an instance with only limited builders of the YP AB so that
> >         we can do more testing before Richard runs our changes through
> >         the main system. Richard has cautioned that the YP AB has lots of
> >         builders each of which has many cores but I hope that we can at
> >         least
> >         do some AB checking ourselves.
> >
> >         ../Randy
> >
> >
> >          > |
> >          >
> >          >
> >          > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> >         <mailto:rahulk@mvista.com>
> >          > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>> wrote:
> >          >
> >          >     Hi Richard/Alexander,
> >          >
> >          >     I am not able to understand how I can use the below file.
> >          >
> >         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >          >
> >          >     did you mean to say that i have to set MACRO in
> >         local.conf based on
> >          >     this file.
> >          >
> >          >     *Thanks & Regards,*
> >          >     Rahul Kumar
> >          >     Software Engineer,Linux Solutions Engineering
> >          >     Group,Montavista Software LLC
> >          >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >         <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
> >          >     <https://plus.google.com/+CodeTwoSoftware>
> >          >
> >          >
> >          >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >          >     <richard.purdie@linuxfoundation.org
> >         <mailto:richard.purdie@linuxfoundation.org>
> >          >     <mailto:richard.purdie@linuxfoundation.org
> >         <mailto:richard.purdie@linuxfoundation.org>>> wrote:
> >          >
> >          >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
> >         wrote:
> >          >          > You need to look at configurations defined here:
> >          >          >
> >          >
> >         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json
> >          >          > and replicate them locally. Then you can reproduce the
> >          >         failures that
> >          >          > the AB gets in those configurations.
> >          >
> >          >         That start of the failing logs on the autobuilder
> >         also list out the
> >          >         configuration options for that build.
> >          >
> >          >         Cheers,
> >          >
> >          >         Richard
> >          >
> >          >
> >          >
> >          >
> >
> >
> >         --
> >         # Randy MacLeod
> >         # Wind River Linux
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
> 

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Peter Kjellerstedt]

> -----Original Message-----
> From: Randy MacLeod <randy.macleod@windriver.com>
> Sent: den 19 maj 2020 23:45
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Rahul Kumar
> <rahulk@mvista.com>
> Cc: Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie
> <richard.purdie@linuxfoundation.org>; OE-core <openembedded-
> core@lists.openembedded.org>; Trevor Gamblin
> <trevor.gamblin@windriver.com>
> Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> 
> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> > The jzlib license is a three clause BSD license, and so is the
> > go/LICENSE, so you should be able to set LICENSE as:
> >
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
> 
> Peter,
> 
> I respectfully disagree.
> 
> The only source that is _executed_ in normal use by bzip2-test is
> the run-tests.sh script that is licensed as GPLv3+

Well, I am definitely not a lawyer either, but I am pretty sure that 
whether something that is distributed under a certain license is 
executed or not is irrelevant (unless of course the license covers 
execution of the code).

> The other files, although they came from source packages,
> are *only* used as  test data. The source code has been completely
> stripped out, hasn't it?

Given that they were originally distributed in an archive together 
with a LICENSE/COPYING/similar file covering the entire archive, 
those files are still covered by that license even if they are not 
source files per se.

> If, instead of compressed data,
> someone were to give me an image file covered by a creative common's
> license and the image had a watermark that when extracted produced
> file with source code with a FOO license, would you change the
> package license to include FOO? In fact, we don't even look at
> image file licensing let alone at embedded watermarks.

Well, if there is a file distributed in the picture (not using the 
word "image" here to avoid confusing the discussion any more) in the 
form of a watermark, then that is no different from distributing it 
as part of a tar.gz file (albeit a bit unusual). Whatever license 
that file is covered by still applies in both cases.

Actually, here is something to think about. I recently read an 
article published by the Linux Foundation called "Docker Containers 
for Legal Professionals". [1] There they discussed the distribution 
of Docker images. Consider this, you take an existing Docker image, 
e.g., fedora:32, and remove everything that is covered by GPL-3.0 
(not sure how to actually accomplish that, but anyway) and then you 
distribute this new Docker image to someone. Does this mean that 
GPL-3.0 covered code is being distributed? The answer is yes. 
Because of the way Docker images are made up from layers, you need 
to adhere to the licenses covering everything in all layers, not 
just the final result. And somewhere down the stack of layers 
making up your Docker image is still all of that GPL-3.0 code 
that you removed in a higher layer.

> I'm not a lawyer so this is simply my opinion on the matter.
> How do we come to an agreement?
> I'd be happy to add a comment in the recipe explaining our position:
> 
> # This package contains a script and test data this is derived from
> # other software packages as explained in the top level README.
> # Although there are COPYING files explaining the license terms
> # for each sub-directory, the files in each directory are only used
> # as test data so the LICENSING terms do not appear to apply to
> # the recipe as we ship it and have therefore NOT been incorporated
> # into the bzip2-ptests recipe licensing tags.

I would be very worried seeing such a statement, and I believe any 
lawyer would too.

> I can consult with some intellectual property experts that I know
> about this particular case if you like.

If you have the possibility to do so, I think it may be a good idea.

> ../Randy

//Peter

[1] https://www.linuxfoundation.org/wp-content/uploads/2020/04/Docker-Containers-for-Legal-Professionals-Whitepaper_v4.ac_-3.pdf

> > You also need to add:
> >
> > LICENSE_${PN} = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dev = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dbg = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-doc = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-src = "bzip2-1.0.6"
> >
> > LICENSE_libbz2 = "bzip2-1.0.6"
> >
> > so the non-ptest packages are not affected by the licenses for the
> ptest
> > package.
> >
> > //Peter
> >
> > *From:*Rahul Kumar <rahulk@mvista.com>
> > *Sent:* den 19 maj 2020 13:58
> > *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > *Cc:* Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin
> > <alex.kanavin@gmail.com>; Richard Purdie
> > <richard.purdie@linuxfoundation.org>; OE-core
> > <openembedded-core@lists.openembedded.org>; Trevor Gamblin
> > <trevor.gamblin@windriver.com>
> > *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >
> > Hi Peter,
> >
> > I am sharing a few information related to bzip2-test source and
> > licensing information.
> > As per your suggestion and as per my understanding I added License to
> > the bzip2 recipe file.
> >
> > bzip2-tests.git source tree structure is given below
> > (here showing licence related fle, removed other file names )
> >
> > bzip2-tests.git/
> > ├──commons-compress
> > │ ├──LICENSE.txt
> > │
> > ├──dotnetzip
> > │ ├──License.txt
> > │ ├──License.zlib.txt
> > |
> > ├──go
> > │ ├──LICENSE
> > │
> > ├──lbzip2
> > ├──pyflate
> > ├──README
> > └── run-tests.sh
> >
> > source code link:
> > https://sourceware.org/git/bzip2-tests.git
> >
> > bzip2-tests.git source contains
> > 1) comman-commpress: which is Originally distributed under the Apache
> > License Version 2.0.
> >
> > See LICENSE.txt
> >
> >
> > 2) dotnetzip:
> > (i)  The DotNetZip Library is distributed under the MicroSoft Public
> License
> >      (Ms-PL) see the License.txt file.
> > (ii) The BZ2 related resources are distributed under the licenses in
> > License.zlib.txt.
> >
> > 3) go:
> >
> >   Go is distributed under a BSD-style license.
> >   See the LICENSE file.
> >
> > 4) lbzip2:
> > lbzip2 is free software: you can redistribute it and/or modify it under
> the
> > terms of the GNU General Public License as published by the Free
> Software
> > Foundation, either version 3 of the License, or (at your option) any
> later
> > version
> >
> > 5) pyflate: You may use and distribute this code and documentation
> under any
> >              DFSG-compatible license (eg. BSD, GNU GPLv2).
> >
> > 6) run-tests.sh: you can redistribute it and/or modify it under the
> > terms of the GNU General Public License (GPL); either
> >                   version 3, or (at your option) any later version.
> >
> >
> > SO in recipe I added the License like below
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> > LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> > LIC_FILES_CHKSUM =
> >
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
> 64
> > \
> >
> > file://${WORKDIR}/git/commons-
> compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
> > \ # For comman-commpress (Apache-2.0)
> >
> >
> file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff
> 352a54f
> > \      # For dotnetzip (Ms-PL)
> >
> >
> file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b
> 79e6de0a029f
> > \   # For dotnetzip  (jzlib +zlib)
> >
> > file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
> >       # For go (BSD-style license)
> >
> > here I need few suggestion:
> >
> > 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-
> ptest.
> >     but not added LIC_FILES_CHKSUM for GPLv3 and BSD because
> > bzip2-tests.git source code doesn't have GPLv3 and BSD License text
> file
> > like other
> >     directories.
> >
> > 2) License.zlib.txt: This is a combination of two licence jzlib and
> > zlib. In meta/files/common-licenses Zlib license is available but not
> jzlib.
> >     In this case how can I proceed?
> >
> > Kindly comment on this and feel free to point out if i am wrong at any
> > place.
> >
> > *Thanks & Regards,*
> >
> > Rahul Kumar
> >
> > Software Engineer,Linux Solutions Engineering
> >
> > Group,Montavista Software LLC
> >
> > Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> > <https://plus.google.com/+CodeTwoSoftware>
> >
> > On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt
> > <peter.kjellerstedt@axis.com <mailto:peter.kjellerstedt@axis.com>>
> wrote:
> >
> >     As I wrote in my previous mail, when it comes to licenses, it is
> the
> >     distribution that is important. So if you build a package
> >     (bzip2-ptest) that includes code that is GPL-3.0, it does not
> matter
> >     if that code is only used as a binary blob, it is still distributed
> >     in the package, and thus the package needs to be covered by the
> >     GPL-3.0 license.
> >
> >     //Peter
> >
> >     *From:*openembedded-core@lists.openembedded.org
> >     <mailto:openembedded-core@lists.openembedded.org>
> >     <openembedded-core@lists.openembedded.org
> >     <mailto:openembedded-core@lists.openembedded.org>> *On Behalf Of
> >     *Rahul Kumar
> >     *Sent:* den 17 maj 2020 21:18
> >     *To:* Randy MacLeod <randy.macleod@windriver.com
> >     <mailto:randy.macleod@windriver.com>>
> >     *Cc:* Alexander Kanavin <alex.kanavin@gmail.com
> >     <mailto:alex.kanavin@gmail.com>>; Richard Purdie
> >     <richard.purdie@linuxfoundation.org
> >     <mailto:richard.purdie@linuxfoundation.org>>; OE-core
> >     <openembedded-core@lists.openembedded.org
> >     <mailto:openembedded-core@lists.openembedded.org>>; Trevor Gamblin
> >     <trevor.gamblin@windriver.com
> <mailto:trevor.gamblin@windriver.com>>
> >     *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >
> >     Hi Randy,
> >
> >     patch has been accepted by bzip2 community with additional changes.
> >     https://sourceware.org/git/?p=bzip2-
> tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
> >
> >
> >     So I need your suggestion with respect to Yocto.
> >
> >     Since required changes for ptest infrastructure is integrated to
> the
> >     bzip2-tests.git source code.
> >     So now we can just change the SRCREV with the latest commit instead
> >     of applying the patch to the bzip2-tests.git source code.
> >
> >     And since we are just integrating the bzip2-tests source to the
> >     bzip2 recipe and not modifying any file so i think no need to add
> >     any License for it.
> >
> >
> >     Now patch will look like
> >
> =====================================================================
> >     --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> >     +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> >     @@ -46,6 +46,7 @@ runtest:
> >              else echo "FAIL: sample2 decompress"; fi
> >              @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> >     decompress";\
> >              else echo "FAIL: sample3 decompress"; fi
> >     +       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
> >
> >       install-ptest:
> >              sed  -n '/^runtest:/,/^install-ptest:/{/^install-
> ptest:/!p}' \
> >     @@ -56,6 +57,7 @@ install-ptest:
> >              cp $(srcdir)/sample1.bz2        $(DESTDIR)/
> >              cp $(srcdir)/sample2.bz2        $(DESTDIR)/
> >              cp $(srcdir)/sample3.bz2        $(DESTDIR)/
> >     +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
> >              ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
> >
> >       install-exec-hook:
> >     diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> >     <http://bzip2_1.0.8.bb> b/meta/recipes-
> extended/bzip2/bzip2_1.0.8.bb
> >     <http://bzip2_1.0.8.bb>
> >     index d58f553..c5aa690 100644
> >     --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> <http://bzip2_1.0.8.bb>
> >     +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> <http://bzip2_1.0.8.bb>
> >     @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
> >       LIC_FILES_CHKSUM =
> >
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
> 64"
> >
> >       SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz
> >     <https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz>
> \
> >     +
> >     git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests
> >     <http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
> >                  file://configure.ac <http://configure.ac>;subdir=${BP}
> \
> >                  file://Makefile.am;subdir=${BP} \
> >                  file://run-ptest \
> >                  "
> >     +
> >       SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
> >       SRC_URI[sha256sum] =
> >     "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
> >
> >     +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"
> *<<
> >     this commit Id includes latest charges for ptest infrastruct.*
> >     +
> >       UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
> >
> >       PACKAGES =+ "libbz2"
> >     @@ -39,7 +43,7 @@ do_install_ptest () {
> >
> >       FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
> >
> >     -RDEPENDS_${PN}-ptest += "make"
> >     +RDEPENDS_${PN}-ptest += "make bash"
> >
> >       PROVIDES_append_class-native = " bzip2-replacement-native"
> >       BBCLASSEXTEND = "native nativesdk"
> >
> =========================================================================
> ========
> >
> >     Kindly comment on it and feel free to point out, if i am wrong at
> >     any place.
> >
> >     *Thanks & Regards,*
> >
> >     Rahul Kumar
> >
> >     Software Engineer,Linux Solutions Engineering
> >
> >     Group,Montavista Software LLC
> >
> >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >     <https://plus.google.com/+CodeTwoSoftware>
> >
> >     On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
> >     <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
> >     wrote:
> >
> >         On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> >          > You need to first see from the failure page which
> >         configuration is
> >          > failing, for example non-gpl3 is one such.
> >          >
> >          > Then you find that configuration in config.json. The below
> >         should
> >          > hopefully be self-explanatory in how you should set up the
> build?
> >          >
> >          > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
> >         "MACHINE" :
> >          > "qemux86", "BBTARGETS" : "core-image-minimal
> >         core-image-full-cmdline",
> >          > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
> >         "WARN_QA_remove =
> >          > 'incompatible-license'" ], "EXTRACMDS" : [
> >          > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >          >
> >          > |
> >          >
> >          > |
> >          > |
> >          >
> >          > |Alex
> >
> >         Hi Rahul,
> >
> >         Sorry for my late reply.
> >
> >         The commit log for v2 is very good now!
> >         Thanks for incorporating my --pedantic suggestions. ;-)
> >
> >         It seems that you need a perl dependency for something (docs?
> >              $ cd .../bzip2.git
> >              $ grep -r "perl " *
> >              format.pl:#!/usr/bin/perl -w
> >              README.XML.STUFF:It uses format.pl <http://format.pl>, a
> >         perl script...
> >
> >         Then we need to figure out how to deal with the GPLv3 issue.
> >
> >         The buildbot output can be tedious to figure out. I haven't
> really
> >         spent enough time plugging away at it to be proficient yet
> either.
> >         Have you been able to reproduce the problems that Richard
> reported?
> >         If not, and you've tried for a bit, then just say so and I'll
> try to
> >         help tomorrow or early next week.
> >
> >         It looks like you are packaging the test code/data with the
> main
> >         package
> >         not in bzip2-ptest. Have a look at:
> >              meta/recipes-support/libpcre/libpcre_8.44.bb
> >         <http://libpcre_8.44.bb>
> >         for an example. There are many more.
> >         Also, if you look at oe-core.git:
> >              $ rgrep LICENSE_ *  | grep PN
> >         you can see many examples of sub-packages with different
> licenses
> >         than the main package. One example is:
> >              meta/recipes-support/gnutls/gnutls_3.6.13.bb
> >         <http://gnutls_3.6.13.bb>
> >         I hope that can address the buildbot problem but I haven't
> tried it
> >         myself yet.
> >
> >         BTW, Trevor has gotten the YP autobuilder going at Wind River
> and
> >         he'll be sending a few documentation updates next week or so.
> >         That may help in case you want to reproduce the YP AB test
> >         infrastructure. I expect that you don't _have_ to do so but
> >         I think it would be good if more contributing organizations did
> >         have an instance with only limited builders of the YP AB so
> that
> >         we can do more testing before Richard runs our changes through
> >         the main system. Richard has cautioned that the YP AB has lots
> of
> >         builders each of which has many cores but I hope that we can at
> >         least
> >         do some AB checking ourselves.
> >
> >         ../Randy
> >
> >
> >          > |
> >          >
> >          >
> >          > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
> >         <mailto:rahulk@mvista.com>
> >          > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>>
> wrote:
> >          >
> >          >     Hi Richard/Alexander,
> >          >
> >          >     I am not able to understand how I can use the below
> file.
> >          >
> >         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-
> helper/tree/config.json
> >          >
> >          >     did you mean to say that i have to set MACRO in
> >         local.conf based on
> >          >     this file.
> >          >
> >          >     *Thanks & Regards,*
> >          >     Rahul Kumar
> >          >     Software Engineer,Linux Solutions Engineering
> >          >     Group,Montavista Software LLC
> >          >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >         <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
> >          >     <https://plus.google.com/+CodeTwoSoftware>
> >          >
> >          >
> >          >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >          >     <richard.purdie@linuxfoundation.org
> >         <mailto:richard.purdie@linuxfoundation.org>
> >          >     <mailto:richard.purdie@linuxfoundation.org
> >         <mailto:richard.purdie@linuxfoundation.org>>> wrote:
> >          >
> >          >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
> >         wrote:
> >          >          > You need to look at configurations defined here:
> >          >          >
> >          >
> >         http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-
> helper/tree/config.json
> >          >          > and replicate them locally. Then you can
> reproduce the
> >          >         failures that
> >          >          > the AB gets in those configurations.
> >          >
> >          >         That start of the failing logs on the autobuilder
> >         also list out the
> >          >         configuration options for that build.
> >          >
> >          >         Cheers,
> >          >
> >          >         Richard
> >          >
> >          >
> >          >
> >          >
> >
> >
> >         --
> >         # Randy MacLeod
> >         # Wind River Linux
> >
> 
> 
> --
> # Randy MacLeod
> # Wind River Linux

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Randy MacLeod]

On 2020-05-19 8:06 p.m., Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: Randy MacLeod <randy.macleod@windriver.com>
>> Sent: den 19 maj 2020 23:45
>> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Rahul Kumar
>> <rahulk@mvista.com>
>> Cc: Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie
>> <richard.purdie@linuxfoundation.org>; OE-core <openembedded-
>> core@lists.openembedded.org>; Trevor Gamblin
>> <trevor.gamblin@windriver.com>
>> Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>>
>> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
>>> The jzlib license is a three clause BSD license, and so is the
>>> go/LICENSE, so you should be able to set LICENSE as:
>>>
>>> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>>
>> Peter,
>>
>> I respectfully disagree.
>>
>> The only source that is _executed_ in normal use by bzip2-test is
>> the run-tests.sh script that is licensed as GPLv3+
> 
> Well, I am definitely not a lawyer either, 

Phew! :)

> but I am pretty sure that
> whether something that is distributed under a certain license is
> executed or not is irrelevant (unless of course the license covers
> execution of the code).

There's a difference between a legal report and the Yocto LICENSE tag.
The Yocto tag is meant to be an over-all/community acknowledged license
for the _code_ in the package that ends up as executable / script on
the target. We should probably document this in greater detail, perhaps
in:
 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-LICENSE

A more comprehensive analysis usually includes a file by file
IP report often accompanied by a summary generated by an IP expert.

> 
>> The other files, although they came from source packages,
>> are *only* used as  test data. The source code has been completely
>> stripped out, hasn't it?
> 
> Given that they were originally distributed in an archive together
> with a LICENSE/COPYING/similar file covering the entire archive,
> those files are still covered by that license even if they are not
> source files per se.


Licenses describe the terms that apply to items that are covered
under copyright. Data generally can not be copyrighted.

 From my IP contact:

---

In order for something to be copyrightable three requirements
must be satisfied:

  1. The work represents a creative form of expression
     (basic facts do not represent a creative form of expression)

  2. The work is original (novel) – not copied from someone else.
     Two different people could come up with similar creative forms
     of expression. They just can’t copy from someone else.

  3. It must be put in tangible form (e.g., written, digital, …).
     Someone can’t just claim it resides inside their head.



Data as a general is not copyrightable because it fails number 1. 
However if someone can argue that a certain compilation of data 
represents some form of creative expression, they might have a case. 
This is discussed in the first two paragraphs here:

    https://libguides.library.kent.edu/data-management/copyright


Data can be protected under patent or trade secret law but different 
requirements apply and a different license would need to be created. 
Open Source licenses are largely copyright licenses. Although sometimes 
they include patent terms, they are generally not considered patent 
licenses.

---


Most of the files here are clearly just data and
are therefore neither subject to copyright nor governed by
typical open source licenses.

Some possible exceptions are:

dotnetzip/dancing-color.ps.bz2
   - This could be considered as software since that's what a PostScript
     file is. In fact it's the 'Dancing links" paper by Donald Knuth:
     https://www-cs-faculty.stanford.edu/~knuth/preprints.html
     Copyright is not asserted but is of course implied for such works.
     No licensing terms are declared.

go/compress/Isaac.Newton-Opticks.txt.bz2
   - out of copyright since unfortunately the author died long ago :-/
     It seems that the people who prepared this document:
       "Produced by Suzanne Lybarger, steve harris, Josephine
       Paolucci and the Online Distributed Proofreading Team at
       http://www.pgdp.net. "
     are interested in:
        "...dedicated to the preservation of written works
         that are in the Public Domain ..."
 
https://www.pgdp.net/wiki/DP_Official_Documentation:General/Distributed_Proofreaders_Mission_Statement



It seems that the README/COPYING/LICENSE.txt/... files
were left in the repo by people who while well intentioned,
were misguided. We could try to fix that error upstream.


> 
>> If, instead of compressed data,
>> someone were to give me an image file covered by a creative common's
>> license and the image had a watermark that when extracted produced
>> file with source code with a FOO license, would you change the
>> package license to include FOO? In fact, we don't even look at
>> image file licensing let alone at embedded watermarks.
> 
> Well, if there is a file distributed in the picture (not using the
> word "image" here to avoid confusing the discussion any more) in the
> form of a watermark, then that is no different from distributing it
> as part of a tar.gz file (albeit a bit unusual). Whatever license
> that file is covered by still applies in both cases.


To me, this is the crux of the matter, i.e.:
   "Whatever license that file is covered by
    still applies in both cases."

I agree with you but I think that the LICENSE can not and should
not and was not meant to apply to the data files.

> 
> Actually, here is something to think about. I recently read an
> article published by the Linux Foundation called "Docker Containers
> for Legal Professionals". [1] There they discussed the distribution
> of Docker images. Consider this, you take an existing Docker image,
> e.g., fedora:32, and remove everything that is covered by GPL-3.0
> (not sure how to actually accomplish that, but anyway) and then you
> distribute this new Docker image to someone. Does this mean that
> GPL-3.0 covered code is being distributed? The answer is yes.
> Because of the way Docker images are made up from layers, you need
> to adhere to the licenses covering everything in all layers, not
> just the final result. And somewhere down the stack of layers
> making up your Docker image is still all of that GPL-3.0 code
> that you removed in a higher layer.

Yes, that's an interesting case that makes sense due to the layered
nature of the docker images.

> 
>> I'm not a lawyer so this is simply my opinion on the matter.
>> How do we come to an agreement?
>> I'd be happy to add a comment in the recipe explaining our position:
>>
>> # This package contains a script and test data this is derived from
>> # other software packages as explained in the top level README.
>> # Although there are COPYING files explaining the license terms
>> # for each sub-directory, the files in each directory are only used
>> # as test data so the LICENSING terms do not appear to apply to
>> # the recipe as we ship it and have therefore NOT been incorporated
>> # into the bzip2-ptests recipe licensing tags.
> 
> I would be very worried seeing such a statement, and I believe any
> lawyer would too.

As written I agree but if I change it to:

 >> # This package contains a script and test data this is derived from
 >> # other software packages as explained in the top level README.
 >> # Although there are COPYING files explaining the license terms
 >> # for each sub-directory, the files in each directory are only used
# for each sub-directory, the files in each directory are only

 >> # as test data so the LICENSING terms do not appear to apply to
# test data so the LICENSING terms do not appear to apply to

 >> # the recipe as we ship it and have therefore NOT been incorporated
 >> # into the bzip2-ptests recipe licensing tags.


would that make more sense?


So this email chain is all about deciding between:
1) LICENSE = \
   "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"

and

2) LICENSE = "GPLv3+"


My vote is still for 2). Yours?

../Randy


 >
> 
>> I can consult with some intellectual property experts that I know
>> about this particular case if you like.
> 
> If you have the possibility to do so, I think it may be a good idea.
> 
>> ../Randy
> 
> //Peter
> 
> [1] https://www.linuxfoundation.org/wp-content/uploads/2020/04/Docker-Containers-for-Legal-Professionals-Whitepaper_v4.ac_-3.pdf
> 
>>> You also need to add:
>>>
>>> LICENSE_${PN} = "bzip2-1.0.6"
>>>
>>> LICENSE_${PN}-dev = "bzip2-1.0.6"
>>>
>>> LICENSE_${PN}-dbg = "bzip2-1.0.6"
>>>
>>> LICENSE_${PN}-doc = "bzip2-1.0.6"
>>>
>>> LICENSE_${PN}-src = "bzip2-1.0.6"
>>>
>>> LICENSE_libbz2 = "bzip2-1.0.6"
>>>
>>> so the non-ptest packages are not affected by the licenses for the
>> ptest
>>> package.
>>>
>>> //Peter
>>>
>>> *From:*Rahul Kumar <rahulk@mvista.com>
>>> *Sent:* den 19 maj 2020 13:58
>>> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
>>> *Cc:* Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin
>>> <alex.kanavin@gmail.com>; Richard Purdie
>>> <richard.purdie@linuxfoundation.org>; OE-core
>>> <openembedded-core@lists.openembedded.org>; Trevor Gamblin
>>> <trevor.gamblin@windriver.com>
>>> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>>>
>>> Hi Peter,
>>>
>>> I am sharing a few information related to bzip2-test source and
>>> licensing information.
>>> As per your suggestion and as per my understanding I added License to
>>> the bzip2 recipe file.
>>>
>>> bzip2-tests.git source tree structure is given below
>>> (here showing licence related fle, removed other file names )
>>>
>>> bzip2-tests.git/
>>> ├──commons-compress
>>> │ ├──LICENSE.txt
>>> │
>>> ├──dotnetzip
>>> │ ├──License.txt
>>> │ ├──License.zlib.txt
>>> |
>>> ├──go
>>> │ ├──LICENSE
>>> │
>>> ├──lbzip2
>>> ├──pyflate
>>> ├──README
>>> └── run-tests.sh
>>>
>>> source code link:
>>> https://sourceware.org/git/bzip2-tests.git
>>>
>>> bzip2-tests.git source contains
>>> 1) comman-commpress: which is Originally distributed under the Apache
>>> License Version 2.0.
>>>
>>> See LICENSE.txt
>>>
>>>
>>> 2) dotnetzip:
>>> (i)  The DotNetZip Library is distributed under the MicroSoft Public
>> License
>>>       (Ms-PL) see the License.txt file.
>>> (ii) The BZ2 related resources are distributed under the licenses in
>>> License.zlib.txt.
>>>
>>> 3) go:
>>>
>>>    Go is distributed under a BSD-style license.
>>>    See the LICENSE file.
>>>
>>> 4) lbzip2:
>>> lbzip2 is free software: you can redistribute it and/or modify it under
>> the
>>> terms of the GNU General Public License as published by the Free
>> Software
>>> Foundation, either version 3 of the License, or (at your option) any
>> later
>>> version
>>>
>>> 5) pyflate: You may use and distribute this code and documentation
>> under any
>>>               DFSG-compatible license (eg. BSD, GNU GPLv2).
>>>
>>> 6) run-tests.sh: you can redistribute it and/or modify it under the
>>> terms of the GNU General Public License (GPL); either
>>>                    version 3, or (at your option) any later version.
>>>
>>>
>>> SO in recipe I added the License like below
>>> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
>>> LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
>>> LIC_FILES_CHKSUM =
>>>
>> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
>> 64
>>> \
>>>
>>> file://${WORKDIR}/git/commons-
>> compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
>>> \ # For comman-commpress (Apache-2.0)
>>>
>>>
>> file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff
>> 352a54f
>>> \      # For dotnetzip (Ms-PL)
>>>
>>>
>> file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b
>> 79e6de0a029f
>>> \   # For dotnetzip  (jzlib +zlib)
>>>
>>> file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
>>>        # For go (BSD-style license)
>>>
>>> here I need few suggestion:
>>>
>>> 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-
>> ptest.
>>>      but not added LIC_FILES_CHKSUM for GPLv3 and BSD because
>>> bzip2-tests.git source code doesn't have GPLv3 and BSD License text
>> file
>>> like other
>>>      directories.
>>>
>>> 2) License.zlib.txt: This is a combination of two licence jzlib and
>>> zlib. In meta/files/common-licenses Zlib license is available but not
>> jzlib.
>>>      In this case how can I proceed?
>>>
>>> Kindly comment on this and feel free to point out if i am wrong at any
>>> place.
>>>
>>> *Thanks & Regards,*
>>>
>>> Rahul Kumar
>>>
>>> Software Engineer,Linux Solutions Engineering
>>>
>>> Group,Montavista Software LLC
>>>
>>> Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>>> <https://plus.google.com/+CodeTwoSoftware>
>>>
>>> On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt
>>> <peter.kjellerstedt@axis.com <mailto:peter.kjellerstedt@axis.com>>
>> wrote:
>>>
>>>      As I wrote in my previous mail, when it comes to licenses, it is
>> the
>>>      distribution that is important. So if you build a package
>>>      (bzip2-ptest) that includes code that is GPL-3.0, it does not
>> matter
>>>      if that code is only used as a binary blob, it is still distributed
>>>      in the package, and thus the package needs to be covered by the
>>>      GPL-3.0 license.
>>>
>>>      //Peter
>>>
>>>      *From:*openembedded-core@lists.openembedded.org
>>>      <mailto:openembedded-core@lists.openembedded.org>
>>>      <openembedded-core@lists.openembedded.org
>>>      <mailto:openembedded-core@lists.openembedded.org>> *On Behalf Of
>>>      *Rahul Kumar
>>>      *Sent:* den 17 maj 2020 21:18
>>>      *To:* Randy MacLeod <randy.macleod@windriver.com
>>>      <mailto:randy.macleod@windriver.com>>
>>>      *Cc:* Alexander Kanavin <alex.kanavin@gmail.com
>>>      <mailto:alex.kanavin@gmail.com>>; Richard Purdie
>>>      <richard.purdie@linuxfoundation.org
>>>      <mailto:richard.purdie@linuxfoundation.org>>; OE-core
>>>      <openembedded-core@lists.openembedded.org
>>>      <mailto:openembedded-core@lists.openembedded.org>>; Trevor Gamblin
>>>      <trevor.gamblin@windriver.com
>> <mailto:trevor.gamblin@windriver.com>>
>>>      *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>>>
>>>      Hi Randy,
>>>
>>>      patch has been accepted by bzip2 community with additional changes.
>>>      https://sourceware.org/git/?p=bzip2-
>> tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
>>>
>>>
>>>      So I need your suggestion with respect to Yocto.
>>>
>>>      Since required changes for ptest infrastructure is integrated to
>> the
>>>      bzip2-tests.git source code.
>>>      So now we can just change the SRCREV with the latest commit instead
>>>      of applying the patch to the bzip2-tests.git source code.
>>>
>>>      And since we are just integrating the bzip2-tests source to the
>>>      bzip2 recipe and not modifying any file so i think no need to add
>>>      any License for it.
>>>
>>>
>>>      Now patch will look like
>>>
>> =====================================================================
>>>      --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
>>>      +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
>>>      @@ -46,6 +46,7 @@ runtest:
>>>               else echo "FAIL: sample2 decompress"; fi
>>>               @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
>>>      decompress";\
>>>               else echo "FAIL: sample3 decompress"; fi
>>>      +       ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
>>>
>>>        install-ptest:
>>>               sed  -n '/^runtest:/,/^install-ptest:/{/^install-
>> ptest:/!p}' \
>>>      @@ -56,6 +57,7 @@ install-ptest:
>>>               cp $(srcdir)/sample1.bz2        $(DESTDIR)/
>>>               cp $(srcdir)/sample2.bz2        $(DESTDIR)/
>>>               cp $(srcdir)/sample3.bz2        $(DESTDIR)/
>>>      +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
>>>               ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
>>>
>>>        install-exec-hook:
>>>      diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
>>>      <http://bzip2_1.0.8.bb> b/meta/recipes-
>> extended/bzip2/bzip2_1.0.8.bb
>>>      <http://bzip2_1.0.8.bb>
>>>      index d58f553..c5aa690 100644
>>>      --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
>> <http://bzip2_1.0.8.bb>
>>>      +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
>> <http://bzip2_1.0.8.bb>
>>>      @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
>>>        LIC_FILES_CHKSUM =
>>>
>> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
>> 64"
>>>
>>>        SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz
>>>      <https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz>
>> \
>>>      +
>>>      git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests
>>>      <http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
>>>                   file://configure.ac <http://configure.ac>;subdir=${BP}
>> \
>>>                   file://Makefile.am;subdir=${BP} \
>>>                   file://run-ptest \
>>>                   "
>>>      +
>>>        SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
>>>        SRC_URI[sha256sum] =
>>>      "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
>>>
>>>      +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"
>> *<<
>>>      this commit Id includes latest charges for ptest infrastruct.*
>>>      +
>>>        UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
>>>
>>>        PACKAGES =+ "libbz2"
>>>      @@ -39,7 +43,7 @@ do_install_ptest () {
>>>
>>>        FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
>>>
>>>      -RDEPENDS_${PN}-ptest += "make"
>>>      +RDEPENDS_${PN}-ptest += "make bash"
>>>
>>>        PROVIDES_append_class-native = " bzip2-replacement-native"
>>>        BBCLASSEXTEND = "native nativesdk"
>>>
>> =========================================================================
>> ========
>>>
>>>      Kindly comment on it and feel free to point out, if i am wrong at
>>>      any place.
>>>
>>>      *Thanks & Regards,*
>>>
>>>      Rahul Kumar
>>>
>>>      Software Engineer,Linux Solutions Engineering
>>>
>>>      Group,Montavista Software LLC
>>>
>>>      Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>>>      <https://plus.google.com/+CodeTwoSoftware>
>>>
>>>      On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
>>>      <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com>>
>>>      wrote:
>>>
>>>          On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
>>>           > You need to first see from the failure page which
>>>          configuration is
>>>           > failing, for example non-gpl3 is one such.
>>>           >
>>>           > Then you find that configuration in config.json. The below
>>>          should
>>>           > hopefully be self-explanatory in how you should set up the
>> build?
>>>           >
>>>           > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
>>>          "MACHINE" :
>>>           > "qemux86", "BBTARGETS" : "core-image-minimal
>>>          core-image-full-cmdline",
>>>           > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
>>>          "WARN_QA_remove =
>>>           > 'incompatible-license'" ], "EXTRACMDS" : [
>>>           > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
>>>           >
>>>           > |
>>>           >
>>>           > |
>>>           > |
>>>           >
>>>           > |Alex
>>>
>>>          Hi Rahul,
>>>
>>>          Sorry for my late reply.
>>>
>>>          The commit log for v2 is very good now!
>>>          Thanks for incorporating my --pedantic suggestions. ;-)
>>>
>>>          It seems that you need a perl dependency for something (docs?
>>>               $ cd .../bzip2.git
>>>               $ grep -r "perl " *
>>>               format.pl:#!/usr/bin/perl -w
>>>               README.XML.STUFF:It uses format.pl <http://format.pl>, a
>>>          perl script...
>>>
>>>          Then we need to figure out how to deal with the GPLv3 issue.
>>>
>>>          The buildbot output can be tedious to figure out. I haven't
>> really
>>>          spent enough time plugging away at it to be proficient yet
>> either.
>>>          Have you been able to reproduce the problems that Richard
>> reported?
>>>          If not, and you've tried for a bit, then just say so and I'll
>> try to
>>>          help tomorrow or early next week.
>>>
>>>          It looks like you are packaging the test code/data with the
>> main
>>>          package
>>>          not in bzip2-ptest. Have a look at:
>>>               meta/recipes-support/libpcre/libpcre_8.44.bb
>>>          <http://libpcre_8.44.bb>
>>>          for an example. There are many more.
>>>          Also, if you look at oe-core.git:
>>>               $ rgrep LICENSE_ *  | grep PN
>>>          you can see many examples of sub-packages with different
>> licenses
>>>          than the main package. One example is:
>>>               meta/recipes-support/gnutls/gnutls_3.6.13.bb
>>>          <http://gnutls_3.6.13.bb>
>>>          I hope that can address the buildbot problem but I haven't
>> tried it
>>>          myself yet.
>>>
>>>          BTW, Trevor has gotten the YP autobuilder going at Wind River
>> and
>>>          he'll be sending a few documentation updates next week or so.
>>>          That may help in case you want to reproduce the YP AB test
>>>          infrastructure. I expect that you don't _have_ to do so but
>>>          I think it would be good if more contributing organizations did
>>>          have an instance with only limited builders of the YP AB so
>> that
>>>          we can do more testing before Richard runs our changes through
>>>          the main system. Richard has cautioned that the YP AB has lots
>> of
>>>          builders each of which has many cores but I hope that we can at
>>>          least
>>>          do some AB checking ourselves.
>>>
>>>          ../Randy
>>>
>>>
>>>           > |
>>>           >
>>>           >
>>>           > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <rahulk@mvista.com
>>>          <mailto:rahulk@mvista.com>
>>>           > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>>
>> wrote:
>>>           >
>>>           >     Hi Richard/Alexander,
>>>           >
>>>           >     I am not able to understand how I can use the below
>> file.
>>>           >
>>>          http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-
>> helper/tree/config.json
>>>           >
>>>           >     did you mean to say that i have to set MACRO in
>>>          local.conf based on
>>>           >     this file.
>>>           >
>>>           >     *Thanks & Regards,*
>>>           >     Rahul Kumar
>>>           >     Software Engineer,Linux Solutions Engineering
>>>           >     Group,Montavista Software LLC
>>>           >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
>>>          <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
>>>           >     <https://plus.google.com/+CodeTwoSoftware>
>>>           >
>>>           >
>>>           >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
>>>           >     <richard.purdie@linuxfoundation.org
>>>          <mailto:richard.purdie@linuxfoundation.org>
>>>           >     <mailto:richard.purdie@linuxfoundation.org
>>>          <mailto:richard.purdie@linuxfoundation.org>>> wrote:
>>>           >
>>>           >         On Mon, 2020-04-27 at 18:30 +0200, Alexander Kanavin
>>>          wrote:
>>>           >          > You need to look at configurations defined here:
>>>           >          >
>>>           >
>>>          http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-
>> helper/tree/config.json
>>>           >          > and replicate them locally. Then you can
>> reproduce the
>>>           >         failures that
>>>           >          > the AB gets in those configurations.
>>>           >
>>>           >         That start of the failing logs on the autobuilder
>>>          also list out the
>>>           >         configuration options for that build.
>>>           >
>>>           >         Cheers,
>>>           >
>>>           >         Richard
>>>           >
>>>           >
>>>           >
>>>           >
>>>
>>>
>>>          --
>>>          # Randy MacLeod
>>>          # Wind River Linux
>>>
>>
>>
>> --
>> # Randy MacLeod
>> # Wind River Linux


-- 
# Randy MacLeod
# Wind River Linux

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

[-- Attachment #1: Type: text/plain, Size: 27135 bytes --]

Hi Randy/Peter/community members,

Can you please conclude I should go with which option.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rahulk@mvista.com
<https://plus.google.com/+CodeTwoSoftware>


On Thu, May 21, 2020 at 2:29 AM Randy MacLeod <randy.macleod@windriver.com>
wrote:

> On 2020-05-19 8:06 p.m., Peter Kjellerstedt wrote:
> >> -----Original Message-----
> >> From: Randy MacLeod <randy.macleod@windriver.com>
> >> Sent: den 19 maj 2020 23:45
> >> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Rahul Kumar
> >> <rahulk@mvista.com>
> >> Cc: Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie
> >> <richard.purdie@linuxfoundation.org>; OE-core <openembedded-
> >> core@lists.openembedded.org>; Trevor Gamblin
> >> <trevor.gamblin@windriver.com>
> >> Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >>
> >> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> >>> The jzlib license is a three clause BSD license, and so is the
> >>> go/LICENSE, so you should be able to set LICENSE as:
> >>>
> >>> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause &
> Zlib"
> >>
> >> Peter,
> >>
> >> I respectfully disagree.
> >>
> >> The only source that is _executed_ in normal use by bzip2-test is
> >> the run-tests.sh script that is licensed as GPLv3+
> >
> > Well, I am definitely not a lawyer either,
>
> Phew! :)
>
> > but I am pretty sure that
> > whether something that is distributed under a certain license is
> > executed or not is irrelevant (unless of course the license covers
> > execution of the code).
>
> There's a difference between a legal report and the Yocto LICENSE tag.
> The Yocto tag is meant to be an over-all/community acknowledged license
> for the _code_ in the package that ends up as executable / script on
> the target. We should probably document this in greater detail, perhaps
> in:
>
>
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-LICENSE
>
> A more comprehensive analysis usually includes a file by file
> IP report often accompanied by a summary generated by an IP expert.
>
> >
> >> The other files, although they came from source packages,
> >> are *only* used as  test data. The source code has been completely
> >> stripped out, hasn't it?
> >
> > Given that they were originally distributed in an archive together
> > with a LICENSE/COPYING/similar file covering the entire archive,
> > those files are still covered by that license even if they are not
> > source files per se.
>
>
> Licenses describe the terms that apply to items that are covered
> under copyright. Data generally can not be copyrighted.
>
>  From my IP contact:
>
> ---
>
> In order for something to be copyrightable three requirements
> must be satisfied:
>
>   1. The work represents a creative form of expression
>      (basic facts do not represent a creative form of expression)
>
>   2. The work is original (novel) – not copied from someone else.
>      Two different people could come up with similar creative forms
>      of expression. They just can’t copy from someone else.
>
>   3. It must be put in tangible form (e.g., written, digital, …).
>      Someone can’t just claim it resides inside their head.
>
>
>
> Data as a general is not copyrightable because it fails number 1.
> However if someone can argue that a certain compilation of data
> represents some form of creative expression, they might have a case.
> This is discussed in the first two paragraphs here:
>
>     https://libguides.library.kent.edu/data-management/copyright
>
>
> Data can be protected under patent or trade secret law but different
> requirements apply and a different license would need to be created.
> Open Source licenses are largely copyright licenses. Although sometimes
> they include patent terms, they are generally not considered patent
> licenses.
>
> ---
>
>
> Most of the files here are clearly just data and
> are therefore neither subject to copyright nor governed by
> typical open source licenses.
>
> Some possible exceptions are:
>
> dotnetzip/dancing-color.ps.bz2
>    - This could be considered as software since that's what a PostScript
>      file is. In fact it's the 'Dancing links" paper by Donald Knuth:
>      https://www-cs-faculty.stanford.edu/~knuth/preprints.html
>      Copyright is not asserted but is of course implied for such works.
>      No licensing terms are declared.
>
> go/compress/Isaac.Newton-Opticks.txt.bz2
>    - out of copyright since unfortunately the author died long ago :-/
>      It seems that the people who prepared this document:
>        "Produced by Suzanne Lybarger, steve harris, Josephine
>        Paolucci and the Online Distributed Proofreading Team at
>        http://www.pgdp.net. "
>      are interested in:
>         "...dedicated to the preservation of written works
>          that are in the Public Domain ..."
>
>
> https://www.pgdp.net/wiki/DP_Official_Documentation:General/Distributed_Proofreaders_Mission_Statement
>
>
>
> It seems that the README/COPYING/LICENSE.txt/... files
> were left in the repo by people who while well intentioned,
> were misguided. We could try to fix that error upstream.
>
>
> >
> >> If, instead of compressed data,
> >> someone were to give me an image file covered by a creative common's
> >> license and the image had a watermark that when extracted produced
> >> file with source code with a FOO license, would you change the
> >> package license to include FOO? In fact, we don't even look at
> >> image file licensing let alone at embedded watermarks.
> >
> > Well, if there is a file distributed in the picture (not using the
> > word "image" here to avoid confusing the discussion any more) in the
> > form of a watermark, then that is no different from distributing it
> > as part of a tar.gz file (albeit a bit unusual). Whatever license
> > that file is covered by still applies in both cases.
>
>
> To me, this is the crux of the matter, i.e.:
>    "Whatever license that file is covered by
>     still applies in both cases."
>
> I agree with you but I think that the LICENSE can not and should
> not and was not meant to apply to the data files.
>
> >
> > Actually, here is something to think about. I recently read an
> > article published by the Linux Foundation called "Docker Containers
> > for Legal Professionals". [1] There they discussed the distribution
> > of Docker images. Consider this, you take an existing Docker image,
> > e.g., fedora:32, and remove everything that is covered by GPL-3.0
> > (not sure how to actually accomplish that, but anyway) and then you
> > distribute this new Docker image to someone. Does this mean that
> > GPL-3.0 covered code is being distributed? The answer is yes.
> > Because of the way Docker images are made up from layers, you need
> > to adhere to the licenses covering everything in all layers, not
> > just the final result. And somewhere down the stack of layers
> > making up your Docker image is still all of that GPL-3.0 code
> > that you removed in a higher layer.
>
> Yes, that's an interesting case that makes sense due to the layered
> nature of the docker images.
>
> >
> >> I'm not a lawyer so this is simply my opinion on the matter.
> >> How do we come to an agreement?
> >> I'd be happy to add a comment in the recipe explaining our position:
> >>
> >> # This package contains a script and test data this is derived from
> >> # other software packages as explained in the top level README.
> >> # Although there are COPYING files explaining the license terms
> >> # for each sub-directory, the files in each directory are only used
> >> # as test data so the LICENSING terms do not appear to apply to
> >> # the recipe as we ship it and have therefore NOT been incorporated
> >> # into the bzip2-ptests recipe licensing tags.
> >
> > I would be very worried seeing such a statement, and I believe any
> > lawyer would too.
>
> As written I agree but if I change it to:
>
>  >> # This package contains a script and test data this is derived from
>  >> # other software packages as explained in the top level README.
>  >> # Although there are COPYING files explaining the license terms
>  >> # for each sub-directory, the files in each directory are only used
> # for each sub-directory, the files in each directory are only
>
>  >> # as test data so the LICENSING terms do not appear to apply to
> # test data so the LICENSING terms do not appear to apply to
>
>  >> # the recipe as we ship it and have therefore NOT been incorporated
>  >> # into the bzip2-ptests recipe licensing tags.
>
>
> would that make more sense?
>
>
> So this email chain is all about deciding between:
> 1) LICENSE = \
>    "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>
> and
>
> 2) LICENSE = "GPLv3+"
>
>
> My vote is still for 2). Yours?
>
> ../Randy
>
>
>  >
> >
> >> I can consult with some intellectual property experts that I know
> >> about this particular case if you like.
> >
> > If you have the possibility to do so, I think it may be a good idea.
> >
> >> ../Randy
> >
> > //Peter
> >
> > [1]
> https://www.linuxfoundation.org/wp-content/uploads/2020/04/Docker-Containers-for-Legal-Professionals-Whitepaper_v4.ac_-3.pdf
> >
> >>> You also need to add:
> >>>
> >>> LICENSE_${PN} = "bzip2-1.0.6"
> >>>
> >>> LICENSE_${PN}-dev = "bzip2-1.0.6"
> >>>
> >>> LICENSE_${PN}-dbg = "bzip2-1.0.6"
> >>>
> >>> LICENSE_${PN}-doc = "bzip2-1.0.6"
> >>>
> >>> LICENSE_${PN}-src = "bzip2-1.0.6"
> >>>
> >>> LICENSE_libbz2 = "bzip2-1.0.6"
> >>>
> >>> so the non-ptest packages are not affected by the licenses for the
> >> ptest
> >>> package.
> >>>
> >>> //Peter
> >>>
> >>> *From:*Rahul Kumar <rahulk@mvista.com>
> >>> *Sent:* den 19 maj 2020 13:58
> >>> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> >>> *Cc:* Randy MacLeod <randy.macleod@windriver.com>; Alexander Kanavin
> >>> <alex.kanavin@gmail.com>; Richard Purdie
> >>> <richard.purdie@linuxfoundation.org>; OE-core
> >>> <openembedded-core@lists.openembedded.org>; Trevor Gamblin
> >>> <trevor.gamblin@windriver.com>
> >>> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >>>
> >>> Hi Peter,
> >>>
> >>> I am sharing a few information related to bzip2-test source and
> >>> licensing information.
> >>> As per your suggestion and as per my understanding I added License to
> >>> the bzip2 recipe file.
> >>>
> >>> bzip2-tests.git source tree structure is given below
> >>> (here showing licence related fle, removed other file names )
> >>>
> >>> bzip2-tests.git/
> >>> ├──commons-compress
> >>> │ ├──LICENSE.txt
> >>> │
> >>> ├──dotnetzip
> >>> │ ├──License.txt
> >>> │ ├──License.zlib.txt
> >>> |
> >>> ├──go
> >>> │ ├──LICENSE
> >>> │
> >>> ├──lbzip2
> >>> ├──pyflate
> >>> ├──README
> >>> └── run-tests.sh
> >>>
> >>> source code link:
> >>> https://sourceware.org/git/bzip2-tests.git
> >>>
> >>> bzip2-tests.git source contains
> >>> 1) comman-commpress: which is Originally distributed under the Apache
> >>> License Version 2.0.
> >>>
> >>> See LICENSE.txt
> >>>
> >>>
> >>> 2) dotnetzip:
> >>> (i)  The DotNetZip Library is distributed under the MicroSoft Public
> >> License
> >>>       (Ms-PL) see the License.txt file.
> >>> (ii) The BZ2 related resources are distributed under the licenses in
> >>> License.zlib.txt.
> >>>
> >>> 3) go:
> >>>
> >>>    Go is distributed under a BSD-style license.
> >>>    See the LICENSE file.
> >>>
> >>> 4) lbzip2:
> >>> lbzip2 is free software: you can redistribute it and/or modify it under
> >> the
> >>> terms of the GNU General Public License as published by the Free
> >> Software
> >>> Foundation, either version 3 of the License, or (at your option) any
> >> later
> >>> version
> >>>
> >>> 5) pyflate: You may use and distribute this code and documentation
> >> under any
> >>>               DFSG-compatible license (eg. BSD, GNU GPLv2).
> >>>
> >>> 6) run-tests.sh: you can redistribute it and/or modify it under the
> >>> terms of the GNU General Public License (GPL); either
> >>>                    version 3, or (at your option) any later version.
> >>>
> >>>
> >>> SO in recipe I added the License like below
> >>> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> >>> LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> >>> LIC_FILES_CHKSUM =
> >>>
> >>
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
> >> 64
> >>> \
> >>>
> >>> file://${WORKDIR}/git/commons-
> >> compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
> >>> \ # For comman-commpress (Apache-2.0)
> >>>
> >>>
> >>
> file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff
> >> 352a54f
> >>> \      # For dotnetzip (Ms-PL)
> >>>
> >>>
> >>
> file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b
> >> 79e6de0a029f
> >>> \   # For dotnetzip  (jzlib +zlib)
> >>>
> >>> file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
> >>>        # For go (BSD-style license)
> >>>
> >>> here I need few suggestion:
> >>>
> >>> 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-
> >> ptest.
> >>>      but not added LIC_FILES_CHKSUM for GPLv3 and BSD because
> >>> bzip2-tests.git source code doesn't have GPLv3 and BSD License text
> >> file
> >>> like other
> >>>      directories.
> >>>
> >>> 2) License.zlib.txt: This is a combination of two licence jzlib and
> >>> zlib. In meta/files/common-licenses Zlib license is available but not
> >> jzlib.
> >>>      In this case how can I proceed?
> >>>
> >>> Kindly comment on this and feel free to point out if i am wrong at any
> >>> place.
> >>>
> >>> *Thanks & Regards,*
> >>>
> >>> Rahul Kumar
> >>>
> >>> Software Engineer,Linux Solutions Engineering
> >>>
> >>> Group,Montavista Software LLC
> >>>
> >>> Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >>> <https://plus.google.com/+CodeTwoSoftware>
> >>>
> >>> On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt
> >>> <peter.kjellerstedt@axis.com <mailto:peter.kjellerstedt@axis.com>>
> >> wrote:
> >>>
> >>>      As I wrote in my previous mail, when it comes to licenses, it is
> >> the
> >>>      distribution that is important. So if you build a package
> >>>      (bzip2-ptest) that includes code that is GPL-3.0, it does not
> >> matter
> >>>      if that code is only used as a binary blob, it is still
> distributed
> >>>      in the package, and thus the package needs to be covered by the
> >>>      GPL-3.0 license.
> >>>
> >>>      //Peter
> >>>
> >>>      *From:*openembedded-core@lists.openembedded.org
> >>>      <mailto:openembedded-core@lists.openembedded.org>
> >>>      <openembedded-core@lists.openembedded.org
> >>>      <mailto:openembedded-core@lists.openembedded.org>> *On Behalf Of
> >>>      *Rahul Kumar
> >>>      *Sent:* den 17 maj 2020 21:18
> >>>      *To:* Randy MacLeod <randy.macleod@windriver.com
> >>>      <mailto:randy.macleod@windriver.com>>
> >>>      *Cc:* Alexander Kanavin <alex.kanavin@gmail.com
> >>>      <mailto:alex.kanavin@gmail.com>>; Richard Purdie
> >>>      <richard.purdie@linuxfoundation.org
> >>>      <mailto:richard.purdie@linuxfoundation.org>>; OE-core
> >>>      <openembedded-core@lists.openembedded.org
> >>>      <mailto:openembedded-core@lists.openembedded.org>>; Trevor
> Gamblin
> >>>      <trevor.gamblin@windriver.com
> >> <mailto:trevor.gamblin@windriver.com>>
> >>>      *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for
> bzip2
> >>>
> >>>      Hi Randy,
> >>>
> >>>      patch has been accepted by bzip2 community with additional
> changes.
> >>>      https://sourceware.org/git/?p=bzip2-
> >> tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
> >>>
> >>>
> >>>      So I need your suggestion with respect to Yocto.
> >>>
> >>>      Since required changes for ptest infrastructure is integrated to
> >> the
> >>>      bzip2-tests.git source code.
> >>>      So now we can just change the SRCREV with the latest commit
> instead
> >>>      of applying the patch to the bzip2-tests.git source code.
> >>>
> >>>      And since we are just integrating the bzip2-tests source to the
> >>>      bzip2 recipe and not modifying any file so i think no need to add
> >>>      any License for it.
> >>>
> >>>
> >>>      Now patch will look like
> >>>
> >> =====================================================================
> >>>      --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> >>>      +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> >>>      @@ -46,6 +46,7 @@ runtest:
> >>>               else echo "FAIL: sample2 decompress"; fi
> >>>               @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> >>>      decompress";\
> >>>               else echo "FAIL: sample3 decompress"; fi
> >>>      +       ./bzip2-tests/run-tests.sh
> --tests-dir="$(PWD)/bzip2-tests"
> >>>
> >>>        install-ptest:
> >>>               sed  -n '/^runtest:/,/^install-ptest:/{/^install-
> >> ptest:/!p}' \
> >>>      @@ -56,6 +57,7 @@ install-ptest:
> >>>               cp $(srcdir)/sample1.bz2        $(DESTDIR)/
> >>>               cp $(srcdir)/sample2.bz2        $(DESTDIR)/
> >>>               cp $(srcdir)/sample3.bz2        $(DESTDIR)/
> >>>      +       cp -rf $(srcdir)/../git         $(DESTDIR)/bzip2-tests
> >>>               ln -s $(bindir)/bzip2           $(DESTDIR)/bzip2
> >>>
> >>>        install-exec-hook:
> >>>      diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> >>>      <http://bzip2_1.0.8.bb> b/meta/recipes-
> >> extended/bzip2/bzip2_1.0.8.bb
> >>>      <http://bzip2_1.0.8.bb>
> >>>      index d58f553..c5aa690 100644
> >>>      --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> >> <http://bzip2_1.0.8.bb>
> >>>      +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> >> <http://bzip2_1.0.8.bb>
> >>>      @@ -8,13 +8,17 @@ LICENSE = "bzip2-1.0.6"
> >>>        LIC_FILES_CHKSUM =
> >>>
> >>
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
> >> 64"
> >>>
> >>>        SRC_URI = "
> https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz
> >>>      <
> https://sourceware.org/pub/$%7bBPN%7d/$%7bBPN%7d-$%7bPV%7d.tar.gz>
> >> \
> >>>      +
> >>>      git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests
> >>>      <http://sourceware.org/git/bzip2-tests.git;name=bzip2-tests> \
> >>>                   file://configure.ac <http://configure.ac
> >;subdir=${BP}
> >> \
> >>>                   file://Makefile.am;subdir=${BP} \
> >>>                   file://run-ptest \
> >>>                   "
> >>>      +
> >>>        SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
> >>>        SRC_URI[sha256sum] =
> >>>      "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
> >>>
> >>>      +SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0"
> >> *<<
> >>>      this commit Id includes latest charges for ptest infrastruct.*
> >>>      +
> >>>        UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
> >>>
> >>>        PACKAGES =+ "libbz2"
> >>>      @@ -39,7 +43,7 @@ do_install_ptest () {
> >>>
> >>>        FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
> >>>
> >>>      -RDEPENDS_${PN}-ptest += "make"
> >>>      +RDEPENDS_${PN}-ptest += "make bash"
> >>>
> >>>        PROVIDES_append_class-native = " bzip2-replacement-native"
> >>>        BBCLASSEXTEND = "native nativesdk"
> >>>
> >>
> =========================================================================
> >> ========
> >>>
> >>>      Kindly comment on it and feel free to point out, if i am wrong at
> >>>      any place.
> >>>
> >>>      *Thanks & Regards,*
> >>>
> >>>      Rahul Kumar
> >>>
> >>>      Software Engineer,Linux Solutions Engineering
> >>>
> >>>      Group,Montavista Software LLC
> >>>
> >>>      Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >>>      <https://plus.google.com/+CodeTwoSoftware>
> >>>
> >>>      On Fri, May 1, 2020 at 6:56 AM Randy MacLeod
> >>>      <randy.macleod@windriver.com <mailto:randy.macleod@windriver.com
> >>
> >>>      wrote:
> >>>
> >>>          On 2020-04-27 3:39 p.m., Alexander Kanavin wrote:
> >>>           > You need to first see from the failure page which
> >>>          configuration is
> >>>           > failing, for example non-gpl3 is one such.
> >>>           >
> >>>           > Then you find that configuration in config.json. The below
> >>>          should
> >>>           > hopefully be self-explanatory in how you should set up the
> >> build?
> >>>           >
> >>>           > |"non-gpl3" : { "NEEDREPOS" : ["poky", "meta-gplv2"],
> >>>          "MACHINE" :
> >>>           > "qemux86", "BBTARGETS" : "core-image-minimal
> >>>          core-image-full-cmdline",
> >>>           > "extravars" : [ "INCOMPATIBLE_LICENSE = '*GPLv3'",
> >>>          "WARN_QA_remove =
> >>>           > 'incompatible-license'" ], "EXTRACMDS" : [
> >>>           > "../../yocto-autobuilder-helper/scripts/check-gplv3" ] },
> >>>           >
> >>>           > |
> >>>           >
> >>>           > |
> >>>           > |
> >>>           >
> >>>           > |Alex
> >>>
> >>>          Hi Rahul,
> >>>
> >>>          Sorry for my late reply.
> >>>
> >>>          The commit log for v2 is very good now!
> >>>          Thanks for incorporating my --pedantic suggestions. ;-)
> >>>
> >>>          It seems that you need a perl dependency for something (docs?
> >>>               $ cd .../bzip2.git
> >>>               $ grep -r "perl " *
> >>>               format.pl:#!/usr/bin/perl -w
> >>>               README.XML.STUFF:It uses format.pl <http://format.pl>, a
> >>>          perl script...
> >>>
> >>>          Then we need to figure out how to deal with the GPLv3 issue.
> >>>
> >>>          The buildbot output can be tedious to figure out. I haven't
> >> really
> >>>          spent enough time plugging away at it to be proficient yet
> >> either.
> >>>          Have you been able to reproduce the problems that Richard
> >> reported?
> >>>          If not, and you've tried for a bit, then just say so and I'll
> >> try to
> >>>          help tomorrow or early next week.
> >>>
> >>>          It looks like you are packaging the test code/data with the
> >> main
> >>>          package
> >>>          not in bzip2-ptest. Have a look at:
> >>>               meta/recipes-support/libpcre/libpcre_8.44.bb
> >>>          <http://libpcre_8.44.bb>
> >>>          for an example. There are many more.
> >>>          Also, if you look at oe-core.git:
> >>>               $ rgrep LICENSE_ *  | grep PN
> >>>          you can see many examples of sub-packages with different
> >> licenses
> >>>          than the main package. One example is:
> >>>               meta/recipes-support/gnutls/gnutls_3.6.13.bb
> >>>          <http://gnutls_3.6.13.bb>
> >>>          I hope that can address the buildbot problem but I haven't
> >> tried it
> >>>          myself yet.
> >>>
> >>>          BTW, Trevor has gotten the YP autobuilder going at Wind River
> >> and
> >>>          he'll be sending a few documentation updates next week or so.
> >>>          That may help in case you want to reproduce the YP AB test
> >>>          infrastructure. I expect that you don't _have_ to do so but
> >>>          I think it would be good if more contributing organizations
> did
> >>>          have an instance with only limited builders of the YP AB so
> >> that
> >>>          we can do more testing before Richard runs our changes through
> >>>          the main system. Richard has cautioned that the YP AB has lots
> >> of
> >>>          builders each of which has many cores but I hope that we can
> at
> >>>          least
> >>>          do some AB checking ourselves.
> >>>
> >>>          ../Randy
> >>>
> >>>
> >>>           > |
> >>>           >
> >>>           >
> >>>           > On Mon, 27 Apr 2020 at 20:54, Rahul Kumar <
> rahulk@mvista.com
> >>>          <mailto:rahulk@mvista.com>
> >>>           > <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>>
> >> wrote:
> >>>           >
> >>>           >     Hi Richard/Alexander,
> >>>           >
> >>>           >     I am not able to understand how I can use the below
> >> file.
> >>>           >
> >>>          http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-
> >> helper/tree/config.json
> >>>           >
> >>>           >     did you mean to say that i have to set MACRO in
> >>>          local.conf based on
> >>>           >     this file.
> >>>           >
> >>>           >     *Thanks & Regards,*
> >>>           >     Rahul Kumar
> >>>           >     Software Engineer,Linux Solutions Engineering
> >>>           >     Group,Montavista Software LLC
> >>>           >     Email Id: rahulk@mvista.com <mailto:rahulk@mvista.com>
> >>>          <mailto:rahulk@mvista.com <mailto:rahulk@mvista.com>>
> >>>           >     <https://plus.google.com/+CodeTwoSoftware>
> >>>           >
> >>>           >
> >>>           >     On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie
> >>>           >     <richard.purdie@linuxfoundation.org
> >>>          <mailto:richard.purdie@linuxfoundation.org>
> >>>           >     <mailto:richard.purdie@linuxfoundation.org
> >>>          <mailto:richard.purdie@linuxfoundation.org>>> wrote:
> >>>           >
> >>>           >         On Mon, 2020-04-27 at 18:30 +0200, Alexander
> Kanavin
> >>>          wrote:
> >>>           >          > You need to look at configurations defined here:
> >>>           >          >
> >>>           >
> >>>          http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-
> >> helper/tree/config.json
> >>>           >          > and replicate them locally. Then you can
> >> reproduce the
> >>>           >         failures that
> >>>           >          > the AB gets in those configurations.
> >>>           >
> >>>           >         That start of the failing logs on the autobuilder
> >>>          also list out the
> >>>           >         configuration options for that build.
> >>>           >
> >>>           >         Cheers,
> >>>           >
> >>>           >         Richard
> >>>           >
> >>>           >
> >>>           >
> >>>           >
> >>>
> >>>
> >>>          --
> >>>          # Randy MacLeod
> >>>          # Wind River Linux
> >>>
> >>
> >>
> >> --
> >> # Randy MacLeod
> >> # Wind River Linux
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>

[-- Attachment #2: Type: text/html, Size: 43208 bytes --]

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Paul Barker]

I'm looking at this after our chat on the call today, picked on this
email in particular just because I needed one to reply to....

On Wed, 20 May 2020 at 21:59, Randy MacLeod <randy.macleod@windriver.com> wrote:
>
> On 2020-05-19 8:06 p.m., Peter Kjellerstedt wrote:
> >> -----Original Message-----
> >> From: Randy MacLeod <randy.macleod@windriver.com>
> >> Sent: den 19 maj 2020 23:45
> >> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Rahul Kumar
> >> <rahulk@mvista.com>
> >> Cc: Alexander Kanavin <alex.kanavin@gmail.com>; Richard Purdie
> >> <richard.purdie@linuxfoundation.org>; OE-core <openembedded-
> >> core@lists.openembedded.org>; Trevor Gamblin
> >> <trevor.gamblin@windriver.com>
> >> Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >>
> >> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> >>> The jzlib license is a three clause BSD license, and so is the
> >>> go/LICENSE, so you should be able to set LICENSE as:
> >>>
> >>> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
> >>
> >> Peter,
> >>
> >> I respectfully disagree.
> >>
> >> The only source that is _executed_ in normal use by bzip2-test is
> >> the run-tests.sh script that is licensed as GPLv3+
> >
> > Well, I am definitely not a lawyer either,
>
> Phew! :)
>
> > but I am pretty sure that
> > whether something that is distributed under a certain license is
> > executed or not is irrelevant (unless of course the license covers
> > execution of the code).
>
> There's a difference between a legal report and the Yocto LICENSE tag.
> The Yocto tag is meant to be an over-all/community acknowledged license
> for the _code_ in the package that ends up as executable / script on
> the target. We should probably document this in greater detail, perhaps
> in:
>
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-LICENSE
>
> A more comprehensive analysis usually includes a file by file
> IP report often accompanied by a summary generated by an IP expert.
>
> >
> >> The other files, although they came from source packages,
> >> are *only* used as  test data. The source code has been completely
> >> stripped out, hasn't it?
> >
> > Given that they were originally distributed in an archive together
> > with a LICENSE/COPYING/similar file covering the entire archive,
> > those files are still covered by that license even if they are not
> > source files per se.
>
>
> Licenses describe the terms that apply to items that are covered
> under copyright. Data generally can not be copyrighted.
>
>  From my IP contact:
>
> ---
>
> In order for something to be copyrightable three requirements
> must be satisfied:
>
>   1. The work represents a creative form of expression
>      (basic facts do not represent a creative form of expression)
>
>   2. The work is original (novel) – not copied from someone else.
>      Two different people could come up with similar creative forms
>      of expression. They just can’t copy from someone else.
>
>   3. It must be put in tangible form (e.g., written, digital, …).
>      Someone can’t just claim it resides inside their head.
>
>
>
> Data as a general is not copyrightable because it fails number 1.
> However if someone can argue that a certain compilation of data
> represents some form of creative expression, they might have a case.
> This is discussed in the first two paragraphs here:
>
>     https://libguides.library.kent.edu/data-management/copyright
>
>
> Data can be protected under patent or trade secret law but different
> requirements apply and a different license would need to be created.
> Open Source licenses are largely copyright licenses. Although sometimes
> they include patent terms, they are generally not considered patent
> licenses.
>
> ---
>
>
> Most of the files here are clearly just data and
> are therefore neither subject to copyright nor governed by
> typical open source licenses.
>
> Some possible exceptions are:
>
> dotnetzip/dancing-color.ps.bz2
>    - This could be considered as software since that's what a PostScript
>      file is. In fact it's the 'Dancing links" paper by Donald Knuth:
>      https://www-cs-faculty.stanford.edu/~knuth/preprints.html
>      Copyright is not asserted but is of course implied for such works.
>      No licensing terms are declared.
>
> go/compress/Isaac.Newton-Opticks.txt.bz2
>    - out of copyright since unfortunately the author died long ago :-/
>      It seems that the people who prepared this document:
>        "Produced by Suzanne Lybarger, steve harris, Josephine
>        Paolucci and the Online Distributed Proofreading Team at
>        http://www.pgdp.net. "
>      are interested in:
>         "...dedicated to the preservation of written works
>          that are in the Public Domain ..."
>
> https://www.pgdp.net/wiki/DP_Official_Documentation:General/Distributed_Proofreaders_Mission_Statement
>
>
>
> It seems that the README/COPYING/LICENSE.txt/... files
> were left in the repo by people who while well intentioned,
> were misguided. We could try to fix that error upstream.
>
>
> >
> >> If, instead of compressed data,
> >> someone were to give me an image file covered by a creative common's
> >> license and the image had a watermark that when extracted produced
> >> file with source code with a FOO license, would you change the
> >> package license to include FOO? In fact, we don't even look at
> >> image file licensing let alone at embedded watermarks.
> >
> > Well, if there is a file distributed in the picture (not using the
> > word "image" here to avoid confusing the discussion any more) in the
> > form of a watermark, then that is no different from distributing it
> > as part of a tar.gz file (albeit a bit unusual). Whatever license
> > that file is covered by still applies in both cases.
>
>
> To me, this is the crux of the matter, i.e.:
>    "Whatever license that file is covered by
>     still applies in both cases."
>
> I agree with you but I think that the LICENSE can not and should
> not and was not meant to apply to the data files.
>
> >
> > Actually, here is something to think about. I recently read an
> > article published by the Linux Foundation called "Docker Containers
> > for Legal Professionals". [1] There they discussed the distribution
> > of Docker images. Consider this, you take an existing Docker image,
> > e.g., fedora:32, and remove everything that is covered by GPL-3.0
> > (not sure how to actually accomplish that, but anyway) and then you
> > distribute this new Docker image to someone. Does this mean that
> > GPL-3.0 covered code is being distributed? The answer is yes.
> > Because of the way Docker images are made up from layers, you need
> > to adhere to the licenses covering everything in all layers, not
> > just the final result. And somewhere down the stack of layers
> > making up your Docker image is still all of that GPL-3.0 code
> > that you removed in a higher layer.
>
> Yes, that's an interesting case that makes sense due to the layered
> nature of the docker images.
>
> >
> >> I'm not a lawyer so this is simply my opinion on the matter.
> >> How do we come to an agreement?
> >> I'd be happy to add a comment in the recipe explaining our position:
> >>
> >> # This package contains a script and test data this is derived from
> >> # other software packages as explained in the top level README.
> >> # Although there are COPYING files explaining the license terms
> >> # for each sub-directory, the files in each directory are only used
> >> # as test data so the LICENSING terms do not appear to apply to
> >> # the recipe as we ship it and have therefore NOT been incorporated
> >> # into the bzip2-ptests recipe licensing tags.
> >
> > I would be very worried seeing such a statement, and I believe any
> > lawyer would too.
>
> As written I agree but if I change it to:
>
>  >> # This package contains a script and test data this is derived from
>  >> # other software packages as explained in the top level README.
>  >> # Although there are COPYING files explaining the license terms
>  >> # for each sub-directory, the files in each directory are only used
> # for each sub-directory, the files in each directory are only
>
>  >> # as test data so the LICENSING terms do not appear to apply to
> # test data so the LICENSING terms do not appear to apply to
>
>  >> # the recipe as we ship it and have therefore NOT been incorporated
>  >> # into the bzip2-ptests recipe licensing tags.
>
>
> would that make more sense?
>
>
> So this email chain is all about deciding between:
> 1) LICENSE = \
>    "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>
> and
>
> 2) LICENSE = "GPLv3+"
>
>
> My vote is still for 2). Yours?

If the bzip2-tests repository is added to SRC_URI then it will be
considered part of the "sources" when you collect all the sources
using something like the archiver bbclass. So LICENSE needs to state
the conditions which need to be followed if you then distribute all
those sources together as an aggregate.

Therefore option (1) is the more accurate representation of the
licenses as they're reported to us by upstream. I'd follow that unless
you've got reason to believe that upstream (in this case,
https://sourceware.org/git/?p=bzip2-tests.git;a=tree) are wrong about
their own licenses.

If you have reason to believe that upstream are wrong then that should
be discussed upstream if possible and any conclusions reached should
go into the recipe as a comment alongside the LICENSE line.

I also think it's worth making clear that the job of OpenEmbedded /
Yocto Project is not to provide legal advice on how to interpret the
various upstream collections of license conditions and license files
that we find. We're not qualified or resourced to do that and it's
always nuanced by jurisdiction and other concerns in practice anyway.
So when I say "any conclusions reached should go into the recipe as a
comment", those conclusions should be about where those license
conditions come from rather than justifying some interpretation of the
conditions.

Thanks,

-- 
Paul Barker
Konsulko Group

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Rahul Kumar
> Sent: den 23 april 2020 20:40
> To: openembedded-core@lists.openembedded.org
> Cc: Rahul Kumar <rahulk@mvista.com>
> Subject: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> 
> Source: git://sourceware.org/git/bzip2-tests.git
> Type: Enhancement
> Description:
> bzip2 now has a test suite available at git://sourceware.org/git/bzip2-
> tests.git.
> 
> This is a collection of "interesting" .bz2 files that can be used to
> test bzip2 works correctly. They come from different projects.
> 
> Some files are deliberately bad, and are use to see how bzip2 handles
> corrupt files. They are explicitly not intended to decompress correctly,
> but to catch errors in bzip2 trying to deal with deliberately bad data.
> All such files have a name ending in .bz2.bad.
> 
> All non-bad files end in bz2. And should come with a .md5 file for
> the original input file. The .md5 file is used to check that bzip2
> could correctly decompress the file. The original (non-compressed)
> files are deliberately not checked in.
> 
> It will by default test with the command 'bzip2', running under
> valgrind (if installed on the system).
> 
> For each .bz2 file found it is decompressed, recompressed and
> decompressed again. Once with the default bzip2 settings and
> once in --small (-s) mode.
> 
> For each .bz2.bad file decompression is tried twice also. In
> default mode and small mode. The bzip2 binary is expected to
> return either 1 or 2 as exit status. Any other exit code is
> interpreted as failure.
> 
> License:
>    In bzip2-tests source code Each directory should contain a README
>    file explaining where the .bz2 files originally came from.
>    Plus a reference to the (Free Software) license that the project
>    files were distributed under.
> 
>    Adding GPLv3+ License to the bzip2 recipe. Since we modify the
>    bzip2-tests.git/run-tests.sh script and we can redistribute it and/or
>    modify it under the terms of the GNU General Public License (GPL);
>    either version 3, or (at your option) any later version.
> 
>    since all other files and directories are unchanged and We are simply
>    using the compressed files as data so we are ignoring the license info for
>    these files and directories in bzip2-tests.git

This is not how licenses work. They typically relate to distribution. 
I.e., it is the act of distributing the code that is covered in the 
license. It does not matter if what is distributed is later used as 
source or as a binary blob, it is still being distributed.

Since the code that is covered by, e.g., GPL-3.0 is only distributed in 
the ptest package, you will have to set individual package licenses. I.e., 
LICENSE should contain all licenses used by any package. Then for each 
package that should have a different license, you need to define it 
explicitly. E.g.:

LICENSE_${PN} = "bzip2-1.0.6"
LICENSE_${PN}-dev = "bzip2-1.0.6"
LICENSE_${PN}-dbg = "bzip2-1.0.6"
LICENSE_${PN}-doc = "bzip2-1.0.6"
LICENSE_${PN}-src = "bzip2-1.0.6"
LICENSE_libbz2 = "bzip2-1.0.6"

The above assumes that what is covered by the GPL-3.0 license only ends 
up in ${PN}-ptest. If any of it ends up in any of the other packages 
above, then obviously they need to be removed from the list too.

//Peter

> Test Summery:
>    On qemux86-64/kvm the ptest results with extra filesystem space
> (atleast 114688) are:
> 
> TOTAL: 	396
> PASS: 	396
> SKIP: 	0
> XFAIL: 	0
> FAIL: 	0
> XPASS: 	0
> ERROR: 	0
> 
> All tests passed
> DURATION: 517
> 
> [YOCTO #13444]
> 
> Signed-off-by: Rahul Kumar <rahulk@mvista.com>
> ---
>  .../bzip2/0001-bzip2-modify-run-tests-script.patch | 188
> +++++++++++++++++++++
>  meta/recipes-extended/bzip2/bzip2/Makefile.am      |   2 +
>  meta/recipes-extended/bzip2/bzip2_1.0.8.bb         |   9 +-
>  3 files changed, 197 insertions(+), 2 deletions(-)
>  create mode 100644 meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-
> run-tests-script.patch
> 
> diff --git a/meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-run-
> tests-script.patch b/meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-
> run-tests-script.patch
> new file mode 100644
> index 0000000..900a9aa
> --- /dev/null
> +++ b/meta/recipes-extended/bzip2/bzip2/0001-bzip2-modify-run-tests-
> script.patch
> @@ -0,0 +1,188 @@
> +From 8e704bc7bf25f892968eac8bcb40a205248ff5b2 Mon Sep 17 00:00:00 2001
> +From: Rahul Kumar <rahulk@mvista.com>
> +Date: Mon, 30 Mar 2020 12:17:00 +0530
> +Subject: [PATCH] bzip2: modify run-tests script
> +
> +1) modify run-tests script to write PASS/FAIL as expected by the ptest
> infrastructure
> +
> +2) Since the discrete md5sum does not have a short form of --status.And
> minimal base
> +   images does not support commands with long form arguments so dropping
> this
> +   argument
> +
> +Upstream-Status: Submitted [bzip2-devel@sourceware.org]
> +- Submitted to bzip2 mailing list and waiting approval
> +
> +Signed-off-by: Rahul Kumar <rahulk@mvista.com>
> +---
> + run-tests.sh | 62 ++++++++++++++++++++++++++++++++---------------------
> -------
> + 1 file changed, 33 insertions(+), 29 deletions(-)
> +
> +diff --git a/run-tests.sh b/run-tests.sh
> +index 1ba8c27..771584d 100755
> +--- a/run-tests.sh
> ++++ b/run-tests.sh
> +@@ -40,21 +40,21 @@ case $i in
> + esac
> + done
> +
> +-if ! type "valgrind" > /dev/null; then
> ++if ! type "valgrind" > /dev/null 2>&1; then
> +   VALGRIND=""
> +   VALGRIND_ARGS=""
> + fi
> +
> + echo "Testing ${BZIP2} in directory ${TESTS_DIR}"
> + if [ "$VALGRIND" != "" ]; then
> +-  echo "  using valgrind"
> ++  echo "Using valgrind: Yes"
> + else
> +-  echo "  NOT using valgrind"
> ++  echo "Using valgrind: No"
> + fi
> + if [[ ${IGNORE_MD5} -eq 0 ]]; then
> +-  echo "  checking md5 sums"
> ++  echo "Checking md5 sums: Yes"
> + else
> +-  echo "  NOT checking md5 sums"
> ++  echo "Checking md5 sums: No"
> + fi
> +
> + # Remove any left over tesfilecopies from previous runs first.
> +@@ -78,14 +78,14 @@ while IFS= read -r -d '' bzfile; do
> +   # Decompress it.
> +   echo "  Decompress..."
> +   rm -f "${file}"
> +-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q ${bzfile} \
> +-    || { echo "!!! bad decompress result $?";
> ++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q ${bzfile} && { echo
> "PASS: ${bzfile} Decompress"; } \
> ++    || { echo "FAIL: ${bzfile} Decompress";
> +          badtests=("${badtests[@]}" $"${bzfile} bad decompress result")
> +          nogood=$[${nogood}+1]; continue; }
> +
> +   if [[ ${IGNORE_MD5} -ne 1 ]]; then
> +-    md5sum --check --status ${md5file} < ${file} \
> +-      || { echo "!!! md5sum doesn't match decompressed file";
> ++    md5sum -c ${md5file} < ${file} && { echo "PASS: ${bzfile} md5sum
> Matched"; } \
> ++      || { echo "FAIL: ${bzfile} md5sum Matched";
> +            badtests=("${badtests[@]}" $"${file} md5sum doesn't match")
> +            nogood=$[${nogood}+1]; continue; }
> +   fi
> +@@ -94,19 +94,19 @@ while IFS= read -r -d '' bzfile; do
> +   mv "${file}" "${copy}"
> +   rm -f "${bzcopy}"
> +   echo "  Recompress..."
> +-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} \
> +-    || { echo "!!! bad compress result $?";
> ++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} && { echo
> "PASS: ${bzfile} Recompress "; } \
> ++    || { echo "FAIL: ${bzfile} Recompress";
> +          badtests=("${badtests[@]}" $"${copy} bad result")
> +          nogood=$[${nogood}+1]; continue; }
> +   echo "  Redecompress..."
> +-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} \
> +-    || { echo "!!! bad (re)decompress result $?";
> ++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} && { echo
> "PASS: ${bzfile} Redecompress"; } \
> ++    || { echo "FAIL: ${bzfile} Redecompress";
> +          badtests=("${badtests[@]}" $"${bzcopy} bad result")
> +          nogood=$[${nogood}+1]; continue; }
> +
> +   if [[ ${IGNORE_MD5} -ne 1 ]]; then
> +-    md5sum --check --status ${md5file} < ${copy} \
> +-      || { echo "!!! md5sum doesn't match (re)decompressed file";
> ++    md5sum -c ${md5file} < ${copy} && { echo "PASS: ${bzfile} md5sum
> Matched"; } \
> ++      || { echo "FAIL: ${bzfile} md5sum Matched";
> +            badtests=("${badtests[@]}" $"${copy} md5sum doesn't match")
> +            nogood=$[${nogood}+1]; continue; }
> +   fi
> +@@ -116,14 +116,14 @@ while IFS= read -r -d '' bzfile; do
> +   # Now do it all again in "small" mode.
> +   echo "  Decompress (small)..."
> +   rm -f "${file}"
> +-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q -s ${bzfile} \
> +-    || { echo "!!! bad decompress result $?";
> ++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -k -d -q -s ${bzfile} &&{ echo
> "PASS: ${bzfile} Decompress (small)"; } \
> ++    || { echo "FAIL: ${bzfile} Decompress (small)";
> +          badtests=("${badtests[@]}" $"${bzfile} bad decompress result")
> +          nogood=$[${nogood}+1]; continue; }
> +
> +   if [[ ${IGNORE_MD5} -ne 1 ]]; then
> +-    md5sum --check --status ${md5file} < ${file} \
> +-      || { echo "!!! md5sum doesn't match decompressed file";
> ++    md5sum -c ${md5file} < ${file} && { echo "PASS: ${bzfile} Md5sum
> Matched"; } \
> ++      || { echo "FAIL: ${bzfile} Md5sum Matched";
> +            badtests=("${badtests[@]}" $"${file} md5sum doesn't match")
> +            nogood=$[${nogood}+1]; continue; }
> +   fi
> +@@ -132,19 +132,19 @@ while IFS= read -r -d '' bzfile; do
> +   mv "${file}" "${copy}"
> +   rm -f "${bzcopy}"
> +   echo "  Recompress (small)..."
> +-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} \
> +-    || { echo "!!! bad compress result $?";
> ++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -z -q -s ${copy} && { echo
> "PASS: ${bzfile} Recompress (small)"; } \
> ++    || { echo "FAIL: ${bzfile} Recompress (small)";
> +          badtests=("${badtests[@]}" $"${copy} bad result")
> +          nogood=$[${nogood}+1]; continue; }
> +   echo "  Redecompress (small)..."
> +-  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} \
> +-    || { echo "!!! bad (re)decompress result $?";
> ++  ${VALGRIND} ${VALGRIND_ARGS} ${BZIP2} -d -q -s ${bzcopy} && { echo
> "PASS: ${bzfile} Redecompress (small)"; } \
> ++    || { echo "FAIL: ${bzfile} Redecompress (small)";
> +          badtests=("${badtests[@]}" $"${bzcopy} bad result")
> +          nogood=$[${nogood}+1]; continue; }
> +
> +   if [[ ${IGNORE_MD5} -ne 1 ]]; then
> +-    md5sum --check --status ${md5file} < ${copy} \
> +-      || { echo "!!! md5sum doesn't match (re)decompressed file";
> ++    md5sum -c ${md5file} < ${copy} && { echo "PASS: ${bzfile} md5sum
> Matched"; } \
> ++      || { echo "FAIL: ${bzfile} md5sum : Miss Matched";
> +            badtests=("${badtests[@]}" $"${copy} md5sum doesn't match")
> +            nogood=$[${nogood}+1]; continue; }
> +   fi
> +@@ -176,7 +176,7 @@ while IFS= read -r -d '' badfile; do
> +   ret=$?
> +
> +   if [[ ${ret} -eq 0 ]]; then
> +-    echo "!!! badness not detected"
> ++    echo "FAIL: badness not detected"
> +     nobad=$[${nobad}+1]
> +     badtests=("${badtests[@]}" $"${badfile} badness not detected")
> +     continue
> +@@ -185,10 +185,12 @@ while IFS= read -r -d '' badfile; do
> +   # Assumes "normal" badness is detected by exit code 1 or 2.
> +   # A crash or valgrind issue will be reported with something else.
> +   if [[ ${ret} != 1 ]] && [[ ${ret} != 2 ]]; then
> +-    echo "!!! baddness caused baddness in ${BZIP2}"
> ++    echo "FAIL: baddness caused baddness in ${BZIP2}"
> +     badbad=$[${badbad}+1]
> +     badtests=("${badtests[@]}" $"${badfile} badness caused baddness")
> +     continue
> ++  else
> ++    echo "PASS: Correctly found data integrity errors in ${badfile}
> during decompress."
> +   fi
> +
> +   echo "  Trying to decompress (small)..."
> +@@ -196,7 +198,7 @@ while IFS= read -r -d '' badfile; do
> +   ret=$?
> +
> +   if [[ ${ret} -eq 0 ]]; then
> +-    echo "!!! badness not detected"
> ++    echo "FAIL: badness not detected "
> +     nobad=$[${nobad}+1]
> +     badtests=("${badtests[@]}" $"${badfile} badness not detected")
> +     continue
> +@@ -205,10 +207,12 @@ while IFS= read -r -d '' badfile; do
> +   # Assumes "normal" badness is detected by exit code 1 or 2.
> +   # A crash or valgrind issue will be reported with something else.
> +   if [[ ${ret} != 1 ]] && [[ ${ret} != 2 ]]; then
> +-    echo "!!! baddness caused baddness in ${BZIP2}"
> ++    echo "FAIL: baddness caused baddness in ${BZIP2}"
> +     badbad=$[${badbad}+1]
> +     badtests=("${badtests[@]}" $"${badfile} badness caused baddness")
> +     continue
> ++  else
> ++    echo "PASS: Correctly found data integrity errors in ${badfile}
> during decompress (small)"
> +   fi
> +
> + done < <(find ${TESTS_DIR} -type f -name \*\.bz2.bad -print0)
> +--
> +2.7.4
> diff --git a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> index dcf6458..aab6558 100644
> --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> @@ -46,6 +46,7 @@ runtest:
>  	else echo "FAIL: sample2 decompress"; fi
>  	@if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> decompress";\
>  	else echo "FAIL: sample3 decompress"; fi
> +	./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
> 
>  install-ptest:
>  	sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
> @@ -56,6 +57,7 @@ install-ptest:
>  	cp $(srcdir)/sample1.bz2	$(DESTDIR)/
>  	cp $(srcdir)/sample2.bz2	$(DESTDIR)/
>  	cp $(srcdir)/sample3.bz2	$(DESTDIR)/
> +	cp -rf $(srcdir)/../git		$(DESTDIR)/bzip2-
> tests
>  	ln -s $(bindir)/bzip2		$(DESTDIR)/bzip2
> 
>  install-exec-hook:
> diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb b/meta/recipes-
> extended/bzip2/bzip2_1.0.8.bb
> index 8e9b779..983fabd 100644
> --- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> +++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
> @@ -4,17 +4,22 @@ Huffman coding. Compression is generally considerably
> better than that achieved
>  LZ77/LZ78-based compressors, and approaches the performance of the PPM
> family of statistical compressors."
>  HOMEPAGE = "https://sourceware.org/bzip2/"
>  SECTION = "console/utils"
> -LICENSE = "bzip2"
> +LICENSE = "bzip2 & GPLv3+"
>  LIC_FILES_CHKSUM =
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df46
> 64"
> 
>  SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \
> +           git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests \
>             file://configure.ac;subdir=${BP} \
>             file://Makefile.am;subdir=${BP} \
>             file://run-ptest \
> +           file://0001-bzip2-modify-run-tests-
> script.patch;patchdir=${WORKDIR}/git \
>             "
> +
>  SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5"
>  SRC_URI[sha256sum] =
> "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
> 
> +SRCREV_bzip2-tests = "8b0198efda1603cf81fa2c7a9bb673dd22ae1661"
> +
>  UPSTREAM_CHECK_URI = "https://www.sourceware.org/pub/bzip2/"
> 
>  PACKAGES =+ "libbz2"
> @@ -39,7 +44,7 @@ do_install_ptest () {
> 
>  FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
> 
> -RDEPENDS_${PN}-ptest += "make"
> +RDEPENDS_${PN}-ptest += "make bash"
> 
>  PROVIDES_append_class-native = " bzip2-replacement-native"
>  BBCLASSEXTEND = "native nativesdk"
> --
> 2.7.4

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 3760 bytes --]



On 5/11/20 11:53 PM, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Rahul Kumar
>> Sent: den 23 april 2020 20:40
>> To: openembedded-core@lists.openembedded.org
>> Cc: Rahul Kumar <rahulk@mvista.com>
>> Subject: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>>
>> Source: git://sourceware.org/git/bzip2-tests.git
>> Type: Enhancement
>> Description:
>> bzip2 now has a test suite available at git://sourceware.org/git/bzip2-
>> tests.git.
>>
>> This is a collection of "interesting" .bz2 files that can be used to
>> test bzip2 works correctly. They come from different projects.
>>
>> Some files are deliberately bad, and are use to see how bzip2 handles
>> corrupt files. They are explicitly not intended to decompress correctly,
>> but to catch errors in bzip2 trying to deal with deliberately bad data.
>> All such files have a name ending in .bz2.bad.
>>
>> All non-bad files end in bz2. And should come with a .md5 file for
>> the original input file. The .md5 file is used to check that bzip2
>> could correctly decompress the file. The original (non-compressed)
>> files are deliberately not checked in.
>>
>> It will by default test with the command 'bzip2', running under
>> valgrind (if installed on the system).
>>
>> For each .bz2 file found it is decompressed, recompressed and
>> decompressed again. Once with the default bzip2 settings and
>> once in --small (-s) mode.
>>
>> For each .bz2.bad file decompression is tried twice also. In
>> default mode and small mode. The bzip2 binary is expected to
>> return either 1 or 2 as exit status. Any other exit code is
>> interpreted as failure.
>>
>> License:
>>    In bzip2-tests source code Each directory should contain a README
>>    file explaining where the .bz2 files originally came from.
>>    Plus a reference to the (Free Software) license that the project
>>    files were distributed under.
>>
>>    Adding GPLv3+ License to the bzip2 recipe. Since we modify the
>>    bzip2-tests.git/run-tests.sh script and we can redistribute it and/or
>>    modify it under the terms of the GNU General Public License (GPL);
>>    either version 3, or (at your option) any later version.
>>
>>    since all other files and directories are unchanged and We are simply
>>    using the compressed files as data so we are ignoring the license info for
>>    these files and directories in bzip2-tests.git
> 
> This is not how licenses work. They typically relate to distribution. 
> I.e., it is the act of distributing the code that is covered in the 
> license. It does not matter if what is distributed is later used as 
> source or as a binary blob, it is still being distributed.
> 
> Since the code that is covered by, e.g., GPL-3.0 is only distributed in 
> the ptest package, you will have to set individual package licenses. I.e., 
> LICENSE should contain all licenses used by any package. Then for each 
> package that should have a different license, you need to define it 
> explicitly. E.g.:
> 
> LICENSE_${PN} = "bzip2-1.0.6"
> LICENSE_${PN}-dev = "bzip2-1.0.6"
> LICENSE_${PN}-dbg = "bzip2-1.0.6"
> LICENSE_${PN}-doc = "bzip2-1.0.6"
> LICENSE_${PN}-src = "bzip2-1.0.6"
> LICENSE_libbz2 = "bzip2-1.0.6"
> 
> The above assumes that what is covered by the GPL-3.0 license only ends 
> up in ${PN}-ptest. If any of it ends up in any of the other packages 
> above, then obviously they need to be removed from the list too.

right, as such this patch will mean bzip2 has to be skipped for distros
which have no GPL3 policy. Its better to have per-package licenses
expressed here.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]