Crossroad repo was finally moved to Freedesktop.
See: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/477
This should avoid the too many failures we have lately on TuxFamily
infrastructure (and also gives a proper bug tracker for Crossroad). I am very
thankful to TuxFamily for all these years! :-)
Let's not be said that I moved the repo because I don't like this friendly FLOSS
host anymore. I just needed something different for Crossroad project now.
The creation of the BMP welcome images for the Windows installer (part of
-Dwindows-installer=true build option) fails in the Windows job. After much
debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far
is that the environment variables for DLLs won't work, since all the DLLs must
be in the same directory as the main binary (though with the WSL thing, I am
unsure, maybe it is still supposed to work), which only happens once GIMP is
installed. So GIMP runs successfully but not plug-ins.
Anyway I wasted too much time working on this and without a local Windows, it
just takes too long (mostly testing thanks to the CI) and is frustrating. Let's
just move to building both the localization files and the images on the main
Debian job (gimp-meson-debian), then use these as dependencies of the
win-installer-nightly job, i.e. when building the installer.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
While Debian testing is the sensible choice for dependency requirements while we
are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12
"bookworm" barely got out.
If we continue to develop at current pace, GIMP 3.0 should be released before
the next stable Debian, so we should not use dependencies unavailable on the
latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian,
nor on Debian derivatives such as Ubuntu, Mint, etc.).
This is why we are now basing GIMP dependency requirement on Debian bookworm.
We'll likely get back to the next "testing" after GIMP 3.0 release.
This commit makes no real changes but style.
As discussed, this makes it much easier to compare commit diffs, rather
than an overlong line where you have to search which package may have
been added/removed/changed.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
The flatpak_ci_initiative.yml template we include got changed 2 days ago,
replacing the "only" by a "rules", which broke our CI file.
Cf. commit 193f63c20f87d38868c05beee6446b387b73e140 in repository citemplates.
The present commit should (hopefully) fix this error:
> Unable to create pipeline
> jobs:flatpak-nightly config key may not be used with `rules`: only
(even though the error is a bit cryptic, the problem is apparently that both
rules: and only: keys cannot be used together)
Python 3.10 introduced sysconfig.get_default_scheme() and somehow Debian decided
it was a good idea to move from the 'posix_prefix' to the 'posix_local' scheme.
See: https://lists.debian.org/debian-python/2022/03/msg00039.html
The main issue with this scheme is that it adds a local/ subdirectory to the set
--prefix. As a consequence, with --prefix=~/.local/, scripts are installed in
~/.local/local/bin/ (instead of proper ~/.local/bin/), data are now in
~/.local/local/share/ and so on.
As expected, this broke a lot of CIs for a lot of projects, as well as a lot of
custom scripts, usage of Python in virtualenv (this later case seems like it is
fixed by special-casing it in Python 3.11), flatpak, etc.
Setting DEB_PYTHON_INSTALL_LAYOUT environment variable to "deb" solves this by
changing the default scheme.
This URL is also useful to understand the issue:
https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin
As a side note, Debian is not the only one which made the mistake. Fedora also
did the same thing (and they have also their own different environment variable
to handle this): https://bugzilla.redhat.com/show_bug.cgi?id=2026979
In the last few days, our deps-win64 job started to fail with:
> $ update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
> update-alternatives: error: no alternatives for x86_64-w64-mingw32-g++
The reason lies in this change in Debian testing 10 days ago:
----
gcc-mingw-w64 (25) unstable; urgency=medium
* Upgrade to GCC 12. Closes: #1023679. It is no longer possible to tweak
the installation directory for different thread models, so the -posix
and -win32 packages are no longer co-installable.
* Drop “Built-Using” from “Architecture: all” packages.
* Since the POSIX and Win32 packages are no longer co-installable,
drop support for alternatives and use symlinks to provide the full
set of command names.
* Standards-Version 4.6.1, no change required.
-- Stephen Kitt <skitt@debian.org> Mon, 12 Dec 2022 09:00:34 +0100
----
So from now on, we'll only install the posix variant of the cross-compiler.
Hopefully it will work for all packages we build.
I added this option in commit 38d6783299. It makes the script stateful, able to
remember all previously processed DLL, hence making the whole job much faster
and efficient.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
If we want to encourage packagers to test the meson tarball (better to
do this now with development releases than later on stable releases!),
we should name it prominently. Therefore I will rename the autotools
tarball as gimp-*-autotools.tar.bz2 whereas the meson tarball will be
named gimp-*.tar.xz.
Also renaming `sources` CI job to `sources-autotools`.
The `ninja dist` step fails with:
> ERROR: Repository has uncommitted changes that will not be included in the dist tarball
> Use --allow-dirty to ignore the warning and proceed anyway
> FAILED: meson-dist
> /usr/bin/meson dist
Astonishingly if I run a `git diff` (or git status) in the CI, I saw no
changes and the dist suddenly succeeded. When I remove it, it fails
again. And of course, locally it's alright. No way to diagnose!
Anyway it's not a bad idea to leave some diagnostic logs in the CI so
here we go, properly outputting the diff and exiting the job with an
error when there is a diff. Because anyway, there should be none. It
would mean that there is likely some issue in versionned generated
files.
Maybe let's try to distribute the meson tarball next to the autotools
tarball for our next dev release, and announce that packagers are
invited to test the meson build from tarball and report back.
These were originally to distribute cross-built binaries. Nowadays, we
just use the native-made installer, which is also closer to what people
will really get for release versions.
So let's just remove these. I keep the crossroad builds as these are
still useful to detect Windows build bugs quickly, but we don't need
these distribution steps.
This also takes care of failures in the job, but since it's mostly a
useless job nowadays, rather than wasting my time investigating this, I
simplify the CI.
The gnome-runtime-images have been recently migrated to Quay. This is already reflected in the template.
Please note this MR has been created semi-automatically. If it doesn't make sense, feel free to close it.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
We were already avoiding re-processing a same DLL within the same run
(this can happen when 2 dependencies have themselves a common
dependency). But the dll_link.py script was stateless regarding previous
runs so we might be checking again the same DLLs multiple times (even
though we were not copying them again).
Let's make the script stateful with a new parameter to give a file where
all the previously processed DLL names are stored. I am hoping it would
improve the efficiency of the packaging-win32-native which is suddenly
extra slow (it always times out, even after raising the max job time;
now we time out after 2h30! The 64-bit packaging job just takes 1h,
which is too much already, but still much more reasonable).
Since this is probably much less tested than the default vector icon
case, any bug there might go unseen for some time. So let's add a new
pipeline to check this. I make so this pipeline is not actually run on
every commit (i.e. manually only), then I'll just add a scheduled
pipeline to check the non-vector icon case at regular intervals.
This pipeline also test the icon-list.mk files are not outdated.
Fixes#950
`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)
Jehan