https://ci.debian.net/packages/d/dhcpcd/unstable/amd64/70729624/

The package's autopkgtest succeeds just fine. It's the qemu image that kills a Python process before the testbed is even setup.

Martin-Éric

Hi Martin-Éric,


Can you elaborate what you mean? Are you referring to this line?
"""
qemu-system-x86_64: terminating on signal 15 from pid 2383650
(/usr/bin/python3)
"""

I'm 95% sure that's harmless (albeit confusing), as it also shows up in
passing tests. I think it stems from how autopkgtest reboots/shutdowns qemu.

Paul

pe 1.5.2026 klo 8.09 Paul Gevers (elbrus@debian.org) kirjoitti:

This one.
testbed is setup. Meanwhile, both tests performed for src:dhcpcd
return SUCCESS, but are marked as having failed based on the previous
error.

Martin-Éric

Hi
No they are not. As I said we also see this for passing tests.

To check, I just triggered a test with only the failing testcase
(autopkgtest option --test-name) and then tried to manually run the test
in the test bed where the test just ran (so before the testbed was
destroyed) and you see [1] that the test already returned 1. I couldn't
rerun the test because it failed with [2].

I then triggered only the passing test, installed the test dependencies
for the failing one in the testbed and ran the failing test. It failed
in a testbed which stayed alive even while testing.

All of this on the test infrastructure host, so no delta's.

Paul

[1]
autopkgtest [05:48:30]: test timesyncd-ntp-servers-from-dhcp:
[-----------------------
Preparing virtual interfaces...
Actual changes:
tx-checksum-ip-generic: off
tx-tcp-segmentation: off [not requested]
tx-tcp-ecn-segmentation: off [not requested]
tx-tcp-mangleid-segmentation: off [not requested]
tx-tcp6-segmentation: off [not requested]
tx-udp-segmentation: off [not requested]
tx-checksum-sctp: off
Preparing dnsmasq configuration...
Obtaining network configuration for veth1 via dhcp...
Check if the NTP server is made available to daemon...SUCCESS!
Release the current lease...
Check if the NTP server has been correctly removed... autopkgtest
[05:49:03]: test timesyncd-ntp-servers-from-dhcp: -----------------------]
autopkgtest [05:49:04]: test timesyncd-ntp-servers-from-dhcp:  - - - - -
- - - - - results - - - - - - - - - -
timesyncd-ntp-servers-from-dhcp FAIL non-zero exit status 1
autopkgtest [05:49:04]:  - - - - - - - - - - running shell - - - - - - -
- - -
You can now log into the VM through the serial terminal.
Depending on which terminal program you have installed, you can use one of

     ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p
10026 user@localhost
     minicom -D unix#/tmp/autopkgtest-qemu.5qs_zm0t/ttyS0
     nc -U /tmp/autopkgtest-qemu.5qs_zm0t/ttyS0
     socat - UNIX-CONNECT:/tmp/autopkgtest-qemu.5qs_zm0t/ttyS0

The tested source package is in /tmp/autopkgtest.FtJQdg/build.Xvr/src

Press Enter to resume running tests.


[2]
root@host:/tmp/autopkgtest.FtJQdg/build.Xvr/src#
debian/tests/timesyncd-ntp-servers-from-dhcp ; echo $?
Preparing virtual interfaces...
RTNETLINK answers: File exists
2

pe 1.5.2026 klo 9.08 Paul Gevers (elbrus@debian.org) kirjoitti:

The red section starts there. It does not start later at testbed setup
or test run, which is what happend last time CI failed on this
package.

No delta here either, and the test cleary succeeds at performing the
actions expected, and it ends with SUCCESS. Wherever the exit comes,
it's not from us.

Martin-Éric

pe 1.5.2026 klo 9.08 Paul Gevers (elbrus@debian.org) kirjoitti:

Looking again, what seems to fail is removal of the NTP server i.e.
the second step of timesyncd-ntp-servers-from-dhcp. Nevertheless, we
have no delta in dhcpcd that would explain this. This new upstream
didn't touch exit hooks at all. It was a terse two-line change for
interface carrier detection.

Martin-Éric

pe 1.5.2026 klo 9.34 Martin-Éric Racine (martin-eric.racine@iki.fi) kirjoitti:

Except for one important part: the CI on Salsa doesn't offer isolation
machine, so it skips the timesyncd test. Having all autokpgtest
capablities available on the Salsa CI would be highly desirable. It
would also make it easier to test and fix the problem, if any (which I
highly doubt, since this new release hasn't changed how dhcpcd handles
exit scripts).

Martin-Éric