On Thu, 09 Jul 2020 at 17:42:35 +0200, Alberto Garcia wrote:
> the mipsel build of webkit2gtk is failing because of gtkdoc-scangobj:
...
> This is only happening on the mipsel builds, and I cannot reproduce
> the problem in eller.debian.org. Adrian Bunk says it fails on the
> Loongson buildds but succeeds on the others.
gtkdoc-scangobj works by compiling a small C program that it uses
to introspect GObject types. According to the build log, that program
exited with status -6 (which is probably Python's representation of it
being killed by signal 6, which is SIGABRT?) with no output.
The Loongson 3A "is known for having an FPU bug" (see #959845) -
perhaps that could be related, if webkit2gtk contains GObject types
with G_TYPE_FLOAT or G_TYPE_DOUBLE values? I'm not sure what individual
packages can do about this, or why we are using known-faulty CPUs on
official buildds.
This is likely to be "won't fix" (or rather "can't fix") for
gtk-doc-tools, unless someone with a suitably faulty FPU can reproduce
the bug and figure out what is going on.
Workaround: instead of
----8<----
ifneq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF
else
EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON
endif
----8<----
webkit2gtk could use something like
----8<----
binaries := $(shell dh_listpackages)
ifneq (,$(filter %-doc,$(binaries)))
EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF
else
EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON
endif
----8<----
together with
----8<----
Package: libwebkit2gtk-4.0-doc
Build-Profiles: <!nodoc>
----8<----
so that you don't run gtk-doc in architecture-specific builds, only in
builds that include Architecture: all. That would also be faster, and you
might be able to move gtk-doc-tools from Build-Depends to
Build-Depends-Indep (usually you can for Meson, but not for Autotools
because it's needed at dh_autoreconf time; I don't know which category
CMake falls into).
smcv
