Bug#976932: gnome-photos: FTBFS on machines with more than 128 cores

Simon McVittie smcv at debian.org
Wed Dec 9 09:59:00 GMT 2020


Control: retitle -1 gnome-photos: FTBFS on machines with more than 128 cores

On Wed, 09 Dec 2020 at 09:35:05 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
>
> > 	cd obj-powerpc64le-linux-gnu && LC_ALL=C.UTF-8 ninja -j160 -v

Is this a 160-CPU machine?! (Or maybe 80- or 40-CPU with hyperthreading?)

> > Bail out! GLib-GObject-FATAL-WARNING: value "80" of type 'gint' is invalid or out of range for property 'threads' of type 'gint'

80 does seem like a lot of threads, although it also seems weird to have an
arbitrary limit.

libgegl has a GeglConfig singleton object with a "threads" property, whose
maximum value is an arbitrary constant GEGL_MAX_THREADS.

gnome-photos sets "threads" to half the number of CPU cores available,
which is entirely reasonable for desktop-class hardware, but is not going
to work on something massively-parallel.

Can you test-build a fix on similar hardware? Oddly enough I don't have a
machine with this many cores conveniently available :-)

If we have to upload a fix untested, then I'll have to do the simplest
possible thing and hope it works, rather than anything more clever. The
simple solution is to clamp the number of CPUs to the range
[1, GEGL_MAX_THREADS], and hope that future versions of gegl don't change
GEGL_MAX_THREADS. The more correct solution (which I would not be confident
about uploading untested) would be to fetch the GParamSpec for the property
and clamp to its allowed range, which would be robust against libgegl
changing the number of threads it allows.

    smcv



More information about the pkg-gnome-maintainers mailing list