On Wed Jun 17, 2026 at 11:00 AM CDT, Mathieu Dubois-Briand wrote:
> On Wed Jun 17, 2026 at 5:58 PM CEST, Mathieu Dubois-Briand wrote:
>> On Tue Jun 16, 2026 at 8:25 PM CEST, rs wrote:
>>> From: Randolph Sapp <[email protected]>
>>>
>>> Change this single xuser account template into a generic
>>> standard-user-account that uses distro level variables for
>>> configuration.
>>>
>>> This allows for seamless configuration of multiple out-of-box scripts
>>> and tests across layers without having to implicitly hope that the
>>> username or groups haven't been changed by a bbappend or recipe
>>> override.
>>>
>>> This also adds a class and a variable to allow recipes to assert that
>>> the user is in requested groups.
>>>
>>> This was proposed specifically to remove some issues highlighted in:
>>> https://lists.openembedded.org/g/openembedded-core/message/230665
>>>
>>> Signed-off-by: Randolph Sapp <[email protected]>
>>> ---
>>
>> Hi Randolph,
>>
>> Thanks, it looks better now.
>>
>> Yet we have some test failures:
>>
>> AssertionError: ssh exited with status '255' for command '['ssh', '-l',
>> 'root', '-o', 'ServerAliveCountMax=2', '-o', 'ServerAliveInterval=30', '-o',
>> 'UserKnownHostsFile=/dev/null', '-o', 'StrictHostKeyChecking=no', '-o',
>> 'LogLevel=ERROR', '192.168.7.2', 'export PATH=/usr/sbin:/sbin:/usr/bin:/bin;
>> export XDG_RUNTIME_DIR=/run/user/`id -u weston`; export
>> WAYLAND_DISPLAY=wayland-1; wayland-info']': this is likely an SSH failure
>> id: unknown user weston
>> failed to create display: No such file or directory
>> ...
>> RESULTS - weston.WestonTest.test_wayland_info: FAILED (0.47s)
>> RESULTS -
>> weston.WestonTest.test_weston_can_initialize_new_wayland_compositor: FAILED
>> (0.27s)
>> RESULTS - weston.WestonTest.test_weston_running: FAILED (0.73s)
>>
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/25/builds/3950
Yeah, that tracks. Have been testing against sato on x86 since that's been the
most problematic combination in the past. Completely missed that.
>> Also we have a failing selftest:
>>
>> 2026-06-17 11:32:17,460 - oe-selftest - INFO -
>> incompatible_lic.NoGPL3InImagesTests.test_core_image_full_cmdline_weston
>> (subunit.RemotedTestCase)
>> 2026-06-17 11:32:17,465 - oe-selftest - INFO - ... FAIL
>> ...
>> ERROR: weston-init-1.0-r0 do_package_write_rpm: File
>> /srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-953747/tmp/work/qemux86_64-poky-linux/weston-init/1.0/recipe-sysroot/etc/passwd
>> doesn't exist in sysroot!
>> ...
>> File:
>> '/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/layers/openembedded-core/meta/classes-global/package_rpm.bbclass',
>> lineno: 202, function: get_attr
>> 0198: def get_attr(path):
>> 0199: stat_f = os.stat(rootpath + "/" + path,
>> follow_symlinks=False)
>> 0200: mode = stat.S_IMODE(stat_f.st_mode)
>> 0201: try:
>> *** 0202: owner = pwd.getpwuid(stat_f.st_uid).pw_name
>> 0203: except Exception as e:
>> 0204: filename = d.getVar('RECIPE_SYSROOT') +
>> '/etc/passwd'
>> 0205: if os.path.exists(filename):
>> 0206: bb.error("Content of /etc/passwd in
>> sysroot:\n{}".format(
>> Exception: KeyError: 'getpwuid(): uid not found: 1000'
>>
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/4139
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/4061
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3911
>>
>> Can you have a look at the issue?
>>
>> Thanks,
>> Mathieu
That's fun. I'll take a look.
> Sorry, we also have a dependency issue in the reproducibility test:
>
> 2026-06-17 12:32:19,348 - oe-selftest - INFO - ERROR: Nothing PROVIDES
> 'standard-user-account' (but
> /srv/pokybuild/yocto-worker/reproducible/build/layers/openembedded-core/meta/recipes-graphics/wayland/weston-init.bb
> DEPENDS on or otherwise requires it)
> 2026-06-17 12:32:19,348 - oe-selftest - INFO - standard-user-account
> was skipped: Recipe standard-user-account, package standard-user-account:
> system groupname "disk" does not have a static ID defined. Add disk to one of
> these files:
> /srv/pokybuild/yocto-worker/reproducible/build/build-st/meta-selftest/files/static-group
> 2026-06-17 12:32:19,348 - oe-selftest - INFO - ERROR: Nothing RPROVIDES
> 'weston-init' (but
> /srv/pokybuild/yocto-worker/reproducible/build/layers/openembedded-core/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb,
>
> /srv/pokybuild/yocto-worker/reproducible/build/layers/openembedded-core/meta/recipes-graphics/wayland/weston-init.bb,
>
> /srv/pokybuild/yocto-worker/reproducible/build/layers/openembedded-core/meta/recipes-graphics/wayland/weston_15.0.1.bb
> RDEPENDS on or otherwise requires it)
> 2026-06-17 12:32:19,348 - oe-selftest - INFO - No eligible RPROVIDERs
> exist for 'weston-init'
> 2026-06-17 12:32:19,348 - oe-selftest - INFO - NOTE: Runtime target
> 'weston-init' is unbuildable, removing...
> 2026-06-17 12:32:19,348 - oe-selftest - INFO - Missing or unbuildable
> dependency chain was: ['weston-init']
> 2026-06-17 12:32:19,349 - oe-selftest - INFO - NOTE: Runtime target
> 'packagegroup-core-weston' is unbuildable, removing...
> 2026-06-17 12:32:19,349 - oe-selftest - INFO - Missing or unbuildable
> dependency chain was: ['packagegroup-core-weston', 'weston-init']
> 2026-06-17 12:32:19,349 - oe-selftest - INFO - NOTE: Runtime target
> 'core-image-weston' is unbuildable, removing...
> 2026-06-17 12:32:19,349 - oe-selftest - INFO - Missing or unbuildable
> dependency chain was: ['core-image-weston', 'packagegroup-core-weston',
> 'weston-init']
> 2026-06-17 12:32:19,349 - oe-selftest - INFO - NOTE: Runtime target
> 'weston-xwayland' is unbuildable, removing...
> 2026-06-17 12:32:19,349 - oe-selftest - INFO - Missing or unbuildable
> dependency chain was: ['weston-xwayland', 'weston-init']
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/4185
>
> Thanks,
> Mathieu
Ah, man. The implications of this error really bug me. There's not really a
clean enough solution to fix the "some groups are just implicitly expected"
issue though. *Suppose I'll make a separate var for groups that we know need to
be created and let everything else be implied.*
Lot of weird cases like:
What if the group is no longer provided by base-passwd? Will there be any
compile time warnings? Should there be any? Should this really be an
installation check?
Scripts using group names vs group IDs will have completely different behavior.
The filesystem is more than happy to keep trucking with an ID that no longer
exists, and that ID can be claimed by anything later. Good system administrators
normally try to prevent that, but this is all oneshot right?
Should recipes have to indicate where they expect a group to come from? That
seems messy, and will have to deal with recipes spanning layers. No telling how
often those values will be wrong due to a namechange more than an actual
deprecation of a group.
Don't like this.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#239046):
https://lists.openembedded.org/g/openembedded-core/message/239046
Mute This Topic: https://lists.openembedded.org/mt/119838359/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
