We have a queue full of ARM retraces that we should probably empty, since the ddebs for these packages are likely long gone. However, we should eventually bring an ARM retracer online. This seems fairly straightforward:
[13:54:43] <ev> pitti: while I have you here, might I ask what the historical reason is for not having ARM retracers?
[13:54:47] <ev> was it lack of space on ddebs?
[13:55:23] <pitti> ev: we actually had had some for a while, but since then we just never got around to setting some up
[13:55:35] <pitti> ev: the main blocker is that RT ticket to move to a proper postgresql duplicate DB
[13:55:46] <pitti> ev: as we cannot share the sqlite one between different hosts
[13:55:52] <ev> right
[13:55:58] <pitti> ev: i. e. pretty much the same problem that we have between "your" and "my" retracers now
[13:56:05] <ev> so apport-retrace should be able to handle ARM just fine
[13:56:22] <pitti> yes, it does
[13:56:42] <ogra_> do the backends actually work nowadays ?
[13:56:50] <pitti> ogra_: backends?
[13:57:00] <pitti> the packaging backend is exactly the same for all arches
[13:57:06] ogra_ remembers when NCommander maintained the arm retracers we simply didnt have any
[13:57:28] <ogra_> pitti, doesnt the retracer need to run the package too ?
[13:57:31] <pitti> there is not much that's platform specific, except perhaps the crash analysis from the disassembl
[13:57:33] <pitti> y
[13:58:17] <pitti> ogra_: which package?
[13:58:29] <ogra_> pitti, dunno, any arm packages actually
[13:58:36] <pitti> ogra_: a retracer by and large needs a checkout of apport trunk, python-launchpadlib, and a good deal of CPU and IO capacity
[13:58:52] <pitti> ogra_: sure, but fortunately we have them in an archive? :-)
Steve points out that with gdb-multiarch, we don't even need ARM hardware.
We can do this with really low overhead. We already construct a sandbox with all the target debs unpacked. The only thing we need to do is to additionally unpack the target system's gdb and its few dependencies, install qemu-user on the retracer system, and run the target gdb through qemu-arm. I tried this approach on bug 1070952, with this:
$ qemu-arm -L /tmp/sandbox usr/bin/gdb --ex 'set debug-file-
It doesn't give me an useful stack trace as we unfortunately do not have any debug symbols for armhf on quantal and raring, and the dependencies of the report might also be slightly outdated (as we do not get Launchpad crash reports from stable releases).
There's a couple of details which need to be changed, such as an arch specific sources.list in the retracer's config directory etc., but those are a SMOP, but I believe this approach works and avoids involving a second chroot, lxc, etc.