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_br...@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 `-
signature.asc
Description: PGP signature