Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-4.1_M1.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. NUC 6
4. Edgerouter
5. Beaglebone

ETA for completion next Monday, June 6.

Thanks,
Jay

On Wed, 2022-06-01 at 15:17 +0100, Richard Purdie via
lists.yoctoproject.org wrote:

A build flagged for QA (yocto-4.1_M1.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.1_M1.rc1


Build hash information:

bitbake: 6a346df51b96a6c0e1ee516df36eb0b6c292b063
meta-agl: 3a0b7a965ba370ca1fbe2ca0e2ac3babace5204d
meta-arm: 0c4c33de09aa921cafcea2ad4b7bc0e19f844213
meta-aws: b2f5ef7e724d3a2271ef99d748734578cf8fcb1a
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: ebb8c1c26e57e78563760431a57b6da388b82be2
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: 90ff53b8df1e3259cbc201c658a4f3f4dddf3aa8
meta-virtualization: 8e8f59d007ca8d60ec77565663cf6285b8acbbd4
oecore: 18a0c31b3386aa5a04eb8ee8e804c2415a61eaaf
poky: 95066dde6861ee08fdb505ab3e0422156cc24fae


[there was one build failure on qemumip64 on the autobuilder in
testsdkext:
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/5251
we don't have any fix for that and investigation will take time, I
don't think it should block M1 and we should proceed with the other QA]

I was able to work this one out. It was a zero length bb_unihashes.dat
file being placed in the eSDK, probably from a race on bitbake's cache
files. I have an idea of what is happening and some patches which
should fix it but they need testing. The bug has been there since at
least dunfell so I don't think it should block release, it is very
rare.

Cheers,

Richard

Hi,
I have a recipe (See below) for python3-pygit2 which fails at do_compile if I just try to run it via

bitbake python3-pygit2

However if I instead

bitbake python3-pygit2 -c devhsell

and then

../temp/run.do_compile

It succeeds. Now I'm relatively new to devshell but I thought these were supposed to be equivalent.

How can I figure out what is going on here?

A build flagged for QA (yocto-4.1_M1.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.1_M1.rc1


Build hash information:

bitbake: 6a346df51b96a6c0e1ee516df36eb0b6c292b063
meta-agl: 3a0b7a965ba370ca1fbe2ca0e2ac3babace5204d
meta-arm: 0c4c33de09aa921cafcea2ad4b7bc0e19f844213
meta-aws: b2f5ef7e724d3a2271ef99d748734578cf8fcb1a
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: ebb8c1c26e57e78563760431a57b6da388b82be2
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: 90ff53b8df1e3259cbc201c658a4f3f4dddf3aa8
meta-virtualization: 8e8f59d007ca8d60ec77565663cf6285b8acbbd4
oecore: 18a0c31b3386aa5a04eb8ee8e804c2415a61eaaf
poky: 95066dde6861ee08fdb505ab3e0422156cc24fae


[there was one build failure on qemumip64 on the autobuilder in
testsdkext:
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/5251
we don't have any fix for that and investigation will take time, I
don't think it should block M1 and we should proceed with the other QA]

This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

On Tue, 2022-05-31 at 12:15 +0200, Quentin Schulz wrote:

Any feedback to give on this patch?

Looks good to me, merged. Sorry about the delay.

Cheers,

Richard

Honister is now EOL so remove the scheduled check.

Signed-off-by: Anuj Mittal <anuj.mittal@...>
---
schedulers.py | 4 ----
1 file changed, 4 deletions(-)

diff --git a/schedulers.py b/schedulers.py
index a11ce14..6d33969 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -417,10 +417,6 @@ schedulers.append(sched.Nightly(name='nightly-check-layer', branch='master', pro
schedulers.append(sched.Nightly(name='nightly-metrics', branch='master', properties=parent_default_props('metrics'),
builderNames=['metrics'], hour=7, minute=0))

-# Run check-layer-nightly twice a week for honister
-schedulers.append(sched.Nightly(name='nightly-check-layer-honister', properties=parent_default_props('check-layer-nightly', 'honister'),
- builderNames=['check-layer-nightly'], dayOfWeek=[2, 5], hour=2, minute=0, codebases = {'' : {'branch' : 'honister'}}))
-
# Run check-layer-nightly twice a week for kirkstone
schedulers.append(sched.Nightly(name='nightly-check-layer-kirkstone', properties=parent_default_props('check-layer-nightly', 'kirkstone'),
builderNames=['check-layer-nightly'], dayOfWeek=[0, 3], hour=2, minute=0, codebases = {'' : {'branch' : 'kirkstone'}}))
--
2.35.3

On Tue, May 31, 2022 at 07:52:05AM -0500, Joshua Watt wrote:

On Tue, May 31, 2022 at 7:27 AM <richard.purdie@...> wrote:

On Sat, 2022-05-28 at 07:40 +0300, Marius Vlad wrote:

On Fri, May 27, 2022 at 04:25:00PM -0400, Scott Murray wrote:

On Fri, 27 May 2022, Tim Orling wrote:

On Fri, May 27, 2022 at 9:18 AM Jan Simon Moeller <
jsmoeller@...> wrote:

Hi !

Yes, we need to look into this and likely change the location of the
RDEPENDS.
Thanks for flagging.

polkit needs to be in DISTRO_FEATURES and the recipe needs to have a check

for that (and inherit features_check)

[snip]

For an immediate fix I've moved the polkit addition to a bbappend added
via BBFILES_DYNAMIC, gated on meta-oe presence. The current intent is
that the meta-agl-core test on the autobuilder only need poky, so letting
this slip in was a thinko on our part. We may revisit making meta-oe a
required dependency when binary packagefeed prototyping starts in AGL.
Your comment re features_check is right on, I'll add that when I get a
chance over the weekend. One thing I may bring up on the next dev call
is Weston does need polkit in some situations (hence the addition in
AGL), so maybe shifting it to oe-core starts to make more sense now...

Yes, when using the logind launcher, or the seatd launcher with the
logind back-end, polkit is needed to activate the session. There's no
more a direct launcher, weston-launch has been removed and upstream weston
can for some time now use systemd user sessions to starting-up.

The seatd launcher with daemon or built-in back-end, appears to be doing
the activation on its own, but I reckon systemd-logind back-end will be
the de-facto back-end if changing the launcher in weston to seatd, and
removing systemd-logind launcher (as we're currently working towards
having just a single launcher).

One thing to mention here is that while digging this up I've found a
patch to systemd-logind [1] which supposedely should allow just logind
to activate the session as a non-root user, just that either it wasn't
working or it is no longer present, as I haven't been able to activate
sessions without polkit installed.

[1] https://github.com/openembedded/openembedded-core/commit/e42dd9cff98f2149904e104f08bc3f19ee7b6fc0

Adding Joshua, I'm hoping he might have some ideas here?

That patch in question fixed a regression in systemd behavior that was
introduced at some point that broke the non-polkit behavior. I was
able to get it fixed, but I also suspect that fighting against using
polkit isn't going to be productive in the long run and we should look
at a way to pull it in..... preferably without needing mozjs (why a
policy system decided to rely on javascript is beyond me). Eventually,
we are going to want polkit-only features from systemd and there won't
be grounds (like "This worked before polkit") to get upstream systemd
to change to support it.

oe-core and poky master already switched from mozjs to duktape with polkit.
I've cherry-picked these changes for my own branches of older yocto releases.

-Mikko

Thanks,
This did turn out be a a simple case of CMAKE_FIND_ROOT_PATH being clobbered in our CMakeLists.txt files which I had missed on the first look.

Hi,

I'm trying to add support for changing root pwd on systemd built by
yocto (using kirkstone branch).
I enabled chpasswd + passwd applets from busybox but they don't work
as the path is readonly. I symliked /etc/passwd and /etc.shadow to a
writable partition and it seems to work. Other problem is I have samba
enabled where pam is a required feature and after password change and
logout pam asks for changing password again.

I've tried to use usermod on target (same way as on build) but shadow
seems to create lock files on readonly and it also fails.

Another idea I had is to use overlayfs for complete /ect directory but
I'm not sure if this is the way to go.

Any suggestions?

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

On Tue, May 31, 2022 at 7:27 AM <richard.purdie@...> wrote:

On Sat, 2022-05-28 at 07:40 +0300, Marius Vlad wrote:

On Fri, May 27, 2022 at 04:25:00PM -0400, Scott Murray wrote:

On Fri, 27 May 2022, Tim Orling wrote:

On Fri, May 27, 2022 at 9:18 AM Jan Simon Moeller <
jsmoeller@...> wrote:

Hi !

Yes, we need to look into this and likely change the location of the
RDEPENDS.
Thanks for flagging.

polkit needs to be in DISTRO_FEATURES and the recipe needs to have a check

for that (and inherit features_check)

[snip]

For an immediate fix I've moved the polkit addition to a bbappend added
via BBFILES_DYNAMIC, gated on meta-oe presence. The current intent is
that the meta-agl-core test on the autobuilder only need poky, so letting
this slip in was a thinko on our part. We may revisit making meta-oe a
required dependency when binary packagefeed prototyping starts in AGL.
Your comment re features_check is right on, I'll add that when I get a
chance over the weekend. One thing I may bring up on the next dev call
is Weston does need polkit in some situations (hence the addition in
AGL), so maybe shifting it to oe-core starts to make more sense now...

Yes, when using the logind launcher, or the seatd launcher with the
logind back-end, polkit is needed to activate the session. There's no
more a direct launcher, weston-launch has been removed and upstream weston
can for some time now use systemd user sessions to starting-up.

The seatd launcher with daemon or built-in back-end, appears to be doing
the activation on its own, but I reckon systemd-logind back-end will be
the de-facto back-end if changing the launcher in weston to seatd, and
removing systemd-logind launcher (as we're currently working towards
having just a single launcher).

One thing to mention here is that while digging this up I've found a
patch to systemd-logind [1] which supposedely should allow just logind
to activate the session as a non-root user, just that either it wasn't
working or it is no longer present, as I haven't been able to activate
sessions without polkit installed.

[1] https://github.com/openembedded/openembedded-core/commit/e42dd9cff98f2149904e104f08bc3f19ee7b6fc0

Adding Joshua, I'm hoping he might have some ideas here?

That patch in question fixed a regression in systemd behavior that was
introduced at some point that broke the non-polkit behavior. I was
able to get it fixed, but I also suspect that fighting against using
polkit isn't going to be productive in the long run and we should look
at a way to pull it in..... preferably without needing mozjs (why a
policy system decided to rely on javascript is beyond me). Eventually,
we are going to want polkit-only features from systemd and there won't
be grounds (like "This worked before polkit") to get upstream systemd
to change to support it.

Cheers,

Richard

On Sat, 2022-05-28 at 07:40 +0300, Marius Vlad wrote:

On Fri, May 27, 2022 at 04:25:00PM -0400, Scott Murray wrote:

On Fri, 27 May 2022, Tim Orling wrote:

On Fri, May 27, 2022 at 9:18 AM Jan Simon Moeller <
jsmoeller@...> wrote:

Hi !

Yes, we need to look into this and likely change the location of the
RDEPENDS.
Thanks for flagging.

polkit needs to be in DISTRO_FEATURES and the recipe needs to have a check

for that (and inherit features_check)

[snip]

For an immediate fix I've moved the polkit addition to a bbappend added
via BBFILES_DYNAMIC, gated on meta-oe presence. The current intent is
that the meta-agl-core test on the autobuilder only need poky, so letting
this slip in was a thinko on our part. We may revisit making meta-oe a
required dependency when binary packagefeed prototyping starts in AGL.
Your comment re features_check is right on, I'll add that when I get a
chance over the weekend. One thing I may bring up on the next dev call
is Weston does need polkit in some situations (hence the addition in
AGL), so maybe shifting it to oe-core starts to make more sense now...

Yes, when using the logind launcher, or the seatd launcher with the
logind back-end, polkit is needed to activate the session. There's no
more a direct launcher, weston-launch has been removed and upstream weston
can for some time now use systemd user sessions to starting-up.

The seatd launcher with daemon or built-in back-end, appears to be doing
the activation on its own, but I reckon systemd-logind back-end will be
the de-facto back-end if changing the launcher in weston to seatd, and
removing systemd-logind launcher (as we're currently working towards
having just a single launcher).

One thing to mention here is that while digging this up I've found a
patch to systemd-logind [1] which supposedely should allow just logind
to activate the session as a non-root user, just that either it wasn't
working or it is no longer present, as I haven't been able to activate
sessions without polkit installed.

[1] https://github.com/openembedded/openembedded-core/commit/e42dd9cff98f2149904e104f08bc3f19ee7b6fc0

Adding Joshua, I'm hoping he might have some ideas here?

Cheers,

Richard

Hi Scott,

Il giorno Fri, 27 May 2022 16:25:00 -0400 (EDT)
Scott Murray <scott.murray@...> ha scritto:

On Fri, 27 May 2022, Tim Orling wrote:

On Fri, May 27, 2022 at 9:18 AM Jan Simon Moeller <
jsmoeller@...> wrote:

Hi !

Yes, we need to look into this and likely change the location of the
RDEPENDS.
Thanks for flagging.

polkit needs to be in DISTRO_FEATURES and the recipe needs to have a check

for that (and inherit features_check)

[snip]

For an immediate fix I've moved the polkit addition to a bbappend added
via BBFILES_DYNAMIC, gated on meta-oe presence.

Thanks for taking care. I confirm my testing build today didn't show up
this failure anymore.

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi all,

Any feedback to give on this patch?

Cheers,
Quentin

Signed-off-by: Armin Kuster <akuster808@...>
---
lib/oeqa/runtime/cases/smack.py | 39 ---------------------------------
1 file changed, 39 deletions(-)

diff --git a/lib/oeqa/runtime/cases/smack.py b/lib/oeqa/runtime/cases/smack.py
index 35e87ef..b8255c7 100644
--- a/lib/oeqa/runtime/cases/smack.py
+++ b/lib/oeqa/runtime/cases/smack.py
@@ -29,8 +29,6 @@ class SmackBasicTest(OERuntimeTestCase):
status,output = self.target.run("cat /proc/self/attr/current")
self.current_label = output.strip()

-class SmackAccessLabel(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_add_access_label(self):
''' Test if chsmack can correctly set a SMACK label '''
@@ -54,8 +52,6 @@ class SmackAccessLabel(SmackBasicTest):
"%s %s" %(LABEL,label_retrieved))


-class SmackExecLabel(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_add_exec_label(self):
'''Test if chsmack can correctly set a SMACK Exec label'''
@@ -79,8 +75,6 @@ class SmackExecLabel(SmackBasicTest):
"%s %s" %(LABEL,label_retrieved))


-class SmackMmapLabel(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_add_mmap_label(self):
'''Test if chsmack can correctly set a SMACK mmap label'''
@@ -104,8 +98,6 @@ class SmackMmapLabel(SmackBasicTest):
"%s %s" %(LABEL,label_retrieved))


-class SmackTransmutable(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_add_transmutable(self):
'''Test if chsmack can correctly set a SMACK transmutable mode'''
@@ -128,8 +120,6 @@ class SmackTransmutable(SmackBasicTest):
"%s %s" %(LABEL,label_retrieved))


-class SmackChangeSelfLabelPrivilege(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_privileged_change_self_label(self):
'''Test if privileged process (with CAP_MAC_ADMIN privilege)
@@ -145,8 +135,6 @@ class SmackChangeSelfLabelPrivilege(SmackBasicTest):
self.assertIn("PRIVILEGED", output,
"Privilege process did not change label.Output: %s" %output)

-class SmackChangeSelfLabelUnprivilege(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_unprivileged_change_self_label(self):
'''Test if unprivileged process (without CAP_MAC_ADMIN privilege)
@@ -163,8 +151,6 @@ class SmackChangeSelfLabelUnprivilege(SmackBasicTest):
"Unprivileged process should not be able to change its label")


-class SmackChangeFileLabelPrivilege(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_unprivileged_change_file_label(self):
'''Test if unprivileged process cannot change file labels'''
@@ -183,8 +169,6 @@ class SmackChangeFileLabelPrivilege(SmackBasicTest):
self.target.run("rm %s" % filename)
self.assertEqual( status, 0, "Unprivileged process changed label for %s" %filename)

-class SmackLoadRule(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_load_smack_rule(self):
'''Test if new smack access rules can be loaded'''
@@ -211,8 +195,6 @@ class SmackLoadRule(SmackBasicTest):
self.target.run('echo -n "%s" > %s/load' %(clean, self.smack_path))


-class SmackOnlycap(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_onlycap(self):
'''Test if smack onlycap label can be set
@@ -223,7 +205,6 @@ class SmackOnlycap(SmackBasicTest):
status, output = self.target.run("sh /usr/sbin/test_smack_onlycap.sh")
self.assertEqual(status, 0, output)

-class SmackNetlabel(SmackBasicTest):

@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_netlabel(self):
@@ -246,7 +227,6 @@ class SmackNetlabel(SmackBasicTest):
test_label, output,
"Did not find expected label in output: %s" %output)

-class SmackCipso(SmackBasicTest):

@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_cipso(self):
@@ -287,7 +267,6 @@ class SmackCipso(SmackBasicTest):
self.assertEqual(status, 0, "Cipso rule C was not set")
self.assertIn("/17,33", output, "Rule C was not set correctly")

-class SmackDirect(SmackBasicTest):

@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_direct(self):
@@ -308,8 +287,6 @@ class SmackDirect(SmackBasicTest):
"Smack direct label does not match.")


-class SmackAmbient(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_ambient(self):
test_ambient = "test_ambient"
@@ -330,8 +307,6 @@ class SmackAmbient(SmackBasicTest):
"Ambient label does not match")


-class SmackloadBinary(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smackload(self):
'''Test if smackload command works'''
@@ -345,8 +320,6 @@ class SmackloadBinary(SmackBasicTest):
self.assertEqual(status, 0, "Smackload rule was loaded correctly")


-class SmackcipsoBinary(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smackcipso(self):
'''Test if smackcipso command works'''
@@ -362,8 +335,6 @@ class SmackcipsoBinary(SmackBasicTest):
self.assertIn( "2/2", output, "Rule was not set correctly. Got: %s" %output)


-class SmackEnforceFileAccess(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_enforce_file_access(self):
'''Test if smack file access is enforced (rwx)
@@ -375,8 +346,6 @@ class SmackEnforceFileAccess(SmackBasicTest):
self.assertEqual(status, 0, output)


-class SmackEnforceMmap(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_mmap_enforced(self):
'''Test if smack mmap access is enforced'''
@@ -449,8 +418,6 @@ class SmackEnforceMmap(SmackBasicTest):
"Output: %s" %output)


-class SmackEnforceTransmutable(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_transmute_dir(self):
'''Test if smack transmute attribute works
@@ -473,8 +440,6 @@ class SmackEnforceTransmutable(SmackBasicTest):
"Did not get expected label. Output: %s" % output)


-class SmackTcpSockets(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_tcp_sockets(self):
'''Test if smack is enforced on tcp sockets
@@ -485,8 +450,6 @@ class SmackTcpSockets(SmackBasicTest):
self.assertEqual(status, 0, output)


-class SmackUdpSockets(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_udp_sockets(self):
'''Test if smack is enforced on udp sockets
@@ -497,8 +460,6 @@ class SmackUdpSockets(SmackBasicTest):
self.assertEqual(status, 0, output)


-class SmackFileLabels(SmackBasicTest):
-
@OETestDepends(['smack.SmackBasicTest.test_smack_basic'])
def test_smack_labels(self):
'''Check for correct Smack labels.'''
--
2.25.1

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-mac/smack/smack-test_1.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/smack/smack-test_1.0.bb b/recipes-mac/smack/smack-test_1.0.bb
index d7824ae..3ab57c6 100644
--- a/recipes-mac/smack/smack-test_1.0.bb
+++ b/recipes-mac/smack/smack-test_1.0.bb
@@ -22,4 +22,4 @@ do_install() {
install -m 0755 *.sh ${D}${sbindir}
}

-RDEPENDS:${PN} = "smack python mmap-smack-test tcp-smack-test udp-smack-test"
+RDEPENDS:${PN} = "smack python3-core mmap-smack-test tcp-smack-test udp-smack-test"
--
2.25.1