Date   

Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.

Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [meta-gplv2][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

On 6/4/21 2:49 PM, kai wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Please ignore it according to Martin's comment in oe-devel list.

Regards,
Kai


Signed-off-by: Kai Kang <kai.kang@...>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"
 
 LAYERDEPENDS_gplv2 = "core"
 
-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"
 
 LICENSE_PATH += "${LAYERDIR}/licenses"
 




-- 
Kai Kang
Wind River Linux


Can the Linux kernel reuse the barebox device tree? #kernel

florian.kauer@...
 

Hi,
I made the following observation in my custom Yocto system:
The device tree loaded by the Linux kernel is one that is only available in the barebox directory, but not available in the kernel sources. In fact, it is quite similar, but I made some changes to it in the device tree provided to the kernel. Especially the machine model that is shown during kernel boot is a string that can only be found in the compiled barebox image, but not in the dtb files (where I can find the correct machine model string) or anywhere else in the compilation results. But also other messages indicate that the wrong device tree is loaded.

It was correct before, and I am not really sure what triggered that (just upgraded from zeus, but it might or might not be triggered by that) and I wouldn't expect that anyone could guess what I have done wrong without debugging my setup in depth. But, my general question is: Is there any mechanism that could explain such a behavior? Any configuration that means "extract the device tree from the bootloader" or something similar?

Greetings,
Florian


[meta-openssl102-fips][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

From: Kai Kang <kai.kang@...>

There is no hardknott branch yet, so keep 'hardknott' rather than
replace it.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 01026f0..27ddad6 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5"

LAYERVERSION_meta-openssl-one-zero-two-fips = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott honister"

LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}"

--
2.17.1


[meta-gplv2][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"

LAYERDEPENDS_gplv2 = "core"

-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"

LICENSE_PATH += "${LAYERDIR}/licenses"

--
2.17.1


[meta-openssl102][PATCH] layer.conf: support honister

kai
 

From: Kai Kang <kai.kang@...>

There is no hardknott branch yet, so keep 'hardknott' rather than
replace it.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 4ea1009..ce7f99b 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two = "5"

LAYERVERSION_meta-openssl-one-zero-two = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "hardknott honister"

LAYERDEPENDS_meta-openssl-one-zero-two = " \
core \
--
2.17.1


[linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: dspi: fsl: fix dspi transfer hang issue

Zhantao Tang
 

Hi Bruce,


There is an patch to fix dspi hang issue.

Would you please help to merge this patch into linux-ycoto kernel, v5.10, branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx?


Thanks,
Zhantao


[PATCH] drivers: dspi: fsl: fix dspi transfer hang issue

Zhantao Tang
 

On NXP S32G RDB2, there is an sja1110 switch, which can be accessed
using dspi interface, but if users use the following commands to test
the switch, the board will hang there.

$ echo 30 > /sys/class/gpio/export
$ echo out > /sys/class/gpio/gpio30/direction
$ echo 0 > /sys/class/gpio/gpio30/value
$ echo -n -e '\x02\x00\x00\x00\x00\x00\x00\x00' | spi-pipe -d /dev/spidev5.1 -b 4 | hexdump -C

The reason is that, the dspi driver wrongly sets the HALT flag in
the register, and the while loop will run forever, so the board hang
there. This patch is to fix this issue.

Signed-off-by: Zhantao Tang <zhantao.tang@...>
---
drivers/spi/spi-fsl-dspi.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 063cf4a60ed3..c20cce466bf7 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -965,10 +965,8 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
dspi->progress = 0;

regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_HALT, SPI_MCR_HALT);
- while (regmap_read(dspi->regmap, SPI_SR, &val) >= 0 &&
- val & SPI_SR_TXRXS)
- ;
+ SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF,
+ SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);

spi_take_timestamp_pre(dspi->ctlr, dspi->cur_transfer,
dspi->progress, !dspi->irq);
@@ -987,10 +985,6 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
} while (status == -EINPROGRESS);
}
}
- regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF |
- SPI_MCR_HALT,
- SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);
if (status)
break;

--
2.25.1


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

kai
 

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show warning:

  WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott: length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch master, please?

Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?

Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.

Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


[meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

kai
 

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1


#bitbake bitbake fails when build for sqlcipher on AM335x #bitbake

shrinivasnh@...
 

I am following steps mentioned below link to create Kernel and u-boot for AM335x starter kit
 
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Overview_Building_the_SDK.html
Its building correctly.

Now I am using the meta-webos-master layer which has sqlcipher to be addedto the Linux kernel, I am getting errrors durig the build itself
The error is as below
========================
/AM335x/prj/tisdk/build$ MACHINE=am335x-evm bitbake arago-base-tisdk-image
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/appdev-426043/AM335x/prj/tisdk/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 19434 at 2021-06-03 19:52:05.846548 ---
WARNING: Layer meta-processor-sdk should set LAYERSERIES_COMPAT_meta-processor-sdk in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer meta-webos should set LAYERSERIES_COMPAT_meta-webos in its conf/layer.conf file to list the core layer names it is compatible with.
ERROR: ParseError at /home/appdev-426043/AM335x/prj/tisdk/sources/meta-arago/meta-webos-master/classes/package.bbclass:52: Could not inherit file classes/prserv.bbclass
 
Request help or pointers to resolve  the issue


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: June 3, 2021

Randy MacLeod
 

Attendees: Sakib, Alex, Richard, Saul, Randy

1. Sakib is working on using procpath (1) to generate full-system process summary that is specific to bitbake builds and perhaps even
YP AB.

The basic idea is to take a single run of top and convert it to something easier to quicly understand (see (4) below).


We are interested in procpath since screen scraping the top output
is likely error prone. Richard is concerned that
using python and this module will be quite inefficent compared to what
top does. That's a valid concern but we believe and will prove that
the module and top are both just accessing the same data in /proc.
Stay tuned.


2. Tony and Randy have a work-around of using taskset for the valgrind
races. We will have a patch to use taskset of the list of 'racey'
valgrind tests. We think it has gotten worse when we added 'smp'
to qemu. There are similar VG bug reports from 5
years ago so we may have to carry the work-around for some time.


3. Add logging to runqemu when qemu fails.

a. Run ps (or top) to see what's happening on the host.
b. collect qemu logs
In this example:

https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/2386/steps/12/logs/stdio
there should be a log file unde:

/home/pokybuild/yocto-worker/qemux86-alt/build/build/tmp/work/qemux86-poky-linux/core-image-sato-sdk/1.0-r0/temp

but s/temp/testimage/ and logs should be under there.

Note that the logs may not always be there so check and
make that clear with a warning when one is missing.
This now is Sakib's top priority for the week.


4. Regarding a LTP test that fails because mkdir failed...
This is described in an email (2) from Richard with the subject:
Re: [swat] qemux86-64 ltp kernel panic

Alex is going to use gcore (3) to get a core file for the qemu process
and try to figure out what is crazy in the qemu guest kernel.

Did that work Alex?
Where are the core file and related symbols?

5. As a general remark, we are overloading the systems but
we don't want to scale back too much.

In the cases wehre qemu failed to copy in 120 seconds,
what has generally be going on is lots of builds involving:
llvm, kea, webkit or two, musl world build.
The load average goes over 300 but as you'd expect most jobs
are sleeping.
We think the biggest step forward on this is the job server that
Trevor is going to start working on that.

There are a few knobs that we can adjust to reduce the maximum load:
- Number of build in parallel - currently 3
- parallel make - currently 16, could drop to 12 but
dropping below say 8 would reduce the test system throughput too much.
- bb number of threads - number of bitbake tasks.

Many times this results in a RCU stall and things go off the rails.


If anyone else is interested in helping, please let me know.
More next week.


--
# Randy MacLeod
# Wind River Linux


1) https://heptapod.host/saajns/procpath
2) https://lists.yoctoproject.org/g/swat/message/156
3) https://www.linux.org/docs/man1/gcore.html

4)

If I hack up a sed pipeline and run it on the entire latency-full.log, I get:

$ cat /tmp/latency-full.log | grep -v "^NOTE:" | \
cut -c 69- | cut -d" " -f 1 | grep -v "\[" | \
sed -e 's|/home/pokybuild/yocto-worker/|/~/|' | \
sed -e 's|/build/build/tmp/work/core2-64-poky-linux/| .../tmp/pklin/... |g' | \
sed -e 's|/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/| .../gcc-foo/... |' | \
sed -e 's|/build/build/tmp/work/core2-32-poky-linux/| .../pklin32/... |' | \
grep -v "^$" | \
sort | uniq -c | sort -n | tail -30

42 /~/meta-oe .../tmp/pklin/... vulkan-cts/1.2.6.0-r0 .../gcc-foo/... 11.1.0/as
42 /~/meta-oe .../tmp/pklin/... vulkan-cts/1.2.6.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++
43 as
43 top
44 tar
45 cmake
45 ninja
50 /~/reproducible-ubuntu/build/build-st-38234/reproducibleB/tmp/work/qemux86_64-poky-linux/linux-yocto/5.4.119+gitAUTOINC+9e2546ab8d_8997f66300-r0 .../gcc-foo/... 9.3.0/cc1
58 bitbake-server
58 /lib/systemd/systemd
58 (sd-pam)
65 /~/pkgman-non-rpm/build/build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo
90 /~/pkgman-non-rpm/build/build/tmp/work/qemux86-poky-linux/linux-yocto/5.4.119+gitAUTOINC+9e2546ab8d_8997f66300-r0/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/9.3.0/cc1
97 /~/meta-oe .../tmp/pklin/... opengl-es-cts/3.2.7.0-r0 .../gcc-foo/... 11.1.0/cc1plus
98 /~/meta-oe .../tmp/pklin/... opengl-es-cts/3.2.7.0-r0 .../gcc-foo/... 11.1.0/as
102 /~/meta-oe .../tmp/pklin/... opengl-es-cts/3.2.7.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++
112 /~/meta-oe .../tmp/pklin/... mongodb/4.4.5+4.4.6-rc0-r0 .../gcc-foo/... 11.1.0/cc1plus
113 /~/meta-oe .../tmp/pklin/... mongodb/4.4.5+4.4.6-rc0-r0 .../gcc-foo/... 11.1.0/as
116 /usr/bin/python3
141 i686-poky-linux-gcc
151 /~/meta-oe .../tmp/pklin/... nodejs/14.16.1-r0 .../gcc-foo/... 11.1.0/cc1plus
153 /~/meta-oe .../tmp/pklin/... nodejs/14.16.1-r0 .../gcc-foo/... 11.1.0/as
154 sh
209 x86_64-poky-linux-gcc
313 x86_64-poky-linux-g++
345 /~/meta-oe/build/build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo
476 /bin/bash
629 make
1130 python3
1331 /bin/sh

the 'one cmd' lines such as, 'make, python3, /bin/sh, tar lines clearly need more context.

There's more work to do cleaning up some 'noise' but does
anyone want anything else in the first version?

Trevor pointed me at:
https://heptapod.host/saajns/procpath
that we might useful but I haven't played with it yet.

A quick simple filter is likely a better starting point.


Re: Conditionally install files depending on locale

Scott Weaver
 

You might consider creating a custom task in your recipe where you can
handle your unique requirements.

https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#tasks

Scott

On Mon, May 31, 2021 at 3:58 PM Amr Bekhit <amr@...> wrote:

Hello,

I'm trying to put together a recipe where I conditionally install files depending on the image locale. I can see from the reference manual that Yocto will use the contents of IMAGE_LINGUAS to install locales during the root filesystem construction process. How can I go about creating locales for my custom packages/recipes?


Recipe for include-what-you-use and rpath problem #sdk

Francesco Cusolito
 

Good morning everybody,

I would like to include IWYU in my SDK, but I couldn't find a recipe, so I'm trying to write my own.
With the help of devtool, I came to something like this:

LICENSE = "NCSA"
LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=59d01ad98720f3c50d6a8a0ef3108c88 \
                    file://iwyu-check-license-header.py;md5=cdc4ab52c0b26e216cbf434649d30403"

SRC_URI = "git://github.com/include-what-you-use/include-what-you-use.git;protocol=https;branch=clang_10"

PV = "0.14+git${SRCPV}"
SRCREV = "0.14"

S = "${WORKDIR}/git"

DEPENDS = "clang"

inherit cmake python3native

BBCLASSEXTEND_append = " \
        nativesdk \
        "

The application seems to compile fine, but in do_package step it fails with this error message:

ERROR: nativesdk-include-what-you-use-0.14+git999-r0 do_package: chrpath command failed with exit code 7:
/build/archimede/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-include-what-you-use/0.14+git999-r0/package/opt/Delcon/sdk/delconos-archimede-raspberrypi3-64/sysroots/x86_64-pokysdk-linux/usr/bin/include-what-you-use: RPATH=$ORIGIN/../lib:/build/archimede/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-include-what-you-use/0.14+git999-r0/recipe-sysroot/opt/Delcon/sdk/delconos-archimede-raspberrypi3-64/sysroots/x86_64-pokysdk-linux/usr/lib

new rpath '$ORIGIN/../lib:$ORIGIN/../../../../../../../../build/archimede/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-include-what-you-use/0.14+git999-r0/recipe-sysroot/opt/Delcon/sdk/delconos-archimede-raspberrypi3-64/sysroots/x86_64-pokysdk-linux/usr/lib' too large; maximum length 220

ERROR: Logfile of failure stored in: /build/archimede/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-include-what-you-use/0.14+git999-r0/temp/log.do_package.1595
ERROR: Task (virtual:nativesdk:/build/archimede/workspace/recipes/include-what-you-use/include-what-you-use_git.bb:do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1033 tasks of which 1024 didn't need to be rerun and 1 failed.

You can see full bitbake logs attached.
It seems to me that the error happens in perform_packagecopy function, in invocation of rpath_replace.

The problem seems to be similar to the one reported on u-boot-mkimage in topic 61277548, 4 years ago.
I tried to apply something similar to u-boot-mkimage recipe commit 5d3df78367be0afbfe001b4fa776a98a82e6ce54 proposed as solution in above topic, but with no success: I came to the conclusion that cmake class is already doing the correct job here, as shown by log files attached.

How can I resolve this RPATH problem?

Thanks in advance,
Francesco


Move of official IRC channels to libera.chat

Nicolas Dechesne
 

Dear all,

As some of you may have read over the past days, there has been an
ownership dispute over the freenode.net network. The IRC network has
been used by the Yocto Project and many other projects over the past
decades as a platform for discussion and support. The dispute led to
the exodus of most former freenode staff from the network and the
founding of a new network: libera.chat [1].

Starting today, the Yocto Project is migrating the official IRC
channels from freenode.net to libera.chat. Everyone is encouraged to
join #yocto on libera.chat, and get their nick registered on the new
network as soon as possible.

It's a soft migration, we don't expect to kick users from #yocto on
freenode anytime, unless things go really bad on freenode. However we
encourage everyone to move to libera.chat and *leave* the freenode
channels during the next few weeks. We understand it will take some
time to finalize the transition of all users, it is very important
that we don't leave any member from our community behind during this
transition.

The Yocto Project community website was updated with all the
information mentioned here, and can be found at [2].

We thank the freenode community for the many years of great service
and collaboration, IRC has been, and will remain a key communication
medium for our community!

In addition, on popular demand, the Yocto Project can also be found on
the Open Matrix Network, in the dedicated room called
#yoctoproject:matrix.org, which can be accessed using [3]. Note that
this Matrix room is bridged to the #yocto channel on Libera.chat,
enabling full two-way communication between IRC and Matrix users.

It is worth mentioning that OpenEmbedded has engaged in a similar
transition, and users are encouraged to join #oe on libera.chat (or
the OpenEmbedded Room on the Open Matrix Network [4]).

In case of any difficulty , please reach out to me, Michael,
Jan-Simon, Khem or Philip!

cheers
nico

[1] https://libera.chat/
[2] https://www.yoctoproject.org/community/mailing-lists/
[3] https://matrix.to/#/#yoctoproject:matrix.org
[4] https://matrix.to/#/#oe:matrix.org


[ANNOUNCEMENT] Yocto Project 3.1.8 (dunfell-23.0.8) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.1.8 (dunfell-23.0.8) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/poky-dunfell-23.0.8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.8/poky-dunfell-23.0.8.tar.bz2

 

A gpg signed version of these release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/testreport.txt

 

Thank you for everyone's contributions to this release.

 

 

Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapalli@...

 

- --------------------------

yocto-3.1.8 Release Notes

- --------------------------

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.8

Git Revision: 6ebb33bdaccaeadff0c85aab27acf35723df00d8

Release Artefact: poky-dunfell-23.0.8

sha: 3ca4775bec270eae7d30bf290db42d918378891ba1be6026f30f6bc245be60e4

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/poky-dunfell-23.0.8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.8/poky-dunfell-23.0.8.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: 2020-04.8-dunfell

Git Revision: ecd636154e7cfc1349a7cfd8026a85eafa219535

Release Artefact: oecore-dunfell-23.0.8

sha: bf986f379fe1e038ccff49aee6f85e7006758738cddd916eb8dd3032a981c929

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/oecore-dunfell-23.0.8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.8/oecore-dunfell-23.0.8.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.8

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.8

sha: 1c9f7ba3e9dba8ceb8155890c7365af6fc6486e54fba4aa3fb8032f6ea494bdb

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/meta-mingw-dunfell-23.0.8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.8/meta-mingw-dunfell-23.0.8.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.8

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.8

sha: 8106a9651a4d1a111f7922557d56898a00a6c1c88c80477997bf5a38a16fd208

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/meta-gplv2-dunfell-23.0.8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.8/meta-gplv2-dunfell-23.0.8.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: 1.46

Tag: 2020-04.8-dunfell

Git Revision: 078f3164dcb1de7a141bec3a8fd52631d0362631

Release Artefact: bitbake-dunfell-23.0.8

sha: 888ada8f64b94d03c430fcf309e994ed0bd96ff09d4909aacc0706e0cf8c8659

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.8/bitbake-dunfell-23.0.8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.8/bitbake-dunfell-23.0.8.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.8

Git Revision:09b64a4d246bdcca62dddee152deef7b0dea69d7

 

- ------------

Contributors

- ------------

Alexander Kanavin

Anatol Belski

Anuj Mittal

Bruce Ashfield

Chen Qi

Christophe Chapuis

Diego Sueiro

Douglas Royds

Gavin Li

Guillaume Champagne

Jose Quaresma

Joshua Watt

Kai Uwe Broulik

Khem Raj

Konrad Weihmann

Lee Chee Yang

Marek Vasut

Mark Hatle

Michael Opdenacker

Mike Crowe

Mikko Rapeli

Mingli Yu

Niels Avonds

Peter Budny

Peter Morrow

Reto Schneider

Richard Purdie

Robert P. J. Day

Romain Naour

Ross Burton

Stefan Ghinea

Steve Sakoman

Vinay Kumar

Yanfei Xu

Yann Dirson

Yi Fan Yu

Zhang Qiang

zhengruoqin

 

- ---------------

Known Issues

- ---------------

Intermittent Failure in ptest : strace.printstrn-umoven.gen.test

 

 

- ---------------

Security Fixes

- ---------------

db: update CVE_PRODUCT

avahi: Exclude CVE-2021-26720 from cve-check

librsvg: Exclude CVE-2018-1000041 from cve-check

coreutils: Exclude CVE-2016-2781 from cve-check

tiff: Exclude CVE-2015-7313 from cve-check

bluez: Exclude CVE-2020-12352 CVE-2020-24490 from cve-check

ghostscript: Exclude CVE-2013-6629 from cve-check

cpio: Exclude CVE-2010-4226 from cve-check

unzip: Exclude CVE-2008-0888 from cve-check

openssh: Exclude CVE-2008-3844 from cve-check

openssh: Exclude CVE-2007-2768 from cve-check

logrotate: Exclude CVE-2011-1548,1549,1550 from cve-check

jquery: Exclude CVE-2007-2379 from cve-check

qemu: Exclude CVE-2018-18438 from cve-check

qemu: Exclude CVE-2007-0998 from cve-check

qemu: Exclude CVE-2017-5957 from cve-check

builder: whitelist CVE-2008-4178 (a different builder)

libnotify: whitelist CVE-2013-7381 (specific to the NodeJS bindings)

cairo: backport patch for CVE-2020-35492

glibc: Document and whitelist CVE-2019-1010022-25

tiff: fix CVE-2020-35523 CVE-2020-35524

qemu: fix CVE-2021-3392

subversion: fix CVE-2020-17525

binutils: fix CVE-2021-3487

tar: Fix CVE-2021-20193

Binutils: Fix CVE-2021-20197

wpa-supplicant: fix CVE-2021-30004

curl: Patch CVE-2021-22876 & CVE-2021-22890

 

 

- ---------------

Fixes

- ---------------

build-appliance-image: Update to dunfell head revision

poky.conf: Bump version for 3.1.8 release

poky.conf: Add fedora33 as a supported distro

documentation: prepare for 3.1.8 release

ref-system-requirements.rst: Add Fedora 33 to list of supported distros

sstate: Handle manifest 'corruption' issue

boost: fix do_fetch failure

Revert "cml1.bbclass: Return sorted list of cfg files"

bitbake: providers: selected version not available should be a warning

meta/lib/oe/rootfs.py: Fix typo "Restoreing" -> "Restoring"

image.bbclass: fix comment "pacackages" -> "packages"

dejagnu: needs expect at runtime

linux-yocto/5.4: qemuppc32: reduce serial shutdown issues

linux-firmware: include all relevant files in -bcm4356

linux-firmware: upgrade 20210208 -> 20210315

lsb-release: fix reproducibility failure

oeqa/qemurunner: Improve handling of run_serial for shutdown commands

oeqa/qemurunner: Fix binary vs str issue

oeqa/qemurunner: Improve logging thread exit handling for qemu shutdown test

python3-jinja2: 2.11.2 -> 2.11.3

poky-tiny.conf: set PREFERRED_VERSION_linux-yocto-tiny to 5.4%

reproducible.py: add quilt-ptest and valgrind-ptest

ovmf: update edk2-stable202005 -> edk2-stable202008

ovmf: update to 202005

ovmf: update to 202002

lib/package_manager: Use shutil.copy instead of bb.utils.copyfile for intercepts

libevent: Increase ptest timing tolerance 50 ms -> 100 ms

sanity.bbclass: mention CONNECTIVITY_CHECK_URIS in network failure message

classes/image: Use xargs to set file timestamps

Revert "oeqa: Set LD_LIBRARY_PATH when executing native commands"

diffoscope: add native libraries to LD_LIBRARY_PATH

make-mod-scripts: add HOSTCXX definitions and gmp-native dependency

perf: fix python-audit RDEPENDS

cml1.bbclass: Return sorted list of cfg files

rootfs.py: find .ko.gz and .ko.xz kernel modules as well

pybootchart/draw: Avoid divide by zero error

gstreamer1.0-plugins-good: on wayland qt5 needs qtwayland

kernel.bbclass: Remove do_install[prefunc] no longer needed

ptest-runner: libgcc must be installed for pthread_cancel to work

linux-yocto/5.4: update to v5.4.116

linux-yocto/5.4: update to v5.4.114

wireless-regdb: upgrade 2020.11.20 -> 2021.04.21

yocto-uninative: Update to 3.1 which includes a patchelf fix

bitbake: fetch/gitsm: Fix crash when using git LFS and submodules

bitbake: runqueue: Fix deferred task issues

bitbake: bitbake: tests/fetch: remove write protected files too

bitbake: bitbake: tests/fetch: fix test execution without .gitconfig

license_image.bbclass: Fix symlink to generic license files

license_image.bbclass: Detect broken symlinks

linux-firmware: Package RSI 911x WiFi firmware

yocto-check-layer: Avoid bug when iterating and autoadding dependencies

kernel.bbclass: Configuration for environment with HOSTCXX

meta/lib/oeqa/core/tests/cases/timeout.py: add a testcase for the previous fix

oeqa: tear down oeqa decorators if one of them raises an exception in setup

oeqa/selftest/bblayers: Add test case for bitbake-layers layerindex-show-depends

cve-update-db-native: skip on empty cpe23Uri

linux-yocto/5.4: fix arm defconfig warnings

linux-yocto/5.4: update to v5.4.112

linux-yocto/5.4: update to v5.4.111

linux-yocto/5.4: update to v5.4.109

ca-certificates: Fix openssl runtime cert dependencies

parselogs: ignore floppy error on qemu-system-x86 at boot stage

groff: not ship /usr/bin/grap2graph

libtool: make sure autoheader run before automake

kmod: do not symlink config.guess/config.sub during autoreconf

pseudo: Upgrade to add trailing slashes ignore path fix

lib/oe/terminal: Fix tmux new-session on older tmux versions (<1.9)

sanity: Further improve directory sanity tests

sanity: Add error check for '%' in build path

insane: clean up some more warning messages

oeqa/selftest: Ensure packages classes are set correctly for maintainers test

oeqa/selftest: Hardcode test assumptions about heartbeat event timings

externalsrc: Detect code changes in submodules

Revert "externalsrc: Detect code changes in submodules"

go_1.14: don't set -buildmode=pie when building for windows targets

goarch: map target os to windows for mingw* TARGET_OS

image-live.bbclass: optional depends when ROOTFS empty

diffoscope: Upgrade 168 -> 172

diffoscope: Upgrade 136 -> 168

selftest/reproducible: Sort the unused exclusion list

selftest/reproducible: track unusued entries in the exclusion list

selftest/reproducible: adjust exclusion list for dunfell

selftest/reproducible: add an exclusion list for items that are not yet reproducible

selftest/reproducible: enable world reproducibility test


Re: systemd, ELF binaries and runtime dependency tracking

Luca Bocassi
 

On Tue, 2021-06-01 at 09:23 -0700, Khem Raj wrote:

On 6/1/21 9:13 AM, Luca Boccassi wrote:
On Tue, 2021-06-01 at 07:58 -0700, Khem Raj wrote:
On 5/31/21 3:40 PM, Paul Eggleton wrote:
Hi folks

Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?

https://github.com/systemd/systemd/pull/17416

For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.
Finding dlopen dependencies is a neat idea, but it has to be accepted
cross distro, and also applications have to manually declare it in code
if I understand systemd's patch correctly. This will be hard to
accomplish as you can see changes are spread across apps from distro
point of view. Perhaps there is a smarter way of detecting adding them
in ELF spec itself and then have tools like linker help implement this
and also possibly collect the information or guide the users to achieve
this would be helpful.
Yes ideally ELF shared objects/the linker/the loader would support weak
symbols (like dylib on OSX). Unfortunately they do not, and it seems
there's no interest to add it becasue there's no concrete use case that
shows it's useful. But that cannot happen until there's some support
for it. Chicken and egg...
right and thats why I will be reluctant to go too far at distro level
unless there is general interest in wider communities as it can make us
an island.

There have been lots of theoretical discussions about pros and cons,
and my hope was that if at least one distro could find it useful, and
could show that it is in practice useful and the theoretical issues are
not that problematic and could be solved, others would follow suit.
you could tool it as a packageconfig for systemd alone and run with it
and see how it pans out.

So leaving aside other distros, is this something that would concretely
benefit the Yocto project for handling the systemd recipe? There are
currently 12 dlopen()-based optional dependencies in systemd, and the
number grows with each release.
we could certainly try that, provided systemd upstream is supportive of it.
Yeah, I was thinking of starting from the systemd recipe only. Given
the project has to add support for it, a distro-wide rollout wouldn't
make much sense anyway.

--
Kind regards,
Luca Boccassi


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Example helps. Thanks!!


On Mon, May 31, 2021 at 2:05 AM Zoran <zoran.stojsavljevic@...> wrote:
What about the following:
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

To be enhanced/added with the following:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-hardknott/README.md

Best Regards,
Zee
_______

On Fri, May 28, 2021 at 3:02 PM Swapna Nannapaneni
<sayinswapna@...> wrote:
>
> Typo. No leading space  INIT_MANAGER = "sysvinit".
>
> Thanks,
> Priya.
>
> On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
>>
>> > you don't want the leading space.
>>
>> I got the idea from reading
>> https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection
>>
>> But this is exactly why we need some explicit examples. :-)
>>
>> Zee
>> _______
>>
>> On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:
>> >
>> > On Fri, 28 May 2021, Zoran wrote:
>> >
>> > > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
>> > >
>> > > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
>> > > blank at the beginning)?
>> > >
>> > > Thank you,
>> > > Zee
>> >
>> >   you don't want the leading space.
>> >
>> > rday




Re: systemd, ELF binaries and runtime dependency tracking

Khem Raj
 

On 6/1/21 9:13 AM, Luca Boccassi wrote:
On Tue, 2021-06-01 at 07:58 -0700, Khem Raj wrote:

On 5/31/21 3:40 PM, Paul Eggleton wrote:
Hi folks

Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?

https://github.com/systemd/systemd/pull/17416

For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.
Finding dlopen dependencies is a neat idea, but it has to be accepted
cross distro, and also applications have to manually declare it in code
if I understand systemd's patch correctly. This will be hard to
accomplish as you can see changes are spread across apps from distro
point of view. Perhaps there is a smarter way of detecting adding them
in ELF spec itself and then have tools like linker help implement this
and also possibly collect the information or guide the users to achieve
this would be helpful.
Yes ideally ELF shared objects/the linker/the loader would support weak
symbols (like dylib on OSX). Unfortunately they do not, and it seems
there's no interest to add it becasue there's no concrete use case that
shows it's useful. But that cannot happen until there's some support
for it. Chicken and egg...
right and thats why I will be reluctant to go too far at distro level unless there is general interest in wider communities as it can make us an island.

There have been lots of theoretical discussions about pros and cons,
and my hope was that if at least one distro could find it useful, and
could show that it is in practice useful and the theoretical issues are
not that problematic and could be solved, others would follow suit.
you could tool it as a packageconfig for systemd alone and run with it and see how it pans out.

So leaving aside other distros, is this something that would concretely
benefit the Yocto project for handling the systemd recipe? There are
currently 12 dlopen()-based optional dependencies in systemd, and the
number grows with each release.
we could certainly try that, provided systemd upstream is supportive of it.

3701 - 3720 of 57417