Dear maintainer(s), I looked at the results of the autopkgtest of your package because it showed up in the glibc regressions. I noticed that it regularly fails on s390x [1] for the first try to test glibc (same happened at least once on i386 too). The retry one day later works. On ci.d.n, we rebuild our containers on a daily basis, so I suspect this has to do with glibc being updated in the testbed, the testbed not being restarted and than causing issues. I'm actually in dubio if I should file this bug against sudo, as it may only be the messenger, hence I x-debbugs-cc-ed the glibc and openldap maintainers into the bug too. Please let us figure out where the issue lies and reassign appropriately. Paul [1] https://ci.debian.net/packages/s/sudo/testing/s390x/ https://ci.debian.net/data/autopkgtest/testing/s390x/s/sudo/28781616/log.gz autopkgtest [01:07:28]: test 03-getroot-ldap: [----------------------- clean up ldap database ... reconfigure slapd ... start slapd ... add sudo schema to slapd ... autopkgtest [01:07:30]: test 03-getroot-ldap: -----------------------] 03-getroot-ldap FAIL non-zero exit status 253
Hi, 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. Paul
Is there still something that sudo can do here? 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? 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? Can a mere mortal DD run an autopkgtest on a porterbox? Greetings Marc
Is there still something that sudo can do here? 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? 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? Can a mere mortal DD run an autopkgtest on a porterbox? Greetings Marc
Hi Marc, 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 would say this always helps. 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. 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
I tried doing that as a poc in https://salsa.debian.org/sudo-team/sudo/-/merge_requests/40 An autopkgtest pipeline output is visble on https://salsa.debian.org/sudo-team/sudo/-/jobs/9602700 Just the 01-getroot test is adapted yet, what do you think? Greetings Marc
I tried doing that as a poc in https://salsa.debian.org/sudo-team/sudo/-/merge_requests/40 An autopkgtest pipeline output is visble on https://salsa.debian.org/sudo-team/sudo/-/jobs/9602700 Just the 01-getroot test is adapted yet, what do you think? Greetings Marc
Hi Marc, Thanks for looking at this old bug :). I glanced over the change and it's a bit involved for me to judge. If verbosity goes up that is good I'd think. Paul
You're welcome. I will upload with the POC and then eventually bring the other autopkgtests up to that standard. Thanks for taking your time to look at the output. I appreciate that. Greetings Marc