On Fri, Jun 4, 2021 at 8:37 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield <bruce.ashfield@...> wrote:

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.

I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.

Apologies on this, I see in the follow up email you did mention the
layerindex .. I read completely over that, and had to search up the
warning myself. (my fault, not yours).

That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.

This point still stands though :D

Bruce

Bruce

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

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

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

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield <bruce.ashfield@...> wrote:

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.

I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.

That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.

Bruce

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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