At the moment, my only use for
fedora-toolbox is doing a
dnf search for the names of RPMs, which I then install with
At the moment, my only use for
I was playing around a bit with the flatpak building tools flatpak-module-tool and fedmod. I couldn’t use them to do what I was trying in a terminal in Silverblue directly. I had to run it in the fedora-toolbox or I guess some other container would suit too. Mainly this was due to dependencies I needed for the rpm I was trying to make a flatpak of, they weren’t all able to be installed on rpm-ostree. The toolbox seemed the quickest route to testing the build I was trying in that case and proved useful.
My model is HP LaserJet 1006P.
This model needs to download a proprietary firmware and then load it to the printer every time you connect it. The thing is that it’s trying to save it a read-only part of the system.
I’d like to see GNOME app integrations work from Flatpaks so I don’t have to layer GNOME Clocks for example.
But what I would really love to see is Silverblue rolling release
+1 for rolling release. At worst, a two-week cycle like Atomic Host had.
+1 for rolling release. In a way Flatpaks already are, and OStree would make it easier to do the same for the base OS
Proper and persistent filetype and URL associations between Flatpak applications would also be nice. It’s a bit annoying to have to click the same app on that selector pop-up every time…
IIRC they wanted to do some sort of a “gated rawhide”, and it was in the list of stuff in the message about delaying F31. Right now the main issue with using rawhide for rolling is just that anything gets in if the tests pass. Sure this is Silverblue, so you could just roll back if something breaks, but it still will get a bit irritating after a bit.
With regards to Firefox sandboxing, the team is very open to code reviews. I actually recently contributed FileChooser portal support, so it may be possible to run it without
--filesystem=home, but I haven’t tried. Official Firefox flatpaks are tracked by this Bugzilla entry and its dependency graph.
Okay, this sounds great already. But the U2F issue is still a major unresolved thing…
Definitely agree. I’m not sure what the right design is for U2F sandboxing – does Flatpak provide a portal for device selection?
AFAIK no. So I decided to tackle this issue, where it can (I think) be solved: In flatpak.
Here is a new issue:
BTW, thanks to your guide, I was able to configure Atom to properly run shellcheck. As that may be useful in many cases, I post it here.
So first, I do not need the extra “talk to flatpak” permission. That is only required when you want to run commands actually on the host (
flatpak-spawn --host) and is thus a very dangerous permission. In my case, the tool to run was totally self-contained, so I could actually increase security and run it in an even stronger sandbox than what Atom has.
The only problem was the configuration GUI of the Atom package that just allowed me to add a single command (parameters did not work), so what you have to do then is to create a simple wrapper script such as this one:
#!/bin/sh flatpak-spawn --sandbox --no-network --clear-env shellcheck "$@"
(It uses the strongest sandbox options I could quickly find, but still has access to the current dir it was started from AFAIK.)
Then you have to save it in a path accessible to the flatpak. Note that the the usual
/usr/lib/bin or so is not possible, as it is not mounted in the flatpak. Instead, your home dir or so may be possible. (I know, a little ugly…)
Finally you just configure Atom to use this script, and it works. And remember, it has an even stronger sandbox…
Okay, no, I actually missed to save the file , actually, it seems to fail with shellcheck even if I do not add
--sandbox, which should make the files readable, at least.
In any case, however, the
--host version works:
#!/bin/sh # --sandbox and --no-network do not work flatpak-spawn --host --clear-env shellcheck "$@"
Sorry for continuing this slightly off-topic thing, but one last comment:
I have now created a repo with all scripts for using Atom with a flatpak and more detailed instructions, see:
That one doesn’t support x264, while unofficial one does.
This will hopefully be solved soon.