I've built an initial version of F31 flatpak runtime and SDK, and built
a set of GNOME flatpaks against it. At the same time, I've also updated
them to 3.34.x. I'll build more of the apps against F31 runtime in the
coming days. Right now the set of apps include:
This set was chosen for the initial port because this is what we want to
preinstall on Silverblue.
This should hopefully go stable around the same time as F31 goes live,
so people should be able to install 3.34 flatpaks on F31.
Karma in Bodhi and testing welcome:
Right now they are available in the fedora-testing flatpak repository.
To enable the remote, 'flatpak remote-modify --enable fedora-testing'
or if you don't have the remote for some reasons, then:
'flatpak remote-add fedora-testing
The subject of disk space and flatpaks came up in the most recent
workstation meeting, and I'd like to separately discuss that in this
thread before creating a flatpak issue.
The full log:
13:16:07 <langdon> allocating enough disk if you have your drive
sliced up is tough
13:16:36 <Son_Goku> and yeah, the disk space issue is a huge problem
13:16:47 <kalev> "the disk space issue" ?
13:16:58 <otaylor> Son_Goku: why would disk space be an issue?
flatpaks store data in $HOME
13:17:19 <langdon> that's the problem.. normally I have a "games disk"
13:17:27 <Son_Goku> likewise
Neither sysroot nor $HOME fits the above use case, where the user
wants to store games on a separate volume entirely. And another use
case is where it's desirable to use the much larger /home volume
storage pool, but permit sharing of apps among users.
Could there be a /home/share/flatpak with the appropriate permissions,
that meets both use case requirements?
Alternatively, Workstation could do what Silverblue does, with
/var/home bind mounted to /home - and therefore system and user
flatpaks go on the same volume. But there should also be a way to set
the default location for flatpak files. Users wanting a games volume
could bind mount it to /var/lib/flatpak, but then they need a way to
set system as the default location instead of users.
(cc: desktop@ list too)
Lennart is out until ~Nov 1 on paternity leave. And then his first
priority is merging all the systemd-homed stuff and a bunch of fix
ups. He says it will be production ready by then.
One thing I got from Lennart that I don't have a complete assessment
on, is to what degree he's replicated fscrypt (userspace tool from
Google) functionality. He's hooking into fscrypt (kernel code)
directly, and doesn't have any of the fancier key management that
Google fscrypt has - i.e. Google fscrypt let's you change the user
master passphrase, which is a wrapped key, separate from the secret
key (let's call it a DEK, even though there is one DEK and then there
are many derived DEK's for each file), so that it's not necessary to
reencrypt everything. Whereas systemd-homed lacks this feature, so it
requires 50% free space to reencrypt everything in case of user
I already told Lennart I personally think that's close to a deal
killer, if I'm really understanding this limitation correctly. It's
weird behavior. And such a burden for resources, space and time and
likely would need to be done offline (user is not logged in and can't
be using their home while the reencryption happens), that it would
inhibit users from changing their passphrase when they probably
should, which makes it anti-security, i.e. "I should change my login
passphrase after that work trip; oh crap I have to reencrypt 250G?! No
way. Guess I won't change the passphrase." I think it's unworkable,
and I said so. Casually some people might use it. But I can't
Someone who can read the code needs to look at it and give an
independent assessment: is it really production worthy, is the use
case too narrow or just right, and if too narrow what kind of work
would be needed to broaden it? Etc. I can't really do any of those
things. But for example, to what degree will homed support FreeIPA/AD
domains? Is that a small problem or big problem, is there some other
way to handle those cases? How?
I'm also concerned about performance implications of e.g. GNOME Boxes
in the case where it creates qcow2 file, on top of user home which is
on a file system backed by a loopback mounted encrypted file, which is
on another file system. So that VM is basically pushing writes through
three file systems. I've done quite a lot of brutal testing over years
where I do bat guano crazy things like Btrfs on qcow2, on Btrfs home
on encrypted loop file, on Btrfs, and I'll use the VM and crash the
host and everything survives - that is, the file systems don't break.
There is data loss but that's sorta expected for any file system. But
a consequence of that arrangement is, Btrfs is shit when it comes to
fsync. So if the GNOME Boxes default cache of writeback continues to
be used, which is reasonable, Btrfs performance gets bad with fsync
heavy workloads. Otherwise it performs the same, and occasionally
better, than other file systems.
So yeah - who wants to help dig into the dirty work and actually make
a recommendation? We don't have enough R&D done yet probably to decide
on this but I'm gonna guess it makes a lot more sense to try to use
systemd-homed and convince Lennart, as early adopters, we want it to
be successful and in order to be successful he's gonna have to let it
grow into something that'll actually do what we want and need. But for
that to be convincing, we have to know what we want and need.
On Tue, Oct 22, 2019 at 1:39 PM Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> What should be do to unblock this? Would another meeting be helpful, or
> do we need to do further investigation/research first, or...?
These are the notes I've jotted down for the status report for the
I'll assume acks, so just reply if you've got a nack or patch,
* Currently there are no major/unexpected issues.
* Working group at 10 members, organization improvements proposed and
* Desire to improve third party repo installs, open questions about
including fedora-workstation-repositories on install media.
* Work on automated infrastructure to build flatpaks on-going
* 31 schedule is on track
* OpenH264 improvements will land in 31, includes High and Advanced profiles
* Better support for non-English users coming to 31
* Additional detail of efforts in Workstation 31
* Hopeful for Wayland on Nvidia by default for Workstation 32