See #9136.
(cherry picked from commit 0cd38a87e1)
Note: when cherry-picking, the tags were fixed as the main dev branch does not
need the underlined tags for localization anymore.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
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
See the commit 28467cb on the gimp-data-extras repo where I moved this
data in. Not sure why this metadata file was ever pushed to the main
repo as it is obviously for the data-extras package (or else I am
missing some information!).
The old 2017 report where it was originally added:
https://bugzilla.gnome.org/show_bug.cgi?id=763398
appstreamcli on CI fails with error:
> E: org.gimp.GIMP:394: release-time-missing date
I didn't have such error on my local build, because it is a new check
only recently added. The CI appstreamcli errored-out this way.
It forces us to add a bogus release date since we don't know it yet. I
chose May 29, because we usually release on Sundays, and it might soon
be time to make a dev release (so who knows, we might get lucky and it
might happen this day), though it should not be taken as a promise or a
real plan just now. I just needed to fill something in, in order to fix
the CI.
I opened a report to ask that appstreamcli proposes a relaxed check mode
where we can test on the <release> tag before knowing the future date:
https://github.com/ximion/appstream/issues/398
appstreamcli returns an info message:
> I: org.gimp.GIMP:3: cid-missing-affiliation-gnome org.gimp.GIMP
Checking the message, it happens because the application ID does not
start with "org.gnome." (but "org.gimp.").
Double-checking AppStream docs, a note says:
> You should only identify with an umbrella project if you use all their
> infrastructure and policies, for instance string freezes dates,
> bugtracker and source control instance.
GNOME Foundation is indeed an umbrella for us for the infrastructure and
obviously part of its policies. But we are still independant and don't
depend on GNOME's freeze dates, or release dates, or design rules
(though we try to follow what makes sense), and so on. So I guess it
means we should not set this metadata tag? 🤷 Let's drop it.
See: https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group
Adding a TODO as date was passing through with appstream-util in relax
validation mode, but there is no such mode in appstreamcli.
Anyway since I have manual check steps for the AppStream files in
devel-docs/release-howto.txt, I never missed setting the date right (so
far! Knocks on wood…) in the AppStream metadata. Therefore let's drop
this trick for now and see how it goes.
It should fix the appstream unit check, but only when using appstreamcli
0.15.3 or over (this version is already on Debian testing).
See issue #8140.
As told to us, this is the reference AppStream file testing tool, and it
understands more of the spec.
Also since commit 73e2e701da, appstream-util chokes on newer url types
from the spec. These tags are now supported both in appstream-util and
appstreamcli source code, except that appstreamcli had release 0.15.3,
available in Debian testing, whereas there were apparently no recent
appstream-glib/util release (and none since 2020). So for these various
reasons, let's go with the appstreamcli tool.
The only downside is that appstream package (where appstreamcli lives)
is not available on MSYS2, but since it's only an optional test tool for
XML files which should be common on all platforms, it's probably
acceptable.
It's better to start early as these need to be translated too and are
now even visible in GIMP itself.
Note that I wrote 2.99.11 in the version attribute, but only to be able
to test this easily during development. It will have to be edited to the
right version at release.
We want it to work whatever the level in the item tree. We only care
about whether the items are selected or not.
Also fixing the AppStream release tag for the description of this
feature.
Without this entry, when starting GIMP as a flatpak application on
elementaryOS, the Dock icon would get duplicated, as if the application
was detached from its launcher. This entry fixes that by allowing the
dock to associate the app's window with the desktop entry.
More information on the type of problem this caused can be found here:
https://github.com/elementary/dock/issues/119
Instead of a target, let's make it a test. Also I realize it already
existed as desktop_file test. But it's simpler to run it directly (no
need of an external script).
Note: I still leave the test-desktop.sh script as it is used for the
autotools test.
Both files should always be synchronized (as development branch will one
day continue on the 2.10 series). Best practice would be that any change
to the AppData is first done on `master`, then cherry-picked to
`gimp-2-10` (even for stable release metadata).
Jehan