Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
to 13. kesäk. 2024 klo 11.52 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > Adding the dnsmasq maintainer in CC. > > to 13. kesäk. 2024 klo 11.39 Paul Gevers (elb...@debian.org) kirjoitti: > > On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote: > > > Subsequent ones randomly timeout waiting for an IP from the DHCP > > > server. This could well be an issue with dnsmasq, which is what we use > > > for the test. Alternately, it could be caused by those constant fails > > > on glibc. Without more detailed logs, I am not in a position to > > > investigate this. Help is welcome. > > > > Well, I can't give you more logs than what your test writes. So that's > > in your hands, I suggest you try and make the test more verbose of > > what's going on, or maybe ensure some logs end up in the artifacts for > > inspection. Also, if dnsmasq is the problem, you might want to contact > > the maintainer and discuss the issue (e.g. in a bug report). From my > > standpoint, it's the autopkgtest of dhcpcd that's having issues and that > > *is* an issue for src:dhcpcd. You could reassign this bug and mark it > > "affects dhcpcd". > > I'm curious to hear whether any of what appears in the log rings any > bell for Simon. > > > I acknowledge that something fishy seems to be ongoing in the archive > > when new version of src:glibc binaries appear (not only with dhcpcd I > > mean). For now I'll not hold that against autopkgtest failures of > > packages too much. > > Which is where I suspect the real issue is. > > Personally, I already find it suspicious that the tracker tells me > about unrelated packages' transitions or issues. If the problem is in > someone else's code, while mine hasn't changed in ages, that's where > the bug report needs to go. In this case, dhcpcd's autopkgtest hasn't > changed in ages, and has been verified to work as-is at Ubuntu, where > isolation machines were implemented a long time before Debian. Sorry Paul but, at this point, I'm gonna call CI itself flaky. Right now, CI hasn't even registered any test attemps for recent uploads to Unstable and its results for Testing out of sync. Given this, if you're gonna start mass-filing bugs against any package whose test reults show discrepancy, first make sure that, in fact, your code is not the one causing others unnecesary work. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Adding the dnsmasq maintainer in CC. to 13. kesäk. 2024 klo 11.39 Paul Gevers (elb...@debian.org) kirjoitti: > On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote: > > Subsequent ones randomly timeout waiting for an IP from the DHCP > > server. This could well be an issue with dnsmasq, which is what we use > > for the test. Alternately, it could be caused by those constant fails > > on glibc. Without more detailed logs, I am not in a position to > > investigate this. Help is welcome. > > Well, I can't give you more logs than what your test writes. So that's > in your hands, I suggest you try and make the test more verbose of > what's going on, or maybe ensure some logs end up in the artifacts for > inspection. Also, if dnsmasq is the problem, you might want to contact > the maintainer and discuss the issue (e.g. in a bug report). From my > standpoint, it's the autopkgtest of dhcpcd that's having issues and that > *is* an issue for src:dhcpcd. You could reassign this bug and mark it > "affects dhcpcd". I'm curious to hear whether any of what appears in the log rings any bell for Simon. > I acknowledge that something fishy seems to be ongoing in the archive > when new version of src:glibc binaries appear (not only with dhcpcd I > mean). For now I'll not hold that against autopkgtest failures of > packages too much. Which is where I suspect the real issue is. Personally, I already find it suspicious that the tracker tells me about unrelated packages' transitions or issues. If the problem is in someone else's code, while mine hasn't changed in ages, that's where the bug report needs to go. In this case, dhcpcd's autopkgtest hasn't changed in ages, and has been verified to work as-is at Ubuntu, where isolation machines were implemented a long time before Debian. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Hi, On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote: https://ci.debian.net/packages/d/dhcpcd/unstable/amd64/ I was looking at https://ci.debian.net/packages/d/dhcpcd/testing/amd64/ Most of these pre-date your previous bug report (#1069599) about the missing Depends on systemd-timesyncd for the test. I file so many bugs, I don't keep track. I forgot I recently filed another bug for dhcpcd. Thanks for reminding me. Subsequent ones randomly timeout waiting for an IP from the DHCP server. This could well be an issue with dnsmasq, which is what we use for the test. Alternately, it could be caused by those constant fails on glibc. Without more detailed logs, I am not in a position to investigate this. Help is welcome. Well, I can't give you more logs than what your test writes. So that's in your hands, I suggest you try and make the test more verbose of what's going on, or maybe ensure some logs end up in the artifacts for inspection. Also, if dnsmasq is the problem, you might want to contact the maintainer and discuss the issue (e.g. in a bug report). From my standpoint, it's the autopkgtest of dhcpcd that's having issues and that *is* an issue for src:dhcpcd. You could reassign this bug and mark it "affects dhcpcd". I acknowledge that something fishy seems to be ongoing in the archive when new version of src:glibc binaries appear (not only with dhcpcd I mean). For now I'll not hold that against autopkgtest failures of packages too much. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Hi, On 12-06-2024 6:20 a.m., Martin-Éric Racine wrote: This is a non-bug. Please elaborate more. This package has only one test and it requires an isolation machine. amd64 is the only architecture that provides it. Other architectures will always be marked flakey. Indeed, it's annotated with isolation-machine and not tested on our infa where that's not possible to fulfill. So on those architectures the test is skipped. Additionally, looking at the tracker for this package, amd64 always passes. I filed this bug exactly because looking at the history on amd64, the package very often fails. In testing in the last 1.5 months: https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47553601/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47552634/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47542478/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47446840/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47186590/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47164143/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47104273/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/46055187/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/46053079/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/45883612/ https://ci.debian.net/packages/d/dhcpcd/testing/amd64/45702932/ Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
ke 12. kesäk. 2024 klo 7.20 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti: > > > > Source: dhcpcd > > Version: 1:10.0.8-1 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: flaky > > > > Dear maintainer(s), > > > > I looked at the results of the autopkgtest of your package because it > > was tested for glibc. I noticed that it regularly fails. > > > > Because the unstable-to-testing migration software now blocks on > > regressions in testing, flaky tests, i.e. tests that flip between > > passing and failing without changes to the list of installed packages, > > are causing people unrelated to your package to spend time on these > > tests. > > > > Don't hesitate to reach out if you need help and some more information > > from our infrastructure. > > This is a non-bug. This package has only one test and it requires an > isolation machine. amd64 is the only architecture that provides it. > Other architectures will always be marked flakey. Additionally, > looking at the tracker for this package, amd64 always passes. This being said, if you can spot what makes it randomly fails, please do send me a patch. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti: > > Source: dhcpcd > Version: 1:10.0.8-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of your package because it > was tested for glibc. I noticed that it regularly fails. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. This is a non-bug. This package has only one test and it requires an isolation machine. amd64 is the only architecture that provides it. Other architectures will always be marked flakey. Additionally, looking at the tracker for this package, amd64 always passes. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Source: dhcpcd Version: 1:10.0.8-1 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package because it was tested for glibc. I noticed that it regularly fails. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47186590/ [--- 86s Preparing virtual interfaces... 86s Actual changes: 86s tx-checksum-ip-generic: off 86s tx-tcp-segmentation: off [not requested] 86s tx-tcp-ecn-segmentation: off [not requested] 86s tx-tcp-mangleid-segmentation: off [not requested] 86s tx-tcp6-segmentation: off [not requested] 86s tx-checksum-sctp: off 86s Preparing dnsmasq configuration... 91s Obtaining network configuration for veth1 via dhcp... 122s timed out 122s autopkgtest [05:47:12]: test timesyncd-ntp-servers-from-dhcp: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
