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 (#137979): 
https://lists.openembedded.org/g/openembedded-core/message/137979
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to