From: Randolph Sapp <rs@ti.com>
To: Randolph Sapp <rs@ti.com>, Alexander Kanavin <alex.kanavin@gmail.com>
Cc: <otavio.salvador@ossystems.com.br>,
<richard.purdie@linuxfoundation.org>, <ross.burton@arm.com>,
<alex@linutronix.de>, <otavio@ossystems.com.br>,
<kexin.hao@windriver.com>, <afd@ti.com>, <detheridge@ti.com>,
<denis@denix.org>, <reatmon@ti.com>,
<openembedded-core@lists.openembedded.org>, <vijayp@ti.com>
Subject: Re: [oe-core][RFC 0/3] Display manager proposal for x11 and wayland
Date: Fri, 14 Mar 2025 19:36:17 -0500 [thread overview]
Message-ID: <D8GF3MBQ4FYJ.1X2RZ51QT237S@ti.com> (raw)
In-Reply-To: <D8G88ZDV4PX6.1Z1L5E9XBFF8X@ti.com>
On Fri Mar 14, 2025 at 2:14 PM CDT, Randolph Sapp wrote:
> On Fri Mar 14, 2025 at 4:14 AM CDT, Alexander Kanavin wrote:
>> On Fri, 14 Mar 2025 at 01:30, <rs@ti.com> wrote:
>>> Example implementation of emptty for weston-init following the request on the
>>> previous RFC [1] and previous example [2]. This variant is applicable to master.
>>>
>>> This packages emptty and a default configuration for emptty as "emptty" and
>>> "emptty-conf" respectively. This allows the existing init packages to override
>>> the configuration similar to the way grub boot configs are handled.
>>>
>>> The weston-init package still handles the weston config and weston user setup as
>>> it always has. The only real difference from a consumer standpoint is that the
>>> autologin group for the weston user changed from "wayland" to the more generic
>>> "nopasswdlogin".
>>>
>>> [1] https://lists.openembedded.org/g/openembedded-core/message/212640
>>> [2] https://lists.openembedded.org/g/openembedded-core/message/212785
>>
>> I quickly checked this locally. There are some issues that need to be
>> addressed before this goes to the autobuilder:
>>
>> 1. WARNING: emptty-0.13.0-r0 do_recipe_qa: QA Issue: Recipe emptty in
>> /srv/work/alex/poky/meta/recipes-graphics/emptty/emptty_0.13.0.bb does
>> not have an assigned maintainer. Please add an entry into
>> meta/conf/distro/include/maintainers.inc. [missing-maintainer]
>
> Yeah. I wouldn't mind maintaining this package and can set that. Just didn't
> know if there was someone I needed to check with before I did that.
>
>> 2. With default poky config:
>>
>> ERROR: Nothing RPROVIDES 'pam-plugin-succeed-if' (but
>> /srv/work/alex/poky/meta/recipes-graphics/emptty/emptty_0.13.0.bb
>> RDEPENDS on or otherwise requires it)
>> NOTE: Runtime target 'pam-plugin-succeed-if' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['pam-plugin-succeed-if']
>> ERROR: Required build target 'emptty' has no buildable providers.
>> Missing or unbuildable dependency chain was: ['emptty', 'pam-plugin-succeed-if']
>>
>> You should either make the pam dependency optional (via PACKAGECONFIG
>> subject to pam in DISTRO_FEATURES), or use REQUIRED_DISTRO_FEATURES.
>
> Good point. I added the PACKAGECONFIG to remove pam support, that should also
> toggle the runtime dep on pam-plugin-succeed-if. Will address in the proper
> series.
>
>> 3. Again, with default poky config:
>>
>> NOTE: Multiple providers are available for runtime virtual-emptty-conf
>> (emptty, weston-init)
>> Consider defining a PREFERRED_RPROVIDER entry to match virtual-emptty-conf
>>
>>
>> Alex
>
> That last note is perplexing. Patch 3/3 is literally setting the default runtime
> provider for virtual-emptty-conf. I'm also seeing the following notice though:
>
> NOTE: Multiple providers are available for runtime libnss-mdns (avahi-libnss-mdns, mdns)
> Consider defining a PREFERRED_RPROVIDER entry to match libnss-mdns
>
> Is there some other variable I need to set for master? Is that message now being
> printed if 2 package are being produced? If that's the case I can check the
> PREFERRED_RPROVIDER variable and conditionally prevent producing the emptty-conf
> package, but that feels a little hacky. Anyone have any better ideas about that?
>
> - Randolph
Another fun issue. This actually adds additional checks to user accounts using
unix_chkpwd in pam and an equivalent mechanism in the libxcrypt path. It's
uncovered a relatively interesting issue around device initialization where
system time is reset to a date prior to the build in the case where there is no
RTC to read and the weston user's login attempts fail until the time catches up.
The password change for that user is in the future.
Forcing a time jump during startup with a custom service resolves the issue, but
it's unusual nothing else has had any problems with this. I thought I remember
Yocto defaulting the OS time to the image build time. Was I hallucinating that?
- Randolph
next prev parent reply other threads:[~2025-03-15 0:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 0:29 [oe-core][RFC 0/3] Display manager proposal for x11 and wayland rs
2025-03-14 0:29 ` [PATCH] Revert "gettext: fix a parallel build issue" rs
2025-03-14 18:13 ` Ross Burton
2025-03-14 18:32 ` Randolph Sapp
2025-03-14 0:29 ` [PATCH] bzip2: add libbz2.so.1.0 link for compat rs
2025-03-14 0:29 ` [oe-core][RFC 1/3] emptty: add version 0.13.0 rs
2025-03-14 0:29 ` [oe-core][RFC 2/3] weston-init: convert to virtual-emptty-conf rs
2025-03-14 0:48 ` Patchtest results for " patchtest
2025-03-14 0:29 ` [oe-core][RFC 3/3] default-providers: set virtual-emptty-conf rs
[not found] ` <182C83EE5DCDDC9F.6194@lists.openembedded.org>
2025-03-14 0:39 ` [OE-core] [PATCH] Revert "gettext: fix a parallel build issue" Randolph Sapp
[not found] ` <182C83EDE0EF5771.27055@lists.openembedded.org>
2025-03-14 0:40 ` [OE-core] [PATCH] bzip2: add libbz2.so.1.0 link for compat Randolph Sapp
2025-03-14 9:14 ` [oe-core][RFC 0/3] Display manager proposal for x11 and wayland Alexander Kanavin
2025-03-14 19:14 ` Randolph Sapp
2025-03-15 0:36 ` Randolph Sapp [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-03-27 2:47 rs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D8GF3MBQ4FYJ.1X2RZ51QT237S@ti.com \
--to=rs@ti.com \
--cc=afd@ti.com \
--cc=alex.kanavin@gmail.com \
--cc=alex@linutronix.de \
--cc=denis@denix.org \
--cc=detheridge@ti.com \
--cc=kexin.hao@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
--cc=otavio@ossystems.com.br \
--cc=reatmon@ti.com \
--cc=richard.purdie@linuxfoundation.org \
--cc=ross.burton@arm.com \
--cc=vijayp@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox