| Message ID | 20221201134148.116754-1-alex.stewart@ni.com |
|---|---|
| Headers | show |
| Series | gvfs: use native ssh client | expand |
Hi, On Thu, Dec 01, 2022 at 07:41:45AM -0600, Alex Stewart wrote: > While rebasing the NI LinuxRT distro to kirkstone, I noticed that my > pyrex container fails gvfs:do_configure with a meson error about not > finding an `ssh` client. > > | Program ssh found: NO > | > | ../gvfs-1.50.0/meson.build:462:2: ERROR: Assert failed: SFTP backend requested but a ssh client is required > > > After some investigation, it seems that gvfs is configured to use the > `ssh` client implementation in the build machine's PATH. If no native > implementation is provided in the native sysroot, it will default to > using the host machine's implementation. > > My new kirkstone pyrex container happened to not install an ssh client, > and so would fail. Since ssh isn't a requirement to run BB or OE, I > don't think it's appropriate to use the host's ssh. > > > This patchset adds the native bbclass to openssh, when the user includes > meta-oe in his layerstack, and then provides the openssh-native content > to gvfs through its DEPENDS. This is sufficient to resolve the error on > my kirkstone pyrex container. > > NOTE: It's a little odd to me that the OE-core openssh recipe doesn't > already inherit native.bbclass - when it *does* inherit > nativesdk.bbclass. I would be open to moving the openssh changes in this > PR to OE-core directly, if someone can ACK that it would be more > appropriate to do so. Why would one really need to build native, the compiler host machine, version of openssh? Why even gvfs is needed for native?! For target or nativesdk the needs are clear, but for native? These kind of things really need good justifications or the whole host tooling graph explodes and build times with it. In most cases the native host target has a lot less build dependencies and features enabled because of this reason. Cheers, -Mikko
Hey Mikko, On 12/1/22 07:57, Mikko Rapeli wrote: > Hi, > > On Thu, Dec 01, 2022 at 07:41:45AM -0600, Alex Stewart wrote: >> While rebasing the NI LinuxRT distro to kirkstone, I noticed that my >> pyrex container fails gvfs:do_configure with a meson error about not >> finding an `ssh` client. >> >> | Program ssh found: NO >> | >> | ../gvfs-1.50.0/meson.build:462:2: ERROR: Assert failed: SFTP backend requested but a ssh client is required >> >> >> After some investigation, it seems that gvfs is configured to use the >> `ssh` client implementation in the build machine's PATH. If no native >> implementation is provided in the native sysroot, it will default to >> using the host machine's implementation. >> >> My new kirkstone pyrex container happened to not install an ssh client, >> and so would fail. Since ssh isn't a requirement to run BB or OE, I >> don't think it's appropriate to use the host's ssh. >> >> >> This patchset adds the native bbclass to openssh, when the user includes >> meta-oe in his layerstack, and then provides the openssh-native content >> to gvfs through its DEPENDS. This is sufficient to resolve the error on >> my kirkstone pyrex container. >> >> NOTE: It's a little odd to me that the OE-core openssh recipe doesn't >> already inherit native.bbclass - when it *does* inherit >> nativesdk.bbclass. I would be open to moving the openssh changes in this >> PR to OE-core directly, if someone can ACK that it would be more >> appropriate to do so. > Why would one really need to build native, the compiler host machine, > version of openssh? Why even gvfs is needed for native?! > For target or nativesdk the needs are clear, but for native? I'm not sure I understand the question. Are you asking why the gvfs compile requires an ssh client in the build host toolchain? If so, I don't know the answer. Trolling through the history of the gvfs project didn't provide me with very much context as to why it is required. And I didn't see an obvious way to work-around the requirement. > These kind of things really need good justifications or the whole host > tooling graph explodes and build times with it. In most cases the native > host target has a lot less build dependencies and features enabled > because of this reason. Agreed. I'd love to eschew this requirement; but that is probably a conversation with gvfs upstream about why it exists in the first place.
Hi, On Thu, Dec 01, 2022 at 08:20:44AM -0600, Alex Stewart wrote: > Hey Mikko, > > On 12/1/22 07:57, Mikko Rapeli wrote: > > Hi, > > > > On Thu, Dec 01, 2022 at 07:41:45AM -0600, Alex Stewart wrote: > > > While rebasing the NI LinuxRT distro to kirkstone, I noticed that my > > > pyrex container fails gvfs:do_configure with a meson error about not > > > finding an `ssh` client. > > > > > > | Program ssh found: NO > > > | > > > | ../gvfs-1.50.0/meson.build:462:2: ERROR: Assert failed: SFTP backend requested but a ssh client is required > > > > > > > > > After some investigation, it seems that gvfs is configured to use the > > > `ssh` client implementation in the build machine's PATH. If no native > > > implementation is provided in the native sysroot, it will default to > > > using the host machine's implementation. > > > > > > My new kirkstone pyrex container happened to not install an ssh client, > > > and so would fail. Since ssh isn't a requirement to run BB or OE, I > > > don't think it's appropriate to use the host's ssh. > > > > > > > > > This patchset adds the native bbclass to openssh, when the user includes > > > meta-oe in his layerstack, and then provides the openssh-native content > > > to gvfs through its DEPENDS. This is sufficient to resolve the error on > > > my kirkstone pyrex container. > > > > > > NOTE: It's a little odd to me that the OE-core openssh recipe doesn't > > > already inherit native.bbclass - when it *does* inherit > > > nativesdk.bbclass. I would be open to moving the openssh changes in this > > > PR to OE-core directly, if someone can ACK that it would be more > > > appropriate to do so. > > Why would one really need to build native, the compiler host machine, > > version of openssh? Why even gvfs is needed for native?! > > For target or nativesdk the needs are clear, but for native? > > I'm not sure I understand the question. Are you asking why the gvfs compile > requires an ssh client in the build host toolchain? What requires gvfs for native build target? I think that dependency should be removed. I don't think this dependency makes sense and I don't think it will really be used by anything. If there is a real use case, then you could try to remove the ssh dependency. You likely don't need ssh communication at build time so just disable the feature completely. Cheers, -Mikko
I'm revoking this PR for the moment, in favor of pursuing an upstream solution. While doing some more investigation based on the commentary that Mikko and I were having in the thread, I discovered more detail about how gvfs is using the ssh binary. As this open gvfs issue [1] points out, meson is configured to find the `ssh` binary in the build host's PATH and to then write that path-string directly into the `args[0]` for the sftp backend. And that's *all* that the ssh binary is used for at build time. That's obviously dangerous - as the issue points out - for the cross-compile case, where you cannot assume that the ssh binary path is the same between the build host and the target distro. But it also means that using a sysroot-native ssh binary is equally as insane, since its path is also different from the final target image. So neither the existing implementation, nor this PR, would provide you with a working gvfs-sftp implementation. The proper solution is probably to change the gvfs-sftp backend upstream to use PATH resolution at runtime to find the ssh binary. Though I don't actually use gvfs-sftp in my use-case, I'll attempt to try and upstream a fix. The other alternative I see is to disable the gvfs-sftp subpackages from building in OE entirely - which seems undesirable for those users who are depending on it. [1] https://gitlab.gnome.org/GNOME/gvfs/-/issues/465 On 12/1/22 07:41, Alex Stewart wrote: > While rebasing the NI LinuxRT distro to kirkstone, I noticed that my > pyrex container fails gvfs:do_configure with a meson error about not > finding an `ssh` client. > > | Program ssh found: NO > | > | ../gvfs-1.50.0/meson.build:462:2: ERROR: Assert failed: SFTP backend requested but a ssh client is required > > > After some investigation, it seems that gvfs is configured to use the > `ssh` client implementation in the build machine's PATH. If no native > implementation is provided in the native sysroot, it will default to > using the host machine's implementation. > > My new kirkstone pyrex container happened to not install an ssh client, > and so would fail. Since ssh isn't a requirement to run BB or OE, I > don't think it's appropriate to use the host's ssh. > > > This patchset adds the native bbclass to openssh, when the user includes > meta-oe in his layerstack, and then provides the openssh-native content > to gvfs through its DEPENDS. This is sufficient to resolve the error on > my kirkstone pyrex container. > > > NOTE: It's a little odd to me that the OE-core openssh recipe doesn't > already inherit native.bbclass - when it *does* inherit > nativesdk.bbclass. I would be open to moving the openssh changes in this > PR to OE-core directly, if someone can ACK that it would be more > appropriate to do so. > > Alex Stewart (3): > openssh: add native BBCLASSEXTEND > gvfs: stylize DEPENDS > gvfs: use native ssh client > > .../recipes-connectivity/openssh/openssh_%.bbappend | 2 ++ > meta-gnome/recipes-gnome/gvfs/gvfs_1.50.2.bb | 12 ++++++++++-- > 2 files changed, 12 insertions(+), 2 deletions(-) > create mode 100644 meta-gnome/recipes-connectivity/openssh/openssh_%.bbappend >
On Thu, Dec 1, 2022 at 12:48 PM Alex Stewart <alex.stewart@ni.com> wrote: > > I'm revoking this PR for the moment, in favor of pursuing an upstream > solution. > > > While doing some more investigation based on the commentary that Mikko > and I were having in the thread, I discovered more detail about how gvfs > is using the ssh binary. > > As this open gvfs issue [1] points out, meson is configured to find the > `ssh` binary in the build host's PATH and to then write that path-string > directly into the `args[0]` for the sftp backend. And that's *all* that > the ssh binary is used for at build time. > > That's obviously dangerous - as the issue points out - for the > cross-compile case, where you cannot assume that the ssh binary path is > the same between the build host and the target distro. But it also means > that using a sysroot-native ssh binary is equally as insane, since its > path is also different from the final target image. So neither the > existing implementation, nor this PR, would provide you with a working > gvfs-sftp implementation. > > > The proper solution is probably to change the gvfs-sftp backend upstream > to use PATH resolution at runtime to find the ssh binary. Though I don't > actually use gvfs-sftp in my use-case, I'll attempt to try and upstream > a fix. > > The other alternative I see is to disable the gvfs-sftp subpackages from > building in OE entirely - which seems undesirable for those users who > are depending on it. > > > [1] https://gitlab.gnome.org/GNOME/gvfs/-/issues/465 > > On 12/1/22 07:41, Alex Stewart wrote: > > While rebasing the NI LinuxRT distro to kirkstone, I noticed that my > > pyrex container fails gvfs:do_configure with a meson error about not > > finding an `ssh` client. > > > > | Program ssh found: NO > > | > > | ../gvfs-1.50.0/meson.build:462:2: ERROR: Assert failed: SFTP backend requested but a ssh client is required > > > > > > After some investigation, it seems that gvfs is configured to use the > > `ssh` client implementation in the build machine's PATH. If no native > > implementation is provided in the native sysroot, it will default to > > using the host machine's implementation. > > > > My new kirkstone pyrex container happened to not install an ssh client, > > and so would fail. Since ssh isn't a requirement to run BB or OE, I > > don't think it's appropriate to use the host's ssh. > > > > > > This patchset adds the native bbclass to openssh, when the user includes > > meta-oe in his layerstack, and then provides the openssh-native content > > to gvfs through its DEPENDS. This is sufficient to resolve the error on > > my kirkstone pyrex container. > > > > > > NOTE: It's a little odd to me that the OE-core openssh recipe doesn't > > already inherit native.bbclass - when it *does* inherit > > nativesdk.bbclass. I would be open to moving the openssh changes in this > > PR to OE-core directly, if someone can ACK that it would be more > > appropriate to do so. > > > > Alex Stewart (3): > > openssh: add native BBCLASSEXTEND > > gvfs: stylize DEPENDS I kept this one patch since it was formatting only. > > gvfs: use native ssh client > > > > .../recipes-connectivity/openssh/openssh_%.bbappend | 2 ++ > > meta-gnome/recipes-gnome/gvfs/gvfs_1.50.2.bb | 12 ++++++++++-- > > 2 files changed, 12 insertions(+), 2 deletions(-) > > create mode 100644 meta-gnome/recipes-connectivity/openssh/openssh_%.bbappend > > > > -- > Alex Stewart > Software Engineer - NI Real-Time OS > NI (National Instruments) > > alex.stewart@ni.com > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#99905): https://lists.openembedded.org/g/openembedded-devel/message/99905 > Mute This Topic: https://lists.openembedded.org/mt/95382223/1997914 > Group Owner: openembedded-devel+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >