with 2.80.3 the problem with building mutter: ERROR: Dependency 'glib-2.0' tool variable 'glib_mkenums' contains erroneous value

With 2.80.3 there's the problem with building mutter:

Dependency glib-2.0 found: YES 2.80.3 (cached)
Program /usr/bin/glib-mkenums found: NO

mutter/cogl/cogl/meson.build:367:19: ERROR: Dependency 'glib-2.0' tool variable 'glib_mkenums' contains erroneous value: '/usr/bin/glib-mkenums'

This is a distributor issue -- please report it to your glib-2.0 provider.

With downgrading to 2.80.2 the build is successful.

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @toolybird, and @gromit

added scopebug statusconfirmed labels and removed statusunconfirmed label

assigned to @heftig and @fabiscafe and unassigned @freswa, @toolybird, and @gromit

I have tested this with the repo version of mutter and can confirm

glib-mkenums was split into glib2-devel by 02a3a726 so mutter needs to add glib2-devel to makedepends.

This should be because of !1 (merged)

In short: we can remove python-packaging and add glib2-devel. In long we may want to work out a todo as this could hit a unknown number of packages.

In long we may want to work out a todo as this could hit a unknown number of packages.

Looks to hit at least every package depending on glib2 that uses meson off a brief test of appstream, libadwaita, flatpak and malcontent.

also gtk4, nautilus, gnome-shell, gnome-control-center

...also cinnamon-control-center.

Thanks for explanation, makedepends works like a charm.

This was expected fallout. I sent an email to arch-dev-public:

Thanks to Fabian, as of 2.80.3-1, the development utilities requiring additional dependencies (python, python-packaging, libelf) have been split from glib2 into glib2-devel with proper depends.

You may need to add glib2-devel to the makedepends of your packages to get them to build again. At the same time, consider removing python or python-packaging from the makedepends if they were only added to run gdbus-codegen, glib-genmarshal or glib-mkenums.

closed

added resolutionnot-a-bug label

Hi, the same goes for glib-genmarshal:

$ pkg-config --variable=glib_genmarshal glib-2.0
/usr/bin/glib-genmarshal
$ ls -l /usr/bin/glib-genmarshal
ls: cannot access '/usr/bin/glib-genmarshal': No such file or directory

Any package checking for glib-genmarshal in glib-2.0.pc fails to build with glib2 2.80.3-2.

Ah ok, sorry, I should have read the above before posting: I need to install the -devel package ^^'

That's a bit weird though: shouldn't the pkg-config files be in the -devel package too? So that checking for glib2 fails in the first place, instead of succeeding with an incomplete glib2 package? That's how it's done e.g. on debian.

Keep in mind that this change was made, because before the build (while compiling) would have errored out, not finding python-packaging and the goal with glib-devel was to fail on dependency check already.

Debian splits it further. glib2-devel is maybe a bad name, as it's more of a glib2-python-bits. If we move the pkg-config, we'd also have to move other parts for that reason - file /usr/lib/pkgconfig/glib-2.0.pc (in glib2) holds

pkg-config --variable=glib_genmarshal glib-2.0 (glib2-devel)
pkg-config --variable=glib_mkenums glib-2.0 (glib2-devel)
pkg-config --variable=glib_valgrind_suppressions glib-2.0 (glib2)
pkg-config --variable=gobject_query glib-2.0 (glib2)

So it would probably mean to go on and split them fully into a real "glib2-runtime" and "glib2-buildtime" package (not real naming, just for clarification) and next to that also touch lots (probably all the GUI apps) of packages that depend on them.

mentioned in merge request libgexiv2!1 (closed)

mentioned in issue cinnamon-control-center#2 (closed)

mentioned in issue gtkglext#1 (closed)

mentioned in issue libfprint#1 (closed)