Successful RPM build must automatically trigger a Flatpak build

This should be a thing. It makes no sense not to do that.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GEADKYSMMMVV5KARSEIZAK424HIYVKJ4/

• Either stop building Fedora Flatpaks for all other applications, OR stop building Fedora Flatpaks for applications that are already available from Flathub?

I'm just an end-user, but I think it would be better to have more
(as many as possible) Fedora Flatpaks available, and instead use third party
remotes like Flathub as a fallback.

• Either stop building Fedora Flatpaks for all other applications, OR stop building Fedora Flatpaks for applications that are already available from Flathub?

I'm just an end-user, but I think it would be better to have more
(as many as possible) Fedora Flatpaks available, and instead use third party
remotes like Flathub as a fallback.

This approach would require significant use of human resources that we don't have. Other than the burden of composing those Flatpaks, there's a maintainership responsibility.

• Either stop building Fedora Flatpaks for all other applications, OR stop building Fedora Flatpaks for applications that are already available from Flathub?

I'm just an end-user, but I think it would be better to have more
(as many as possible) Fedora Flatpaks available, and instead use third party
remotes like Flathub as a fallback.

This approach would require significant use of human resources that we don't have. Other than the burden of composing those Flatpaks, there's a maintainership responsibility.

Or instead we make Flatpak generation more automated with less human involvement. This is how we should have aimed to do Flatpaks from the very beginning. I know that there's a bias against automation for this stuff, but it really makes no sense to make people care about how those Flatpaks of applications are composed.

• Either stop building Fedora Flatpaks for all other applications, OR stop building Fedora Flatpaks for applications that are already available from Flathub?

I'm just an end-user, but I think it would be better to have more
(as many as possible) Fedora Flatpaks available, and instead use third party
remotes like Flathub as a fallback.

This approach would require significant use of human resources that we don't have. Other than the burden of composing those Flatpaks, there's a maintainership responsibility.

Or instead we make Flatpak generation more automated with less human involvement. This is how we should have aimed to do Flatpaks from the very beginning. I know that there's a bias against automation for this stuff, but it really makes no sense to make people care about how those Flatpaks of applications are composed.

Is there a bias against automation? I have no idea about that. Do you know what's the reasoning?

Or instead we make Flatpak generation more automated with less human involvement. This is how we should have aimed to do Flatpaks from the very beginning. I know that there's a bias against automation for this stuff, but it really makes no sense to make people care about how those Flatpaks of applications are composed.

Is there a bias against automation? I have no idea about that. Do you know what's the reasoning?

The original "Factory 2.0" plan was to do rebuilds with Freshmaker - but it was never actually deployed in Fedora and since been stripped down and made quite specific to RHEL workflows.

Sure, writing something specific to Flatpaks to automate rebuilds would be possible, but at this point I think effort would be better spent solving the dependency on modularity first.

What about bug reporting? Abrt should support Fedora flatpak bug reporting OOTB, right? What about flathub flatpaks? Where does this fit into the plan?

At the moment I don't have any Fedora flatpaks misbehaving, but I have one Flathub flatpak (Element) that frequently crashes. But abrt gives the "processing failed" message when trying to report it. The log shows:

--- Running report_uReport ---
Error: No segments found in coredump './coredump'
('report_uReport' exited with 1)

ABRT is not able to report crashes for any containerized apps currently, including flatpaks.

What about applications whose builds are different for flatpak and traditional distributions? For example, GNOME Builder does a lot of things different based on how it was compiled. Are we using manifests coming from Flathub? How are those being composed so they are as close to the way upstream applications expect to be run within a Flatpak.

I have a suspicion that our Flatpak's are considerably more broken than those on Flathub and that sounds like a terrible way to advertise our distribution when something that will likely work better is already available.

The build instructions come from spec files in dist-git (where packages that need them have flatpak conditionals to get the flatpak builds right) and flatpak metadata is mostly copied verbatim from flathub build manifests.

GNOME Builder doesn't have a Fedora Flatpak yet so if you want you could work on that and make sure it comes out exactly like you want it :) I could help you get started if you want.

I have a suspicion that our Flatpak's are considerably more broken than those on Flathub and that sounds like a terrible way to advertise our distribution when something that will likely work better is already available.

Do you know any examples where a Fedora Flatpak gets build instructions wrong and is broken? I think that would be helpful so we can fix the issues.

Do you know any examples where a Fedora Flatpak gets build instructions wrong and is broken? I think that would be helpful so we can fix the issues.

I don't (because I'm not using any) but my thoughts are build systems that are sniffing things like /.flatpak-info during build and doing compile time checks instead of runtime checks.

But if we're using flatpak-builder to compose them and not bundling bits from RPMs, that pretty much makes me feel more-or-less fine as long as those manifests are coming from Flathub.

Ah, I haven't seen anything look at /.flatpak-info during build yet. Do you know anything that does that? I thought .flatpak-info was mostly used for runtime checks.

Just to be clear how the build works, it's only finish-args that are synced from flathub and not the rest of the flathub manifest. The build instructions that are used come from rpm spec files, which are then built for /app prefix as a temporary rpm, which then gets repackaged as OCI flatpak container using flatpak-module-tools which shells out to various things like ostree and flatpak build-finish for putting the package together.

Anything inside a flatpak build will have access to /.flatpak-info and in general it's used as the "am_i_in_flatpak()" sort of check.

Yes, I understand that, and I am just wondering if you know of anything that actually checks /.flatpak-info during build, as in my experience it's usually used for runtime checks? E.g. gnome-builder does

  if (g_file_test ("/.flatpak-info", G_FILE_TEST_EXISTS))
    kind = IDE_PROCESS_KIND_FLATPAK;

... which is a runtime "am_i_in_flatpak()" check, not a build time check. We don't have .flatpak-info during the rpm builds so I am trying to find out if it's a theoretical concern or if you actually know anything that checks it from meson.build and needs fixing in some way :)

it's a theoretical concern or if you actually know anything that checks it

For me it's theoretical because I don't fulltext index everyone's build system to search them (maybe Fedora does though?) But there have been dozens of times where I've considered it, so that means there is a non-zero chance something else out there already does.

it's a theoretical concern or if you actually know anything that checks it

Additionally, I'd like to do this check in Builder very soon, so that I can throw out a whole class of runtime checks.

Ah, makes sense, thanks! I think from Fedora's perspective it would help to have an explicit meson option to pass that would turn on or off flatpak support, as opposed to relying on a build time autodetect using /.flatpak-info.

Additionally, I'd like to do this check in Builder very soon, so that I can throw out a whole class of runtime checks.

I think this is OK for applications, but libraries should remember they may unexpectedly end up running in a flatpak-like environment even if not built for flatpak. E.g. any library that depends on WebKit needs to check for .flatpak-info at runtime or features that require portals might break.

I think this is OK for applications, but libraries should remember they may unexpectedly end up running in a flatpak-like environment even if not built for flatpak.

Why? It's no different than compiling for a different OS stream. Why would I expect copying a .so from Debian to work on Fedora?

Because if your library is used by WebKit (e.g. GTK) and switches to checking .flatpak-info at build time instead of runtime, then the check will fail when we build outside of flatpak and run outside flatpak inside WebKit's bubblewrap sandbox with .flatpak-info created in the sandbox. That's the only way to force use of desktop portals without breaking things, and all sorts of things will break without portals or without .flatpak-info. So build-time checks are not enough. Again, this isn't a problem for applications like Builder, but it is for libraries.

run outside flatpak inside WebKit's bubblewrap sandbox with .flatpak-info created in the sandbox

I guess this explains a bit on why I was seeing weird symbolizing issues with WebKit workers because Sysprof peeks at the rather erroneous /.flatpak-info.

Agreed:

• Due to the recent formation of the Flatpak SIG, let's wait and see if quality of Fedora Flatpaks will improve. No need to reconsider Flatpak strategy when they're just getting started.
• We request that the Flatpak SIG create some sort of tracker for problems with Fedora Flatpaks.

I'd personally like us to summarise the issues that have been observed with Fedora Flatpaks, and check in periodically to assess their status.

I'd personally like us to summarise the issues that have been observed with Fedora Flatpaks, and check in periodically to assess their status.

Kalev, Owen, can you or the Flatpak SIG help with this?