Date   

Re: How to install rrdtool-per package?

ingemar0720@...
 

On Wed, Jul 1, 2020 at 04:46 AM, Josef Holzmayr wrote:
The correct place to do this is your DISTRO conf file.

Is this the correct way to set up it?

PACKAGECONFIG_pn-rrdtool="rrdtool rrdtool-perl"

 


Re: How to install rrdtool-per package?

Josef Holzmayr <holzmayr@...>
 

Howdy!

Am 01.07.2020 um 13:04 schrieb ingemar0720@gmail.com:
Hello Josef
Thanks for you reply!
From your link, it seems rrdtool recipe already give an alias as `rrdtool-perl`, is it correct?
Exactly. If activated, then the rrdtool recipe already procides the rrdtool-perl package.

Then shall I add PACKAGECONFIG in .bbappend file for rrdtool? Or i shall add in my own recipe?
The correct place to do this is your DISTRO conf file.

Greetz

--
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


Re: How to install rrdtool-per package?

ingemar0720@...
 

Hello Josef

Thanks for you reply!
From your link, it seems rrdtool recipe already give an alias as `rrdtool-perl`, is it correct?

Then shall I add PACKAGECONFIG in .bbappend file for rrdtool? Or i shall add in my own recipe?


Re: Dunfell 3.1.1 gcc-sanitizers build failure

MikeB
 

The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.

Thank you all for the help!

On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@...> wrote:
On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@...>
wrote:
>
> On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@...> wrote:
> >
> > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@...> wrote:
> > >
> > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@...> wrote:
> > > >
> > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
> > > >
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > > | ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > >
> > > > At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
> > >
> > > I've encountered a similar error just today when switching SDKMACHINE.
> > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> > > just recently fixed a bug in archive.bbclass
> > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> > > gcc-source raced with do_preconfigure and I'm wondering if it's
> > > related
> >
> > I believe I have fixed this in
> > https://lists.openembedded.org/g/openembedded-core/message/140161,
> > please try it out to make sure it solves your issue as well.
>
> That patch came in after the 3.1.1 release, but it is present in the
> dunfell branch so it will make it into 3.1.2

Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: How to install rrdtool-per package?

Josef Holzmayr <holzmayr@...>
 

Howdy!

Looks very much like you'll need to set up PACKAGECONFIG of rrdtool, then it should provide rrdtool-perl.

See also: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rrdtool/rrdtool_1.7.2.bb?h=master#n104

Greetz

Am 01.07.2020 um 11:50 schrieb ingemar0720@gmail.com:

My Yocto build failed and it seems to be looking for "rrdtool-perl" package. I've added package "rrdtool" into my "INSTALL_APPEND" variable but it still fail. The logs is in below. Could someone helped me to find the correct recipe to install it?
"""
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Wed 01 Jul 2020 09:34:21 AM UTC.
Last metadata expiration check: 0:00:01 ago on Wed 01 Jul 2020 09:34:22 AM UTC.
No module defaults found
--> Starting dependency resolution
--> Finished dependency resolution
Error:
 Problem: conflicting requests
  - nothing provides rrdtool-perl needed by rpimonitor-2.13-r0.arm1176jzfshf_vfp
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
ERROR: Logfile of failure stored in: /home/ingemar/yocto/sdk/build/tmp/work/raspberrypi0_wifi-poky-linux-gnueabi/rpi-image/1.0-r0/temp/log.do_rootfs.27003
ERROR: Task (/home/ingemar/yocto/sdk/build/../build/meta-rpi/recipes-core/images/rpi-image.bb:do_rootfs) failed with exit code '1'
"""
--
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


How to install rrdtool-per package?

ingemar0720@...
 

My Yocto build failed and it seems to be looking for "rrdtool-perl" package. I've added package "rrdtool" into my "INSTALL_APPEND" variable but it still fail. The logs is in below. Could someone helped me to find the correct recipe to install it?

 

"""

repo: using cache for: oe-repo

not found other for:

not found modules for:

not found deltainfo for:

not found updateinfo for:

oe-repo: using metadata from Wed 01 Jul 2020 09:34:21 AM UTC.

Last metadata expiration check: 0:00:01 ago on Wed 01 Jul 2020 09:34:22 AM UTC.

No module defaults found

--> Starting dependency resolution

--> Finished dependency resolution

Error:

 Problem: conflicting requests

  - nothing provides rrdtool-perl needed by rpimonitor-2.13-r0.arm1176jzfshf_vfp

(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

 

ERROR: Logfile of failure stored in: /home/ingemar/yocto/sdk/build/tmp/work/raspberrypi0_wifi-poky-linux-gnueabi/rpi-image/1.0-r0/temp/log.do_rootfs.27003

ERROR: Task (/home/ingemar/yocto/sdk/build/../build/meta-rpi/recipes-core/images/rpi-image.bb:do_rootfs) failed with exit code '1'

"""


Re: Need help understanding #devtool flow to library #devtool

tobies@...
 

Hi Quentin

That was indeed the problem. The reason that my code was not working as expected was not in the devtool flow but in my code :-).

So now on to debugging my real problem.

Thanks a lot!

Stephan


Re: License reporting for golang (and rust)

Robert Berger
 

Hi,

My comments are in-line

On 30/06/2020 14:37, Irving ST wrote:
Hi,
For anyone else having the same problem, here's what I eventually did
for my go stuff:
I created a bbclass containing a task that gets inherited by all
packages, but the task only does some work when it detects that it is
inherited by a golang recipe.
The task basically sets up GOPATH and calls
https://github.com/rancher/trash - this tool populates all the source
dependencies and generate a trash.lock file in the repository.
Then I used https://github.com/pivotal/LicenseFinder to generate a
json report that can be postprocessed with python.
Is your work available somewhere in the public? I would like to give it a try with dunfell 3.1.1 and influxdb.[1] Also it would be interesting what happens if you include a prebuilt go executable[2].

[1] https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-from-source/github.com-influxdata-influxdb/github.com-influxdata-influxdb_1.8.0.bb (from khem and slightly hacked)

[2] https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-prebuilt/influxdb/influxdb_1.8.0.bb

To me it seems that Go used the vendor directory approach in the past,
and there are multiple tools that can be used for this; and nowadays
go seems to have switched to a different approach called go modules.
It looks like master and dunfell 3.1.1 support go modules now.[3][4]

[3] http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=7892a056f7e03e9c086148f8f027bd1cebf2aa68
[4] http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=ce277ec45f1f241b1eb17ea6999dbe5a718b898a

Now we have both go dep and go modules support ;)

With this multiple tools and methods of managing dependencies, I am
not sure whether it is feasible to integrate this in Yocto at all -
though I think I have seen mailing list posts on meta-virtualization
adding vendor information to their recipes, so maybe some progress is
happening there.
Currently arm 32 Golang support is broken in meta-virt (docker), but I am confident it's going to be fixed soon.[5]

[5] https://lists.yoctoproject.org/g/meta-virtualization/message/5488?p=,,,20,0,0,0::Created,,docker,20,2,0,75127700

Best regards,
Irving Tjiptowarsono
Regards,

Robert


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Steve Sakoman
 

On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.
That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2
Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Steve Sakoman
 

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.
That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2

Steve


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Joshua Watt
 

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.



I've attached the full error log. Any troubleshooting advice would be appreciated.


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Joshua Watt
 

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related


I've attached the full error log. Any troubleshooting advice would be appreciated.


Re: M+ & H bugs with Milestone Movements WW26

Armin Kuster
 


Stephen,

On 6/30/20 4:28 PM, Stephen Jolley wrote:

All,

Thanks for sending this out.


Is there any priority to these that may help the community pick off the ones most important to the Project?

-armin

YP M+ or high bugs which moved to a new milestone in WW26 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

13947

buildtools checksum files are named different on non-release and release builds

richard.purdie@...

vineela.tummalapalli@...

3.2 M1

3.2 M2

Medium+

5322

Global DNS fallback mechanism not present in poky distro

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

10693

Add a testcase for multilib eSDK on the autobuilder

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

11449

Allow overriding classes to override overridden classes

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

11746

oe-selftest: capture self.logger messages in XML output

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

11906

rpmbuild: Can not build packages on qemu target

hongxu.jia@...

hongxu.jia@...

3.2 M1

3.2 M4

 

12090

bitbake resident server reconnect needed ?

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

12279

enhance manifest not found warning

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

12342

lib32-core-image-sato -ctestimage failed due to wrong package names

kai.kang@...

kai.kang@...

3.2 M1

3.2 M3

 

12368

persistent bitbake server does not re-parse if previous build was ctrl+C'd

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

12760

CMake Toolchain File Has Wrong Module Path

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.2 M1

3.2 M3

 

12970

uninative file should be versionned

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

12986

Failed to expand SRCPV on updateding SRC_URI using pn overrides and BBCLASSEXTEND

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13008

toaster testing

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13025

WIC image install support

kexin.hao@...

kexin.hao@...

3.2 M1

3.2 M2

 

13079

devtool documentation needs to mention oe-local-files

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13070

recipetool.RecipetoolTests.test_recipetool_load_plugin - Testcase 1640: FAILED

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13109

Implement CPE to package to Release mapping

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13183

bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13182

Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx failed

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

13190

RRS cannot handle multiple recipes with same PN

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13278

If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13288

pseudo should not follow symlinks in /proc

randy.macleod@...

seebs@...

3.2 M1

3.2 M2

 

13320

Update license files to match current SPDX names and license contents

randy.macleod@...

newcomer@...

3.2 M1

3.2 M2

 

13325

Add link to the output directory from LHS console view

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13355

RDEPENDS does not work properly for native builds (only supports recipe names, not package names)

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13417

Development manual coverage of devtool

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13424

devupstream doesn't work with mutilib

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13426

Loses track of data if file rename()d to same name

randy.macleod@...

seebs@...

3.2 M1

3.2 M2

 

13448

bitbake master appears to expand variables it should not need to

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13459

sdk: compiler targets glibc, even though rootfs uses musl-libc

randy.macleod@...

randy.macleod@...

3.2 M1

3.2 M2

 

13480

gcc-cross plugins feature cannot be used

zhe.he@...

zhe.he@...

3.2 M1

3.99

 

13489

layer index: properly handle issues in first parse

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13490

layer index: log failures during initial parse

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13495

Support building out container image without init manager

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

13508

Meson detects googletest installed on system

hongxu.jia@...

hongxu.jia@...

3.2 M1

3.2 M4

 

13581

Line wrapping over prompt in BASH

randy.macleod@...

jason.wessel@...

3.2 M1

3.2 M2

 

13599

Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13604

[master-next] Distrodata.test_maintainers  fails

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

13625

test_devtool_add_library fails in multilib setups

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13631

core-image-full-cmdline qemumips systemd boot failure

kai.kang@...

kai.kang@...

3.2 M1

3.2 M3

 

13642

Split single "run-config" step into multiple steps

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13646

runtime tests sometimes can't login to the serial console on systemd images (generates warning)

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13699

Prolonged recipe parsing times after removing tmp when the resident bitbake server is used

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13711

Parsing fails on externalsrc recipe containing both git and file in SRC_URI

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13727

unable to run dockerd on MACHINE=intel-corei7-64 yet works on MACHINE=genericx86-64

timothy.t.orling@...

ksaye@...

3.2 M1

3.2 M2

 

13729

Changing siteinfo files doesn't change task checksum

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13738

devtool modify fails with file:// fetcher

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13732

eSDK: getting error "xmlcatalog: not found" installing SDK

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

13748

bitbake doesn't detect changes in code to run do_compile when using devtool modify on recipe with destsuffix

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13804

do_package_qa race generating warning

richard.purdie@...

newcomer@...

3.2 M1

3.2 M2

 

13807

Add support for elfutils debuginfod

randy.macleod@...

newcomer@...

3.2 M1

3.2 M2

 

13823

fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13838

[QA 3.1 M3 RC1] failure in ptest: valgrind.drd/tests/bar_bad and valgrind.drd/tests/bar_bad_xml

randy.macleod@...

randy.macleod@...

3.2 M1

3.2 M2

 

13886

bitbake resident server does not honour --runonly or --runall options

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13891

insane.bbclass: do_package_qa hangs when checking a FIFO (named pipe) file

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13892

Cannot access the terminal via serial port on BeagleBone Black

kexin.hao@...

guillaume.bonnet@...

3.2 M1

3.2 M2

 

13893

bitbake considers any package name starting with "texinfo-native" as satisfiable DEPENDS

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13911

SystemExit failure when running oe-selftests

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

13904

do_prepare_recipe_sysroot: postinst-useradd-* does not run in order of dependency and sometimes fails

randy.macleod@...

sakib.sajal@...

3.2 M4

3.2 M2

 

13953

oe-selftest doesn't cleanup in non-parallel builds

richard.purdie@...

richard.purdie@...

3.2 M2

---

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 



    


M+ & H bugs with Milestone Movements WW26

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW26 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

13947

buildtools checksum files are named different on non-release and release builds

richard.purdie@...

vineela.tummalapalli@...

3.2 M1

3.2 M2

Medium+

5322

Global DNS fallback mechanism not present in poky distro

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

10693

Add a testcase for multilib eSDK on the autobuilder

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

11449

Allow overriding classes to override overridden classes

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

11746

oe-selftest: capture self.logger messages in XML output

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

11906

rpmbuild: Can not build packages on qemu target

hongxu.jia@...

hongxu.jia@...

3.2 M1

3.2 M4

 

12090

bitbake resident server reconnect needed ?

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

12279

enhance manifest not found warning

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

12342

lib32-core-image-sato -ctestimage failed due to wrong package names

kai.kang@...

kai.kang@...

3.2 M1

3.2 M3

 

12368

persistent bitbake server does not re-parse if previous build was ctrl+C'd

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

12760

CMake Toolchain File Has Wrong Module Path

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.2 M1

3.2 M3

 

12970

uninative file should be versionned

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

12986

Failed to expand SRCPV on updateding SRC_URI using pn overrides and BBCLASSEXTEND

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13008

toaster testing

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13025

WIC image install support

kexin.hao@...

kexin.hao@...

3.2 M1

3.2 M2

 

13079

devtool documentation needs to mention oe-local-files

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13070

recipetool.RecipetoolTests.test_recipetool_load_plugin - Testcase 1640: FAILED

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13109

Implement CPE to package to Release mapping

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13183

bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13182

Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx failed

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

13190

RRS cannot handle multiple recipes with same PN

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13278

If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13288

pseudo should not follow symlinks in /proc

randy.macleod@...

seebs@...

3.2 M1

3.2 M2

 

13320

Update license files to match current SPDX names and license contents

randy.macleod@...

newcomer@...

3.2 M1

3.2 M2

 

13325

Add link to the output directory from LHS console view

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13355

RDEPENDS does not work properly for native builds (only supports recipe names, not package names)

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13417

Development manual coverage of devtool

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13424

devupstream doesn't work with mutilib

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13426

Loses track of data if file rename()d to same name

randy.macleod@...

seebs@...

3.2 M1

3.2 M2

 

13448

bitbake master appears to expand variables it should not need to

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13459

sdk: compiler targets glibc, even though rootfs uses musl-libc

randy.macleod@...

randy.macleod@...

3.2 M1

3.2 M2

 

13480

gcc-cross plugins feature cannot be used

zhe.he@...

zhe.he@...

3.2 M1

3.99

 

13489

layer index: properly handle issues in first parse

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13490

layer index: log failures during initial parse

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13495

Support building out container image without init manager

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

13508

Meson detects googletest installed on system

hongxu.jia@...

hongxu.jia@...

3.2 M1

3.2 M4

 

13581

Line wrapping over prompt in BASH

randy.macleod@...

jason.wessel@...

3.2 M1

3.2 M2

 

13599

Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13604

[master-next] Distrodata.test_maintainers  fails

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

13625

test_devtool_add_library fails in multilib setups

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13631

core-image-full-cmdline qemumips systemd boot failure

kai.kang@...

kai.kang@...

3.2 M1

3.2 M3

 

13642

Split single "run-config" step into multiple steps

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13646

runtime tests sometimes can't login to the serial console on systemd images (generates warning)

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.2 M1

3.2 M2

 

13699

Prolonged recipe parsing times after removing tmp when the resident bitbake server is used

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13711

Parsing fails on externalsrc recipe containing both git and file in SRC_URI

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13727

unable to run dockerd on MACHINE=intel-corei7-64 yet works on MACHINE=genericx86-64

timothy.t.orling@...

ksaye@...

3.2 M1

3.2 M2

 

13729

Changing siteinfo files doesn't change task checksum

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13738

devtool modify fails with file:// fetcher

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13732

eSDK: getting error "xmlcatalog: not found" installing SDK

Qi.Chen@...

Qi.Chen@...

3.2 M1

3.2 M3

 

13748

bitbake doesn't detect changes in code to run do_compile when using devtool modify on recipe with destsuffix

timothy.t.orling@...

bluelightning@...

3.2 M1

3.2 M2

 

13804

do_package_qa race generating warning

richard.purdie@...

newcomer@...

3.2 M1

3.2 M2

 

13807

Add support for elfutils debuginfod

randy.macleod@...

newcomer@...

3.2 M1

3.2 M2

 

13823

fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13838

[QA 3.1 M3 RC1] failure in ptest: valgrind.drd/tests/bar_bad and valgrind.drd/tests/bar_bad_xml

randy.macleod@...

randy.macleod@...

3.2 M1

3.2 M2

 

13886

bitbake resident server does not honour --runonly or --runall options

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13891

insane.bbclass: do_package_qa hangs when checking a FIFO (named pipe) file

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13892

Cannot access the terminal via serial port on BeagleBone Black

kexin.hao@...

guillaume.bonnet@...

3.2 M1

3.2 M2

 

13893

bitbake considers any package name starting with "texinfo-native" as satisfiable DEPENDS

richard.purdie@...

richard.purdie@...

3.2 M1

3.2 M2

 

13911

SystemExit failure when running oe-selftests

kai.kang@...

kai.kang@...

3.2 M1

3.2 M2

 

13904

do_prepare_recipe_sysroot: postinst-useradd-* does not run in order of dependency and sometimes fails

randy.macleod@...

sakib.sajal@...

3.2 M4

3.2 M2

 

13953

oe-selftest doesn't cleanup in non-parallel builds

richard.purdie@...

richard.purdie@...

3.2 M2

---

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW26!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

timothy.t.orling@...

17

randy.macleod@...

5

akuster808@...

4

richard.purdie@...

4

david.reyna@...

2

JPEWhacker@...

1

bluelightning@...

1

jpuhlman@...

1

ricardo.ribalda@...

1

Grand Total

36

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Khem Raj
 

On 6/30/20 2:56 PM, MikeB wrote:
I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've attached the full error log.  Any troubleshooting advice would be appreciated.
try to do a bitbake -ccleansstate on gcc-source-9.3.0


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 342 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 38 bug owners as of the end of WW26 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 86 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

david.reyna@...

10

mark.morton@...

9

bluelightning@...

7

ross@...

7

richard.purdie@...

6

Qi.Chen@...

5

michael@...

5

jon.mason@...

3

yi.zhao@...

3

raj.khem@...

3

rpjday@...

3

trevor.gamblin@...

2

alejandro@...

2

ycnakajsph@...

2

kai.kang@...

2

sakib.sajal@...

2

dl9pf@...

2

mark.hatle@...

2

randy.macleod@...

2

mostthingsweb@...

2

timothy.t.orling@...

2

JPEWhacker@...

2

chee.yang.lee@...

2

kergoth@...

2

jaewon@...

2

matthew.zeng@...

1

bruce.ashfield@...

1

hongxu.jia@...

1

Martin.Jansa@...

1

maxime.roussinbelanger@...

1

bunk@...

1

naveen.kumar.saini@...

1

kai.ruhnau@...

1

liu.ming50@...

1

limon.anibal@...

1

denis@...

1

jpuhlman@...

1

changqing.li@...

1

Grand Total

102

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Dunfell 3.1.1 gcc-sanitizers build failure

MikeB
 

I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
 
At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.

I've attached the full error log.  Any troubleshooting advice would be appreciated.


Re: INCOMPATIBLE_LICENSE - how to use it properly?

Khem Raj
 

On 6/30/20 3:07 AM, Mikko Rapeli wrote:
Hi,
On Tue, Jun 30, 2020 at 09:34:39AM +0000, John Ernberg wrote:
Hi,

I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable
licenses for us from our images. I started simple and picked the
examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0).

Currently we're based on Warrior, but I also did a short test on master
(results later in the message)

Our images use systemd as init system. We use busybox ash as shell on
these images for now.

When setting the INCOMPATIBLE_LICENSE according to the manual example,
systemd cannot be built anymore because bash is being skipped due to
license.

Turns out that because systemd-bash-completion and
systemd-kernel-install both rdepend on bash, we can't build systemd at
all, because bash is not buildable. Even if we're not installing those
features of systemd.

A dive into TaskData suggests that all the rdepends of all packages
provided by a recipe are flattened into depends of the recipe when
testing buildability.

A quick test on master from about 2 weeks ago show the same behavior.

For the test on master all I did was change the DISTRO_FEATURES of
core-image-minimal to include systemd.


Am I using ICOMPATIBLE_LICENSE properly so far?
If so, is being unable to fulfill an rdepend for an unused package meant
to fail the whole build, and how can I avoid it short of including
meta-gplv2 or writing lots of .bbappends to remove the dependencies?
Otherwise, where did I go wrong, and what should I be trying instead?
You need to add exceptions to build a lot GPLv3 components but not let them
be part of product images.
In distro config:
INCOMPATIBLE_LICENSE += "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
...
WHITELIST_GPL-3.0 += "bash"
PACKAGE_EXCLUDE += "bash-ptest bash-dbg bash-staticdev bash-dev bash-doc bash-locale bashbug bash"
...
The PACKAGE_EXCLUDE must be complete list of binary packages produced by the recipe.

I think having two different distro configs is a reliable approach here, we keep adding more refined packaging which means you have to be on your toes all the time in the allowed list above.

I end up enabling a large set of GPLv3 tools for use as development tooling at build
time or in SDK:
$ grep WHITELIST_ distro.conf
WHITELIST_GPL-3.0 += "autoconf"
WHITELIST_GPL-3.0 += "bash"
WHITELIST_GPL-3.0 += "bc"
WHITELIST_GPL-3.0 += "binutils"
WHITELIST_GPL-3.0 += "bison"
WHITELIST_GPL-3.0 += "ccache"
WHITELIST_GPL-3.0 += "coreutils"
WHITELIST_GPL-3.0 += "diffutils"
WHITELIST_GPL-3.0 += "elfutils"
WHITELIST_GPL-3.0 += "findutils"
WHITELIST_GPL-3.0 += "gawk"
WHITELIST_GPL-3.0 += "gdb"
WHITELIST_GPL-3.0 += "gdbm"
WHITELIST_GPL-3.0 += "gettext"
WHITELIST_GPL-3.0 += "gnutls"
WHITELIST_GPL-3.0 += "grep"
WHITELIST_GPL-3.0 += "libevent"
WHITELIST_GPL-3.0 += "libpipeline"
WHITELIST_GPL-3.0 += "libunistring"
WHITELIST_GPL-3.0 += "m4"
WHITELIST_GPL-3.0 += "make"
WHITELIST_GPL-3.0 += "readline"
WHITELIST_GPL-3.0 += "rsync"
WHITELIST_GPL-3.0 += "sed"
WHITELIST_GPL-3.0 += "which"
If one does not do this, alternative is to use a bunch of old and deprecated tool
versions from meta-gplv2.
Hope this helps,
-Mikko

4921 - 4940 of 54718