Building flatpak under WSL

[beow]

Ubuntu 18.04 WSL

Following the steps in https://github.com/flatpak/flatpak/blob/wip/WSL/README.md it all works fine until "make" of flatpak itself. It fails with the following messages

make[2]: Entering directory '/home/xxx/flatpak'
  GISCAN   Flatpak-1.0.gir
/home/xxx/flatpak/tmp-introspectgga44z0h/.libs/Flatpak-1.0: error while loading shared libraries: libostree-1.so.1: cannot open shared object file: No such file or directory
Command '['/home/xxx/flatpak/tmp-introspectgga44z0h/Flatpak-1.0', '--introspect-dump=/home/xxx/flatpak/tmp-introspectgga44z0h/functions.txt,/home/xxx/flatpak/tmp-introspectgga44z0h/dump.xml']' returned non-zero exit status 127.
/usr/share/gobject-introspection-1.0/Makefile.introspection:159: recipe for target 'Flatpak-1.0.gir' failed
make[2]: *** [Flatpak-1.0.gir] Error 1
make[2]: Leaving directory '/home/xxx/flatpak'
Makefile:4261: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/xxx/flatpak'
Makefile:1659: recipe for target 'all' failed
make: *** [all] Error 2

libostree-1.so.1 is there under

$ ls -l /usr/local/lib/
total 4228
drwxr-xr-x 1 root root      512 Mar 24 08:23 girepository-1.0
-rwxr-xr-x 1 root root     1135 Mar 24 08:23 libostree-1.la
lrwxrwxrwx 1 root root       20 Mar 24 08:23 libostree-1.so -> libostree-1.so.1.0.0
lrwxrwxrwx 1 root root       20 Mar 24 08:23 libostree-1.so.1 -> libostree-1.so.1.0.0
-rwxr-xr-x 1 root root  3853872 Mar 24 08:23 libostree-1.so.1.0.0
drwxr-xr-x 1 root root      512 Mar 24 08:23 ostree
drwxr-xr-x 1 root root      512 Mar 24 08:23 pkgconfig
drwxrwxr-x 1 root staff     512 Nov 14 17:30 python2.7
drwxrwsr-x 1 root staff     512 Jul 25  2018 python3.6

Also can't find the /home/xxx/flatpak/tmp-introspectgga44z0h/ directory under flatpak, but maybe 'make' erases it when terminating the script?

[alexlarsson]

I have not tried this in a long time. Maybe something changed...

[oleid]

FWIW: I am able to run Spotify via flatpak from alpine Linux in WSL2.

$ flatpak run  --command=sh com.spotify.Client
$ export DISPLAY=172.17.240.1:0
$ /app/bin/spotify

So I suspect things might work out of the box with WSL2.

I used GWSL from Microsoft store to display the application. It is basically a nicely wrapped VCXSRV.

[smcv]

My understanding is that WSL 1 was basically a container, running on a Linux-syscall-compatibility mode provided by the Windows kernel, whereas WSL 2 is very different: it's basically a virtual machine, running a real Linux kernel. As a result, Flatpak (and anything similar that uses advanced/complicated Linux kernel features) is a lot more likely to work on WSL 2 than it is on WSL 1.

[oleid]

Yes, I have the same understanding.

I just realized that I've highjacked a totally unrelated issue. This is about building flatpak with WSL, not about building flatpaks with WSL 🙄

Building flatpak itself should work with both, WSL and WSL2, as it doesn't require specific kernel features. Building flatpaks not.

[smcv]

I think the original issue here is an omission in the instructions on the wip/WSL branch. They assume that installing into /usr/local will work well, but if /usr/local/lib isn't in LD_LIBRARY_PATH then things might fail to find libostree.

Some possible workarounds: disable GObject-Introspection, or build libostree and Flatpak as OS packages (for an Ubuntu container that would mean a .deb, probably based on the packages I maintain in Debian or the packages Alex maintains in a PPA) instead of doing a local installation, or install the OS's libostree-1-1 package.

If WSL2 can run an unmodified Flatpak, then the long-term solution might be to just not care about WSL1 - the wip/WSL branch could be marked as unmaintained, or just go away entirely.

[oleid]

If WSL2 can run an unmodified Flatpak [...]

Yes, the only outstanding issues seem to be what to use as a DISPLAY. It would seem Microsoft is going to do something Wayland based, c.f. https://devblogs.microsoft.com/commandline/whats-new-in-the-windows-subsystem-for-linux-september-2020/#gui-apps - so it remains to be seen how much is left do to one this is integrated.

the long-term solution might be to just not care about WSL1

I agree. Considering WSL2 works on Windows 10 today and it seems to be possible to convert a WSL1 distribution to WSL2, I don't see any reason to support legacy stuff.

[japtain-cack]

I'm not able to install neovim using flatpack via WSL2/Ubuntu 20.04 on windows 10/11 due to bwrap incompatibilities. Or rather, org.freedesktop.Platform.openh264, fails to install due to those issues.

flatpak --version
Flatpak 1.14.0

lsb_release -r
Release:        20.04

sudo flatpak install neovim
Alias tip: _ flatpak install neovim
Looking for matches…
Found ref ‘app/io.neovim.nvim/x86_64/stable’ in remote ‘flathub’ (system).
Use this ref? [Y/n]: y
Required runtime for io.neovim.nvim/x86_64/stable (runtime/org.freedesktop.Sdk/x86_64/21.08) found in remote flathub
Do you want to install it? [Y/n]: y

io.neovim.nvim permissions:
    ipc      network      fallback-x11      wayland      x11     file access [1]

    [1] /tmp, /var/tmp, host


        ID                                           Branch          Op          Remote           Download
        ID                                           Branch          Op          Remote           Download
 1. [✓] io.neovim.nvim.Locale                        stable          i           flathub            1.4 MB / 1.4 MB
 2. [✓] org.freedesktop.Platform.GL.default          21.08           i           flathub          129.5 MB / 129.8 MB
 3. [✗] org.freedesktop.Platform.openh264            2.0             i           flathub            1.2 MB / 1.5 MB
 4. [✓] org.freedesktop.Sdk.Locale                   21.08           i           flathub          181.3 MB / 330.8 MB
 5. [|] org.freedesktop.Sdk                          21.08           i           flathub          139.0 MB / 476.3 MB
 6. [ ] io.neovim.nvim                               stable          i           flathub          < 8.2 MB

Warning: While trying to apply extra data: apply_extra script failed, exit status 256
Installing 6/6… ████████████████████ 100%  502.1 kB/s  00:00bwrap: Creating new namespace failed: Permission denied
bwrap: Creating new namespace failed: Permission denied
bwrap: Creating new namespace failed: Permission denied

[smcv]

I'm not able to install neovim using flatpack via WSL2/Ubuntu 20.04 on windows 10/11 due to bwrap incompatibilities

This issue was originally about building flatpak under WSL1, not about running flatpak under WSL2, which is a rather different situation.

If bwrap is failing to create new namespaces in your WSL environment, then that seems like something to bring up with the people who maintain WSL: if its emulation of a real Linux system is not sufficiently accurate to run Flatpak, then it's unlikely that changes in either flatpak or bwrap will be able to resolve this. flatpak and bwrap are primarily designed to run on a real Linux system, and the ability to create new namespaces is fundamental to how they work.

[smcv]

I'm closing this as "not planned" because the original issue was about WSL1, which is no longer an interesting thing to support.

If there are things that can change in flatpak/bwrap to make it work better on WSL2, then that should be a separate issue or PR, and will have to be led by someone who understands the scope and limitations of WSL2.