I managed to push an update [0] that unexpectedly died in autopkgtests [1]. I'm thankful that the tests brought this problem to light, and grateful for the bug report--chalk it up as a nice win for autopkgtests! I'm now pondering how best to track this down, however, and at something of a loss. So far as I'm aware, the only artifacts left over from the run are the logs [2], unless one uses the AUTOPKGTEST_ARTIFACTS mechanism [3] (which I intend to start using ASAP).
Even with artifacts tweaked to grab a coredump or whatnot, is there any way to test a modified package in the autopkgtest environment without a full archive upload? This particular program is pretty hardware-sensitive, and attempts to reproduce the bug locally have not yet been fruitful (though given that the autopkgtest failed on all architectures, it's likely less hardware-dependent than I'm making out). Ideally, I'd be able to run the autopkgtests as part of Salsa CI, which [4] suggests to be doable. Going even further, I'd be able to ssh into a failed autopkgtest environment (for some (short) time), and run some one-off experiments therein. Am I missing an existing process through which this is possible? Thanks! --nick [0] https://tracker.debian.org/pkg/growlight [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982786 [2] https://ci.debian.net/data/autopkgtest/testing/amd64/g/growlight/10443325/log.gz [3] https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html [4] https://debconf20.debconf.org/talks/39-running-autopkgtest-for-your-package/ -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
signature.asc
Description: PGP signature
