Message ID | 20231222151108.645675-8-alex@linutronix.de |
---|---|
State | New |
Headers | show |
Series | [1/9] python3-yappi: update 1.4.0 -> 1.6.0 | expand |
On Fri, Dec 22 2023 at 04:11:07 PM +01:00:00, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > diff --git a/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb > b/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb > index 0ee53afb6..caa353bb8 100644 > --- a/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb > +++ b/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb > @@ -43,8 +43,6 @@ RDEPENDS:${PN} = " \ > xdg-dbus-proxy \ > " > > -EXTRA_OEMESON += "-Dsystem_dbus_proxy=${bindir}/xdg-dbus-proxy > -Dsystem_bubblewrap=${bindir}/bwrap" My understanding was that these were runtime dependencies and setting the paths would ensure that target flatpak can find them
On Fri 22. Dec 2023 at 17.50, <f_l_k@t-online.de> wrote: > > -EXTRA_OEMESON += "-Dsystem_dbus_proxy=${bindir}/xdg-dbus-proxy > -Dsystem_bubblewrap=${bindir}/bwrap" > > My understanding was that these were runtime dependencies and setting the > paths would ensure that target flatpak can find them > No, it actually tries to find these at build time on the host, and run them, checking if the versions are correct. Which is of course a bogus check, because they would be provided by the host distro, and not match what is going to be in the target image: https://github.com/flatpak/flatpak/blob/main/meson.build#L254 If they're unset, then flatpak instead falls back to internal helper binaries that it installs into libexec: https://github.com/flatpak/flatpak/blob/main/meson.build#L351 Alex
> On 22 Dec 2023, at 16:20, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > > On Fri 22. Dec 2023 at 17.50, <f_l_k@t-online.de> wrote: > > -EXTRA_OEMESON += "-Dsystem_dbus_proxy=${bindir}/xdg-dbus-proxy -Dsystem_bubblewrap=${bindir}/bwrap" > > My understanding was that these were runtime dependencies and setting the paths would ensure that target flatpak can find them > > No, it actually tries to find these at build time on the host, and run them, checking if the versions are correct. Which is of course a bogus check, because they would be provided by the host distro, and not match what is going to be in the target image: > https://github.com/flatpak/flatpak/blob/main/meson.build#L254 > > If they're unset, then flatpak instead falls back to internal helper binaries that it installs into libexec: > https://github.com/flatpak/flatpak/blob/main/meson.build#L351 This should be in the commit message. :) Ross
diff --git a/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb b/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb index 0ee53afb6..caa353bb8 100644 --- a/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb +++ b/meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb @@ -43,8 +43,6 @@ RDEPENDS:${PN} = " \ xdg-dbus-proxy \ " -EXTRA_OEMESON += "-Dsystem_dbus_proxy=${bindir}/xdg-dbus-proxy -Dsystem_bubblewrap=${bindir}/bwrap" - GIR_MESON_OPTION = "gir" GIR_MESON_ENABLE_FLAG = 'enabled' GIR_MESON_DISABLE_FLAG = 'disabled'
This is not how yocto builds work: any needed executables should come from the build itself, with limited exceptions listed in HOSTTOOLS. flatpak is entirely capable of building without requiring them upfront. Signed-off-by: Alexander Kanavin <alex@linutronix.de> --- meta-oe/recipes-extended/flatpak/flatpak_1.15.6.bb | 2 -- 1 file changed, 2 deletions(-)