Hi Marc, On 09-12-2022 19:34, Marc Haber wrote:
On Thu, Dec 01, 2022 at 01:02:45PM +0100, Paul Gevers wrote:And right after hitting the send button I realized that my reasoning is at least partially flawed. The testbed will always update glibc, because the testbed is build from testing, and glibc hasn't migrated yet. Still, it's a weird pattern.Is there still something that sudo can do here?
The last pure testing run [1] also failed, so maybe all the glibc triggered failures were just coincidence and the test is flaky (on s390x).
I fixed an issue in the ldap autopkgtest¹ recently, but your logs looks like the test gets further than the place where this issue errors out. Would more output in the test help?
I would say this always helps.
What is the canonical way to write a test that can have its verbosity turned up for debugging, how is this wish communicated to a system that runs the tests in an automated way?
Why would you want to disable verbosity of tests? I recommend to always enable verbose logs. There's no way to trigger an existing test on the infrastructure with different options/environment variables. However, when run manually one has the full freedom to ask autopkgtest to run commands before the actual test in the testbed.
Can a mere mortal DD run an autopkgtest on a porterbox?
Yes. I suggest to check https://salsa.debian.org/mbanck/dd-autopkgtest/ for a helper script to do that.
Paul[1] https://ci.debian.net/data/autopkgtest/testing/s390x/s/sudo/29143772/log.gz
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature