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

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:

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 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'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


Reply via email to