Date   

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


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

Anibal Limon
 



On Fri, 22 May 2020 at 08:37, Ross Burton <ross@...> wrote:
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.

I like the idea of format the output at level of pytest, in OEQA there is OETestResult class that is where the changes need to be made to add the option to use AM format.


Regards,
Anibal
 

Ross


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

Alexander Kanavin
 

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.


Alex


On Sun, 24 May 2020 at 17:41, Robert P. J. Day <rpjday@...> wrote:

  currently poring over wind river docs and in release notes for WR
LTS 19 (equivalent to YP 3.0), one of the notes for RCPL 7 for this
release of WR states:

"New support to deploy a platform project image based on the
intel-x86-64 BSP with the runqemu command. You no longer require a
QEMU-based BSP to deploy and test your x86-based image."

  first, am i interpreting that correctly that i can build an x86_64
image for actual hardware, and run it under QEMU?

  and if so, is that a WR thing, or if available under YP, a pointer
to the appropriate doc would be sufficient.  thank you kindly.

rday


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

Robert P. J. Day
 

currently poring over wind river docs and in release notes for WR
LTS 19 (equivalent to YP 3.0), one of the notes for RCPL 7 for this
release of WR states:

"New support to deploy a platform project image based on the
intel-x86-64 BSP with the runqemu command. You no longer require a
QEMU-based BSP to deploy and test your x86-based image."

first, am i interpreting that correctly that i can build an x86_64
image for actual hardware, and run it under QEMU?

and if so, is that a WR thing, or if available under YP, a pointer
to the appropriate doc would be sufficient. thank you kindly.

rday


nodejs 12.16 in Yocto 2.2 compatiblity

msrinivasan@...
 

Hi,
I am cross compile nodejs 12.16 recipe for ARM v7 target using Yocto 2.2. I can built nodejs as a individual task (i.e. bitbake -c compile)  (with some changes in recipe) with dependency over openssl 1.1.1b recipe from Yocto 2.6. But further build (i.e. bitbake nodejs)  fails with dependency rpm-native's compile which depend on default  openssl 1.0.2j from sysroot folder (STAGING_DIR) (currently has openssl 1.1.1b's header files at sysroot folder). My aim to have quiet build of nodejs with dependency on openssl 1.1.1b only and rest of build depend over openssl 1.0.2q. Finally with reference from sysroot (STAGING_DIR), image must contains both openssl versions (1.1.1b, 1.0.2q) share libraries.
Please let me know your inputs. 

Thanks  & Regards
Manjunatha Srinivasvan N
 


Re: How to include initrd.cpio to image

Gmane Admin
 

Op 03-05-2020 om 13:42 schreef Gmane Admin:
Op 30-04-2020 om 23:33 schreef Gmane Admin:
I am generating core-image-minimal-initramfs-edison.cpio.gz which is found in the deploy-core-image-minimal-initramfs-image-complete/ directory.

When I build my image edison-image initrd gets included and deployed in edison-image-edison.hddimg. But I am not using that.

I also generate edison-image-edison.ext4 which has bzImage kernel in /boot. But by Zeus, I have no idea how to get edison-image to install a file from the other recipe's deploy.

To me it doesn't make sense to include bzImage without initrd, kernel will not be able to load the rootfs without.

I know I can bundle the initramfs, and that has worked fine before. Until kernel + initrd grew above 15MB, now U-Boot won't load it. I have now kernel = 10MB + initrd = 10MB which boot fine when I copy initrd to /boot manually.
Gmane is crazy. It's me, Ferry.
I'm still stuck here. Any ideas?
Self answering, I added this to my image recipe:

ROOTFS_POSTPROCESS_COMMAND += "install_initrd; "

install_initrd() {
bbnote "Adding initrd to image ${IMAGE_ROOTFS}"
install -d {IMAGE_ROOTFS}/boot
bbnote "from ${DEPLOY_DIR_IMAGE}/core-image-minimal-initramfs-edison.cpio.gz"
install -m 0755 ${DEPLOY_DIR_IMAGE}/core-image-minimal-initramfs-edison.cpio.gz ${IMAGE_ROOTFS}/boot/initrd
}



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

Ross Burton <ross@...>
 

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


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

 

On Fri, 22 May 2020 at 14:25, Ross Burton <ross@...> wrote:

On Fri, 22 May 2020 at 10:29, Paul Barker <pbarker@...> wrote:

On Fri, 22 May 2020 at 10:26, Alexander Kanavin <alex.kanavin@...> wrote:

On Fri, 22 May 2020 at 05:54, zangrc <zangrc.fnst@...> wrote:

+ char pytest_append[] = "| sed -e 's/\\[...%\\]//g'| sed -e 's/PASSED/PASS/g'| sed -e 's/FAILED/FAIL/g'|sed -e 's/SKIPPED/SKIP/g'| awk '{if ($NF==\"PASS\" || $NF==\"FAIL\" || $NF==\"SKIP\" || $NF==\"XFAIL\" || $NF==\"XPASS\"){printf \"%s: %s\\n\", $NF, $0}else{print}}'| awk '{if ($NF==\"PASS\" || $NF==\"FAIL\" || $NF==\"SKIP\" || $NF==\"XFAIL\" || $NF==\"XPASS\") {$NF=\"\";print $0}else{print}}'";

Is it possible to process the output directly, rather than tweak it via sed/awk shell pipelines that are very difficult to read?
Another option could be to generate the output in the correct format
directly from Python using something like this module which I wrote a
few years back:
https://gitlab.com/b5/BetaTest/betatest/-/blob/master/betatest/amtest.py
Yes, this, please.

I endorsed this approach on the oe-devel list when this first came up,
and I'm really pleased you already implemented it.

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 :)

Thanks,

--
Paul Barker
Konsulko Group


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

Ross Burton <ross@...>
 

On Fri, 22 May 2020 at 10:29, Paul Barker <pbarker@...> wrote:

On Fri, 22 May 2020 at 10:26, Alexander Kanavin <alex.kanavin@...> wrote:

On Fri, 22 May 2020 at 05:54, zangrc <zangrc.fnst@...> wrote:

+ char pytest_append[] = "| sed -e 's/\\[...%\\]//g'| sed -e 's/PASSED/PASS/g'| sed -e 's/FAILED/FAIL/g'|sed -e 's/SKIPPED/SKIP/g'| awk '{if ($NF==\"PASS\" || $NF==\"FAIL\" || $NF==\"SKIP\" || $NF==\"XFAIL\" || $NF==\"XPASS\"){printf \"%s: %s\\n\", $NF, $0}else{print}}'| awk '{if ($NF==\"PASS\" || $NF==\"FAIL\" || $NF==\"SKIP\" || $NF==\"XFAIL\" || $NF==\"XPASS\") {$NF=\"\";print $0}else{print}}'";

Is it possible to process the output directly, rather than tweak it via sed/awk shell pipelines that are very difficult to read?
Another option could be to generate the output in the correct format
directly from Python using something like this module which I wrote a
few years back:
https://gitlab.com/b5/BetaTest/betatest/-/blob/master/betatest/amtest.py
Yes, this, please.

I endorsed this approach on the oe-devel list when this first came up,
and I'm really pleased you already implemented it.

We could have a recipe in oe-core with this in, or just drop it into
the python recipe directly.

Ross


Re: strange formatting of command output on core-image-base

stefan.wenninger@...
 

Hi Raj,

you seem to have been spot on. After adding the "packagegroup-core-full-cmdline" to my image all command output looks perfect.
This packagegroup was the only relevant difference between core-image-base and core-image-full-cmdline imo. Some package out of this group did the trick.

Thank you very much, I consider this topic closed.

Stefan Wenninger


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

 

On Fri, 22 May 2020 at 10:26, Alexander Kanavin <alex.kanavin@...> wrote:

On Fri, 22 May 2020 at 05:54, zangrc <zangrc.fnst@...> wrote:

+ char pytest_append[] = "| sed -e 's/\\[...%\\]//g'| sed -e 's/PASSED/PASS/g'| sed -e 's/FAILED/FAIL/g'|sed -e 's/SKIPPED/SKIP/g'| awk '{if ($NF==\"PASS\" || $NF==\"FAIL\" || $NF==\"SKIP\" || $NF==\"XFAIL\" || $NF==\"XPASS\"){printf \"%s: %s\\n\", $NF, $0}else{print}}'| awk '{if ($NF==\"PASS\" || $NF==\"FAIL\" || $NF==\"SKIP\" || $NF==\"XFAIL\" || $NF==\"XPASS\") {$NF=\"\";print $0}else{print}}'";

Is it possible to process the output directly, rather than tweak it via sed/awk shell pipelines that are very difficult to read?
Another option could be to generate the output in the correct format
directly from Python using something like this module which I wrote a
few years back:
https://gitlab.com/b5/BetaTest/betatest/-/blob/master/betatest/amtest.py

Thanks,

--
Paul Barker
Konsulko Group

8321 - 8340 of 57783