This reverts commit 490c8e7dc4.
Actually, I forgot to add 'GITLAB_CI' as an authorized MS Entra app on
Partner Center. So, I just done that and submission from our CI worked.
This is used by our release scripts on gimp-web.
Let's not generate for other pipelines, however, since they
don't have long life on GitLab and there is no permalinks yet.
Closes#11397
Now, the .msixupload submission will be done from our CI with 'msstore-cli'.
Unfortunately, we can't easily update the changelog due to problems of
Submission API regarding '\b' and '\u0008' backspaces, but it's better to
not have a changelog than to keep using the painfully slow Partner Center.
Actually it does more harm than good on CI, causing inconsistency and work.
The plan was to use it in all jobs but it is simply impossible for Flatpak
(https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1502)
and seems that for Crossbuilds too (tested both crossroad and quasi-msys2).
Actually, only Windows jobs can use it, but started to fail on x86 runners.
On the other hand, sometimes the build is faster without ccache and we do
not have the burden of contacting managers etc. Just pkg caching is fine.
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
This is again a change in gettext 0.23 whose release notes say:
> The value of the xml:lang attribute, inserted by msgfmt, now conforms to W3C standards.
Our xpath selection now recognizes both the old and new (proper) format
so that it works both with older and new versions of msgfmt.
xgettext changed its default behavior since version 0.23 regarding
escaping of special characters into XML entities. Now we need to change
the gt:escapeRule value, differently depending on xgettext version (it
will fail in both cases with the wrong value, except the "wrong" value
is the opposite before and after).
Fixes: #11756
Context: Debian Bookworm only have GCC that links to MSVCRT C library.
Actually, crossroads is failing on our CI probably due to GCC-MSVCRT.
On Debian, there is GCC-UCRT too but it is marked as Experimental and
crossroad does not support it nor Clang-UCRT yet: GNOME/gimp!1860.
Some people reported crossroad working with GCC-MSVCRT in Fedora but
adding a brand new pipeline would be at least suboptimal to mantain.
So, we are temporarely moving from crossroad to quasi-msys2 project which
have UCRT support for both GCC and Clang (it takes compiler resources from
MSYS2). The compilers itself we will take from Debian Testing for parity
(they are standard GCC and Clang with proper CFLAGS set by quasi-msys2).
We may go back to Crossroad when it has UCRT support like quasi-msys2.
It's very unclear who and when added that package to the deps list and if
it is needed to we bundle something more than the library (share/lensfun?).
Indeed, that GEGL op is reported to not work properly as a tool (2ba36733) and
have severe UX problems (#4695), being impossible to use even as experimental.
So, let's not install it to not bloat GIMP installation with not used code.
This seems to be a remnant of the time we custom builded libmypaint.
According to my tests, removing it from the list do not break build,
after all pacman auto installs it for being a libmypaint dependency.