Date   

Re: Overwrite a bblcass globally

Quentin Schulz
 

Hi Ayoub,

On Tue, May 26, 2020 at 04:36:13PM +0200, Ayoub Zaki via lists.yoctoproject.org wrote:
Hi,

I would like to make changes on systemd.bblcass in my layer.

I can create new one e.g my-systemd.bbclass to overwrite the default one
but this will not work since I want that ALL recipes in all layers I'm
using to make usage of it.

are there ways to achieve this?
BBPATH[1] is what's used to locate bbclasses. It's defined in your
conf/layer.conf.

You can either make sure your layer is parsed before the one having the
original systemd.bbclass (in BBLAYERS of conf/bblayers.conf) or prepend
to BBPATH instead of appending.

Although... It's usually bad practice because it means that if I were to use
two layers doing the same thing (overriding the same bbclass), the behavior
is kind of undefined depending on which order they are parsed.

Ideally, you should contribute back the modifications to upstream
systemd.bbclass, that way, no need to duplicate it and override it from
somewhere else.

[1] https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-BBPATH

Cheers,
Quentin


Overwrite a bblcass globally

Ayoub Zaki
 

Hi,

I would like to make changes on systemd.bblcass in my layer. 

I can create new one e.g my-systemd.bbclass to overwrite the default one but this will not work since I want that ALL recipes in all layers I'm using to make usage of it.

are there ways to achieve this?


Thank you !


Cheers



Re: gpg: can't connect to the agent: File name too long

Damien LEFEVRE
 

I think my problem is that the do_image_* are running as fakeroot/pseudo.

Is there a way to run this task as a normal local user.

I read that I should create the socket when not running under local user with
gpgconf --create-socketdir

But this fails too although I set permissions for all on the gpg files and directories:
'''
| gpgconf: socketdir is '/test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/my_img/home'
| gpgconf: no /run/user dir
| gpgconf: using homedir as fallback
| gpgconf: error creating socket directory
| gpgconf: fatal error (exit status 1)
'''

Basically I need to, as a normal user, run gpg after do_image_tegra.

Any hint?


Re: overwrite LAYERSERIES_COMPAT_ for different layer

TRO <thomas.roos@...>
 

Hi,
thanks for the reply - I've put it in the bblayers.conf - working.
cheers, Thomas


Enhancements/Bugs closed WW21!

Stephen Jolley
 

All,

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

Who

Count

jean-marie.lemetayer@...

10

akuster808@...

3

randy.macleod@...

2

otavio@...

1

ross@...

1

ricardo.ribalda@...

1

steve@...

1

nicolas.dechesne@...

1

alex.kanavin@...

1

Grand Total

21

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 344 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 50 bug owners as of the end of WW21 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 110 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

30

david.reyna@...

19

bluelightning@...

17

akuster808@...

12

bruce.ashfield@...

12

kai.kang@...

10

ross@...

9

Qi.Chen@...

9

trevor.gamblin@...

8

mark.morton@...

8

randy.macleod@...

7

JPEWhacker@...

7

changqing.li@...

6

timothy.t.orling@...

6

michael@...

5

rpjday@...

4

pbarker@...

4

anuj.mittal@...

4

mingli.yu@...

4

yi.zhao@...

3

raj.khem@...

3

jon.mason@...

3

kexin.hao@...

3

alex.kanavin@...

3

hongxu.jia@...

3

mostthingsweb@...

2

mark.hatle@...

2

dl9pf@...

2

seebs@...

2

ycnakajsph@...

2

kergoth@...

2

alejandro@...

2

chee.yang.lee@...

2

jaewon@...

2

akuster@...

2

jpuhlman@...

2

joe.slater@...

1

nicolas.dechesne@...

1

ydirson@...

1

steve@...

1

ricardo.ribalda@...

1

naveen.kumar.saini@...

1

denis@...

1

kai.ruhnau@...

1

jason.wessel@...

1

sakib.sajal@...

1

matthew.zeng@...

1

Martin.Jansa@...

1

liu.ming50@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: how to un-blacklist a blacklisted recipe?

Robert P. J. Day
 

On Mon, 25 May 2020, Martin Jansa wrote:

Yes, it's worth. Thanks
done, and submitted. it was just my horrific luck that i was testing
that feature, and randomly grabbed two recipes that used standard
assignment. le *sigh* ...

rday


Re: how to un-blacklist a blacklisted recipe?

Martin Jansa
 

Yes, it's worth. Thanks

On Mon, May 25, 2020 at 7:40 PM Robert P. J. Day <rpjday@...> wrote:
On Mon, 25 May 2020, Robert P. J. Day wrote:

> On Mon, 25 May 2020, Martin Jansa wrote:
>
> > Yes, in local.conf or distro config, both work fine. Maybe your
> > PNBLACKLIST you're trying to unblacklist is using normal assignment
> > instead of weak one? See
>
>   i just now determined that that is exactly what is happening --
> tried it with nanopb recipe from meta-oe, which contains:
>
>   PNBLACKLIST[nanopb] = "Needs forward porting to use python3"
>
> switched that to weak assignment, all good. does that imply that,
> other than in perhaps exceptional circumstances, *all* blacklisting
> should use weak assignment?

  never mind, just took a look at the commit which does exactly this.
is it worth submitting a patch to tweak the few hard assignments?

rday


Re: how to un-blacklist a blacklisted recipe?

Robert P. J. Day
 

On Mon, 25 May 2020, Robert P. J. Day wrote:

On Mon, 25 May 2020, Martin Jansa wrote:

Yes, in local.conf or distro config, both work fine. Maybe your
PNBLACKLIST you're trying to unblacklist is using normal assignment
instead of weak one? See
i just now determined that that is exactly what is happening --
tried it with nanopb recipe from meta-oe, which contains:

PNBLACKLIST[nanopb] = "Needs forward porting to use python3"

switched that to weak assignment, all good. does that imply that,
other than in perhaps exceptional circumstances, *all* blacklisting
should use weak assignment?
never mind, just took a look at the commit which does exactly this.
is it worth submitting a patch to tweak the few hard assignments?

rday


Re: how to un-blacklist a blacklisted recipe?

Robert P. J. Day
 

On Mon, 25 May 2020, Martin Jansa wrote:

Yes, in local.conf or distro config, both work fine. Maybe your
PNBLACKLIST you're trying to unblacklist is using normal assignment
instead of weak one? See
i just now determined that that is exactly what is happening --
tried it with nanopb recipe from meta-oe, which contains:

PNBLACKLIST[nanopb] = "Needs forward porting to use python3"

switched that to weak assignment, all good. does that imply that,
other than in perhaps exceptional circumstances, *all* blacklisting
should use weak assignment?

rday


Re: how to un-blacklist a blacklisted recipe?

Martin Jansa
 

Yes, in local.conf or distro config, both work fine.

Maybe your PNBLACKLIST you're trying to unblacklist is using normal assignment instead of weak one? See


On Mon, May 25, 2020 at 7:22 PM Robert P. J. Day <rpjday@...> wrote:
On Mon, 25 May 2020, Martin Jansa wrote:

> I don't use WR, but setting it to empty works fine for me.

  *where* did you set it to empty? in your local.conf?

> Why do you think it shouldn't work? See
> https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18


Re: how to un-blacklist a blacklisted recipe?

Robert P. J. Day
 

On Mon, 25 May 2020, Martin Jansa wrote:

I don't use WR, but setting it to empty works fine for me.
*where* did you set it to empty? in your local.conf?

Why do you think it shouldn't work? See
https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18


Re: how to un-blacklist a blacklisted recipe?

Robert P. J. Day
 

On Mon, 25 May 2020, Martin Jansa wrote:

I don't use WR, but setting it to empty works fine for me.
Why do you think it shouldn't work? See
https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18
i tested it ... at least i *thought* i tested it on a blacklisted
recipe. i'll try it again, i guess i just misspelled something.

rday


Re: how to un-blacklist a blacklisted recipe?

Martin Jansa
 

I don't use WR, but setting it to empty works fine for me.

Why do you think it shouldn't work? See


On Mon, May 25, 2020 at 6:38 PM Robert P. J. Day <rpjday@...> wrote:

  asking what is almost certainly a silly question, but as i'm poring
over the wind river LTS 19 (aka "zeus") developer's guide, i know that
WR adds a feature for un-blacklisting blacklisted recipes via the
PNWHITELIST variable, but the guide says something quite different in
that it suggests that one can clear a blacklist from a recipe by
setting the blacklist message to the empty string, as in:

  PNBLACKLIST[recipe] = ""

https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_LTS_19_tki1589820771450/page/inj1480988608162.html

  um, wut?

  oddly, there is no mention of WR's PNWHITELIST feature on that page,
so i assumed that 1) someone forgot to update the guide to mention it,
and 2) setting the message to the empty string might be the standard
YP way to do it, but i'm pretty sure that won't work.

  is there a way to un-blacklist a blacklisted recipe using standard
YP? the reference manual entry for PNBLACKLIST doesn't suggest so:

https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PNBLACKLIST

  thoughts?

rday





how to un-blacklist a blacklisted recipe?

Robert P. J. Day
 

asking what is almost certainly a silly question, but as i'm poring
over the wind river LTS 19 (aka "zeus") developer's guide, i know that
WR adds a feature for un-blacklisting blacklisted recipes via the
PNWHITELIST variable, but the guide says something quite different in
that it suggests that one can clear a blacklist from a recipe by
setting the blacklist message to the empty string, as in:

PNBLACKLIST[recipe] = ""

https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_LTS_19_tki1589820771450/page/inj1480988608162.html

um, wut?

oddly, there is no mention of WR's PNWHITELIST feature on that page,
so i assumed that 1) someone forgot to update the guide to mention it,
and 2) setting the message to the empty string might be the standard
YP way to do it, but i'm pretty sure that won't work.

is there a way to un-blacklist a blacklisted recipe using standard
YP? the reference manual entry for PNBLACKLIST doesn't suggest so:

https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PNBLACKLIST

thoughts?

rday


Re: overwrite LAYERSERIES_COMPAT_ for different layer

Quentin Schulz
 

On Mon, May 25, 2020 at 03:10:39PM +0200, Martin Jansa wrote:
You can add a layer which will set LAYERSERIES_COMPAT for another layer,
but it needs to be parsed before the layer you want to change, e.g.:
https://github.com/webosose/meta-webosose/blob/thud/meta-qt5-compat/conf/layer.conf
it's useful to use this layer also to implement whatever modifications are
needed to make the layer to be actually compatible with the release you're
using, like:
https://github.com/webOS-ports/meta-webos-ports/tree/zeus/meta-qt5-compat
FWIW, you could make the parsing order not matter (at least in thud,
from a quick look, master as well). LAYERSERIES_COMPAT is resolved after
all layer.conf have been parsed[1]. I do not know if it's on purpose or
not, meaning it could well disappear in the near future.

So you could override it from anywhere by using __append but it has to
be done before or during the conf/layer.conf parsing. This also makes it
future proof wrt layer priorities and how LAYERSERIES_COMPAT is set (+=,
=, ?= ?).

I personally have it in conf/bblayers.conf (for some reason we "ship"
this one, though it's not best practice IIRC).

[1] https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/cookerdata.py?h=thud#n399

Cheers,
Quentin


gpg: can't connect to the agent: File name too long

Damien LEFEVRE
 

Hi,

I'm using this command from a new image type
'''
gpg --homedir home --encrypt --sign --default-key "server@..." --pinentry-mode loopback --passphrase-file server.passphrase  --recipient "device@..." --output ${IMAGE_LINK_NAME}.fw ${IMGDEPLOYDIR}/${IMAGE_NAME}.img
'''

From yocto build I get this error

'''
| gpg: can't connect to the agent: File name too long
| gpg: Warning: not using 'server@...' as default key: No secret key
| gpg: all values passed to '--default-key' ignored
'''

I added this img_ota.bbclass

'''
inherit image_types image_types_tegra pythonnative

create_img_ota_pkg() {
    rm -rf "${WORKDIR}/my_img"
    mkdir -p "${WORKDIR}/my_img"
    oldwd=`pwd`
    cd "${WORKDIR}/my_img"
    ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/" home
    ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/update.passphrase" update.passphrase
    ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/encrypt.py" encrypt.py
    ln -sf "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.img" "${IMAGE_LINK_NAME}.img"
    #gpg --homedir home --encrypt --sign --default-key "server@..." --pinentry-mode loopback --passphrase-file server.passphrase  --recipient "device@..." --output ${IMAGE_LINK_NAME}.fw ${IMGDEPLOYDIR}/${IMAGE_NAME}.img
    echo $(which python3)
    python3 encrypt.py blabla.fw ${IMAGE_LINK_NAME}.img
    cd oldwd
}

create_my_pkg[vardepsexclude] += "DATETIME"

IMAGE_CMD_img_ota = "create_img_ota_pkg"
do_image_img_ota[depends] += " \
    gpg-keys-native:do_populate_sysroot \
"

IMAGE_TYPEDEP_img_ota += "tegraflash"
IMAGE_TYPES += "img_ota"
'''

I have a native recipe creating the gpg db and install the keys.

I did check the gpg and gpg-agent binaries used come from /test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/recipe-sysroot-native/usr/bin

I tried to wrap the command in a python script but it had no effect.

If I open a terminal, add  /test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/recipe-sysroot-native/usr/bin to PATH and run the commands, they go through successfully and I don't manage to reproduce the error.

What is different with bitbake which could make this fail?

Thanks
-Damien


Please unsubscribe me from the mailing list.

Jean François DAROCHA
 

Please unsubscribe me from the mailing list.

 


Re: overwrite LAYERSERIES_COMPAT_ for different layer

Martin Jansa
 

You can add a layer which will set LAYERSERIES_COMPAT for another layer, but it needs to be parsed before the layer you want to change, e.g.:
it's useful to use this layer also to implement whatever modifications are needed to make the layer to be actually compatible with the release you're using, like:


On Mon, May 25, 2020 at 1:17 PM TRO <thomas.roos@...> wrote:
Hi,
have an issue with a layer which doesn't have the current dunfell release in it's LAYERSERIES_COMPAT_
-> can I overwrite it somehow in a different layer or local.conf?
-> can I configure the error "...is not compatible with the core layer..." to a warning?
cheers, Thomas

9161 - 9180 of 58636