On Sun, 5 Feb 2023 at 05:15, SIMON BABY <simonkbaby@...> wrote:

Thank you for the reply.
I was trying to add the layer https://github.com/savoirfairelinux/meta-embedded-containers in my yocto build. Below recipe uses sudo commands.

https://github.com/savoirfairelinux/meta-embedded-containers/blob/b131baa90291c159d3a725b8d66786c85964556c/recipes-support/container-image/container-image.bb

while building it fails at sudo command and getting the error below.

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

That layer is not maintained and you should not be using it. If you
want to use containers, meta-virtualization is the supported way.

Alex

Hi Richard,
Thank you for the reply.
 I was trying to add the layer https://github.com/savoirfairelinux/meta-embedded-containers in my yocto build. Below recipe uses sudo commands. 

https://github.com/savoirfairelinux/meta-embedded-containers/blob/b131baa90291c159d3a725b8d66786c85964556c/recipes-support/container-image/container-image.bb

while building it fails at sudo command and getting the error below.

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Regards
Simon

I am also facing the same issue while compiling grpc. 

On Fri, 2023-02-03 at 14:08 -0800, SIMON BABY wrote:

Hello team,
I am getting the below error whe try to execute command in bitbake
recipe having sudo. eg: sudo kill

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit
set

Can some please help how to fix it. The same errot did not see when i
execute outside bitbake.

You didn't say which task this was in, I'm going to guess it is one
being run under pseudo, our fakeroot emulator.

The fakeroot emulation doesn't work well with "real" sudo commands.

Cheers,

Richard

Hello team,
I am getting the below error whe try to execute command in bitbake recipe having sudo. eg: sudo kill

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Can some please help how to fix it. The same errot did not see when i execute outside bitbake.

There is a bug in the chrony Kirkstone recipe that was fixed in Langdale but has not been fixed in Kirkstone:
https://lists.openembedded.org/g/openembedded-devel/message/99080?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Cchrony+pkg-config%2C20%2C2%2C0%2C94155994
This adds pkgconfig to the inherit line to allow configure to find pkg-config.  Without this fix the recipe cannot build some features like NTS.

How to get this fix into Kirkstone?  Do I submit a patch?

Yes please, it does cherry-pick back cleanly but I didn't take the time to build/test.

FYI:

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

../Randy

meta-oe.git on kirkstone

❯ git log -6 --oneline langdale ^kirkstone meta-networking/recipes-support/chrony/
c354f9277 (langdale-next) chrony: Remove the libcap and nss PACKAGECONFIGs
aa811aa77 chrony: Make it possible to enable editline support again
aa20821f1 chrony: correct parameter to configure to disable readline usage
22682fdfb chrony: add pkgconfig class as pkg-config is explicitly searched for
fca74376e chrony: upgrade 4.2 -> 4.3
517c9dab9 chrony: add support for config and source snippet includes

❯ git cherry-pick 22682fdfb
Auto-merging meta-networking/recipes-support/chrony/chrony_4.2.bb
[kirkstone d4cc4f260] chrony: add pkgconfig class as pkg-config is explicitly searched for
 Author: Federico Pellegrin <fede@...>
 Date: Thu Oct 6 14:17:21 2022 +0200
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
# Randy MacLeod
# Wind River Linux

On 2023-02-02 17:10, Randy MacLeod via lists.yoctoproject.org wrote:

I don't know why there are two peaks that you can easily see on the linear scale distribution
but the 3 graphs show why I picked the 3 second cutoff.

I'm guessing but I suspect that the lower latency distribution is just from when

the Yocto AB workers are idle. The builders in the cluster at WR are always
busy, sometimes needlessly,  so I didn't consider that initially.

Sigh, that's obviously wrong since this data is only collected when running bitbake!

Maybe it's the arm vs the intel workers?

I'll stop speculating until I look at the data a bit more...

--

# Randy MacLeod
# Wind River Linux

On Thu, 2023-02-02 at 06:57 +0000, wangmy wrote:

I see the following two items on the page of 2022 Yocto Project Weekly Status Archive:
1. A tool, used for collaboration on the creation of release notes,
git-refinery-web has been made publicly available by Intel, thanks!
We may not be able to use it for 4.1 due to the timescales but the
hope is to use it in the future for collaboratively creating the
release notes.

You can find the code here:

https://git.yoctoproject.org/git-refinery-web/

We've had a few issues deploying an instance of it unfortunately.

2. Thinking about the idea of variable “filter” functions to help
implementation of recipe class extensions (like native and
nativesdk).

Where can I find relevant content about "variable filter function" and "git-refinery-web"?

There are some examples of filter functions here:

https://git.yoctoproject.org/poky-contrib/log/?h=jpew/bb-filters

It is very much a work in progress idea.

Cheers,

Richard

Hello Joel,

I do get the same, but my understanding is that the RT features are not enabled. I would expect to get:

  Linux raspberrypi4-64 5.15.34-v8 #1 SMP PREEMPT RT Tue Apr 19 19:21:26 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

When I check the .config file in the work folder CONFIG_PREEMPT=y is set but I would expect to see CONFIG_PREEMPT_RT=y instead.

That is what you get for rpi4 32 bit as mentioned by Aleksandr above. Is my understanding wrong?

Hi All,

QA for yocto-4.0.7.rc1 is completed. This is the full report for this release:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.

Thanks,
Jing Hui

I don't know why there are two peaks that you can easily see on the linear scale distribution
but the 3 graphs show why I picked the 3 second cutoff.

I'm guessing but I suspect that the lower latency distribution is just from when

the Yocto AB workers are idle. The builders in the cluster at WR are always
busy, sometimes needlessly,  so I didn't consider that initially.

-- 
# Randy MacLeod
# Wind River Linux

For the month of January 2023, the distribution of dd times has a long
tail that extends to 13 seconds with 2 events exceeding the current
limit of 30 seconds.

Reduce the timeout to 3 seconds based on the observed distribution of
dd times, which would result in the timout triggering about 20 times a month.
That's enough data to be useful but not so much that it's overwhelming the
logging or the people who will analyze it. It also avoids the rapid increase
in the tail of the distribution which starts to rise exponentially under 2 seconds.
It's sensible response time for people to expect the system to have.

See attached graphs!

I don't know why there are two peaks that you can easily see on the linear scale distribution
but the 3 graphs show why I picked the 3 second cutoff.

Below is histogram data for a 0.1 second bin of  the tail of the distribution.

I can share the raw data or the 0.001 ms binned version if anyone is interested.

../Randy

     53 1.0
     39 1.1
     31 1.2
     22 1.3
     14 1.4
     23 1.5
     10 1.6
     14 1.7
      7 1.8
      5 1.9
      6 2.0
      7 2.1
      3 2.2
      3 2.3
      2 2.4
      5 2.5
      1 2.6
      2 2.7
      1 2.9
      1 3.1
      3 3.3
      1 3.4
      4 3.6
      1 3.8
      1 3.9
      1 4.1
      2 4.2
      2 4.5
      1 5.0
      1 5.1
      1 5.4
      1 6.3
      1 13.

Signed-off-by: Randy MacLeod <Randy.MacLeod@...>
---
 config.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 446528a..e50ec44 100644
--- a/config.json
+++ b/config.json
@@ -68,7 +68,7 @@
             "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
             "BB_HEARTBEAT_EVENT = '60'",
             "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
-            "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh -c 100 -t 15'",
+            "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh -c 100 -t 3'",
             "BB_LOG_HOST_STAT_ON_FAILURE = '1'",
             "BB_LOG_HOST_STAT_CMDS_FAILURE = 'oe-time-dd-test.sh -l'",
             "SDK_TOOLCHAIN_LANGS += 'rust'",

-- 
# Randy MacLeod
# Wind River Linux

For the month of January 2023, the distribution of dd times has a long
tail that extends to 13 seconds with 2 events exceeding the current
limit of 30 seconds.

Reduce the timeout to 3 seconds based on the observed distribution of
dd times, which would result in the timout triggering about 20 times a month.
That's enough data to be useful but not so much that it's overwhelming the
logging or the people who will analyze it. It also avoids the rapid increase
in the tail of the distribution which starts to rise exponentially under 2 seconds.
It's sensible response time for people to expect the system to have.

Signed-off-by: Randy MacLeod <Randy.MacLeod@...>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 446528a..e50ec44 100644
--- a/config.json
+++ b/config.json
@@ -68,7 +68,7 @@
"RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
"BB_HEARTBEAT_EVENT = '60'",
"BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
- "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh -c 100 -t 15'",
+ "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh -c 100 -t 3'",
"BB_LOG_HOST_STAT_ON_FAILURE = '1'",
"BB_LOG_HOST_STAT_CMDS_FAILURE = 'oe-time-dd-test.sh -l'",
"SDK_TOOLCHAIN_LANGS += 'rust'",
--
2.34.1

There is a bug in the chrony Kirkstone recipe that was fixed in Langdale but has not been fixed in Kirkstone:
https://lists.openembedded.org/g/openembedded-devel/message/99080?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Cchrony+pkg-config%2C20%2C2%2C0%2C94155994
This adds pkgconfig to the inherit line to allow configure to find pkg-config.  Without this fix the recipe cannot build some features like NTS.

How to get this fix into Kirkstone?  Do I submit a patch?

Looking forward to the patches too. Thanks for working on it!

David