Control: tags -1 + confirmed Hi Paul,
On Sat, Feb 16, 2019 at 08:42:35AM +0100, Paul Gevers wrote: > With a recent upload of lighttpd the autopkgtest of lighttpd fails in > testing when that autopkgtest is run with the binary packages of > lighttpd from unstable. It passes when run with only packages from > testing. In tabular form: > pass fail > lighttpd from testing 1.4.53-2 > all others from testing from testing Thank you for looking through failures thoroughly. In this case, I was aware of the issue. I confirm that it is a genuine regression of the upload. While I have your attention, I'm interested in your input though. :) > autopkgtest [00:11:07]: test defconfig: [----------------------- > 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't > exist: /var/cache/lighttpd/uploads > 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir > /var/cache/lighttpd/compress/ Permission denied What happens here is that /var/cache/lighttpd/compress is not created during installation. That actually is a problem, but the question is whether the test environment is "sane". The very same autopkgtest does not fail on salsa-ci: https://salsa.debian.org/debian/lighttpd/-/jobs/126948 Upon closer inspection the difference becomes apparent. salsa-ci is performing a regular package installation. lighttpd's init script ensures the presence of said directory as does the tmpfile.d config. However ci.debian.net runs neither (because it seems to come without an init system). We can of course create these locations in the package itself. Indeed we already do that for e.g. /var/log/lighttpd (and that makes us require root for build). It turns out that ci.debian.net's environment is a bit artificial in this regard. Should we weaken the test here or should we ensure presence of those locations through non-init means? Thanks for your input Helmut
