Date   

Excluding kernel configuration fragment

Fred Baksik
 

What is the best way of excluding a kernel configuration fragment?

I am trying to disable sound support in the kernel.  I can create a fragment for this but then this conflicts with the other existing fragments.
For example when using meta-intel and removing sound support then you will receive warnings like:

WARNING: linux-intel-4.19.73+gitAUTOINC+a7cb57afb9_ca05e9cd64-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:

---------- CONFIG_USB_AUDIO -----------------
Config: CONFIG_USB_AUDIO
From: /.../build_corei7-64/tmp/work-shared/intel-corei7-64/kernel-source/.kernel-meta/configs/v4.19/standard/intel/features/usb/usb-gadgets.cfg
Requested value:  CONFIG_USB_AUDIO=m
Actual value:  

I haven't had much luck with the documentation finding how to prune machine features and fragments; I may just misunderstand how this is supposed to be done.


Re: How to PROVIDE boost-python

Emily
 

Hi Laurent - 

Thanks for the suggestion. It looks like there are a few packages that provide libboost_python3:

find tmp/work/*/*/*/packages-split -name libboost_python\*
tmp/work/aarch64-poky-linux/boost/1.64.0-r0/packages-split/boost-dev/usr/lib/libboost_python3.so
tmp/work/aarch64-poky-linux/boost/1.64.0-r0/packages-split/boost-python/usr/lib/libboost_python3.so.1.64.0
tmp/work/aarch64-poky-linux/boost/1.64.0-r0/packages-split/boost-staticdev/usr/lib/libboost_python3.a
tmp/work/aarch64-poky-linux/boost/1.64.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_python3.so.1.64.0

Adding boost-python to RDEPENDS doesn't help, I have tried it before also. This sort of made sense to me as I thought RDEPENDS was for run time dependencies, but perhaps I have misunderstood. 

I am working with the rocko branch and python2, so perhaps that's the problem?

Thanks,
Emily


On Tue, Mar 17, 2020 at 1:02 PM Laurent Gauthier <laurent.gauthier@...> wrote:
Hi Emily,

To find the solution to your issue in a rational and deterministic way
we need to start from the error message.

What I understand is that while build recipe "opc-ua-server-gfex" you
get an error message that says in short "ld: cannot find
-lboost_python-mt".

Therefore you need to determine which recipe (and which package in
that recipe) provides the "boost_python-mt" library.

One way to determine this is to run something like this:

    find /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/*/*/*/packages-split
-name libboost_python\*

This should show you which recipe, and which package produced by that
recipe has the library you are looking for.

The names of the first-level directories inside "packages-split" are
packages names.

Based on things you have mentioned in your previous e-mail my guess
would be that adding an RDEPENDS = "boost-python" should help, but I
might be wrong.

I hope this will help you move in the right direction.

Kind regards, Laurent.


On Tue, Mar 17, 2020 at 6:07 PM Emily <easmith5555@...> wrote:
>
> Hi Quentin -
>
> That's what I tried originally! DEPENDS on boost and not boost-python gives me the following error when trying to build my original recipe:
>
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> cannot find -lboost_python-mt
>
> So I tried a bunch of other this which also didn't seem to work.
>
> Thanks for the response!
> Emily
>
>
> On Tue, Mar 17, 2020 at 11:04 AM Quentin Schulz <quentin.schulz@...> wrote:
>>
>> Hi Emily,
>>
>> On Tue, Mar 17, 2020 at 10:44:10AM -0500, Emily wrote:
>> > Hi all -
>> >
>> > I'm trying to build an opca recipe (
>> > https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb)
>> > and it's giving me a build error like:
>> >
>> > |
>> > /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
>> > cannot find -lboost_python-mt
>> >
>> > Which seems to indicated I need to add boost-python to my list of DEPENDS.
>> > When I do that I get the error:
>> >
>> > ERROR: Nothing PROVIDES 'boost-python' (but
>> > /local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/
>> > opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close
>> > matches:
>> >   boost RPROVIDES boost-python
>> >
>> > I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and
>> > to the image definition as I saw this online, but neither seems to work. It
>> > seems like boost-python is being built (I can see it in the list when I run
>> > oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at
>> > build for this recipe.
>> >
>> > If I remove boost from my list of DEPENDS I get an error about that, so
>> > obviously boost itself is available at build for the original recipe. I've
>> > also tried adding boost-native to DEPENDS, also did not work.
>> >
>> > Is there something obvious I'm missing, or some trick to making
>> > boost-python available at build for this other recipe?
>> >
>>
>> Ok so two things.
>>
>> Yes, I'd say you need python in PACKAGECONFIG for boost. However, it
>> seems it's already part of the default value of PACKAGECONFIG, c.f.
>> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/boost/boost.inc?h=master#n45
>> so if no bbappend is overriding it, I'd say you're safe. Better check
>> with the version in your layer that it's there.
>> If you don't want to check manually, try `bitbake -e boost | grep -e
>> "^PACKAGECONFIG="`
>>
>> DEPENDS contains only recipes (well, PROVIDES but PROVIDES has the name
>> of the recipe in it at all times) while RDEPENDS_* (usually ${PN}*) contains
>> only packages.
>>
>> So you need to DEPENDS on boost, not boost-python. That should be enough
>> hopefully!
>>
>> Quentin
>
>



--
Laurent Gauthier
Phone: +33 630 483 429
http://soccasys.com


Re: How to PROVIDE boost-python

Laurent Gauthier
 

Hi Emily,

To find the solution to your issue in a rational and deterministic way
we need to start from the error message.

What I understand is that while build recipe "opc-ua-server-gfex" you
get an error message that says in short "ld: cannot find
-lboost_python-mt".

Therefore you need to determine which recipe (and which package in
that recipe) provides the "boost_python-mt" library.

One way to determine this is to run something like this:

find /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/*/*/*/packages-split
-name libboost_python\*

This should show you which recipe, and which package produced by that
recipe has the library you are looking for.

The names of the first-level directories inside "packages-split" are
packages names.

Based on things you have mentioned in your previous e-mail my guess
would be that adding an RDEPENDS = "boost-python" should help, but I
might be wrong.

I hope this will help you move in the right direction.

Kind regards, Laurent.

On Tue, Mar 17, 2020 at 6:07 PM Emily <easmith5555@...> wrote:

Hi Quentin -

That's what I tried originally! DEPENDS on boost and not boost-python gives me the following error when trying to build my original recipe:

/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
cannot find -lboost_python-mt

So I tried a bunch of other this which also didn't seem to work.

Thanks for the response!
Emily


On Tue, Mar 17, 2020 at 11:04 AM Quentin Schulz <quentin.schulz@...> wrote:

Hi Emily,

On Tue, Mar 17, 2020 at 10:44:10AM -0500, Emily wrote:
Hi all -

I'm trying to build an opca recipe (
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb)
and it's giving me a build error like:

|
/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
cannot find -lboost_python-mt

Which seems to indicated I need to add boost-python to my list of DEPENDS.
When I do that I get the error:

ERROR: Nothing PROVIDES 'boost-python' (but
/local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/
opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close
matches:
boost RPROVIDES boost-python

I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and
to the image definition as I saw this online, but neither seems to work. It
seems like boost-python is being built (I can see it in the list when I run
oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at
build for this recipe.

If I remove boost from my list of DEPENDS I get an error about that, so
obviously boost itself is available at build for the original recipe. I've
also tried adding boost-native to DEPENDS, also did not work.

Is there something obvious I'm missing, or some trick to making
boost-python available at build for this other recipe?
Ok so two things.

Yes, I'd say you need python in PACKAGECONFIG for boost. However, it
seems it's already part of the default value of PACKAGECONFIG, c.f.
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/boost/boost.inc?h=master#n45
so if no bbappend is overriding it, I'd say you're safe. Better check
with the version in your layer that it's there.
If you don't want to check manually, try `bitbake -e boost | grep -e
"^PACKAGECONFIG="`

DEPENDS contains only recipes (well, PROVIDES but PROVIDES has the name
of the recipe in it at all times) while RDEPENDS_* (usually ${PN}*) contains
only packages.

So you need to DEPENDS on boost, not boost-python. That should be enough
hopefully!

Quentin
--
Laurent Gauthier
Phone: +33 630 483 429
http://soccasys.com


Re: How to PROVIDE boost-python

Emily
 

Hi Quentin - 

That's what I tried originally! DEPENDS on boost and not boost-python gives me the following error when trying to build my original recipe: 

/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
cannot find -lboost_python-mt  

So I tried a bunch of other this which also didn't seem to work. 

Thanks for the response!
Emily


On Tue, Mar 17, 2020 at 11:04 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Emily,

On Tue, Mar 17, 2020 at 10:44:10AM -0500, Emily wrote:
> Hi all -
>
> I'm trying to build an opca recipe (
> https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb)
> and it's giving me a build error like:
>
> |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> cannot find -lboost_python-mt
>
> Which seems to indicated I need to add boost-python to my list of DEPENDS.
> When I do that I get the error:
>
> ERROR: Nothing PROVIDES 'boost-python' (but
> /local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/
> opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close
> matches:
>   boost RPROVIDES boost-python
>
> I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and
> to the image definition as I saw this online, but neither seems to work. It
> seems like boost-python is being built (I can see it in the list when I run
> oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at
> build for this recipe.
>
> If I remove boost from my list of DEPENDS I get an error about that, so
> obviously boost itself is available at build for the original recipe. I've
> also tried adding boost-native to DEPENDS, also did not work.
>
> Is there something obvious I'm missing, or some trick to making
> boost-python available at build for this other recipe?
>

Ok so two things.

Yes, I'd say you need python in PACKAGECONFIG for boost. However, it
seems it's already part of the default value of PACKAGECONFIG, c.f.
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/boost/boost.inc?h=master#n45
so if no bbappend is overriding it, I'd say you're safe. Better check
with the version in your layer that it's there.
If you don't want to check manually, try `bitbake -e boost | grep -e
"^PACKAGECONFIG="`

DEPENDS contains only recipes (well, PROVIDES but PROVIDES has the name
of the recipe in it at all times) while RDEPENDS_* (usually ${PN}*) contains
only packages.

So you need to DEPENDS on boost, not boost-python. That should be enough
hopefully!

Quentin


Re: How to PROVIDE boost-python

Quentin Schulz
 

Hi Emily,

On Tue, Mar 17, 2020 at 10:44:10AM -0500, Emily wrote:
Hi all -

I'm trying to build an opca recipe (
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb)
and it's giving me a build error like:

|
/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
cannot find -lboost_python-mt

Which seems to indicated I need to add boost-python to my list of DEPENDS.
When I do that I get the error:

ERROR: Nothing PROVIDES 'boost-python' (but
/local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/
opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close
matches:
boost RPROVIDES boost-python

I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and
to the image definition as I saw this online, but neither seems to work. It
seems like boost-python is being built (I can see it in the list when I run
oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at
build for this recipe.

If I remove boost from my list of DEPENDS I get an error about that, so
obviously boost itself is available at build for the original recipe. I've
also tried adding boost-native to DEPENDS, also did not work.

Is there something obvious I'm missing, or some trick to making
boost-python available at build for this other recipe?
Ok so two things.

Yes, I'd say you need python in PACKAGECONFIG for boost. However, it
seems it's already part of the default value of PACKAGECONFIG, c.f.
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/boost/boost.inc?h=master#n45
so if no bbappend is overriding it, I'd say you're safe. Better check
with the version in your layer that it's there.
If you don't want to check manually, try `bitbake -e boost | grep -e
"^PACKAGECONFIG="`

DEPENDS contains only recipes (well, PROVIDES but PROVIDES has the name
of the recipe in it at all times) while RDEPENDS_* (usually ${PN}*) contains
only packages.

So you need to DEPENDS on boost, not boost-python. That should be enough
hopefully!

Quentin


How to PROVIDE boost-python

Emily
 

Hi all - 

I'm trying to build an opca recipe (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb) and it's giving me a build error like: 

| /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld: cannot find -lboost_python-mt

Which seems to indicated I need to add boost-python to my list of DEPENDS. When I do that I get the error: 

ERROR: Nothing PROVIDES 'boost-python' (but /local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close matches:
  boost RPROVIDES boost-python 

I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and to the image definition as I saw this online, but neither seems to work. It seems like boost-python is being built (I can see it in the list when I run oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at build for this recipe. 

If I remove boost from my list of DEPENDS I get an error about that, so obviously boost itself is available at build for the original recipe. I've also tried adding boost-native to DEPENDS, also did not work. 

Is there something obvious I'm missing, or some trick to making boost-python available at build for this other recipe? 

Thanks!
Emily Smith


Yocto Project Status WW11'20

Stephen Jolley
 

Current Dev Position: YP 3.1 M4 - Stabilization

Next Deadline: YP 3.1 M4 build date  3/30/2020

 

Next Team Meetings:

 

Key Status/Updates:

  • M3 has now been built and is in QA. We are therefore feature frozen.
  • YP 3.1 has been announced as an LTS release: https://www.yoctoproject.org/yocto-project-long-term-support-announced/
  • There were logging changes merged to better handle hashequiv and usability concerns, thanks Joshua
  • We have seen a welcome rise in green builds recently although several key intermittent failures have not been addressed. It is crucial for an LTS release we do resolve these.
  • Recipe upgrades are now unlikely to be merged into 3.1 as we focus on stabilizing and bug fixing for the final release

 

YP 3.1 Milestone Dates:

  • YP 3.1 M3 is in QA
  • YP 3.1 M3 release date 3/6/2020
  • YP 3.1 M4 build date  3/30/2020
  • YP 3.1 M4 release date  4/24/2020

 

Planned upcoming dot releases:

  • YP 3.0.3 build date  5/4/2020
  • YP 3.0.3 release date 5/15/2020
  • YP 2.7.4 build date  5/18/2020
  • YP 2.7.4 release date 5/29/2020

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


#yocto [meta-raspberrypi] Unused memory never used #yocto

markus4dev@...
 

Hi!

I am building a solution on top of raspberrypi 3a+. I am having problem that around 50% of available memory never gets used by the node applications and instead the kswapd kicks in and after a while the rpi doesn´t respond anymore. I seems that 50% of the available memory is locked. I have tried the apps on the raspbian buster image and the memory is allocated as expected.  

My yocto setup is like this:

- meta-oe
- meta-python
- meta-multimedia
- meta-networking
- meta-raspberrypi
- meta-mender-core
- meta-mender-raspberrypi
- my-custom-layer

I have added a little swap file (4MB) just in case kswapd needs it (my goal is to remove that since I don´t want to get my SD card destroyed). I have added gpu_mem=16 to restrict memory allocation from GPU. I don't use the camera (not activated VIDEO_CAMERA = "1")

What am I missing? 

Regards,
Markus


Re: EXTRA_OECMAKE options are ignored #sdk #yocto

Armando Hernandez
 

On Wed, Mar 11, 2020 at 11:26 AM, Khem Raj wrote:
please post your recipe
Hello Khem Raj,

Sorry for the late reply. I was not available during last week.
So, I post here my recipe.
But before I want to make two comments:
  1.    I found a variable in the cmake\*.bbclass (i.e. OECMAKE_EXTRA_ROOT_PATH) that I am using in my recipe. Now, that extra root path is not ignored anymore. However, there is an executable that needs to be ran. This executable seems to be not found. The executable is placed under:
        /home/ahejuser/SDK/sysroots/x86_64-pokysdk-linux/usr/share/nativesdk-capicxx-core-3.1.12.3/
    But there is a link pointing to this file and such soft-link is placed under
       /home/ahejuser/SDK/sysroots/x86_64-pokysdk-linux/usr/bin/
    That las path is part of my PATH environment variable (i.e. ${PATH}).
  2. I modified my recipe to include "CMAKE_FIND_ROOT_PATH_MODE_PROGRAM" in my EXTRA_OECMAKE variable (set to BOTH).
    I was expecting that with this, the executable could be found, but the build complains that the executable cannot be found:
       /bin/sh: 1: commonapi-someip-generator-linux-x86_64: not found
    However, if I type in the executable it will be found - as expected since it can be accessed via the PATH environment variable.

I made a small modification to my initial recipe (ou will see the difference between my pasted recipe and my previous post). However the result is the same.

I added "set(CMAKE_FIND_DEBUG_MODE TRUE)" and "set(CMAKE_FIND_DEBUG_MODE FALSE)" before and afer the add_custom_command() call in my CMakeFile.txt but I got not relevant output that helps me to debug this (maybe that CMAKE_FIND_DEUG_MODE is not used properly, but wanted to mentioned it anyways).

So... here my recipe:

LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

SRC_URI = "https://github.com/xxxxxxxxx/common-test.git;protocol=https"

PV = "1.0+git${SRCPV}"
SRCREV = "68c6e3b837ef7d8b12d8aec0f4f558c947fac0c"

S = "${WORKDIR}/git"

inherit cmake

EXTRA_OECMAKE = "-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=BOTH"
OECMAKE_EXTRA_ROOT_PATH="/home/ahejuser/SDK/sysroots/x86_64-pokysdk-linux"

Again, any hint will be pretty much appreciated.
Thanks in advance!

Armando Hernandez


M+ & H bugs with Milestone Movements WW11

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

13604

[master-next] Distrodata.test_maintainers  fails

randy.macleod@...

kai.kang@...

3.1 M3

3.1 M4

 

13714

add gcc to buildtools for Centos7 uninative

randy.macleod@...

timothy.t.orling@...

3.1 M3

3.1 M4

 

13802

ltp tests fail with ssh connection lost  error intermittently

richard.purdie@...

akuster@...

3.1 M3

3.1 M4

Medium+

12604

Default ptest-runner invocation on multilib may not execute any test suites

randy.macleod@...

limon.anibal@...

3.99

3.2

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW101

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

2

peter.kjellerstedt@...

1

timothy.t.orling@...

1

akuster@...

1

Grand Total

5

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current Top developers on Yocto Project 3.1

Stephen Jolley
 

All,

Below is the list as of top 50 developers as of the end of WW11 of who have open medium or higher bugs and enhancements against YP 3.1.   There are 28 possible work days left until the final release candidates for YP 3.1 needs to be released.

Who

Count

richard.purdie@...

34

liezhi.yang@...

27

david.reyna@...

25

bluelightning@...

14

akuster808@...

13

Qi.Chen@...

11

mark.morton@...

11

kai.kang@...

10

bruce.ashfield@...

10

randy.macleod@...

9

timothy.t.orling@...

9

ross@...

7

hongxu.jia@...

5

michael@...

5

kexin.hao@...

5

jon.mason@...

5

changqing.li@...

5

srifenbark@...

4

alejandro@...

4

trevor.gamblin@...

4

JPEWhacker@...

4

mingli.yu@...

4

pbarker@...

4

raj.khem@...

3

alex.kanavin@...

3

ycnakajsph@...

2

anuj.mittal@...

2

seebs@...

2

matthew.zeng@...

2

mark.hatle@...

2

jaewon@...

2

kergoth@...

2

yang.wang@...

2

chee.yang.lee@...

2

scott.branden@...

1

joe.slater@...

1

limon.anibal@...

1

maxime.roussinbelanger@...

1

amber.n.elliot@...

1

Martin.Jansa@...

1

dl9pf@...

1

sakib.sajal@...

1

georgi.georgiev@...

1

cody.yu@...

1

anon2313@...

1

kai.ruhnau@...

1

apoorv.sangal@...

1

bunk@...

1

zhe.he@...

1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


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 291 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@...

 


Re: git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Richard Purdie
 

On Thu, 2020-03-12 at 14:55 +0100, Matthias Schoepfer via Lists.Yoctoproject.Org wrote:
We have noticed the following issue: We keep the versions of out
software by means of tags on the git repositories, i.e. during the
build, somethings like git describe --tags gets called. In yocto,
our
recipe of SomeLibrary might look then similar to this:

SRC_URI =
"git://our.private.gitserver.org/git/SomeLibrary.git;tags=v${PV}"

When we build the image, and *then* apply a tag to HEAD, that was
already built before, it seems like the tags are not fetched (my
guess
is git fetcher sees that origins HEAD and local HEAD have the same
hash
and is fine with it).

The error is, that while the correct version is built, it will
report
itself with a wrong version.

Is this a bug?
Each of the fetcher backends makes some assumptions about what it
considers to be "the same".

For tarballs from whatever source this is easy and we use the hash of
the tarball.

For git, we work off the hash from git itself. If the hash changes, the
source is taken to be different. Hashes of the same data are taken to
be the same.

What we don't do is account for any tag that represents that hash. If
you have some extra part of the build process which is using that as a
factor for the build you would also have to account for it in the task
hashes. Nothing does that by default.

git tags are a pain as they require network access to evaluate and they
break the mirroring structure as you can't know a given tag was fetched
into the mirror.

So no, I'd not define it as a bug, the bug is you're relying on the tag
data but not adding it to the task hashes.

You'd somehow need to inject the "git tag for revision X" output into
the do_fetch task dependencies.

For autorev this happens via:

meta/classes/base.bbclass: d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}"

so you'd need a new version of get_srcrev() and need to inject that
into the vardeps of the fetch task.

Cheers,

Richard


Re: git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Alexander Kanavin
 

Right, now I see what you mean. The build process does not rely on static metadata in the source tree to determine the version, and is instead poking the git checkout to determine what the version is? That's not established practice. You should write the version into a file in the source tree, then create a commit, then tag that commit with the version.

Alternatively, you could pass in ${PV} to the build process instead as a command line parameter.

Alex


On Mon, 16 Mar 2020 at 12:52, Matthias Schöpfer <matthias.schoepfer@...> wrote:
Hi Alexander,

thanks for your message. I will try to explain my issue once again,
since it still seems not clearly formulated. We build our images on CI
(Jenkins). There, we have a shared download dir, so that we do not have
to fetch all sources on every build. This gets shared for our
"experimental" builds, that use latest git master HEAD (yes, evil
AUTOREV) and our "stable" builds, where only tagged (i.e. no AUTOREV
versions) are used. Our software uses the git tag to create a version.
So, when on experimental, you might get something like:

# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.3-3 (gabcdef1)

What happens is, that people check their changes on the experimental
build. After testing, it is considered for the next release, so they
attach a version tag to the git repository and update the _<version>.bb
accordingly. Now they build the image with the "stable" profile. But the
hash "abcdef1" has not changed. Hence, although we pushed a new tag,
yocto git fetcher does not update the cached download git, since git
hashes match (same with SRCREV). Which means, even tough we have a
recipe ourcoolsoftware_1.2.4.bb with SRCREV="abcdef1..." which will
build the correct hash, our software checks the local repository, which
is missing the last tag and will still be reporting a wrong version
1.2.3-3 for example.

If we were to do a
bitbake -c cleanall ourcoolsoftware && bitbake ourcoolimage

then we get
# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.4 (gabcdef1)

because we artificially force a complete fetch of the repository.

We usually do a clean build (no sstate / tmp / etc.) but we use the
download dir, because we do not see why we would need to download gcc
etc. every time. A workaround would be to bitbake -c cleanall our
packages, but it seems hacky and prone to error (need to keep lists of
our used software in at least two places). My question is therefore, if
this is a "bug" and if we were to investigate this and propose a patch,
if this could this be considered for merge, or if this behaviour is
intentional and adding a fetch --tags would be considered harmful in any
way.

Hope, I could bring my point across now.

Thanks and Regards,

  Matthias

On 3/16/20 9:43 AM, Alexander Kanavin wrote:
> 'devtool upgrade' updates SRCREV to match the version tag that you specify:
>
> devtool upgrade -V <tag>
>
> If you omit -V, it will upgrade to the latest tag. It updates PV as
> well. Why is it unsuitable for you?
>
> Alex
>
> On Mon, 16 Mar 2020 at 09:35, Matthias Schöpfer
> <matthias.schoepfer@...
> <mailto:matthias.schoepfer@...>> wrote:
>
>     Hi Alexander,
>
>     does it solve the Problem of a SRCREV, that has been fetched (for
>     example for a _git testbuild) and now gets a tag applied and build with
>     the _<version> build. The problem is *not* that the yocto PV package is
>     wrong *nor* that the wrong version of the software gets build! The
>     problem is, that the tag does not get fetched and our software gets its
>     version from the git tags. Since this is very convenient to have the
>     version information in one place only, we will not change this.
>
>     Thanks and Regards,
>
>         Matthias
>
>     On 3/15/20 5:02 PM, Alexander Kanavin wrote:
>      > On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via
>      > Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org>
>     <http://Lists.Yoctoproject.Org>
>      > <matthias.schoepfer=googlemail.com@...
>     <mailto:googlemail.com@...>
>      > <mailto:googlemail.com@...
>     <mailto:googlemail.com@...>>> wrote:
>      >
>      >     2) It allows for very convenient bump of versions. We develop a
>      >     product,
>      >     so, version bumps are on daily or weekly basis. All that is
>     needed
>      >     is to
>      >     rename the .bb file. No need to edit SRCREV.
>      >
>      >
>      > You can trivially script SRCREV updates ('devtool upgrade'/'devtool
>      > finish'). The disadvantage of using tags is that you lose
>      > reproducibility, as tags can be moved or deleted, and so I wouldn't
>      > encourage this practice.
>      >
>      > Alex
>
>
>     --
>
>     Dr.-Ing. Matthias Schoepfer
>     Mobile: +49 175 2062739
>     email: matthias.schoepfer@...
>     <mailto:matthias.schoepfer@...>
>


--

Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...


Re: QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Sangeeta Jain
 

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Adrian Bunk
Sent: Monday, 16 March, 2020 7:55 PM
To: Jain, Sangeeta <sangeeta.jain@...>
Cc: yocto@...
Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-
3.1_M3.rc1)

On Mon, Mar 16, 2020 at 11:45:09AM +0000, Sangeeta Jain wrote:
...
Runtime auto test for following platforms:
...
6. MPC8315e-rdb
...
This platform has been removed from master, and is therefore not in M3.
Thanks for reminding!


Thanks,
Sangeeta
cu
Adrian


Re: QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Adrian Bunk
 

On Mon, Mar 16, 2020 at 11:45:09AM +0000, Sangeeta Jain wrote:
...
Runtime auto test for following platforms:
...
6. MPC8315e-rdb
...
This platform has been removed from master, and is therefore not in M3.

Thanks,
Sangeeta
cu
Adrian


Re: git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Matthias Schoepfer
 

Hi Alexander,

thanks for your message. I will try to explain my issue once again, since it still seems not clearly formulated. We build our images on CI (Jenkins). There, we have a shared download dir, so that we do not have to fetch all sources on every build. This gets shared for our "experimental" builds, that use latest git master HEAD (yes, evil AUTOREV) and our "stable" builds, where only tagged (i.e. no AUTOREV versions) are used. Our software uses the git tag to create a version. So, when on experimental, you might get something like:

# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.3-3 (gabcdef1)

What happens is, that people check their changes on the experimental build. After testing, it is considered for the next release, so they attach a version tag to the git repository and update the _<version>.bb accordingly. Now they build the image with the "stable" profile. But the hash "abcdef1" has not changed. Hence, although we pushed a new tag, yocto git fetcher does not update the cached download git, since git hashes match (same with SRCREV). Which means, even tough we have a recipe ourcoolsoftware_1.2.4.bb with SRCREV="abcdef1..." which will build the correct hash, our software checks the local repository, which is missing the last tag and will still be reporting a wrong version 1.2.3-3 for example.

If we were to do a
bitbake -c cleanall ourcoolsoftware && bitbake ourcoolimage

then we get
# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.4 (gabcdef1)

because we artificially force a complete fetch of the repository.

We usually do a clean build (no sstate / tmp / etc.) but we use the download dir, because we do not see why we would need to download gcc etc. every time. A workaround would be to bitbake -c cleanall our packages, but it seems hacky and prone to error (need to keep lists of our used software in at least two places). My question is therefore, if this is a "bug" and if we were to investigate this and propose a patch, if this could this be considered for merge, or if this behaviour is intentional and adding a fetch --tags would be considered harmful in any way.

Hope, I could bring my point across now.

Thanks and Regards,

Matthias

On 3/16/20 9:43 AM, Alexander Kanavin wrote:
'devtool upgrade' updates SRCREV to match the version tag that you specify:
devtool upgrade -V <tag>
If you omit -V, it will upgrade to the latest tag. It updates PV as well. Why is it unsuitable for you?
Alex
On Mon, 16 Mar 2020 at 09:35, Matthias Schöpfer <matthias.schoepfer@... <mailto:matthias.schoepfer@...>> wrote:
Hi Alexander,
does it solve the Problem of a SRCREV, that has been fetched (for
example for a _git testbuild) and now gets a tag applied and build with
the _<version> build. The problem is *not* that the yocto PV package is
wrong *nor* that the wrong version of the software gets build! The
problem is, that the tag does not get fetched and our software gets its
version from the git tags. Since this is very convenient to have the
version information in one place only, we will not change this.
Thanks and Regards,
   Matthias
On 3/15/20 5:02 PM, Alexander Kanavin wrote:
> On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via
> Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org>
<http://Lists.Yoctoproject.Org>
> <matthias.schoepfer=googlemail.com@...
<mailto:googlemail.com@...>
> <mailto:googlemail.com@...
<mailto:googlemail.com@...>>> wrote:
>
>     2) It allows for very convenient bump of versions. We develop a
>     product,
>     so, version bumps are on daily or weekly basis. All that is
needed
>     is to
>     rename the .bb file. No need to edit SRCREV.
>
>
> You can trivially script SRCREV updates ('devtool upgrade'/'devtool
> finish'). The disadvantage of using tags is that you lose
> reproducibility, as tags can be moved or deleted, and so I wouldn't
> encourage this practice.
>
> Alex
--
Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...
<mailto:matthias.schoepfer@...>
--

Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...


QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1_M3.rc1.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Thursday, March 19.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of pokybuild@...
Sent: Monday, 16 March, 2020 5:40 PM
To: yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>;
Chan, Aaron Chun Yew <aaron.chun.yew.chan@...>;
richard.purdie@...; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: [yocto] QA notification for completed autobuilder build
(yocto-
3.1_M3.rc1)


A build flagged for QA (yocto-3.1_M3.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1_M3.rc1


Build hash information:

bitbake: e67dfa4a4d0d63e4752655f25367582e5a95f1da
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 60773e8496370d821309e00f2c312128a130c22b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 61d80b07bcfa4adf5f1feb2904fec0a8d09c89f6
poky: 6f02caa39985fb89d9ad49e1f788a9a8dd6e12d7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



Re: QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1_M3.rc1.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Thursday, March 19.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of pokybuild@...
Sent: Monday, 16 March, 2020 5:40 PM
To: yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>;
richard.purdie@...; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.1_M3.rc1)


A build flagged for QA (yocto-3.1_M3.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1_M3.rc1


Build hash information:

bitbake: e67dfa4a4d0d63e4752655f25367582e5a95f1da
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 60773e8496370d821309e00f2c312128a130c22b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 61d80b07bcfa4adf5f1feb2904fec0a8d09c89f6
poky: 6f02caa39985fb89d9ad49e1f788a9a8dd6e12d7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


9021 - 9040 of 57806