On Mon, Feb 18, 2019 at 07:38:49PM +0100, Paul Gevers wrote: > 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? That is not the case; it's the other way around: salsa-ci runs stuff on docker containers -- and so have no init system. LXC is designed to run system containers, and it does have a full 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? Again, this argument does not hold. LXC (and ci.debian.net) boots an actual init system inside the container, and it has *always* been like this. I have downloaded the lighttpd source here, and read all the tests. All of them to start lighttpd directly, and at least the first test requires being run as root; Tests that need to run as root need to say so in the control file; salsa-ci runs stuff as root already, and that's why it doesn't fail there. In fact, just adding `Restrictions: needs-root` makes the test pass again. Just tested this here. By the way, since all the tests are starting lighttpd directly means that the service definitions and the init integration is not being tested being "the service starts" (because the package installation, and therefore autopkgtest, would fail if that fails). Also, note that when you start lighttpd directly in your script, there will be another instance -- the one started by the init system -- running in the background.
Attachment:
signature.asc
Description: PGP signature