See: #15547
This needs approval from Cannonical and allows migrating app data from
older versions as well writting current app data outside the sandbox.
Closes: #15807 by preloading API-related libraries for 3P plug-ins sake.
This will only work if the .appimage is run normally (without extract), because
when extracted its APPDIR can be placed on dirs with spaces unsupported by LD.
It also requires plug-ins to be built with the Debian used for the AppImage.
But there is nothing new under the sun, this rule is valid for all packages.
Closes#14060
Alternative (legacy) approach to 96a65045e9
Flatpak 1.16 will take some time to land on distros so let's use --device=all
which is retrocompatible and recommended by Flathub linter for this use case.
The only problem is that the "sandbox cops" on our Flathub repo will complain
since we are allowing more devices than needed (even MIDI works as side-effect).
Better approach to 89e88cde
So, we will not either compress nor tar the logs in the end.
As per Jehan comments (I think I've seen something on some MR),
we can bypass the GitLab limitations just by cp-ing the logs.
Partially reverts d07aa8f5 and 73040bce
Just some little improvements:
- Removes --keep-build-dirs to ensure we don't pass build files of modules
(we keep using it for babl and gegl to get the meson-log.txt file)
- Changes ORA build file to _build-cached-$RUNNER.tar.zst for more clarity
(and change back to _build-$RUNNER the final dir passed to the next job)
- Move /build check for the deps jobs (gimp job should just extract)
This reverts 1fcdb724 and 8e6da721, which are inoffensive but inconsistent.
They are added while Jehan's final fix did not landed. Back then, we were
experimenting XZ and other things that we don't use in other parts of the .sh.
So, let's go back to just single tar, since logs are not that big after all.
Apparently that is the reason why the Aarch64 jobs are rebuilding
everything, though I'm not sure to understand why (can gimp-flatpak job
grab the deps-flatpak artifacts from the wrong architecture?).
… delete build/ contents.
We were hitting an error on CI:
> ERROR: Uploading artifacts as "archive" to coordinator... 413 Request Entity Too Large […]
Because the .flatpak-builder/ tarball was huge.
After further testing, it turned out that this is a per-file limit,
since simply not compressing the folder and passing it as artifacts
worked, except this time, we were hitting permission issues: artifacts
end up as root on successive jobs, whereas the CI job runs unprivileged
as a "build" user, which doesn't fly with flatpak-builder still needing
to work and touch previous files.
So I'm doing some in-between by compressing sub-folders (the real
advantage is not the compression part, but the archiving in tar, which
preserves ownership and permissions).
Note that while this kinda partly worked, .flatpak-builder/build/ was
still huge, even when compressing .flatpak-builder/build/* contents in
further individual archives. So I just simply drop this data as it's not
needed at all for flatpak-builder caching (cache/ subfolder is).
See also discussions in #2404.
tar doesn't compress on its own, it's just a container format. It
doesn't look like these 2 files are actually used otherwise, apart from
being log artifacts (at least I couldn't find any script decompressing
these).
This is an attempt to reduce size of artifacts on deps-flatpak because
CI complains with a "Request Entity Too Large" error.
