Date   

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


overwrite LAYERSERIES_COMPAT_ for different layer

TRO <thomas.roos@...>
 

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


Re: can i run an arbitrary x86_64-based image under QEMU?

Robert P. J. Day
 

On Sun, 24 May 2020, Alexander Kanavin wrote:

To me this seems like Wind River's special sauce.

The CHANGELOG in meta-intel says this:

Added QEMU support.
-------------------
We now build several virtio drivers into the kernel by default, and
have qemuboot.conf files for intel-corei7-64 and intel-core2-32
targets. This allows one to do basic testing on meta-intel images
without having to use hardware. The virtio drivers are added via
KERNEL_FEATURES_INTEL_COMMON. This prevents them from being added to
custom kernels by default. They can be removed by adding the
following to a conf or kernel bbappend file:
  KERNEL_FEATURES_INTEL_COMMON_remove = “cfg/virtio.scc” OVMF
firmware is also built and can be used in order to emulate a UEFI
environment. A full runqemu command line for intel-corei7-64 could
look like this:
  runqemu core-image-minimal intel-corei7-64 wic ovmf
======

It's probably not too difficult to make this work in YP upstream
(given that qemu is able to run desktop Linux distribution images
aimed at real HW), but currently this isn't documented or (most
importantly) tested on the AB.
i suspected it was a WR thing, thanks.

rday


Re: [ptest-runner] Added output processing to pytest

zangrc
 

Is it possible to continue to add ptest for python-XX in the old way at present, and wait for the new recipe to be integrated (uncertain time), and then uniformly process the output? Or suspend the work of appending ptest and wait for the solution.

--
Zang Ruochen

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Ross Burton
Sent: Friday, May 22, 2020 9:37 PM
To: Paul Barker <pbarker@...>
Cc: Alexander Kanavin <alex.kanavin@...>; Zang, Ruochen/臧 若尘 <zangrc.fnst@...>; Yocto discussion list <yocto@...>; Anibal Limon <anibal.limon@...>
Subject: Re: [yocto] [ptest-runner] Added output processing to pytest

On Fri, 22 May 2020 at 14:31, Paul Barker <pbarker@...> wrote:
We could have a recipe in oe-core with this in, or just drop it into
the python recipe directly.
It's packaged on pypi: https://pypi.org/project/betatest/

I need to do a new release as I tidied a few things up and added a
subtest wrapper after I published v0.1.0. This gives me a kick to get
that done :)
Awesome. I endorse a pypi recipe shipping that, which recipes can then re-use.

The next question is how to integrate that runner with pytest.

Ross

8341 - 8360 of 57813