Your message dated Sun, 26 Oct 2025 20:48:36 +0100
with message-id <[email protected]>
and subject line Re: autopkgtest: provide stack-traces of crashed integration
tests
has caused the Debian Bug report #919269,
regarding autopkgtest: provide stack-traces of crashed integration tests
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
919269: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919269
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: autopkgtest
Severity: normal
Dear Maintainer,
I am the upstream of GSequencer. The software comes with system integration
tests.
https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/tests/ags-integration-test
The makefile compiles the integrations sets and runs them against the
installation.
https://salsa.debian.org/multimedia-team/gsequencer/blob/master/functional-system-tests.mk.am#L144
Since they can crash and actually they do on other architectures than amd64 as
seen here:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
So I tried to reproduce the crash with my ubuntu i386 chroot but without
success. The
integration test didn't crash and completed successfuly.
I think there is probably an issue.
It would be nice to have stack-traces for such cases. With the package
"systemd-coredump"
you can easily retrieve stack-traces by running `coredumpctl debug`. This
without explicitly
running in gdb.
by Joël
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autopkgtest depends on:
ii apt-utils 1.8.0~alpha3
ii libdpkg-perl 1.19.2
ii procps 2:3.3.15-2
ii python3 3.6.7-1
ii python3-debian 0.1.33
Versions of packages autopkgtest recommends:
ii autodep8 0.17
Versions of packages autopkgtest suggests:
pn lxc <none>
pn lxd <none>
pn ovmf <none>
pn qemu-efi-aarch64 <none>
pn qemu-efi-arm <none>
pn qemu-system <none>
pn qemu-utils <none>
pn schroot <none>
pn vmdb2 <none>
--- End Message ---
--- Begin Message ---
Hi,
Sorry for taking so long to reply.
On Mon, 14 Jan 2019 11:55:28 +0100 =?utf-8?q?Jo=C3=ABl_Kr=C3=A4hemann?=
<[email protected]> wrote:
It would be nice to have stack-traces for such cases. With the package
"systemd-coredump"
you can easily retrieve stack-traces by running `coredumpctl debug`. This
without explicitly
running in gdb.
While the idea to centralize is nice, it seems to us that doing this in
the autopkgtest package is doing it at the wrong layer.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
