Le Fri, May 02, 2025 at 11:41:34AM +0200, Chris Hofstaedtler a écrit :
It looks like the tests have an internal timeout, until when they expect something to start. I imagine this timeout can be increased.
Thanks Chris for checking this, Indeed it seems that there is a timeout of 30s that seems enough to cause the tests to fail around 5% of the times. I also note that some of the failures were synchronised on some architecture (like failing on the same day in amd64 and arm64), so it may be network issues that are not solvable by changing the timeout.
I've briefly spoken to Paul here at MiniDebConf Hamburg. It might be reasonable to rejectlist r-cran-httr2 on riscv64, but please consider increasing the r-cran-httr2 tests internal timeout first.
Indeed, the failure rate on risc64 is way higher than on other release architectures. The tests run also 10 times slower, which is a lot. I am not familiar with risc64, but if the usage pattern of this architecture is narrower than amd64 and arm64 and does not include scientific computing, it may make sense to just remove all team-maintained r-cran-* packages there too, as it is not supported upstream. Risc64 users who just want to perform HTTP requests with a script language have better alternatives such as Perl or Python. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
