Control: retitle -1 game-data-packager: FTBFS: inkscape SIGABRT after throwing
an instance of 'Gio::DBus::Error'
Control: tags -1 = confirmed
"ninja: build stopped: subcommand failed" is a very generic error
message to be quoting (it's hardly better than "something is wrong").
The problem here appears to be that Inkscape is failing to run
non-interactively, with these warnings that do not appear to be fatal
(they appear in several Inkscape runs, some of which seem to have been
successful):
** (inkscape:52523): WARNING **: 14:51:09.674: Failed to wrap object of
type 'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call
a library init() function.
** (inkscape:52523): WARNING **: 14:51:09.755: Failed to wrap object of
type 'GtkRecentManager'. Hint: this error is commonly caused by failing to call
a library init() function.
and then this error message that appears to be the fatal one:
terminate called after throwing an instance of 'Gio::DBus::Error'
Aborted
On Sat, 05 Apr 2025 at 03:21:47 +0200, Santiago Vila wrote:
- The failure happens randomly. Never on AWS instances with 1 CPU,
and 85% of the time on instances with 2 CPUs.
This is (fully? mostly?) reproducible in the environment where I
successfully built the v84 release, so presumably it's related to the
transition to Inkscape 1.4 that happened since then.
It's interesting that it reliably succeeds on a single-CPU system.
Might this indicate a thread-safety problem inside Inkscape, which is
accidentally avoided by being unable to run more than one thread in
parallel?
You mentioned on #1102086 that you tried --max-parallel=1 and it didn't
help. A build log with only one parallel `ninja` job, but with more than
one vCPU, might help to clarify what is going on by avoiding the output of
more than one instance of Inkscape getting interleaved.
- I first tried to override dh_auto_test (see #1102086), but then
realized the failure happens in dh_auto_build (!). Are you running
the tests in dh_auto_build?
No, this is not a test, it's a build step that cannot be skipped because
it outputs part of the content of the .deb. I know it might sometimes
seem like the only reason why a package ever fails to build is a test
failure, but this particular build failure is genuinely the build, not
the tests.
In this package we ship icons' "source code" as a SVG file containing
several sizes and shapes of icon as different layers, and we generate
the icons that are actually seen by end users from that "source code" by
exporting the individual layers programmatically. We also use Inkscape
to convert some more elaborate icons from SVG to PNG - some of them
contain SVG filters that are implemented in Inkscape, but not
implemented in librsvg, which is what e.g. GNOME uses to render SVG
icons in end users' GUI menus.
- The attached patch fixes the issue in my environment. The dbus thing
was added in commit [d471d0d1b] from 2017 with the following commit message:
Build-depend on dbus and wrap dh_auto_build in dbus-run-session
So that Inkscape stops warning about inability to access the session bus
but naturally a warning will always be better than not being able to build the
package at all.
Until recently, what we did with Inkscape was working. I think this is
probably an Inkscape regression - although I can see that running
Inkscape non-interactively and without providing a GUI environment is
not its usual use-case.
I tried the equivalent of the patch you proposed, and it works in an
isolated build environment (sbuild in a VM), but the build is still
failing for me if I build in a non-isolated environment (`debuild`), so
I think this needs further investigation. To make this fully reliable, I
think it might be necessary to unset XDG_RUNTIME_DIR, or unset
DBUS_SESSION_BUS_ADDRESS, or something like that.
Running Inkscape without a D-Bus session bus is probably an adequate
workaround to get the package buildable again in trixie, but the concern
I have about this in the longer term is that the presence of the
warnings seems like it indicates we're doing something that is not
really meant to be supported by Inkscape, and it seems equally likely
that at some point in the future, it will require a D-Bus session bus
and fail to run in its absence. I don't really want the g-d-p build to
have to switch between "has session bus" and "no session bus"
periodically, especially if the need to do so is presented as a demand
that I drop everything and make a particular change my top priority. So
I'd prefer to find something that will get it running in as "normal" an
environment as possible, with a minimum of warnings.
I'll try to look into this later this weekend. One angle that I want to
look at is whether we can tell Inkscape to stop trying to use various
desktop integration features when we run it non-interactively, for
example with GIO_USE_VFS=local, GVFS_DISABLE_FUSE=1,
GTK_DEBUG=no-portals or similar.
smcv
