Hi, Just as a quick update, following the decision not to add pam to the default distro features, Matt Madison, the maintainer of meta-tegra BSP layer, committed a patch to remove the unneeded Weston dependency from recipe l4t-graphics-demos: https://github.com/OE4T/meta-tegra/commit/abf7600589090740565cfc0afc94c01e7e1f6ce0
As a result, the yocto-check-script successfully passes for meta-tegra, so the issue I was initially having is resolved. However, considering the shared details about weston/pam/vnc, in my personal opinion it is still worth addressing Joshua's very valid question and figuring out how to improve weston-init and weston recipes to make pam really required only for vnc. Best regards, Leon On Fri, Jul 17, 2026 at 9:11 AM Richard Purdie < [email protected]> wrote: > On Thu, 2026-07-16 at 17:20 -0600, Tom Rini wrote: > > On Thu, Jul 16, 2026 at 09:28:26PM +0100, Richard Purdie wrote: > > > On Thu, 2026-07-16 at 12:27 -0600, Tom Rini wrote: > > > > On Thu, Jul 16, 2026 at 12:25:00PM +0100, Richard Purdie wrote: > > > > > On Wed, 2026-07-08 at 17:37 +0300, Leon Anavi via > > > > > lists.openembedded.org wrote: > > > > > > This fixes issues with test_machine_world when running the > > > > > > yocto-check-layer script for BSP layers that include weston in > > > > > > the > > > > > > dependency chain, for example meta-tegra: > > > > > > > > > > > > ERROR: Required build target 'meta-world-pkgdata' has no > > > > > > buildable > > > > > > providers. > > > > > > Missing or unbuildable dependency chain was: ['meta-world- > > > > > > pkgdata', > > > > > > 'l4t-graphics-demos', 'weston'] > > > > > > > > > > Why wouldn't l4t-graphics-demos just list pam as a required distro > > > > > feature for that recipe? > > > > > > > > Because it doesn't come from l4t-graphics-demos it comes from weston? > > > > And l4t-graphics-demos supports wayland or x11. Doing something here > > > > would be the not satisfying approach Paul mentioned on v1 or so of > > > > this thread. It shuts yocto-check-layer up while doing nothing of > > > > value. > > > > > > I should explain a little about the unfortunate way that > > > REQUIRED_DISTRO_FEATURES works. > > > > > > Anything that needs a specific distro feature uses that but it has a > > > unfortunate ripple side effect where anything with that recipe as a > > > dependency, must also then have the same REQUIRED_DISTRO_FEATURES line > > > (or more restrictive). > > > > > > This was discussed extensively in the past and you will see this in the > > > way x11 is rippled through recipes. > > > > > > I appreciate you will then argue this should be automatic as obviously > > > anything depending on X will require Y as a DISTRO_FEATURE. I have > > > refused to implement any such magic as it turns out it can misfire > > > spectacularly badly and end up just masking every recipe out as a > > > ripple effect for a poorly thought out change as the worst case > > > scenario. There are plenty of scenarios where unexpected bad things can > > > happen which would be hard to spot. This was discussed in the past too. > > > > > > So, my point is that if you have weston-init as a dependency, even > > > indirectly, you have the required distro features requirement passed to > > > that recipe and need to mark the recipe as such. > > > > > > No, it isn't great, but the alternatives can go spectacularly wrong too > > > and you can't work out how to do this correctly automatically in a safe > > > way. > > > > > > You are doing something of value, you're clearly marking the > > > requirement of the recipe (which it has via it's dependencies). > > > > > > I think the question is marking the recipe in question to say it > > > requires "pam+systemd+weston" or "x11", which might mean anonymous > > > python but is definitely doable. > > > > This specific problem has (will be) fixed in meta-tegra since weston can > > just be dropped. But if I follow what you're saying right, since > > meta/recipes-graphics/wayland/weston_15.0.0.bb ends up with: > > REQUIRED_DISTRO_FEATURES = "wayland opengl > ${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager', 'systemd', 'pam', > '', d)}" > > essentially every recipe that has DEPENDS on a PACKAGECONFIG that > > brings in weston *also* needs that same logic, to not run in to a > > problem later on. > > Correct. > > > Is there tooling to find and check that? And is the answer yes, we just > > ran in to it? > > I'm not aware of any such tooling, it has all just been done manually so > far. > > Cheers, > > Richard >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#241654): https://lists.openembedded.org/g/openembedded-core/message/241654 Mute This Topic: https://lists.openembedded.org/mt/120174368/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
