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
