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
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 retryin
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://
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
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 sit
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
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
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?.
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 righ
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]: [sess
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
[Deta
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
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
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
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 envir
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
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.
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-sp
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
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
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 in
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/packa
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-pac
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
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
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 prob
26 matches
Mail list logo
