Several of our own translations of the Windows installer are unused
because Inno Setup corresponding translations are marked "unofficial".
This mostly means that the language files for these are probably old and
unmaintained, hence outdated. And these files are not bundled together
with Inno Setup release (though still hosted in their repo).
Nevertheless it doesn't make sense that we would just waste the work of
our translators here. Maybe Inno Setup localization is not complete, so
what? At best it could even encourage translators to contribute upstream
to Inno Setup. Let's just enable all our current localizations of the
installer and see how it goes!
Anyway Python deps does not work yet on the master build. That's
unneeded to build nightlies with Python support. Let's drop it for now
and add it back later when we will make it work.
This breaks the flatpak tests at the end when we prepared a future
<release> appdata tag. For released version, we must not do this, but
for nightlies, it doesn't matter.
This will set the default color profile directory under its path inside
the sandbox and therefore fix issue #15 of our flathub repo.
While I am at it, I do some cleaning and remove --enable-vector-icons
since this is now the default.
This is in particular necessary because permission in manifest
--filesystem=/usr/share/color/icc does not work as expected to mount the
system repository inside the sandbox at the same path.
See commit 8f3bf7b175d44118f9146e31191fcb7558614b31 from flathub
repository for org.gimp.GIMP.
Let's go with a simpler manifest since soon it will be built on a better
machine (our CI server) and to make scripts simpler.
Note that I also removed the old webkitgtk dependency, but actually I
realize the GNOME runtime does not have the new dependency as well,
since the runtime actually has a webkit2gtk-4.0 instead. We'll have to
look into this.
This flatpak is tested and working.
I have not yet verified though if it has the maximum options enabled
(guessing not), but only that we had at least the required dependencies
at least.
When we will merge, it will become the nightly flatpak and the current
nightly can be used to follow the 2.10 (future) branch.
This is the script I have been personally using for some time now to
build the devel and nightly flatpak on my server regularly through cron
files.
It is not the best script, arguably, and we can most likely do better.
But for now, it worked for me and is a first step toward maybe making
official nightly flatpak builds soon.