Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Le 17/09/2019 à 10:00, Samuel Thibault a écrit : > xvfb-run -s -noreset -a dbus-run-session -- dh_auto_test Trying manually on the canonistack builder I was using for debugging that seems to fix it, I would get the error in most tries before and with the extra options it's always successful
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le mar. 17 sept. 2019 09:51:39 +0200, a ecrit: > I retried to see how it goes and it failed again > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/s390x/a/at-spi2-atk/20190916_143737_eebd4@/log.gz Thanks for retrying it. It seems to be failing just like you get: ** (at-spi2-registryd:5979): WARNING **: 14:37:14.876: AT-SPI: Cannot open default display i.e. the problem is at the X11 level. I'm wondering... Could try to use this in debian/rules: xvfb-run -s -noreset -a dbus-run-session -- dh_auto_test Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
I've synced that new version to Ubuntu, the first try of autopkgtest successed https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/s390x/a/at-spi2-atk/20190913_192348_d1d08@/log.gz I retried to see how it goes and it failed again https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/s390x/a/at-spi2-atk/20190916_143737_eebd4@/log.gz So it's not failing every time, hopefully the logs are useful Le 13/09/2019 à 11:57, Samuel Thibault a écrit : > I have uploaded a 2.34.0-2 version which sends the dbus-daemon output to > stdout, to get the warnings from dbus-daemon (and possibly > at-spi2-registryd) to check whether the autopkgtest has the same issue > as when you run by hand. > > Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
I have uploaded a 2.34.0-2 version which sends the dbus-daemon output to stdout, to get the warnings from dbus-daemon (and possibly at-spi2-registryd) to check whether the autopkgtest has the same issue as when you run by hand. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le ven. 13 sept. 2019 11:22:00 +0200, a ecrit: > Le 13/09/2019 à 11:02, Samuel Thibault a écrit : > > Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a > > script which dumps the output of ps axuf and printenv to a file, so we > > get to be sure in which situation it gets started. (posting it again with lines unwrapped for readability). So this does have DISPLAY and XAUTHORITY set. I wonder how XOpenDisplay(NULL) could fail, then. If you put an xlogo call in that /usr/lib/at-spi2-core/at-spi2-registryd script, does it succeed to connect to the Xvfb? Samuel Le 13/09/2019 à 11:02, Samuel Thibault a écrit : > Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a > script which dumps the output of ps axuf and printenv to a file, so we > get to be sure in which situation it gets started. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ? S 08:04 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [rcu_gp] root 4 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [rcu_par_gp] root 6 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kworker/0:0H-kblockd] root 8 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [mm_percpu_wq] root 9 0.0 0.0 0 0 ? S 08:04 0:00 \_ [ksoftirqd/0] root 10 0.0 0.0 0 0 ? I 08:04 0:00 \_ [rcu_sched] root 11 0.0 0.0 0 0 ? S 08:04 0:00 \_ [migration/0] root 12 0.0 0.0 0 0 ? S 08:04 0:00 \_ [cpuhp/0] root 13 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kdevtmpfs] root 14 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [netns] root 15 0.0 0.0 0 0 ? S 08:04 0:00 \_ [rcu_tasks_kthre] root 16 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kauditd] root 17 0.0 0.0 0 0 ? S 08:04 0:00 \_ [khungtaskd] root 18 0.0 0.0 0 0 ? S 08:04 0:00 \_ [oom_reaper] root 19 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [writeback] root 20 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kcompactd0] root 21 0.0 0.0 0 0 ? SN 08:04 0:00 \_ [ksmd] root 107 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kintegrityd] root 108 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kblockd] root 109 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [blkcg_punt_bio] root 110 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [tpm_dev_wq] root 111 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [md] root 112 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [cio] root 113 0.0 0.0 0 0 ? S 08:04 0:00 \_ [watchdogd] root 115 0.0 0.0 0 0 ? S 08:04 0:00 \_ [cmmthread] root 116 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kswapd0] root 117 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kworker/u3:0] root 118 0.0 0.0 0 0 ? S 08:04 0:00 \_ [ecryptfs-kthrea] root 121 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kthrotld] root 122 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kmcheck] root 123 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [ipv6_addrconf] root 134 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kstrp] root 185 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kworker/0:1H-kblockd] root 294 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [raid5wq] root 337 0.0 0.0 0 0 ? S 08:04 0:00 \_ [jbd2/vda1-8] root 338 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [ext4-rsv-conver] root 456 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [vfio-ccw] root 486 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kaluad] root 487 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kmpath_rdacd] root 488 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kmpathd] root 489 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kmpath_handlerd] root 921 0.0 0.0 0 0 ? S< 08:05 0:00 \_ [loop0] root 1058 0.0 0.0 0 0 ? S< 08:05 0:00 \_ [loop1] root 8010 0.0 0.0 0 0 ? I 08:19 0:00 \_ [kworker/0:0-events] root 11210 0.0 0.0 0 0 ? I 08:52 0:00 \_ [kworker/u2:0-events_power_efficient] root 12168 0.0 0.0 0 0 ? I 09:05 0:00 \_ [kworker/0:3-events] root 12294 0.0 0.0 0 0 ? I 09:10 0:00 \_ [kworker/u2:2-events_power_efficient] root 12515 0.0 0.0 0 0 ? I 09:19 0:00
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Le 13/09/2019 à 11:02, Samuel Thibault a écrit : > Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a > script which dumps the output of ps axuf and printenv to a file, so we > get to be sure in which situation it gets started. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ? S 08:04 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [rcu_gp] root 4 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [rcu_par_gp] root 6 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kworker/0:0H-kblockd] root 8 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [mm_percpu_wq] root 9 0.0 0.0 0 0 ? S 08:04 0:00 \_ [ksoftirqd/0] root 10 0.0 0.0 0 0 ? I 08:04 0:00 \_ [rcu_sched] root 11 0.0 0.0 0 0 ? S 08:04 0:00 \_ [migration/0] root 12 0.0 0.0 0 0 ? S 08:04 0:00 \_ [cpuhp/0] root 13 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kdevtmpfs] root 14 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [netns] root 15 0.0 0.0 0 0 ? S 08:04 0:00 \_ [rcu_tasks_kthre] root 16 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kauditd] root 17 0.0 0.0 0 0 ? S 08:04 0:00 \_ [khungtaskd] root 18 0.0 0.0 0 0 ? S 08:04 0:00 \_ [oom_reaper] root 19 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [writeback] root 20 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kcompactd0] root 21 0.0 0.0 0 0 ? SN 08:04 0:00 \_ [ksmd] root 107 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kintegrityd] root 108 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kblockd] root 109 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [blkcg_punt_bio] root 110 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [tpm_dev_wq] root 111 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [md] root 112 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [cio] root 113 0.0 0.0 0 0 ? S 08:04 0:00 \_ [watchdogd] root 115 0.0 0.0 0 0 ? S 08:04 0:00 \_ [cmmthread] root 116 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kswapd0] root 117 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kworker/u3:0] root 118 0.0 0.0 0 0 ? S 08:04 0:00 \_ [ecryptfs-kthrea] root 121 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kthrotld] root 122 0.0 0.0 0 0 ? S 08:04 0:00 \_ [kmcheck] root 123 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [ipv6_addrconf] root 134 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kstrp] root 185 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kworker/0:1H-kblockd] root 294 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [raid5wq] root 337 0.0 0.0 0 0 ? S 08:04 0:00 \_ [jbd2/vda1-8] root 338 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [ext4-rsv-conver] root 456 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [vfio-ccw] root 486 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kaluad] root 487 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kmpath_rdacd] root 488 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kmpathd] root 489 0.0 0.0 0 0 ? I< 08:04 0:00 \_ [kmpath_handlerd] root 921 0.0 0.0 0 0 ? S< 08:05 0:00 \_ [loop0] root 1058 0.0 0.0 0 0 ? S< 08:05 0:00 \_ [loop1] root 8010 0.0 0.0 0 0 ? I 08:19 0:00 \_ [kworker/0:0-events] root 11210 0.0 0.0 0 0 ? I 08:52 0:00 \_ [kworker/u2:0-events_power_efficient] root 12168 0.0 0.0 0 0 ? I 09:05 0:00 \_ [kworker/0:3-events] root 12294 0.0 0.0 0 0 ? I 09:10 0:00 \_ [kworker/u2:2-events_power_efficient] root 12515 0.0 0.0 0 0 ? I 09:19 0:00 \_ [kworker/u2:1-events_unbound] root 12580 0.0 0.0 0 0 ? I 09:20 0:00 \_ [kworker/0:1-events] root 12581 0.0 0.0 0 0 ? I 09:20 0:00 \_ [kworker/0:2-events] root 1 0.0 1.7 106964 8560 ? Ss 08:04 0:02 /sbin/init root 424 0.0 1.5 47824 7756 ? S
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le ven. 13 sept. 2019 10:54:07 +0200, a ecrit: > Le 13/09/2019 à 10:44, Samuel Thibault a écrit : > > Just thinking: is that dbus-daemon which is the parent of > > at-spi2-registryd (and thus gives it its environment variables)? I > > vaguely remember "systemd --user" taking over that role, but possibly it > > misses passing the DISPLAY variable along?... > > Yes xauth is installed and e.g xlogo works. Ok, so that must be something with the dbus activation. Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a script which dumps the output of ps axuf and printenv to a file, so we get to be sure in which situation it gets started. > If it was a problem with the way dbus is set it would probably not be > arch specific? Normally it wouldn't. "Normally". > I've tried to ssh -X (which success to start xlogo locally over ssh) and > > $ dbus-run-session ./atk-test > # random seed: R02Se0d960b12c7b7375a48b46c8448ee3fb > 1..158 > # Start of Accessible tests > run_app: > /home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml > child_pid 11208 > Bail out! dbind-FATAL-ERROR: AT-SPI: Couldn't connect to accessibility > bus. Is at-spi-bus-launcher running? Unfortunately at-spi can't work remotely like this, it has to be a local X session, ssh X forwarding is not enough. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Le 13/09/2019 à 10:44, Samuel Thibault a écrit : > Just thinking: is that dbus-daemon which is the parent of > at-spi2-registryd (and thus gives it its environment variables)? I > vaguely remember "systemd --user" taking over that role, but possibly it > misses passing the DISPLAY variable along?... Yes xauth is installed and e.g xlogo works. If it was a problem with the way dbus is set it would probably not be arch specific? I've tried to ssh -X (which success to start xlogo locally over ssh) and $ dbus-run-session ./atk-test # random seed: R02Se0d960b12c7b7375a48b46c8448ee3fb 1..158 # Start of Accessible tests run_app: /home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml child_pid 11208 Bail out! dbind-FATAL-ERROR: AT-SPI: Couldn't connect to accessibility bus. Is at-spi-bus-launcher running? (atk-test:11207): dbind-ERROR **: 08:52:43.200: AT-SPI: Couldn't connect to accessibility bus. Is at-spi-bus-launcher running? I wonder if that's at-spi-bus-launcher error out of something? (but it doesn't hit an error when started by hand)
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Samuel Thibault, le ven. 13 sept. 2019 10:37:23 +0200, a ecrit: > Sebastien Bacher, le ven. 13 sept. 2019 10:30:10 +0200, a ecrit: > > dbus-daemon[10074]: [session uid=1000 pid=10074] Activating service > > name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=10077 > > So it's apparently the right dbus-daemon which starts the at-spi service. > > > ** (at-spi2-registryd:10093): WARNING **: 08:24:49.049: AT-SPI: Cannot > > open default display > > But for some reason XOpenDisplay(NULL) failed to connect to the Xvfb > started by xvfb-run, and all the rest comes from this. Do you have xauth > installed and does xvfb-run properly set things for X applications to > connect? You might want to check with > > $ xvfb-run -a /usr/bin/xlogo Just thinking: is that dbus-daemon which is the parent of at-spi2-registryd (and thus gives it its environment variables)? I vaguely remember "systemd --user" taking over that role, but possibly it misses passing the DISPLAY variable along?... Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le ven. 13 sept. 2019 10:30:10 +0200, a ecrit: > I'm able to reproduce by starting the test manually on a canonistack > instance > > $ xvfb-run -a dbus-run-session gdb ./atk-test > ... > [Detaching after fork from child process 10080] > child_pid 10080 > dbus-daemon[10074]: [session uid=1000 pid=10074] Activating service > name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=10077 So it's apparently the right dbus-daemon which starts the at-spi service. > ** (at-spi2-registryd:10093): WARNING **: 08:24:49.049: AT-SPI: Cannot > open default display But for some reason XOpenDisplay(NULL) failed to connect to the Xvfb started by xvfb-run, and all the rest comes from this. Do you have xauth installed and does xvfb-run properly set things for X applications to connect? You might want to check with $ xvfb-run -a /usr/bin/xlogo Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
I'm able to reproduce by starting the test manually on a canonistack
instance
$ xvfb-run -a dbus-run-session gdb ./atk-test
...
# random seed: R02S97663fd16d09abca48dfb08b794e21eb
1..158
# Start of Accessible tests
run_app:
/home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml
[Detaching after fork from child process 10080]
child_pid 10080
dbus-daemon[10074]: [session uid=1000 pid=10074] Activating service
name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=10077
comm="/home/ubuntu/build/at-spi2-atk-2.34.0/obj-s390x-li"
label="unconfined")
dbus-daemon[10074]: [session uid=1000 pid=10074] Successfully activated
service 'org.a11y.Bus'
dbus-daemon[10089]: Activating service name='org.a11y.atspi.Registry'
requested by ':1.1' (uid=1000 pid=10080
comm="/home/ubuntu/build/at-spi2-atk-2.34.0/obj-s390x-li"
label="unconfined")
dbus-daemon[10089]: Successfully activated service 'org.a11y.atspi.Registry'
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
** (at-spi2-registryd:10093): WARNING **: 08:24:49.049: AT-SPI: Cannot
open default display
** (app-test:10080): WARNING **: 08:24:49.050: AT-SPI: Could not obtain
desktop path or name
Bail out! dbind-FATAL-WARNING: Couldn't get application list: Message
recipient disconnected from message bus without replying
(atk-test:10077): dbind-WARNING **: 08:24:49.050: Couldn't get
application list: Message recipient disconnected from message bus
without replying
dbus-daemon[10089]: Activating service name='org.a11y.atspi.Registry'
requested by ':1.0' (uid=1000 pid=10077
comm="/home/ubuntu/build/at-spi2-atk-2.34.0/obj-s390x-li"
label="unconfined")
Program received signal SIGTRAP, Trace/breakpoint trap.
__GI_raise (sig=sig@entry=5) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) dbus-daemon[10089]: Successfully activated service
'org.a11y.atspi.Registry'
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
...
#0 0x03fffdb48c6e in __GI_raise (sig=sig@entry=5)
at ../sysdeps/unix/sysv/linux/raise.c:50
set =
{__val = {0, 0, 0, 0, 2929167958240, 4398009972902, 1, 18,
4398012587912, 2929167873312, 4398010847088, 4398046504392,
2929167993248, 2929167839808, 4398046505320, 1}}
pid =
tid =
#1 0x03fffddd985a in _g_log_abort (breakpoint=breakpoint@entry=1)
at ../../../glib/gmessages.c:554
debugger_present = 1
#2 0x03fffdddab50 in g_logv (log_domain=,
log_domain@entry=0x3fffdd278a6 "dbind",
log_level=G_LOG_LEVEL_WARNING, format=format@entry=0x3fffdd296de
"Couldn't get application list: %s", args=args@entry=0x3ffe8a0) at
../../../glib/gmessages.c:1373
domain = 0x0
data = 0x0
depth = 1
log_func = 0x3fffddfcd90
domain_fatal_mask =
masquerade_fatal = 0
test_level = 18
was_fatal =
was_recursion =
msg =
msg_alloc =
i = 4
#3 0x03fffdddad1a in g_log
(log_domain=log_domain@entry=0x3fffdd278a6 "dbind",
log_level=log_level@entry=G_LOG_LEVEL_WARNING,
format=format@entry=0x3fffdd296de "Couldn't get application list: %s")
at ../../../glib/gmessages.c:1415
args =
{{__gpr = 4, __fpr = 0, __overflow_arg_area = 0x3ffe968,
__reg_save_area = 0x3ffe8c8}}
#4 0x03fffdd1d5be in ref_accessible_desktop
(app=0x2aa00039800 [AtspiApplication]) at ../atspi/atspi-misc.c:597
message =
iter =
{dummy1 = 0x0, dummy2 = 0x2aa00030ca0, dummy3 = 1023, dummy4 =
-5448, dummy5 = 682, dummy6 = 200192, dummy7 = 0, dummy8 = 100, dummy9 =
682, dummy10 = 88450, dummy11 = 1023, pad1 = -33923192, pad2 = 0x0, pad3
= 0x3fffdc1419c <___fprintf_chk+116>}
iter_array =
{dummy1 = 0x3ffe950, dummy2 = 0x2aa00015982, dummy3 =
1023, dummy4 = -33923192, dummy5 = 0, dummy6 = 0, dummy7 = 682, dummy8 =
87302, dummy9 = 0, dummy10 = 4, dummy11 = 0, pad1 = 0, pad2 =
0x3ffeab8, pad3 = 0x3ffea18}
--Type for more, q to quit, c to continue without paging--
bus_name_dup =
error = 0x2aa00038c20
reply = 0x0
a = 0x2aa00039800 [AtspiApplication]
#5 0x03fffdd1d5be in _atspi_ref_accessible
(app=, path=) at ../atspi/atspi-misc.c:632
a = 0x2aa00039800 [AtspiApplication]
#6 0x03fffdd1e604 in atspi_get_desktop (i=i@entry=0)
at ../atspi/atspi-registry.c:71
#7 0x02aa000155da in get_root_obj
(file_name=file_name@entry=0x2aa00015982
"/home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml")
at ../tests/atk_test_util.c:81
tries = 0
child =
timeout = {tv_sec = 0, tv_nsec = 1000}
obj = 0x0
#8 0x02aa70e0 in atk_test_accessible_get_name
(fixture=, user_data=)
at ../tests/atk_test_accessible.c:37
obj =
__func__ = "atk_test_accessible_get_name"
Cheers,
Le 13/09/2019 à 00:30, Samuel Thibault a écrit :
> I tried
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
I tried on a porterbox with the set of packages, and using a crontab to make it not have a controlling tty. It still worked. I'm out of ideas to reproduce the issue myself. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Hi Samuel, On 12-09-2019 16:04, Samuel Thibault wrote: > Now that the list of installed packages is clear and does include all > that is is needed, I'd like to know the environment variables. Normally > the porterbox dchroots are quite raw, but who knows. Ubuntu sets some variables, I don't think we set much on ci.d.n. Ubuntu runs in a VM, ci.d.n runs in a clean lxc. > Also, do autopkgtest run with a controlling terminal or not? That might > make a difference, and I have always run it in a terminal only. In lxc, the connection is just sending commands via lxc-attach (I think), not sure what that means for your question. I don't know how Ubuntu attaches to its VMs. >> also the environment is what is installed on the system by default > > Which system? A clean (bootstrapped) VM. Paul signature.asc Description: OpenPGP digital signature
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le jeu. 12 sept. 2019 14:17:40 +0200, a ecrit: > Le 12/09/2019 à 13:23, Samuel Thibault a écrit : > > But then the problem is that testbed-packages does not contain > > at-spi2-core. The tests can't work without it. > > Samuel, I think you are chassing the wrong thing there. The tests are > working on other archs and hit a SIGTRAP on s390x, They are not working on arm64 either. I have tried to run on the arm64 and s390x Debian porter boxes in a dchroot and it succeeded there. I wanted to make sure that I have the same set of packages. Now that the list of installed packages is clear and does include all that is is needed, I'd like to know the environment variables. Normally the porterbox dchroots are quite raw, but who knows. Also, do autopkgtest run with a controlling terminal or not? That might make a difference, and I have always run it in a terminal only. > also the environment is what is installed on the system by default Which system? > (which is what the testbed artifacts lists) + the 'installed packages > list' I copied earlier, That "+" was not obvious, and probably needs to be made more obvious in the artifact names. > and that includes at-spi. I guess it would be useful to get a > backtrace from the sigtrap, The problem is that from what I see, it's not the test which crashes, but one of dbus-daemon/at-spi-registryd/at-spi-bus-launcher. > I will see if I can get access to an similar env to reproduce/get one That's what I was trying to do. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Le 12/09/2019 à 13:23, Samuel Thibault a écrit : > But then the problem is that testbed-packages does not contain > at-spi2-core. The tests can't work without it. Samuel, I think you are chassing the wrong thing there. The tests are working on other archs and hit a SIGTRAP on s390x, also the environment is what is installed on the system by default (which is what the testbed artifacts lists) + the 'installed packages list' I copied earlier, and that includes at-spi. I guess it would be useful to get a backtrace from the sigtrap, I will see if I can get access to an similar env to reproduce/get one Cheers,
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Hi, On 12-09-2019 13:25, Samuel Thibault wrote: > Put another way, the set of packages available during the test execution > is the union of the two? Yes. Paul signature.asc Description: OpenPGP digital signature
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Ah, I missed that part. Paul Gevers, le jeu. 12 sept. 2019 09:42:52 +0200, a ecrit: > On 12-09-2019 01:14, Samuel Thibault wrote: > > testbed-packages contains xauth, but not at-spi2-core > > These are already installed in the testbed [...] > > tests-packages contains at-spi2-core, but not xauth. > > These are installed because of the test dependencies Put another way, the set of packages available during the test execution is the union of the two? Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le jeu. 12 sept. 2019 10:17:12 +0200, a ecrit: > Ah, that makes more sense and Paul answered then. It's just that it's already > pre-installed on the test setup (you can see in the artifacts' > testbed-packages) But then the problem is that testbed-packages does not contain at-spi2-core. The tests can't work without it. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Le 12/09/2019 à 09:46, Samuel Thibault a écrit : > Oops, please read "*no* xauth" here. > >> That doesn't include xauth unless I'm overlooking something? > Yes, and that's the concern. The xvfb-run script can't work without it. > debian/tests/control does specify it as a dependency, but autopkgtest > didn't install it. Ah, that makes more sense and Paul answered then. It's just that it's already pre-installed on the test setup (you can see in the artifacts' testbed-packages)
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le jeu. 12 sept. 2019 09:44:31 +0200, a ecrit: > Le 12/09/2019 à 09:39, Samuel Thibault a écrit : > > There is xauth installation there. Oops, please read "*no* xauth" here. > That doesn't include xauth unless I'm overlooking something? Yes, and that's the concern. The xvfb-run script can't work without it. debian/tests/control does specify it as a dependency, but autopkgtest didn't install it. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Le 12/09/2019 à 09:39, Samuel Thibault a écrit : > There is xauth installation there. That's why I had a look at the > artifacts to be sure whether perhaps it was already installed, and it is > in one of the two files, but not the other, so I'm just confused now. Is > ubuntu's autopkgtest really installing the deps referenced in > debian/tests/control? Are we looking at the same log? What I see is 'The following additional packages will be installed: at-spi2-core autoconf automake autopoint autotools-dev build-essential cpp cpp-9 debhelper dh-autoreconf dh-strip-nondeterminism dwz g++ g++-9 gcc gcc-9 gettext gir1.2-atk-1.0 gir1.2-atspi-2.0 gir1.2-freedesktop icu-devtools intltool-debian libarchive-zip-perl libasan5 libatk-bridge2.0-0 libatk-bridge2.0-dev libatk1.0-0 libatk1.0-data libatk1.0-dev libatomic1 libatspi2.0-0 libatspi2.0-dev libblkid-dev libc-dev-bin libc6-dev libcc1-0 libdbus-1-dev libdbus-glib-1-2 libdbus-glib-1-dev libdbus-glib-1-dev-bin libdrm-amdgpu1 libdrm-nouveau2 libdrm-radeon1 libffi-dev libfile-stripnondeterminism-perl libfontenc1 libgcc-9-dev libgl1 libgl1-mesa-dri libglapi-mesa libglib2.0-dev libglib2.0-dev-bin libglvnd0 libglx-mesa0 libglx0 libgomp1 libice6 libicu-dev libisl21 libitm1 libllvm8 libmount-dev libmpc3 libpcre16-3 libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix0 libpcre3-dev libpcre32-3 libpcrecpp0v5 libpthread-stubs0-dev libselinux1-dev libsensors-config libsensors5 libsepol1-dev libsm6 libstdc++-9-dev libsub-override-perl libtool libubsan1 libx11-dev libx11-xcb1 libxau-dev libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb1-dev libxdamage1 libxdmcp-dev libxext-dev libxfixes-dev libxfixes3 libxfont2 libxi-dev libxi6 libxkbfile1 libxml2-dev libxmu6 libxpm4 libxshmfence1 libxt6 libxtst-dev libxtst6 libxxf86vm1 linux-libc-dev m4 meson ninja-build pkg-config po-debconf python3-distutils python3-lib2to3 uuid-dev x11-common x11-xkb-utils x11proto-core-dev x11proto-dev x11proto-fixes-dev x11proto-input-dev x11proto-record-dev x11proto-xext-dev xorg-sgml-doctools xserver-common xtrans-dev xvfb zlib1g-dev' That doesn't include xauth unless I'm overlooking something? Cheers,
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Hi Samuel, On 12-09-2019 01:14, Samuel Thibault wrote: > Sebastien Bacher, le mer. 11 sept. 2019 10:36:38 +0200, a ecrit: >> The autopkgtests added recently seem to fail most of the time on s390x >> (they did success only one there since they have been added) >> http://autopkgtest.ubuntu.com/packages/a/at-spi2-atk/eoan/s390x > > I don't understand the artifacts. Which one contains the set of packages > installed during the test? > > testbed-packages contains xauth, but not at-spi2-core These are already installed in the testbed, before any package specific packages are installed. These are listed to have the version of installed packages available. > tests-packages contains at-spi2-core, but not xauth. These are installed because of the test dependencies on top of what the testbed already has. Apparently xauth was already installed and didn't need listing. > Both (and others referenced in debian/tests/control) are needed for the > tests to run at all. And as they are both listed, that part should be covered. Paul signature.asc Description: OpenPGP digital signature
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Sebastien Bacher, le jeu. 12 sept. 2019 09:18:09 +0200, a ecrit: > Le 12/09/2019 à 01:14, Samuel Thibault a écrit : > > I don't understand the artifacts. Which one contains the set of packages > > installed during the test? > > > > testbed-packages contains xauth, but not at-spi2-core > > tests-packages contains at-spi2-core, but not xauth. > > > > Both (and others referenced in debian/tests/control) are needed for the > > tests to run at all. > > > > Samuel > > I think the easiest is just to look at one of the logs, e.g > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/s390x/a/at-spi2-atk/20190910_191420_7c934@/log.gz > > look for the 'The following additional packages will be installed' > section there There is xauth installation there. That's why I had a look at the artifacts to be sure whether perhaps it was already installed, and it is in one of the two files, but not the other, so I'm just confused now. Is ubuntu's autopkgtest really installing the deps referenced in debian/tests/control? Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Hey Samuel, Le 12/09/2019 à 01:14, Samuel Thibault a écrit : > I don't understand the artifacts. Which one contains the set of packages > installed during the test? > > testbed-packages contains xauth, but not at-spi2-core > tests-packages contains at-spi2-core, but not xauth. > > Both (and others referenced in debian/tests/control) are needed for the > tests to run at all. > > Samuel I think the easiest is just to look at one of the logs, e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/s390x/a/at-spi2-atk/20190910_191420_7c934@/log.gz look for the 'The following additional packages will be installed' section there Cheers,
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Hello, Sebastien Bacher, le mer. 11 sept. 2019 10:36:38 +0200, a ecrit: > The autopkgtests added recently seem to fail most of the time on s390x > (they did success only one there since they have been added) > http://autopkgtest.ubuntu.com/packages/a/at-spi2-atk/eoan/s390x I don't understand the artifacts. Which one contains the set of packages installed during the test? testbed-packages contains xauth, but not at-spi2-core tests-packages contains at-spi2-core, but not xauth. Both (and others referenced in debian/tests/control) are needed for the tests to run at all. Samuel
Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x
Package: at-spi2-atk Version: 2.34.0-1 The autopkgtests added recently seem to fail most of the time on s390x (they did success only one there since they have been added) http://autopkgtest.ubuntu.com/packages/a/at-spi2-atk/eoan/s390x (Ubuntu sync the package from Debian so the problem would probably exist there has wellf if autopkgtest was enabled on that arch) The error is a SIGTRAP but it's not really clear from the log what the problem is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/s390x/a/at-spi2-atk/20190910_191420_7c934@/log.gz Cheers,
