Devuan bug report logs - #450
autopkgtest: cannot build a testbed for LXC

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: autopkgtest
Version: 5.10
Severity: grave
Justification: renders package unusable

Dear Maintainer,

man autopkgtest-build-lxc says

SYNOPSIS
       autopkgtest-build-lxc distribution release [architecture] [script]

       It calls lxc-create with the distribution template (which can currently be debian or ubuntu) and -rrelease to build a
       debootstrap-like container, then enables deb-src apt sources, and runs apt-get update.

Then by root

# autopkgtest-build-lxc devuan beowulf
lxc-create: autopkgtest-beowulf: utils.c: get_template_path: 918 No such file or directory - bad template: devuan
lxc-create: autopkgtest-beowulf: lxccontainer.c: do_lxcapi_create: 1786 Unknown template "devuan"
lxc-create: autopkgtest-beowulf: tools/lxc_create.c: main: 327 Failed to create container autopkgtest-beowulf

Note that LXC virtualization backend is the default of debci and autopkgtest commands.

If Devuan project has no intention/plan to deploy CI, then autpkgtest and debci can be simply banned...

Best regards, Ryutaroh Matsumoto


-- System Information:
Distributor ID:	Debian
Description:	Devuan GNU/Linux 3 (beowulf)
Release:	3
Codename:	beowulf
Architecture: x86_64

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils       1.8.2
ii  libdpkg-perl    1.19.7
ii  procps          2:3.3.15-2+devuan1
ii  python3         3.7.3-1
ii  python3-debian  0.1.35

Versions of packages autopkgtest recommends:
ii  autodep8  0.18

Versions of packages autopkgtest suggests:
ii  lxc               1:3.1.0+really3.0.3-8
pn  lxd               <none>
pn  ovmf              <none>
pn  qemu-efi-aarch64  <none>
pn  qemu-efi-arm      <none>
pn  qemu-system       <none>
pn  qemu-utils        <none>
pn  schroot           <none>
pn  vmdb2             <none>

-- no debconf information

Message #8 received at 450@bugs.devuan.org (full text, mbox, reply):

Control: tags -1 debian

Ryutaroh,

Thanks.

On Sun, May 10, 2020 at 10:46:15AM +0900, Ryutaroh Matsumoto wrote:
> If Devuan project has no intention/plan to deploy CI, then autpkgtest and debci can be simply banned...

I just think nobody has provided the necessary autopkgtest templates.

Are you able to prepare them? I am not aware that we have anybody on teh dev
team who actively uses lxc.

Thanks

Mark

Message #15 received at 450@bugs.devuan.org (full text, mbox, reply):

Hi Mark, thanks again for your attention and response.

>> If Devuan project has no intention/plan to deploy CI, then autpkgtest and debci can be simply banned...
> I just think nobody has provided the necessary autopkgtest templates.
> Are you able to prepare them? I am not aware that we have anybody on teh dev
> team who actively uses lxc.

I'm unsure, but at least I can try...

Do you think someone in Devuan project has interest in CI and/or
autopkgtest all packages?
Automated continuous application of autopkgtest on all packages
will sqeeze out unknown bugs in Devuan, but having a
machine(s) running autopkgtest may be an obstacle.

I am happily using Google Cloud Platform Compute Engine
with 640MB RAM and 30GB storage costing absolutely no money,
but I strongly doubt if 640MB RAM and 30GB storage are
enough for continuous autopkgtest...

Best regards, Ryutaroh

Message #20 received at 450@bugs.devuan.org (full text, mbox, reply):

On Sun, May 10, 2020 at 06:23:10PM +0900, Ryutaroh Matsumoto wrote:
> Hi Mark, thanks again for your attention and response.
> 
> >> If Devuan project has no intention/plan to deploy CI, then autpkgtest and debci can be simply banned...
> > I just think nobody has provided the necessary autopkgtest templates.
> > Are you able to prepare them? I am not aware that we have anybody on teh dev
> > team who actively uses lxc.
> 
> I'm unsure, but at least I can try...

Thanks

> Do you think someone in Devuan project has interest in CI and/or
> autopkgtest all packages?

We currently use https://jenkins.devuan.dev for our package building. Sources
are in git. However, the vast majority of packages are used directly from Debian
by redirection. We only fork and compile sources that need modification. This is
significantly different from most (all?) other Debian derivatives.

> Automated continuous application of autopkgtest on all packages
> will sqeeze out unknown bugs in Devuan, but having a
> machine(s) running autopkgtest may be an obstacle.
> 
> I am happily using Google Cloud Platform Compute Engine
> with 640MB RAM and 30GB storage costing absolutely no money,
> but I strongly doubt if 640MB RAM and 30GB storage are
> enough for continuous autopkgtest...

Yes, I doubt that too. I am certainly not aware of anybody looking at this, but
if you are interested in it and think that would benefit, do come and get
involved implementing it.

Thanks.

Mark

Message #25 received at 450@bugs.devuan.org (full text, mbox, reply):

Ryutaroh,

Since you are now submitting autopkgtest results (for which, thanks). Is this
bug resolved and closable?

Thanks.

Mark

Message #30 received at 450@bugs.devuan.org (full text, mbox, reply):

Hi Mark,

I used autopkgtest QEMU, which does more through tests than LXC.
autopkgtest LXC does not work, as far as I see.
(Specifically, testbed for LXC must be made by hand).

Some tests are skipped if LXC is used with autopkgtest.
All tests are done when QEMU is used with autopkgtest,
but it is much slower and consumes much more memory than LXC.

Best regards, Ryutaroh

From: Mark Hindley <mark@hindley.org.uk>
Subject: Re: [devuan-dev] bug#450: autopkgtest: cannot build a testbed for LXC
Date: Fri, 22 May 2020 10:03:43 +0100

> Ryutaroh,
> 
> Since you are now submitting autopkgtest results (for which, thanks). Is this
> bug resolved and closable?
> 
> Thanks.
> 
> Mark

Send a report that this bug log contains spam.