Bug#994741: regression tests: skipped vs failed

2021-09-26 Thread Mattia Rizzolo 
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: 
> /<>/testfiles/rendering_tests/fonts/GeomTest-gzipped-SVG-glyphs.otf
> Background RRGGBBAA: ff00
> 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

Bug#994741: regression tests: skipped vs failed

2021-09-23 Thread ian_bruce 
On Tue, 21 Sep 2021 19:03:07 +0200
Mattia Rizzolo  wrote:

> concerning the ftbfs of 1.1. I know of it of course. Just that I've
> been busy over the past month. I'm as weirded out by that test failure
> as you, especially since I couldn't reproduce it anywhere else.

Does that not suggest that the problem is some peculiarity of the build
environment, rather than any specific problem with the Inkscape code?

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.

https://buildd.debian.org/status/fetch.php?pkg=inkscape=amd64=1.0.2-4=1618427913=0

https://buildd.debian.org/status/fetch.php?pkg=inkscape=amd64=1.1-1=1629559190=0

But what is this?


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: 
/<>/testfiles/rendering_tests/fonts/GeomTest-gzipped-SVG-glyphs.otf
Background RRGGBBAA: ff00
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?

How does D-Bus come into this mess? 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.

The "src: url(fonts/GeomTest-gzipped-SVG-glyphs.otf)" part actually does
come from the regression test, but otherwise that tiny file provides no
hint of what is going on.

https://sources.debian.org/src/inkscape/1.1-1/testfiles/rendering_tests/text-gzipped-svg-glyph.svg/

But again: why does a font file need to be retrieved from a "url", in
the context of a regression test?

> But no, I'm not going to ignore a test failure just because it's
> skipped in other architectures for different reasons: I'll need more
> convincing reasons.

Do we know that it's skipped in other architectures for different
reasons? Maybe it's skipped in other architectures for the same reason:
it breaks things.

Again, note that this particular test was not present in previous
versions, which is why it never caused a problem before.

Bug#994741: regression tests: skipped vs failed

2021-09-22 Thread Mattia Rizzolo 
On Wed, Sep 22, 2021 at 03:31:36PM +0300, Andrius Merkys wrote:
> On 2021-09-21 20:03, Mattia Rizzolo wrote:
> > Then, concerning the ftbfs of 1.1.  I know of it of course.  Just that
> > I've been busy over the past month.  I'm as weirded out by that test
> > failure as you, especially since I couldn't reproduce it anywhere else.
> > But no, I'm not going to ignore a test failure just because it's skipped
> > in other architectures for different reasons: I'll need more convincing
> > reasons.
> 
> Thanks Mattia for letting us know you are working on it. Have you tried
> building inkscape with network disabled?

?? of course.  that's basically standard building env for me since I
use pbuilder.  by contrast, know that the debian buildds do *not*
disable the network.

Anyway, I'm first going to upload 1.1.1 to experimental today and see
how that goes, otherwise I'm going to start debugging more.

There is also another failure I need to take care of, as building in
ubuntu exposed an unaligned memory access that causes bus errors in
armhf (when run in a arm64 cpu).

-- 
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

Bug#994741: regression tests: skipped vs failed

2021-09-22 Thread Andrius Merkys 
On 2021-09-21 20:03, Mattia Rizzolo wrote:
> Then, concerning the ftbfs of 1.1.  I know of it of course.  Just that
> I've been busy over the past month.  I'm as weirded out by that test
> failure as you, especially since I couldn't reproduce it anywhere else.
> But no, I'm not going to ignore a test failure just because it's skipped
> in other architectures for different reasons: I'll need more convincing
> reasons.

Thanks Mattia for letting us know you are working on it. Have you tried
building inkscape with network disabled?

Andrius

Bug#994741: regression tests: skipped vs failed

2021-09-21 Thread ian_bruce 
On Tue, 21 Sep 2021 18:57:41 +0300
Andrius Merkys  wrote:

> I cannot reproduce the failure myself on amd64. I tried building on a
> machine without a display, and yet the test succeeds. I will try a
> porterbox next.

If the test succeeds, is the overall build then successful? Is that the
cause of the amd64 build failure on the autobuild systems?

If so, then cannot this problem be temporarily fixed by ignoring the
test result on amd64, also? If it's acceptable to not run the test at
all on 32-bit architectures, and to ignore the result on 64-bit BE
architectures, then it cannot really be that important for 64-bit LE
architectures.

By temporarily ignoring the test result, the immediate problem can be
solved: Inkscape v1.1 is not currently available for amd64 and other
64-bit LE systems. Having temporarily disabled this test, the actual
cause of the failure can then be investigated at anybody's convenience,
without further delaying the availability of the Inkscape distribution
package.

Inkscape v1.0.2 is REALLY buggy. This needs to be fixed soon.

Bug#994741: regression tests: skipped vs failed

2021-09-21 Thread ian_bruce 
On Tue, 21 Sep 2021 12:33:07 +0300
Andrius Merkys  wrote:

> if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
>  set(RENDERING_TESTS_64bit
>  # .otf font with compressed SVG glyphs
>  # (test not stable on 32bit Windows)
>  text-gzipped-svg-glyph
>  )
> endif()
> 
> Thus this test is only run on 64bit architectures.

Thanks for pointing that out.

It appears that my assumption that this regression test failure was the
cause of the overall build failure on amd64, was incorrect. According to
the build logs, this test also fails on ppc64 and sparc64, and yet the
builds for those architectures have apparently succeeded.

This appears to be the critical failure on amd64:


cd /<>/obj-x86_64-linux-gnu && /usr/bin/ctest 
--force-new-ctest-process
ninja: build stopped: subcommand failed.
dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 
MESON_TESTTHREADS=1 ninja test returned exit code 1
make[1]: *** [debian/rules:21: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


Build finished at 2021-08-21T15:19:37Z


Since the regression test failure is apparently an unrelated problem,
how should that be interpreted?

Bug#994741: regression tests: skipped vs failed

2021-09-21 Thread Mattia Rizzolo 
Come on, inkscape 1.0 is not _that_ buggy.  It has been around for a whole
year (with a few fixing releases in-between), and it's the version present
in Debian 11.  If it really has grave bugs (I really mean grave), then
those should be filed separately, and I should work on getting them fixed
as patches on top of 1.0.2.

Then, concerning the ftbfs of 1.1.  I know of it of course.  Just that I've
been busy over the past month.  I'm as weirded out by that test failure as
you, especially since I couldn't reproduce it anywhere else.
But no, I'm not going to ignore a test failure just because it's skipped in
other architectures for different reasons: I'll need more convincing
reasons.

If you'd like other bugs in inkscape 1.1: opposed to 1.0.2 it's doing some
kind of unaligned memory access somewhere (yet to debug), which makes it
crash on armhf when run on arm64 hardware.  I was basically forced to
ignore that test failure on Ubuntu and that annoyed me enough, I really
don't want to ignore tests just because it's convenient for somebody.


On Tue, 21 Sep 2021, 6:51 pm ,  wrote:

> On Tue, 21 Sep 2021 18:57:41 +0300
> Andrius Merkys  wrote:
>
> > I cannot reproduce the failure myself on amd64. I tried building on a
> > machine without a display, and yet the test succeeds. I will try a
> > porterbox next.
>
> If the test succeeds, is the overall build then successful? Is that the
> cause of the amd64 build failure on the autobuild systems?
>
> If so, then cannot this problem be temporarily fixed by ignoring the
> test result on amd64, also? If it's acceptable to not run the test at
> all on 32-bit architectures, and to ignore the result on 64-bit BE
> architectures, then it cannot really be that important for 64-bit LE
> architectures.
>
> By temporarily ignoring the test result, the immediate problem can be
> solved: Inkscape v1.1 is not currently available for amd64 and other
> 64-bit LE systems. Having temporarily disabled this test, the actual
> cause of the failure can then be investigated at anybody's convenience,
> without further delaying the availability of the Inkscape distribution
> package.
>
> Inkscape v1.0.2 is REALLY buggy. This needs to be fixed soon.
>
>

Bug#994741: regression tests: skipped vs failed

2021-09-21 Thread Andrius Merkys 

On 2021-09-21 18:03, ian_br...@mail.ru wrote:

It appears that my assumption that this regression test failure was the
cause of the overall build failure on amd64, was incorrect. According to
the build logs, this test also fails on ppc64 and sparc64, and yet the
builds for those architectures have apparently succeeded.


Actually, build logs show failure of this test case both on amd64 and 
ppc64, to name a few, but on ppc64 this failure is intentionally ignored 
[1]:


ifeq ($(DEB_HOST_ARCH_ENDIAN),little)
dh_auto_test -a --no-parallel
else
	# the testsuite fails on BE. 
https://gitlab.com/inkscape/inkscape/-/issues/1365

-dh_auto_test -a --no-parallel
endif

(ppc64 is BE = Big Endian)

However, I cannot reproduce the failure myself on amd64. I tried 
building on a machine without a display, and yet the test succeeds. I 
will try a porterbox next.


[1] https://sources.debian.org/src/inkscape/1.1-1/debian/rules/

Best,
Andrius

Bug#994741: regression tests: skipped vs failed

2021-09-21 Thread ian_bruce 
The Inkscape v1.1 build fails on amd64, because of a regression test
called "text-gzipped-svg-glyph", which can be found here:

https://sources.debian.org/src/inkscape/1.1-1/testfiles/rendering_tests/text-gzipped-svg-glyph.svg/

from the build log:


Start 301: render_text-glyphs-vertical
301/303 Test #301: render_text-glyphs-vertical    Passed2.25 sec
Start 302: render_test-powerstroke-join
302/303 Test #302: render_test-powerstroke-join ...   Passed0.55 sec
Start 303: render_text-gzipped-svg-glyph
303/303 Test #303: render_text-gzipped-svg-glyph ..***Failed0.26 sec

text-gzipped-svg-glyph FAILED
text-gzipped-svg-glyph-large SKIPPED

99% tests passed, 1 tests failed out of 303


On i386, the build succeeds, apparently because this test does not run
at all:


Start 301: render_text-glyphs-vertical
301/302 Test #301: render_text-glyphs-vertical    Passed2.65 sec
Start 302: render_test-powerstroke-join
302/302 Test #302: render_test-powerstroke-join ...   Passed0.94 sec

100% tests passed, 0 tests failed out of 302


If this test is not required on i386 (and presumably other architectures
where the build succeeds), then it shouldn't be required on amd64, either.

This discrepancy needs to be investigated.

Bug#994741: regression tests: skipped vs failed

2021-09-21 Thread Andrius Merkys 

Hi Ian,

On 2021-09-21 09:52, ian_br...@mail.ru wrote:

On i386, the build succeeds, apparently because this test does not run
at all:


 Start 301: render_text-glyphs-vertical
 301/302 Test #301: render_text-glyphs-vertical    Passed2.65 
sec
 Start 302: render_test-powerstroke-join
 302/302 Test #302: render_test-powerstroke-join ...   Passed0.94 
sec

 100% tests passed, 0 tests failed out of 302


If this test is not required on i386 (and presumably other architectures
where the build succeeds), then it shouldn't be required on amd64, either.


From [1]:

if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
set(RENDERING_TESTS_64bit
# .otf font with compressed SVG glyphs
# (test not stable on 32bit Windows)
text-gzipped-svg-glyph
)
endif()

Thus this test is only run on 64bit architectures.

[1] 
https://sources.debian.org/src/inkscape/1.1-1/testfiles/rendering_tests/CMakeLists.txt/


Andrius