[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#922447: lighttpd: autopkgtest regression

Hi Helmut,

[Adding the debian-ci team into the discussion]

On 18-02-2019 08:06, Helmut Grohne wrote:
>> 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 ci.d.n runs its tests in a standard LXC. So depending on what you
think you should support, that is where delta's from bare metal
configurations come from.

> The very same autopkgtest does not fail on salsa-ci:
> https://salsa.debian.org/debian/lighttpd/-/jobs/126948

I don't know how salsa-ci runs it's pipelines.

> Upon closer inspection the difference becomes apparent. salsa-ci is
> performing a regular package installation.

As does ci.d.n, except in an LXC.

> 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).

Didn't know about that. Does anybody know if that is normal for LXCs?

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

If your package/test only works on bare metal, you should declare an
isolation-machine restriction (and it will be skipped on ci.d.n). If
your package should also work in LXC, you should probably fix the
package. If you want the test to run on the current ci.d.n
infrastructure and don't want/need to support LXC usage of your package,
you can fix the situation in your test only.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: