So, I think I "found" the problem, will need to verify. But I wanted to
drop a few lines as reply here:
On Thu, Sep 23, 2021 at 07:30:25AM -0700, ian_bruce@mail.ru wrote:
> Does that not suggest that the problem is some peculiarity of the build
> environment, rather than any specific problem with the Inkscape code?
It does. But it doesn't mean that it shouldn't be investiaged properly.
FYI, here comes an *inkscape* bug as well, though it's not on amd64 like
the one you are concerned about.
https://gitlab.com/inkscape/inkscape/-/issues/2821
> Comparing the build logs for v1.0.2 and v1.1, one discovers that the
> reason that this is not a problem for v1.0.2 is that this specific test
> apparently does not exist in that version.
And is a very good thing they added the test. It is very much not a
reason to dismiss their reasults.
> Unable to init server: Could not connect: Connection refused
> Failed to get connection
> ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed
>
> ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_proxy_call: assertion 'DBUS_IS_G_PROXY (proxy)' failed
>
> ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_connection_register_g_object: assertion 'connection != NULL' failed
> end_font_face_cb: font face rule limited support.
> font-family : 'GeomTest';
> src : url(fonts/GeomTest-gzipped-SVG-glyphs.otf)
> end_font_face_cb: Added font: /<<PKGBUILDDIR>>/testfiles/rendering_tests/fonts/GeomTest-gzipped-SVG-glyphs.otf
> Background RRGGBBAA: ffffff00
> Area 0:0:110:40 exported to 110 x 40 pixels (96 dpi)
> Pixbuf::create_from_file: Unrecognized image file format
> ()
> Pixbuf::create_from_file: Unrecognized image file format
> ()
> Pixbuf::create_from_file: Unrecognized image file format
> ()
> 1589
> text-gzipped-svg-glyph FAILED
> text-gzipped-svg-glyph-large SKIPPED
>
>
> Why is a "connection" necessary to retrieve a font file from a "url"?
> And why should the "server" then "refuse" it? Is this not expecting
> entirely too much from a mere package-build server?
It's not. a server-client is simply one very common software structure,
and the way dbus works.
> How does D-Bus come into this mess?
what's wrong with dbus?
> Surely the resources provided by the
> filesystem should be all that is required for compilation and regression
> testing? This is not some kind of network client, or if it somehow is,
> that functionality should not be required to just build the distribution
> package.
nothing in there talks about *network*. But doesn't mean that different
pieces of software can't talk to each other locally through other means.
> Again, note that this particular test was not present in previous
> versions, which is why it never caused a problem before.
Again, so what?
Just for your information, what I figured after a while is that, in that
failing build the following weird things are happening, compared to my
local build:
* there is no dbus installed
But the build log has:
-- Found dbus-1, version 1.12.20
-- Found dbus-glib-1, version 0.112
so, mh... it install the library it wants alright, but not the dbus
service itself.
* there is no libfontconfig1-dev
But I need to check if something actually need it; at least at
configure step it doesn't seem to be checked.
* there is no librsvg2-(2|common|dev)
It should not need the dev library, but I suspect the librsvg2-common
is *the* one package that normally triggers the shared-mime-info dpkg
trigger, that is what I suspect is causing the test to fail.
* it's using graphicsmagic instead of imagemagick, which is probably the
cause of all of the above
This points to, at the very least, a bunch of missing build-dependencies
that are probably pulled in by imagemagick normally (but not by
graphicsmagic, which is set as Provides:imagegick but it's really way
too different…). And, perhaps, a lack of some checking at configure
time on the inkscape side.
I don't know why in experimental graphicsmagic is pulled in, but given
the different dependency resolver than unstable it's not quite
surprising.
I'll now try to reproduce it locally given these new hints and hopefully
come back with something working.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature