We still want the normal GIMP_RELEASE C macro to be set because the
whole development frame should have code behaving like release code, yet
only for the AppStream metadata testing, we want to allow a "TODO"
release date while in +git code.
We are very likely releasing on Monday 4, and not even now but after a
good night. The whole Gitlab infrastructure is clearly half-borked right
now, we are constantly waiting for runners, sometimes we get random
error 500 when loading Gitlab pages, sometimes some stuff get stuck on
display and we need to refresh.
Not only this, but the Flathub infra is also broken (I believe it's also
hosted by GNOME?) and all our builds are either failing or sometimes
going further then failing at "Committing builds" or other steps,
usually with some HTTP error.
It's not the wisest idea to make a RC1 release in such condition.
As I recall, this is something we in fact used to have in gimp-2-10
branch and which we lost when switching from appstream-util to
appstreamcli validation tool (the later is now recommended, but it's
also less featureful, they don't even have a relax test!). So that was a
regression in the build system.
Note that it's not just not to have to put a date too early in our
AppStream metadata, but it's also that this way, we won't forget to
update it upon release (hence shipping with a wrong release data in
metadata). Indeed, when building a non-release version, date="TODO" will
pass the test, yet moving on to a point release version, the validation
test will now fail on a TODO date.
I had just forgotten to add it, though fortunately (or not) it doesn't
break string freeze because the <release> description fields are not
localized right now.
Cf. discussions in #8628 and this infrastructure report:
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/473
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
