The authors.xml validation was also not run. This is nearly the last of
getting rid of run_target(). There is still the desktop file validation
but it doesn't have any output argument. We'll see how we update this
last one.
The only other usages of run_target() are proper usage (creating
'install-*' targets).
Similarly to the previous commit, the tips and tags validation was never
happening as it was implemented as a custom top-level meson target. It
was not run during a normal build. Now it is.
Basically the build was never running this target (unless maybe in some
edge cases as could be demonstrated by the Arch repository build, though
it doesn't look they did anything particular; this is how we discovered
the bug #6447 as this was not run on our own local or CI builds).
Reading the docs of run_target(), it may actually have been normal.
run_target() looks to be only about creating top-level targets (which
one could run with `ninja validate_menus` in our case for instance), not
actually running the command (i.e. badly named function).
For the command to be actually run on a normal build, let's use a
custom_target() as proposed by Paolo Bonzini. After testing, the xmllint
validation is properly run on a normal build and dependency works fine
with both the source XML and generated XML files (touching these files
trigger a rebuild).
The output of xmllint is stored in some dummy file, which is only useful
to prevent re-running the command at each build even though source XML
were unchanged (so it's more of a flag file).
See discussion in #6447.
All the widgets with label inside GimpProcedureDialog have same
GtkSizeGroup (dialog->priv->label_group), which result in wrong sizes of
widget if any of the label is long. In this commit, a new GtkSizeGroup
is made for each of the container, so that labels are aligned but size
of widget in one container do not affect size of widgets in other
containers.
For the widget not belonging to any of the container, default
GtkSizeGroup (dialog->priv->label_group) is used.
Added an option for exporting thumbnail in WebP Export dialogbox.
Additionally, introduced a function gimp_procedure_dialog_fill_expander.
The function is similar to gimp_procedure_dialog_fill_frame but allows
adding GtkExpander instead of GtkFrame.
Per discussion on !262 and in particular Ell comments, the contributed
patch was right but the comment was not. It is not just about
g-ir-scanner and failing build. The build can still be successful yet
the built GIMP would crash when run on a CPU not supporting all the
extensions.
Don't enable conditionally based on the buildtype.
Further, don't use `add_project_arguments()` to enable the instructions:
this will lead to crashes within g-ir-scanner, which can't properly
parse these instructions.
https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
Something which came with the 2.99.2 release already, though I update
the NEWS file retroactively because we forgot to write this down and
that's a pretty important feature (for ctrl-scroll zooming for instance,
which became a lot more useful in GIMP 2.99.x). This should not be
forgotten when we'll write the GIMP 3 release note, so I'm adding it in
this file where we'll get most contents from.
I must have not been awake yet when I pushed the
fix for #6116 because it has two problems:
- Updating cur_progress caused by not editing the
for loop after a copy/paste, found thanks to
Stanislav Grinkov.
- Not using the correct drawable to determine the
drawable_type which I noticed while fixing the
above issue.
These issues are not present in the backported
version for 2.10.
How to create the packages through MR labels and where to find the
resulting test packages…
Note that it would be nice if we had automatic messages on the MR
writing down the procedure (with generated links for the specific
pipeline ID) once a pipeline succeeds.
It would simplify the whole process even further. We can see some other
day how such a thing could be automated.
… based on set labels.
If the label "5. Windows Installer" is set, the MR pipeline should
trigger the Windows installer pipeline as well.
If the label "5. Flatpak package" is set, it should generate the flatpak
(not publish it obviously, yet it can be downloaded and installed
manually).
This will allow us to easily test MRs and allow people to test our code
before we merge it to the main branches.
Currently we run the job on a weekly schedule. If we keep a retention
period of 2 days, it means that people will not have access to a nightly
Windows installer 5 days out of 7, which is not useful.
Gitlab has a retention policy not to delete artifacts for last jobs, but
it apparently actually bases this check on being the last pipeline, not
being actually the last job of a given name. Since we have pipelines
running all the time, this retention policy just won't apply to our
installer job which will get deleted.
Cf. https://gitlab.com/gitlab-org/gitlab/-/issues/332142
- dri access needed (cf. commit de8be943 on our Flathub repo).
- GNOME runtime still only provides lcms 2.10 (even in its master build)
and we need version 2.12 to avoid some crashes (cf. commit ae60863e
from our flathub repo).
Trying to keep the differences to a minimum. There are still some, like
the extension point is absent from the nightly manifest, but I'm not
sure if it makes sense to have it there.
Also top "cleanup" list is different but we should probably take a
closer look at this. Maybe it's outdated on both sides anyway.
This reverts commit 61389adfa0.
I was initially hoping to debug why the GEGL `master` HEAD was
presumably failing to build (according to the reverted commit) but it
actually doesn't (as tested in a feature branch's CI) even though I
don't see any recent change looking like a build fix. So let's just do a
simple reverse. :-)
Without this, the flatpak build is just too long and Gitlab CI just
stops logging it. So we end up with a log saying the quite useless (at
the end):
> Job's log exceeded limit of 16777216 bytes.
> Job execution will continue but no more output will be collected.
We don't even reach babl/GEGL/GIMP builds, which are the most important.
With this little trick, I am redirecting output to a log file and simply
including said log into the artifacts, hence allowing to debug the full
build.
Argh! So it turns out that .publish_nightly template uses already an
only: key so we cannot use rules: (on the other hand I guess using only:
ourselves is alright and concatenate ours and the one in the template).
Fixes:
> jobs:flatpak-nightly config key may not be used with `rules`: only
This clashes with the usage of "rules:" and is even more useless as it
is about checking success of earlier stages (yet this job doesn't need
to wait for any other job).
Fixes CI error:
> jobs:flatpak config key may not be used with `rules`: when
To get a nightly flatpak, GNOME project offers a CI template[0] that can
be extended instead of having to define everything from scratch.
At the core is the "flatpak" job that tries to build the flatpak. If the
build finishes succesfully, the result should be available as a CI
artifact as a flatpak bundle. The app id is the same as on Flathub.
Another part is the "flatpak-nightly" job that publishes the flatpak if
the build succeeded. Without this job, the bundle stays only temporarily.
This job can and should only be run on the "master" branch. This jobs is
started only when the "flatpak" job finishes successfully.
Both jobs can be triggered only thorugh schedules[1]. To finish the
flatpak nightlies setup, a schedule needs to be set.
[0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
[1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
- Poppler 20.10.0 to 21.04.0
- poppler-data from 0.4.9 to 0.4.10
- OpenBLAS from 0.3.9 to 0.3.15
- libde265 from 1.0.7 to 1.0.8
- gexiv 0.12.1 to 0.12.2
Add patches and dependencies needed to build the development
version of GIMP. Also switches the in-tree manifest to using
the nightly branch of the GNOME SDK and meson
as the buildsystem.
The logs are just too long for gitlab and ends with:
> Job's log exceeded limit of 4194304 bytes.
This doesn't prevent the job from actually finish successfully. Yet the
day when we will have a build issue, we won't have a way to debug if it
happens close to the end of the installer creation. So let's redirect
both stderr and stdout to a log file and include it in the artifacts.
Actually most of the build code was already there but the initial meson
contributor commented the Legacy icon theme out. Not sure why.
I only had to fix a few icon names, which changed into Freedesktop
standard names after commit 1e5cf10585. Other than this, existing meson
build rules seem to work fine AFAICS.
Since we moved most of them to bin/, share/lua*/ and lib/lua/ files are
not necessary anymore (according to my tests so far at least). Let's not
include them.
Also exclude the lua DLL from the generic libraries. It is only for when
the lua option is set.
No need to have GIMP trying to run the Javascript goat-exercise at
startup. All it does is make annoying error message on console output.
We know it won't run because no interpreter is available. No need for
trying.
Unlike what I said in my previous commit, it still just takes too long
to build the installer, whether I move some of the substeps around or
whether I increase the max duration. So rather than increasing max
duration a lot more, let's just add an intermediate stage.
