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

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

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
}

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

On Fri, 22 May 2020 at 14:25, Ross Burton <@rossburton> 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

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

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

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

Because there are quite a few OSS that use pytest for testing, and the
test output of pytest is not consistent with the output format of
automake, so the output of pytest needs to be processed. The following
is the solution given by Richard Purdie:

teaching ptest runner how to handle the alternate output
format(triggered by run-ptest-XXX instead of run-ptest)

Signed-off-by: Zang Ruochen <zangrc.fnst@...>
---
utils.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/utils.c b/utils.c
index a8ba190..fa4a483 100644
--- a/utils.c
+++ b/utils.c
@@ -74,6 +74,33 @@ check_allocation1(void *p, size_t size, char *file, int line, int exit_on_null)
}
}

+char *
+get_ptest_path(const char *dir, const char *d_name) {
+ struct stat st_buf;
+ char *run_ptest_default;
+ char *run_ptest_pytest;
+ char *run_ptest;
+
+ if (asprintf(&run_ptest_default, "%s/%s/ptest/run-ptest",
+ dir, d_name) == -1) {
+ return run_ptest;
+ }
+
+ if (asprintf(&run_ptest_pytest, "%s/%s/ptest/run-ptest-pytest",
+ dir, d_name) == -1) {
+ return run_ptest;
+ }
+
+ if (stat(run_ptest_pytest, &st_buf) != -1) {
+ free(run_ptest_default);
+ run_ptest = run_ptest_pytest;
+ } else {
+ free(run_ptest_pytest);
+ run_ptest = run_ptest_default;
+ }
+
+ return run_ptest;
+}

struct ptest_list *
get_available_ptests(const char *dir)
@@ -129,8 +156,8 @@ get_available_ptests(const char *dir)
continue;
}

- if (asprintf(&run_ptest, "%s/%s/ptest/run-ptest",
- dir, d_name) == -1) {
+ run_ptest = get_ptest_path(dir, d_name);
+ if (run_ptest == NULL) {
fail = 1;
saved_errno = errno;
free(d_name);
@@ -282,7 +309,22 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
close(fd_stderr); /* try using to see if this fixes bash run-read. rwm todo */
close_fds();

- execv(run_ptest, argv);
+ if (is_end_with(run_ptest, "run-ptest-pytest") == 1) {
+ char *cmd;
+ 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}}'";
+ if (asprintf(&cmd, "sh %s %s", run_ptest, pytest_append) == -1) {
+ exit(-1);
+ }
+ if (system(cmd) == -1) {
+ free(cmd);
+ exit(-1);
+ }
+ free(cmd);
+ } else {
+ if (execv(run_ptest, argv) == -1 ) {
+ exit(-1);
+ }
+ }

/* exit(1); not needed? */
}
@@ -400,6 +442,17 @@ setup_slave_pty(FILE *fp) {
return (slave);
}

+int
+is_end_with(const char *str1, const char *str2)
+{
+ char *head;
+ head = strstr(str1, str2);
+ if (head != NULL && strlen(head) == strlen(str2)) {
+ return 1;
+ } else {
+ return 0;
+ }
+}

int
run_ptests(struct ptest_list *head, const struct ptest_options opts,
--
2.17.1

Hi,

I have a following statement to remove a node in a DTS file:

&gpmi {
/delete-node/ fsl,use-minimum-ecc;
};

I can build it correctly in OpenWRT build, but I cannot built it
correctly in OE / Yocto (Zeus), it did not remove the node
fsl,use-minimum-ecc. The u-boot is appended from meta-freescale
u-boot-imx_2018.03.bb. Any workarounds to fix that problem?

Thank you.

Kind regards,

- jh

--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

Hi,

I ha a configuration for raspberry pi from recent dunfell branch.
When I run my image with runquemu:

[zork@archdevel yocto-wallscreen-qemu-build]$ runqemu
runqemu - INFO - Running bitbake -e ...
runqemu - INFO - Overriding conf file setting of STAGING_DIR_NATIVE to /home/zork/data/yocto-wallscreen-qemu-build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native from Bitbake environment
runqemu - INFO - Continuing with the following parameters:
KERNEL: [/home/zork/data/yocto-wallscreen-qemu-build/tmp/deploy/images/qemuarm/zImage--5.4.27+git0+bee554e595_ab849248b4-r0-qemuarm-20200519150054.bin]
MACHINE: [qemuarm]
FSTYPE: [ext4]
ROOTFS: [/home/zork/data/yocto-wallscreen-qemu-build/tmp/deploy/images/qemuarm/basic-dev-image-qemuarm-20200519150054.rootfs.ext4]
CONFFILE: [/home/zork/data/yocto-wallscreen-qemu-build/tmp/deploy/images/qemuarm/basic-dev-image-qemuarm-20200519150054.qemuboot.conf]

runqemu - INFO - Setting up tap interface under sudo
runqemu - INFO - Network configuration: ip=192.168.7.2::192.168.7.1:255.255.255.0
runqemu - INFO - Running /home/zork/data/yocto-wallscreen-qemu-build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-arm -device virtio-net-device,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive id=disk0,file=/home/zork/data/yocto-wallscreen-qemu-build/tmp/deploy/images/qemuarm/basic-dev-image-qemuarm-20200519150054.rootfs.ext4,if=none,format=raw -device virtio-blk-device,drive=disk0 -show-cursor -device VGA,edid=on -device qemu-xhci -device usb-tablet -device usb-kbd -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -machine virt,highmem=off -cpu cortex-a15 -m 256 -serial mon:vc -serial null -kernel /home/zork/data/yocto-wallscreen-qemu-build/tmp/deploy/images/qemuarm/zImage--5.4.27+git0+bee554e595_ab849248b4-r0-qemuarm-20200519150054.bin -append 'root=/dev/vda rw mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 console=ttyAMA0 '


I have tap0 interface on host with netmask 32:

11: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether e6:ae:b4:35:07:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.7.1/32 brd 192.168.7.255 scope global tap0
valid_lft forever preferred_lft forever

How to change this mask to 24?

Thanks,
Łukasz

On 5/20/20 3:23 AM, stefan.wenninger@... wrote:

Hi,
I recently switched form an image based on fsl-image-qt5 to one based on core-image-base.
The new image works fine in every regard except that the output of some commands looks weird.
I have attached the output of commands "nmcli" and "systemctl status dbus". Once executed on the fsl-image-qt5 based system and once on the core-image-base based system (_weird.txt).
There are two main points I gather from that weird output:
1. There are some codes like "[[32m"+"[[0m" or "[[0;1;32m"+"[[0m", which I assume are colour codes, that are printed and not applied.
2. The output appears to be opened in a vi-like editor?! It clears and fills the entire terminal page and seems to display an input mode at the bottom.
Both of these aspects are non-existent on the fsl-image-qt5 based system. There, colours are displayed normally and the output is just printed right beneath my command call.
I have discovered that I can get these two commands to work properly on the core-image-base based system, if I pipe their output into cat: "nmcli | cat".
My assumption for the colour codes is that, the core-image-base system uses a different text encoding, or a different style of colour codes and therefore does not recognize the ones presented by nmcli.
I have tried to install the ttf-dejavu-* fonts that are present on the fsl-image-qt system. I also verfied that both systems seem to be using POSIX as their LANG setting ("locale" produces the same output on both).
I have no idea why the output is presented in what seems to be a vi editor though. Both systems have their EDITOR variable set to "vi".
Am I missing some kind of package or setting in my image?
I am at my wits' end and would greatly appreciate anyone trying to shed some light on what is going on here.
Stefan Wenninger

Its perhaps some of busybox applets like cat etc. Try core-image-full-cmdline and see if its any better.

Hi,
I recently switched form an image based on fsl-image-qt5 to one based on core-image-base.
The new image works fine in every regard except that the output of some commands looks weird.

I have attached the output of commands "nmcli" and "systemctl status dbus". Once executed on the fsl-image-qt5 based system and once on the core-image-base based system (_weird.txt).
There are two main points I gather from that weird output:
1. There are some codes like "[[32m"+"[[0m" or "[[0;1;32m"+"[[0m", which I assume are colour codes, that are printed and not applied.
2. The output appears to be opened in a vi-like editor?! It clears and fills the entire terminal page and seems to display an input mode at the bottom.

Both of these aspects are non-existent on the fsl-image-qt5 based system. There, colours are displayed normally and the output is just printed right beneath my command call.

I have discovered that I can get these two commands to work properly on the core-image-base based system, if I pipe their output into cat: "nmcli | cat".

My assumption for the colour codes is that, the core-image-base system uses a different text encoding, or a different style of colour codes and therefore does not recognize the ones presented by nmcli.
I have tried to install the ttf-dejavu-* fonts that are present on the fsl-image-qt system. I also verfied that both systems seem to be using POSIX as their LANG setting ("locale" produces the same output on both).
I have no idea why the output is presented in what seems to be a vi editor though. Both systems have their EDITOR variable set to "vi".

Am I missing some kind of package or setting in my image?

I am at my wits' end and would greatly appreciate anyone trying to shed some light on what is going on here.
Stefan Wenninger

Hi Damien,

Hi,

I've put GnuPG in my image, and I'd like to deploy a set to public and private keys into the system images.

How can I do that from recipes?

You do this with a shell function that is added to ROOTFS_POSTPROCESS_COMMAND. Here is a script that I use to create SSH keys:

# Image post-processing to configure sshd

# Setup ssh key login for these users
SSH_USERS ??= ""
SSH_DISALLOW_PWAUTH ??= "1"

configure_sshd() {
   # disallow password authentication
   if [ "${SSH_DIALLOW_PWAUTH}" == "1" ]; then
      echo "PasswordAuthentication no" >> ${IMAGE_ROOTFS}/etc/ssh/sshd_config
   fi

   # keys will be stored tmp/deploy/keys
   mkdir -p ${DEPLOY_DIR}/keys

   # create the keys for the users
   for user in ${SSH_USERS}; do
      if [ ! -f ${DEPLOY_DIR}/keys/${user}-sshkey ]; then
      /usr/bin/ssh-keygen -t rsa -N '' \
         -f ${DEPLOY_DIR}/keys/${user}-sshkey
      fi

      # add public key to authorized_keys for the user
      mkdir -p ${IMAGE_ROOTFS}/home/${user}/.ssh
      cat ${DEPLOY_DIR}/keys/${user}-sshkey.pub \
          >> ${IMAGE_ROOTFS}/home/${user}/.ssh/authorized_keys
   done
}
ROOTFS_POSTPROCESS_COMMAND += "configure_sshd;"

I have this script as an include file that I included into my image recipes.

:rjs

Thanks,

-Damien

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700