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: [email protected] <https://plus.google.com/+CodeTwoSoftware> On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org <[email protected]> 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: [email protected] > <https://plus.google.com/+CodeTwoSoftware> > > > On Fri, May 1, 2020 at 6:56 AM Randy MacLeod <[email protected]> > 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 <[email protected] >> > <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]> >> > <https://plus.google.com/+CodeTwoSoftware> >> > >> > >> > On Mon, Apr 27, 2020 at 11:46 PM Richard Purdie >> > <[email protected] >> > <mailto:[email protected]>> 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 >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138149): https://lists.openembedded.org/g/openembedded-core/message/138149 Mute This Topic: https://lists.openembedded.org/mt/73224911/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
