Re: [oe-core][PATCHv6 0/5] Display manager proposal for x11 and wayland

["Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>]

On Wed May 28, 2025 at 12:16 AM CEST, Randolph Sapp wrote:
> On Wed May 21, 2025 at 10:58 AM CDT, Mathieu Dubois-Briand wrote:
>> On Wed May 21, 2025 at 1:39 AM CEST, rs wrote:
>>> From: Randolph Sapp <rs@ti.com>
>>>
>>> We've recently run into some issues with weston-init attempting to start Weston
>>> prior to all drm devices being registered. There's not really a good, scriptable
>>> mechanism to listen in to device registration events that works with the
>>> existing weston-init package. Well, at least one that doesn't involve polling
>>> files or introducing more dependency on the init system being used.
>>>
>>> I also see there is also a lot of scripting around starting X11,
>>> xserver-nodm-init, that (from my limited review) should experience the same
>>> issue.
>>>
>>> I'd like to introduce the following display manager for oe-core, emptty [1].
>>> This display manager is, as described upstream, a "Dead simple CLI Display
>>> Manager on TTY". It supports both x11 and wayland sessions, with togglable build
>>> parameters to completely remove x11 and pam dependencies. It's licensed MIT,
>>> which shouldn't be an issue for any users. (It is written in Go, if you have
>>> opinions about that.)
>>>
>>> With this, both weston-init and the xserver-nodm-init packages can be re-tuned
>>> to leverage this display manager and simply add a user and emptty config for an
>>> autologin session. This can resolve the current behavior across init systems
>>> without additional scripting, and move some development out of this layer.
>>>
>>> This lists myself as a maintainer of emptty as well as xserver-nodm-init and
>>> xuser-account since these are currently unassigned and I've reworked them
>>> significantly here.
>>>
>>> Sorry for the delay on this series. I found a few bugs in emptty that I wanted
>>> to address before submitting this officially.
>>>
>>> [1] https://github.com/tvrzna/emptty
>>>
>>> v2:
>>> 	- Address spelling issues in commit messages
>>> 	- Attempt to resolve some test related issues with weston
>>> 	- Add additional logs to X11 related tests
>>> v3:
>>> 	- Reset AUTOLOGIN_MAX_RETRY to the default value of 2. When running
>>> 	  under QEMU the first auth attempt almost always fails.
>>> v4:
>>> 	- Add a tmpfile entry for the x11 domain socket directory.
>>> 	- Remove some scripts associated with weston-init that were being
>>> 	  shipped with weston
>>> v5:
>>> 	- Move tmpfile data to individual files
>>> 	- Add explicit entries for these in the FILES variable
>>> v6:
>>> 	- Do not attempt to ship a tmpfiles.d entry in libx11
>>>
>>
>> Hi Randolph,
>>
>> Thanks for the version, but again a previously seen error. Sorry for
>> the bad news :(
>>
>> RESULTS - xorg.XorgTest.test_xorg_running: FAILED (1.31s)
>> ...
>> AssertionError: 1 != 0 : Xorg does not appear to be running   PID USER       VSZ STAT COMMAND
>>
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/20/builds/1637
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/95/builds/1638
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/9/builds/1649
>>
>> I will drop the patch on my side, but I will keep the a-full build
>> running, we might see some other failures in the coming hours:
>>
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/1630
>
> Ah, the auth failures persist. Normally this is caused when the user attempts to
> login before the user account was created or something unusual like that. I
> don't suppose there's any way this could be happening on the test machines?
>
> I'm not able to reproduce this locally, but my build config is different. I tend
> to use oe-core and nodistro instead of poky. They aren't playing around with the
> reproducible build date stuff or anything like that are they?
>
> Well, I mean I did see this on occasion. The first login attempt almost always
> failed, but the subsequent attempts were fine. Bumping the attempt count back up
> the default (2) was enough to resolve it on my end, but evidently it's not
> enough here.
>
> This is not happening on hardware from what I'm seeing.

Hi Randolph,

I was able to reproduce it locally, with the following configuration:
- https://git.yoctoproject.org/poky-ci-archive on tag
  autobuilder.yoctoproject.org/valkyrie/a-full-1630.
- template local.conf, with the following modifications:
  MACHINE = "qemux86"
  DISTRO = "poky-altcfg"
  SDKMACHINE = "x86_64"
  PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
  INHERIT += 'image-buildinfo'
  IMAGE_BUILDINFO_VARS:append = ' IMAGE_BASENAME IMAGE_NAME'
  PACKAGE_CLASSES = 'package_ipk package_rpm package_deb'
  IMAGE_ROOTFS_EXTRA_SPACE:append = '${@bb.utils.contains('IMAGE_FEATURES', 'package-management', ' + 262144', '', d)}'
  IMAGE_INSTALL:append = ' ssh-pregen-hostkeys'
  SANITY_TESTED_DISTROS = ''
  OE_FRAGMENTS += 'core/yocto-autobuilder/autobuilder core/yocto-autobuilder/autobuilder-resource-constraints'
  # (Plus my own sstate cache and downloads dir).
- bitbake core-image-sato
- bitbake core-image-sato:do_testimage

Of course using the tag from poky-ci-archive is not mandatory, you
should see the same behaviour with master branch and your patches.

I saw some oe-selftest was also failing on the autobuilder, with an
error related to emptty. You can reproduce it with:

oe-selftest -r sstatetests.SStateHashSameSigs3.test_sstate_sametune_samesigs

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com