build-aux: Replace Flatpak modules with pre-compiled dependencies

[tytan652]

Description

Important

This PR relies on https://github.com/tytan652/obs-deps-bst, the PR is also meant to discuss including the BuildStream-based project under the obsproject org.

This PR is x86_64 only, if it gets approved, #9979 will be refactored with aarch64 tarballs and I will try to work on documenting obs-deps-bst.

To reduce compile time and prepare for aarch64 support, dependencies compilation except CEF is moved to a BuildStream project junctionned with Freedesktop SDK.

The BuildStream project is configured to build dependencies in a Flatpak-like environment.

Motivation and Context

Move away dependency compile time, in an aarch64 context it moves away 6 hours of build time to another repo with ~3 hours of build time* without cache.
So only the CEF wrapper and OBS have to be built on this repo CI, so ~1h IIRC for aarch64 without cache.

*Build time is reduced since BuildStream tries to build elements in parallel when possible even with QEMU emulation.

Also on obs-deps-bst side, sources are cached so outage of independent git remote is not an issue if cached.

How Has This Been Tested?

Types of changes

• Tweak (non-breaking change to improve existing functionality)
• Performance enhancement (non-breaking change which improves efficiency)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[RytoEX]

@GeorgesStavracas Thoughts on this approach?

[GeorgesStavracas]

I concur with this approach, with 2 conditions:

• Since we're very close to FDO 25.08, might be better to use it when it's released? Thoughts?
• The obs-deps-bst repository has to be moved to the obsproject group first

(Interestingly, last week I talked to the new Fedora project leader Jef Spaleta and we agreed that moving to FDO-SDK and vendoring our dependencies is a decision that the Fedora project supports)

[tytan652]

• Since we're very close to FDO 25.08, might be better to use it when it's released? Thoughts?

I think certainty on when 25.08 releases before when OBS Studio next beta is needed to be able to do the switch.

---

Edit: If we want to try to switch to Freedesktop SDK 25.08, we need:

• 25.08 being out in stable before OBS 32 beta
• flathub-infra action-images providing an image with 25.08 pre-installed

[PatTheMav]

The changes in this PR look fine to me. Would it be possible to integrate the BuildStream code into obs-deps itself, bringing the actions over and adding the Linux-specific workflow jobs? The BuildStream-specific files could easily all live in its own deps.flatpak directory and we'd have all our dependency-building code in one place (and thus would also have all PRs and issues associated with them in a single place) which would help with visibility.

[tytan652]

Because of GHA caching limits, the Buildstream project needs it's own repo. Le 7 août 2025 22:00:37 GMT+02:00, Patrick Heyer ***@***.***> a écrit :

…

PatTheMav left a comment (obsproject/obs-studio#10934) The changes in this PR look fine to me. Would it be possible to integrate the BuildStream code into `obs-deps` itself, bringing the actions over and adding the Linux-specific workflow jobs? The BuildStream-specific files could easily all live in its own `deps.flatpak` directory and we'd have all our dependency-building code in one place (and thus would also have all PRs and issues associated with them in a single place) which would help with visibility. -- Reply to this email directly or view it on GitHub: #10934 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[PatTheMav]

Because of GHA caching limits, the Buildstream project needs it's own repo. Le 7 août 2025 22:00:37 GMT+02:00, Patrick Heyer @.> a écrit :
…
PatTheMav left a comment (obsproject/obs-studio#10934) The changes in this PR look fine to me. Would it be possible to integrate the BuildStream code into obs-deps itself, bringing the actions over and adding the Linux-specific workflow jobs? The BuildStream-specific files could easily all live in its own deps.flatpak directory and we'd have all our dependency-building code in one place (and thus would also have all PRs and issues associated with them in a single place) which would help with visibility. -- Reply to this email directly or view it on GitHub: #10934 (comment) You are receiving this because you authored the thread. Message ID: @.>

Got it. I think I can give it a simple review pass for any obvious gotchas, particularly with an eye towards project data etc., but otherwise I'd probably defer to you and @GeorgesStavracas when it comes to the repo itself, so you can maintain it as independently as obs-deps is maintained (so no expectations for stuff to work exactly the same way, etc.).

[PatTheMav]

Gave the buildstream repo a quick glance, seems to be fine, couldn't spot any (ab)use of secrets or GitHub tokens (not that I expected any).

Personally I'd probable prefer to call it obs-deps-buildstream (if "BuildStream" is more or less exclusively associated with Flatpak that makes it superfluous to mention it in the repo name), but I'll leave this to @RytoEX to pick up.

[tytan652]

"bst" is a common abbreviation but going for "buildstream" is fine too (project.conf would need an update).

if "BuildStream" is more or less exclusively associated with Flatpak that makes it superfluous to mention it in the repo name

It isn't, it can be used to build OCI images, entire Linux distribution and in our case dependencies for our Flatpak (even stuff on macOS or WSL).
This is not for the short-term, but I has some thought about making an OCI image from it for static analysis if judged helpful.

[tytan652]

Due to libobs now depending on SIMDe, the devel tarball is no longer cleaned up (devtools still is).

[RytoEX]

Personally I'd probable prefer to call it obs-deps-buildstream (if "BuildStream" is more or less exclusively associated with Flatpak that makes it superfluous to mention it in the repo name)

I'd personally prefer the less ambiguous "obs-deps-buildstream" name.

[GeorgesStavracas]

The buildstream repository was moved to the obsproject group, so this should be ready to go now

[RytoEX]

Catching up here.

• Since we're very close to FDO 25.08, might be better to use it when it's released? Thoughts?

Edit: If we want to try to switch to Freedesktop SDK 25.08, we need:
* 25.08 being out in stable before OBS 32 beta
* flathub-infra action-images providing an image with 25.08 pre-installed

Have these conditions been met?

Are there any benchmarks of the CI build times for obs-studio with these changes?

[RytoEX]

Looks okay, but would like previous questions addressed before I approve.

[tytan652]

Have these conditions been met?

It was for having 25.08 on 32, 25.08 wasn't out and this PR got pushed back for the next release.

obs-deps-buildstream master branch is on 25.08, I'm waiting for the next obs-deps updates to sync up and make a new release with 25.08 (for a separated update PR).

Are there any benchmarks of the CI build times for obs-studio with these changes?

Besides this PR CI, not much.
Building OBS Studio without cache before could lead IIRC to 45min to 1h of build time since it builds everything fro source besides CEF.
With this PR, it will likely go at worst to ~25min unless our codebase goes bigger.

[PatTheMav]

Have these conditions been met?

It was for having 25.08 on 32, 25.08 wasn't out and this PR got pushed back for the next release.

obs-deps-buildstream master branch is on 25.08, I'm waiting for the next obs-deps updates to sync up and make a new release with 25.08 (for a separated update PR).

Are there any benchmarks of the CI build times for obs-studio with these changes?

Besides this PR CI, not much. Building OBS Studio without cache before could lead IIRC to 45min to 1h of build time since it builds everything fro source besides CEF. With this PR, it will likely go at worst to ~25min unless our codebase goes bigger.

Is there any concept/solution in the Flatpak ecosystem to fulfil the CI need to just figure out whether it compiles successfully?

Because for any given push to the master branch or a simple CI push that's the information we're interested in, as there is no expectation that CI generates builds that can actually run on an actual system. That changes when the "Seeking Testers" label is added, a nightly build runs, or we create a version tag.

So the question that swirls in my mind is: Is the Ubuntu build meaningfully different from the Flatpak build or could compilation of the Ubuntu build (with the appropriate preprocessor macros set) simulate compilation for Flatpak?

The way I see it, the difference between Flatpak and Ubuntu is largely only important for builds that will be pushed to Flathub or that are intended to be actually downloaded and used by users (see above). And if we could thus omit Flatpak compilation runs for "simple" PRs, that would cut down on CI time a lot.

[tytan652]

Is the Ubuntu build meaningfully different from the Flatpak build or could compilation of the Ubuntu build (with the appropriate preprocessor macros set) simulate compilation for Flatpak?

Ubuntu and Freedesktop SDK (Flatpak) are two separate Linux distribution and must not be seen as equal.
Ubuntu is the most limiting one with older/missing deps while Flatpak allows us to compile most of OBS with recent deps (besides some plugins for sandbox related reason).

If we want to ensure proper Flatpak support, we need Flatpak CI to ensure that a PR still builds properly in Flatpak environment. This is not really something we should try to "make savings" on.

Can CI time usage can be improved even more ? The answer is maybe, but the main focus of this PR is improving deps compilation and openning the road towards aarch64 builds.

[RytoEX]

Seems fine. This should land for 32.1.