Hi Jeff, On 03-10-2022 13:39, Jeff wrote:
This morning, I see that for s390x in testing, there was a timeout and failure (both in 380_cancel_user_defined_with_pids), as well as two passes:https://ci.debian.net/packages/g/gscan2pdf/testing/s390x/
Ends with: """ "Too many open files" at t/380_cancel_user_defined_with_pids.t line 40. """Might that be a hint? Maybe a race condition under a high amount of parallelism built?
Again, the failure rate with 27 hour timeout wasn't that high, but 27 hours is really long... Hmm, autopkgtest should have sane default timeouts, and now I take a careful look, I notice that the timeout happens during *building* of your package, even *before* the test is started. Do you really need the "build-needed" restriction? Our spec [1] has this:
Please use this considerately, as for large builds it unnecessarily
builds the entire project when you only need a tiny subset (like the
tests/ subdirectory). It is often possible to run ``make -C tests``
instead, or copy the test code to ``$AUTOPKGTEST_TMP`` and build it
there with some custom commands. This cuts down the load on the
Continuous Integration servers and also makes tests more robust as
it prevents accidentally running them against the built source tree
instead of the installed packages.
What's more, autopkgtest is really ment to test as-installed packages,
building the binaries again makes it very easy to test the freshly built
binaries *instead of* the installed binaries. (Not saying that's the
case here, but building the binaries is something that I think tests
should hardly ever do.)
I also see that all the other architectures have passes, but this is not reflected by the summary page:https://ci.debian.net/packages/g/gscan2pdf/ Any idea why?
This page only shows "pure" runs because showing failures cause by packages in other suites that are not allowed to migrate is confusing. We do want to change that page, but UI is difficult and we haven't found the time and energy to implement it.
Given that gscan2pdf is a desktop app, I assume there are no users on s390x. Hence, I'm not sure of the value of debugging on s390x. According to:https://www.debian.org/doc/debian-policy/ch-source.htmlDEB_HOST_ARCH and DEB_TARGET_ARCH should be set. I'm tempted to test for s390x in the test target in debian/rules and skip accordingly. Objections?
autopkgtest also supports an "Architecture" field in the d/t/control file that takes negation. So, why not use "Architecture: !s390x" if you just want to disable the test there?
Given that the packages in stable are, well, stable, and I made no changes to those parts of gscan2pdf, I wonder what happened in the rest of the environment between stable and testing. I'd be interested to confirm this by pushing the stable version of gscan2pdf through testing s390x a couple of times.
Not sure you can do that, except by using "+really" version number uploads. Also, see:
https://ci.debian.net/data/autopkgtest/stable/armel/g/gscan2pdf/23364480/log.gz So stable is not free from the issue. Paul[1] https://salsa.debian.org/ci-team/autopkgtest/-/raw/master/doc/README.package-tests.rst
OpenPGP_signature
Description: OpenPGP digital signature
