Hi Yves-Alexis, On 08-04-2024 10:13 a.m., Yves-Alexis Perez wrote:
thanks for the report. I might try to investigate a bit but at that point honestly I don't have much clue what happens.
Can we try and find out together?
Could you please provide a bit more context in the bug report so we have a bit more data?
What kind of context are you looking for? Your package has an autopkgtest (which I assume was added such that it can run). It declares a isolation-machine restriction, so until yesterday, the test was never executed on ci.debian.net. I just realized that I could have looked at Ubuntu too, which uses qemu already longer. The test passes there, so we're looking for delta's.
Because at that point I didn't really ask for anything and you're making your problem my problem, which doesn't feel really fair, to be honest.
It makes me sad that you see it like that. I had the impression I was running ci.d.n as a service to Debian maintainers.
And if enabling isolation-machine breaks the test, then maybe isolation- machine needs to be fixed, or just not enabled?
Enabling isolation-machine doesn't break tests. It enables more tests to run and the test that previously didn't run now fails. Now I think we should be interested to learn why (personally even more so because it passes on Ubuntu's infrastructure [1]). Honestly, looking at the log it appeared to me that the test was never tried and you simple had forgotten to start the daemon, but given it works in Ubuntu, might this be a race condition?
I cant say for sure but it looks like the easiest way for me.
If you don't want your isolation-machine restricted tests to run, I can trivially disable it again. I was rather hoping to fix either the test, or the setup at ci.d.n or both.
Paul [1] https://autopkgtest.ubuntu.com/packages/s/strongswan
OpenPGP_signature.asc
Description: OpenPGP digital signature
