make droute-test make[2]: Entering directory `/var/tmp/portage/app-accessibility/at-spi2-atk-2.6.2/work/at-spi2-atk-2.6.2/droute' x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I.. -Wall -O2 -pipe -march=native -Werror-implicit-function-declaration -c -o droute_test-droute-test.o `test -f 'droute-test.c' || echo './'`droute-test.c /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I.. -Wall -O2 -pipe -march=native -Werror-implicit-function-declaration ../dbind/libdbind.la libdroute.la -ldbus-1 -lglib-2.0 -latspi -ldbus-1 -lglib-2.0 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -o droute-test droute_test-droute-test.o libtool: link: x86_64-pc-linux-gnu-gcc -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I.. -Wall -O2 -pipe -march=native -Werror-implicit-function-declaration -Wl,-O1 -Wl,--hash-style=gnu -o droute-test droute_test-droute-test.o ../dbind/.libs/libdbind.a ./.libs/libdroute.a -latspi -ldbus-1 -lglib-2.0 -Wl,--as-needed make[2]: Leaving directory `/var/tmp/portage/app-accessibility/at-spi2-atk-2.6.2/work/at-spi2-atk-2.6.2/droute' make check-TESTS make[2]: Entering directory `/var/tmp/portage/app-accessibility/at-spi2-atk-2.6.2/work/at-spi2-atk-2.6.2/droute' /bin/sh: line 5: 7159 Segmentation fault (core dumped) ${dir}$tst FAIL: droute-test =============================================================== 1 of 1 test failed Please report to accessibility-atspi@lists.linux-foundation.org =============================================================== Backtrace of the SIGSEGV: #0 0x00007ffff7988b63 in dbus_connection_get_data () from /usr/lib64/libdbus-1.so.3 #1 0x00007ffff7bc261b in atspi_dbus_connection_setup_with_g_main () from /usr/lib64/libatspi.so.0 #2 0x00000000004027f5 in main () And indeed tests run fine as my normal user (the one who ones the DBUS session).
looks like the test-suite needs to run in a dbus session. Please take a bit more time to write your report next time, it is hard to understand what is the problem here.
I'm seeing the same test failure with at-spi2-atk 2.8.1
(In reply to Hans de Graaff from comment #2) > I'm seeing the same test failure with at-spi2-atk 2.8.1 Me too, on ia64. Émeric
(In reply to Émeric Maschino from comment #3) > (In reply to Hans de Graaff from comment #2) > > I'm seeing the same test failure with at-spi2-atk 2.8.1 > > Me too, on ia64. > > Émeric Same failure on amd64 for at-spi2-atk-2.10.2
(In reply to Paolo Pedroni from comment #4) > Same failure on amd64 for at-spi2-atk-2.10.2 Me too on ia64 with thisnewer version. Émeric
Same failure in at-spi2-atk-2.12.1 on amd64 I can confirm that if I manually run tests as root or as a normal user, they succeed. Is there any way we can make the tests run in a dbus session? Or should this be reported upstream?
What does occur when running "unset DISPLAY" before emake check? If still failing try "dbus-launch emake check"
(In reply to Pacho Ramos from comment #7) > What does occur when running "unset DISPLAY" before emake check? If I put a line with "unset DISPLAY" before the "Xemake check" one in the ebuild, tests fail in the same way. If, at the command line in the /var/tmp/portage/app-accessibility/at-spi2-atk-2.12.1/work/at-spi2-atk-2.12.1 directory, I type: $ unset DISPLAY $ make check tests succeed (but they succeed even if I don't uset DISPLAY) > If still > failing try "dbus-launch emake check" Changing the ebuild line to "dbus-launch Xemake check" yield a "Couldn't exec Xemake: No such file or directory" error, no tests are run and the ebuild goes on installing files At the command line tests succeed anyway...
I don't understand why it does not fail for me from 2.10 to 2.14 at least. Could you guys check with 2.14, just in case and provide a full build.log and emerge --info ?
Created attachment 392600 [details] build.log
Created attachment 392602 [details] emerge --info
I'm using stable Gnome so I opted for 2.12.1. build.log and emerge --info attached.
I'm completely in the dark here, all looks fine except for the segfault. Could you attach the test-suite.log file ? Also paste the output of: $ emerge -pv app-accessibility/at-spi2-core sys-apps/dbus Can you try rebuild those three packages with a march that is set for your specific CPU (like core2 is nothing better comes up). I have seen strange things with native. This is unlikely to be a problem for amd64 arches but who knows. Finally, I see some nvidia bits in your emerge --info, are your running nvidia's blob ? It is known to trigger strange problems like breaking Xorg's input in the past.
Also, just in case, could check/unset DBUS_SESSION_BUS_ADDRESS in your env before building ?
(In reply to Gilles Dartiguelongue from comment #14) > Also, just in case, could check/unset DBUS_SESSION_BUS_ADDRESS in your env > before building ? It was set, and unsetting it resulted in a successful test run.
+ 29 Dec 2014; Gilles Dartiguelongue <eva@gentoo.org> + -at-spi2-atk-2.10.2.ebuild, at-spi2-atk-2.12.1.ebuild, + at-spi2-atk-2.12.1-r1.ebuild, at-spi2-atk-2.14.1.ebuild: + Unset DBUS_SESSION_BUS_ADDRESS to run unittests, bug #449010. + We really need to do something about all these environment variables. Thanks for reporting.
(In reply to Gilles Dartiguelongue from comment #16) > + 29 Dec 2014; Gilles Dartiguelongue <eva@gentoo.org> > + -at-spi2-atk-2.10.2.ebuild, at-spi2-atk-2.12.1.ebuild, > + at-spi2-atk-2.12.1-r1.ebuild, at-spi2-atk-2.14.1.ebuild: > + Unset DBUS_SESSION_BUS_ADDRESS to run unittests, bug #449010. > + > > We really need to do something about all these environment variables. Thanks > for reporting. I fully agree, maybe we could take a look on bug 515196 until bug 499288 Personally I am all for doing it at PM level (bug 499288), but looks like the bug is currently completely stalled and taking care it would require a new EAPI and all the process and discussions ... :S
