feat: add linux dependencies build

[acolombier]

Needed for Flatpak AppImage and static build on Linux

[daschuer]

How does this interoperate with the Flatpack runtimes?

For my understanding we use https://docs.flatpak.org/en/latest/qt.html
with shared modules. How fits vcpkg into the game?

We don't use it yet. See:
https://github.com/flathub/org.mixxx.Mixxx/blob/master/org.mixxx.Mixxx.yaml

Do you know a project that hat has experience with using vcpkg for building modules for flatpack?

[acolombier]

Regarding the integration with the runtime, I will need to explore that a bit further - my understanding is that I can bring my own Qt version in the mix.

The main interest of bringing VCPKG in the Mixxx is to manage all other dependencies - as you can see in the current Flatpak, they are arbitrarily pinned, meaning we have no visibility or guarantee on those.

Regarding other project using it, I don't know any,

[daschuer]

That's also my understanding with faltpak. It is intended that you use the shared modules and but you can also pack your own libraries. It is however the question if vcpkg helps here or if it s better to use flatpak like others do. It looks like the Flatpak runtime has Qt 6.9 already: https://invent.kde.org/packaging/flatpak-kde-runtime

Why do you want your own Qt version?

[acolombier]

Still from my understanding, and thus subject to validation, flatpak's runtime is independently managed and we have no way to pin a version. This means that in the case of regression between Qt patches (e.g QML TableView, or QFileInfo mimetype), we could still be impacted and have a way to exclude a version like deb or rpm manifest would allow us to. We also would have limitation on Qt plugins AFAIU

We may still decide to rely on it and we could decide not to package Qt deps in Flatpak, but for now, I'd like to have a unified ways to ship Mixxx dependencies across OS, so this can help with the 3.0 or Android projects. This also, for example, enables the ability to use Flatpak-based IDE (tested with Qt Creator), or sandboxed IDE (IDE without full disk access, more and more common on atomic distros)

[daschuer]

but for now, I'd like to have a unified ways to ship Mixxx dependencies across

Hey, we have already discussed it and you have confirmed that introduction of flatpak is not the path into a unified dependencies across OSs which implies to drop Debian and RPM distributions at one point.

I think here. Appimage is the good path. It has for my knowledge vcpkg support.

[acolombier]

I think we got lost in translation there. What I meant by "unified" here was rather than any Linux distros could use VCPKG, tho it may not be the recommended and supported way for some - e.g Ubuntu users should still expect better result with deb-based env, etc...

The TLDR is, this VCPKG linux env includes anything you need, tho there may be better options for your distro.

[daschuer]

I think this started with this GutHub issue:
mixxxdj/mixxx#15552

The issue is that vcpkg is not well suited for Flatpak.
I really strongly recommend to build a Flatpak like anyone else. Using it on top of vcpkg is likely a call for problems or at least a maintenance burden. I also don't expect that vcpkg itself is well maintained on Linux.

On the other hand we have already a standard flatpak. Updating it and integrate it to our daily CI ourself should be not a big deal.

[acolombier]

The issue is that vcpkg is not well suited for Flatpak.

What is the rational behind this statement? Do you have any experience that would justify this or maybe resources that can back your point?

I also don't expect that vcpkg itself is well maintained on Linux.

If this was true, it means that Android, which depends on linux as host triplet, would likely not be suitable either.
The upstream repo actively test that tripplet so this feels like an irrational arbitrary claim, but happy to be proven otherwise.

I really don't understand why we would push back on this initiative, before we even tried.
Worse case scenario, we have a solution for linux distros that are neither debian based or rpm based and AppImage requirement. If your fear comes from the repetitive failing CI (and thus maintainence burden), I can reassure you that this is unrelated and appears to be some temporary issues on SourceForge.

[daschuer]

I have only limited experience with Flatpak builds. What I know as a Flatpak user is that it uses a modular approach from upstream maintained sdks and modules.

Theoretically we can link all libraries statically using vcpkg put the resulting binary into a Flatpak. This way we loose some Flatpak advantages.

• Upstream maintained libraries with some patches
• Runtime updates, Delta updates
• Disk space requirements
• Ram requirements, start up time, due to shared libraries.
• Meet quality rules, if distribution platforms
• Vcpkg requirements in build machines.
• Extra knowledge required for building

I am not sure how important these arguments are, but it feels obvious, that our Mixxx Flatpak vcpkg based will be an exception.

I did a brief GitHub search and found some projects using vcpkg and flatpak however they still use the flatpak modules for building the flatpak dependencies.
See: https://github.com/JakubMelka/PDF4QT

We already have a flat pack for Mixxx. So there must be really a blocking reason to not follow the normal Flatpak build pricess.

[acolombier]

Once again, flatpak is ONLY one usecase so I don't understand why we are arguing about this in here. I will stop responding on that topic on this PR.

[acolombier]

Daniel and I had a chance to discuss that over the phone and clear out some of the misunderstanding.

It was agreed that this solely constitute a research effort and isn't in any ways a commitment in managing flatpak with vcpkg.
It will however be the way for AppImage, if anybody is looking into starting this effor

[ywwg]

Thanks for taking the effort to work this out offline! We can also discuss this further at Thursday's meeting if y'all think that would help and are available?

[daschuer]

I am not available on Thursday

[acolombier]

@JoergAtGithub I am affraid I cannot go around the disk space any further. But also, I am suspecting that, once the NuGET cache will be populated, we won't need as much space. Would we consider merging and testing, and reverting in case it doesn't work? I can cleanup the PR to ready state if we are happy with this.

[daschuer]

Why do you still need it?

[JoergAtGithub]

We still have no Linux build with the same packages as for the other platforms. I see this as a very important step that puts Linux on a par with the other platforms.

[acolombier]

Why do you still need it?

AppImage, or other Linux distro not based on package manager

[daschuer]

The issue is that no one will use it productive.
Linux users will either use the debian or RPM packages or flat pack. So I think we can just skip this work here.

[acolombier]

I do use VCPKG locally on Linux, as this allows me to test Mixxx with the same version than other OSes. This is crucial for QML development, where many feature are missing in Qt distributed on Debian/Ubuntu.

[daschuer]

It is no issue that you use it locally. Just keep in mind that we still have our minimum Ubuntu support policy: https://github.com/mixxxdj/mixxx/wiki/Minimum-requirements-policy
This means you can't use some of the missing features. Or provide a workaround based on the system provided version.

[JoergAtGithub]

Our policy explicitly allows to implement features, that only work on newer Linux versions:

New features can be committed to the main branch which depend on packages not yet available in that Ubuntu version

[acolombier]

Just keep in mind that we still have our minimum Ubuntu support policy

100%. However, regarding the pace 3.0/QML is progressing at, it is safe to assume that the minimum version is going to Ubuntu 26.04 which seems to come with Qt 6.9.

[daschuer]

Yes, that seems to be fine. Look, this PR starts as a requirement for a Flatpak build. Now we have the flatpack build scripts in our packaging folder using the Qt 6.10. This should be also allow to test Qt 6.9 features an all distros.
In addition you can already use "Ubuntu 26.04 LTS Resolute Raccoon" or any other distro featuring Qt 6.9. in a virtual environment which matches the setups our users use, not a extra developers only approach like you propose here.

[acolombier]

Yeah, that's fair to say that the primary requirement has changed, as we now have a Flatpak setup without VCPKG. The AppImage/static Linux build requiremen or the ability to use the latest Qt features remain.

you can already use "Ubuntu 26.04 LTS Resolute Raccoon" or any other distro featuring Qt 6.9. in a virtual environment

Setting up a whole virtual environment is tedious and comes with many limitations (e.g hardware acceleration). Since I still have many hours of work on QML, I'd like to work efficiently, and reduce the pain throughout the experience.
Finally, VCPKG allows me to work with the exact same deps than other OSes, which is crucial to debug certain issues like here

Though I hear your reserves, I understand there is no objection in moving forward with Linux VCPKG. I have pushed a clean version. Let's merge it after #206 so we can revert it easily, in case we are unable to warm up the nuget cache.

[daschuer]

I have still objections to maintain the Linux VCPKG environment at all. You can already use it at home or in your private repository.
Other contributors shall however keep their native Linux environment to have the best testing coverage among them.
I recommend even for you to use your native Linux environment to use most closely what users will use. Use the desired minimal target version (probabyl 6.9.2) to not be surprised that certain things are not available in that version.

[JoergAtGithub]

I spent some days to debug this. The reason that the x64-linux build fails is not lack on diskspace, it is that the qtbase dependecies x11 and opengl are missing.

[acolombier]

Strange, the runner is definitely running out of space, as I have made some runs with a forked watch df that shows the disk reaching 100% becomes it becomes unresponsive.

I have pushed your suggestion to see if this is making a difference!

[acolombier]

It's passing now! Great catch @JoergAtGithub !

[JoergAtGithub]

The Linux build in https://github.com/mixxxdj/vcpkg/actions/runs/21768846503/job/62811532807?pr=190 was pass, after editing the PR description an automatic re-run of the same commit was triggered and failed with "No space left on device": https://github.com/mixxxdj/vcpkg/actions/runs/21783612572/job/62864443255?pr=190

The reason seems to be in the mounting in the volumens of the GitHub runner. In the Pass-Case, /dev/root has 145G total memory available:

Run df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       145G   54G   91G  38% /
tmpfs           7.9G   84K  7.9G   1% /dev/shm
tmpfs           3.2G 1016K  3.2G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
efivarfs        128M   26K  128M   1% /sys/firmware/efi/efivars
/dev/sda16      881M   62M  758M   8% /boot
/dev/sda15      105M  6.2M   99M   6% /boot/efi
tmpfs           1.6G   12K  1.6G   1% /run/user/1001

In the failing caseI, /dev/root has only 72G total memory available, but there appears another volume /dev/sdb1 with additional 74G diskspace:

Run df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        72G   51G   21G  71% /
tmpfs           7.9G   84K  7.9G   1% /dev/shm
tmpfs           3.2G  1.0M  3.2G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
efivarfs        128M   32K  128M   1% /sys/firmware/efi/efivars
/dev/sda16      881M   62M  758M   8% /boot
/dev/sda15      105M  6.2M   99M   6% /boot/efi
/dev/sdb1        74G  4.1G   66G   6% /mnt
tmpfs           1.6G   12K  1.6G   1% /run/user/1001

[acolombier]

Ah that's good to know. I don't think there is anything we can do about that, and I assume they might have multiple class of VM in the runner pool. I'll see what we can do.

Now that we know the build passes tho, how about merging to let it warm up the cache? It might need a few retry but this should be fairly straightforward.

Edit: I think I have a fix here - working on it now.

[daschuer]

I wander if it is till reasonable to fight with the CI limitations here. As I outlined above it is even contraproductive. With every contributor that is using the Linux vcpkg environment, we loose one tester for one of our release setups. This is a strong downside.

I have the impression that this is also the attempt to equalize our release builds across all OSs. If this is true, let's discuss the pro and cons separately independent from this PR and let's put this here on hold in the meantime.

What's you hidden agenda here? What do you think?
Please explain.

[acolombier]

I wander if it is till reasonable to fight with the CI limitations here.

It's a fair concern. Worth to highlight that this is the same issue I had for Android, and for which I came up with a nasty workaround. I am hopping that with 9db226a, I now have a sustainable solution for all Linux-based build (Linux and Androids - more Android arch and version will need to be included at some point).

With every contributor that is using the Linux vcpkg environment, we loose one tester for one of our release setups.

We should rather take the problem on the other direction and think about why would contributors move to a Linux vcpkg environment? The TLDR is, I doubt anybody would use it except if they need the latest supported Qt version or the ability to statically link Mixxx. Another usecase is going to be containerised build environment. For example, if you want to build Mixxx with Qt Creator on Flatpak, VCPKG is the most straight forward solution.

Let's put this here on hold in the meantime.

This has already been on hold for 4 months. Except if there is strong concerns here, I would suggest we move forward.

What's you hidden agenda here?

I did updated the PR description previously. My hidden agenda is to progress on whta I considered being the future of Mixxx, that is:

• QML
• Android

While having VCPKG is going to be useful for me to move faster on the above, I am still planing to use the release setup for my day to day Mixxx builds, which I use to perform or make 2.x features (Taglib, SiS, ...), so in my case, you won't be loosing a RPM setup tester!

[acolombier]

@JoergAtGithub all is green now!

[JoergAtGithub]

Thank you Antoine for the explanation and clarification, and of course for your tireless work on this PR!

I have reviewed the code and confirm hereby, that:

• It contains nothing beyond what is strictly necessary for the purpose of providing VCPKG-based AppImages, as specified in the mutual agreement between Daniel and Antoine dated November 11, 2025:

  It will however be the way for AppImage, if anybody is looking into starting this effor

• Furthermore, I can confirm that the implemented solution for the GitHub disk space issue is a robust and permanent solution that offers plenty of reserve and is not on the edge.

[ywwg]

I agree that this seems like a low-risk change that will help enable development under certain circumstances. Let's give it a shot and if we run into problems we can revisit the issue.