Starting Flatpak applications fails from Toolbox

[ondrejholy]

Describe the bug
I am no more able to start Flatpak applications installed on my system from the Toolbox. E.g. toolbox run flatpak run org.gnome.Devhelp worked nicely (see https://ondrej.holych.net/devhelp-on-fedora-silverblue/) probably until today reboot...

Steps how to reproduce the behaviour

1. flatpak install org.gnome.Devhelp # on the system, not in the Toolbox
2. toolbox run flatpak run org.gnome.Devhelp

Expected behaviour
The Devhelp application starts.

Actual behaviour
The following error is shown bwrap: Can't find source path /run/user/1000/doc/by-app/org.gnome.Devhelp: No such file or directory and the application doesn't start.

Output of toolbox --version (v0.0.90+)
toolbox version 0.0.97

Toolbox package info (rpm -q toolbox)
toolbox-0.0.97-1.fc33.x86_64

Output of podman version

Version:      2.2.1
API Version:  2.1.0
Go Version:   go1.15.5
Built:        Tue Dec  8 15:37:50 2020
OS/Arch:      linux/amd64

Podman package info (rpm -q podman)
podman-2.2.1-1.fc33.x86_64

Info about your OS
Fedora Silverblue 33

Additional context
Outside of the Toolbox, flatpak run org.gnome.Devhelp is started without any error.

Yesterday I ranrpm-ostree update and dnf update. rpm-ostree rollback doesn't help. So this might be something with dnf update, but unfortunately, dnf history undo last is not possible as the packages are not available anymore.
See the output of dnf history info last here.

A similar issue is also reported on https://discussion.fedoraproject.org/t/flatpaks-no-loger-spawn-from-toolbox/25093.

[HarryMichal]

Hi! Interesting problem... I'm surprised calling Flatpak worked in the first place because the images do not have flatpak installed and there is no "official way" (#145, #553) of calling programs on the host from toolbox. Coincidentally, I read your article a couple of hours ago and I was surprised by your solution :).

In other cases I would suggest to invoke flatpak with flatpak-spawn --host flatpak <some args> but your goal is to execute Devhelp from the environment inside the toolbox instead of the host environment to see the relevant documantion. Right now I don't know how to help.

PS: If my assumption about Flatpak not being invocable from a toolbox is wrong, then we need to investigate a bit because that should not be possible. @debarshiray?

[ptomato]

This also broke things like alias vim='flatpak run org.vim.Vim' and alias subl='flatpak run com.sublimetext.three' which previously worked inside toolbox. Luckily, simply adding flatpak-spawn --host does fix this.

[debarshiray]

I am very surprised to know that it was actually possible to run Flatpaks from inside a Toolbox container. This seems to have been some happy coincidence because this isn’t supposed to work until we land the code for #145

We definitely never tested for this. :)

I see that people were complaining about this already on the 20th of December. Toolbox 0.0.97 came out on the 3rd of November and 0.0.96 on 1st of October. In between those releases we stopped using org.freedesktop.Flatpak.SessionHelper to keep some of the configuration files in /etc synchronized with the host, but it's not immediately obvious how that could cause this. Flatpak.SessionHelper is a standalone session D-Bus service separate from the rest of Flatpak.

Other than that, I wonder if something in the kernel or Flatpak might have changed.

In Toolbox, over time, we have been opening up access to more and more parts of the host, so I can't imagine what might have (inadvertently) broken this.

Although, I must say that your new solution of installing devhelp inside the Toolbox container and using toolbox run devhelp in your own custom devhelp.desktop file is definitely a lot more supported than the previous approach. The run command was added specifically to address gaps in our Flatpak story.

[debarshiray]

Duplicate of #145