Bug#1102099: game-data-packager: FTBFS: inkscape SIGABRT after throwing an instance of 'Gio::DBus::Error'

[Simon McVittie]

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