1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394
|
Host dependencies
=================
Most parts of autopkgtest run on some host system, such as a developer's
workstation, Debian's ci.debian.net, or Ubuntu's equivalent.
Relevant components include:
- lib/, except for lib/in-testbed/
- runner/
- ssh-setup/
- tests/
- tools/
- virt/
- debian/rules
For these components, we can safely depend on reasonably new libraries and
Python. For example, if a Debian LTS developer runs autopkgtest on their
Debian 12 system to test Debian 10 LTS, then these components are run in
Debian 12.
To make backports easy, we aim to limit the dependencies of
pre-existing features to:
- latest Debian stable (for ci.debian.net, and Debian developers)
- latest Ubuntu LTS (for Ubuntu infrastructure and developers)
As of mid 2023, this means Debian 12, Ubuntu 22.04 and Python 3.10.
If it's straightforward to avoid a newer dependency without too much
extra code, we can consider extending that to:
- previous Debian stable
- previous Ubuntu LTS
As of mid 2023, this means Debian 11, Ubuntu 20.04 and Python 3.8.
If it becomes necessary to raise these minimum requirements for the
host system in a future version of autopkgtest, then users of older
distributions will need to use a correspondingly older version of
autopkgtest.
New features might require newer packages: for example, during
development of Debian 12, the new -virt-unshare backend required a Debian
12 prerelease and was not runnable on Debian 11, but other backends
continued to be available on Debian 11.
Testbed dependencies
====================
Some parts of autopkgtest run inside the testbed:
- lib/in-testbed/
- setup-commands/
- shell snippets inlined into various places
- the eofcat Python script inlined into -virt-qemu
For example, if a Debian LTS developer runs autopkgtest on their Debian 12
system to test Debian 10 LTS, then these components are run in Debian 10.
This means we aim to be more conservative about the dependencies of this
category of code.
To keep autopkgtest useful for the developers of long-term support efforts
like Debian/Freexian (E)LTS, Ubuntu ESM, and third-party distributions
based on an older Debian or Ubuntu branch, we aim to limit the dependencies
of this code to:
- Debian 8 'jessie' (2015)
* apt 1.0.9.8.4
* python3 3.4
- Ubuntu 14.04 'trusty' (2014)
* apt 1.0.1
* python3 3.4
whichever one has the older version of whatever component is relevant.
Some notable features that we cannot rely on as a result of this policy:
- sources.list.d/*.sources (since apt 1.1: Debian 9, Ubuntu 16.04)
- signed-by=/path/to/keyring (since apt 1.1)
- embedding PGP keys directly into Signed-By
(since apt 2.3.10: Debian 12, Ubuntu 22.04)
If an autopkgtest change causes these older testbed suites to regress,
developers working on these older suites are invited to contribute tested
fallback code paths for them.
Some non-essential features have higher requirements:
* testing packages from a foreign architecture: apt 1.9.0
(Debian 11 / Ubuntu 20.04)
If it becomes necessary to raise these minimum requirements for a
testbed in a future version of autopkgtest, then maintainers of older
long-term-supported distributions will need to use an older version of
autopkgtest to test their distributions.
Testing autopkgtest backends
============================
This is a cheat-sheet for developers of autopkgtest who do not have any
particular requirements for the packages under test or the containers in
which they are tested, and just want to prove that the various backends
still work.
The current working directory is assumed to be the autopkgtest source
code. Omit the ./runner/ and ./tools/ prefixes to test the system copy.
All examples refer to testing the 'util-linux' source package on amd64, in
either Debian 11 'bullseye' or Ubuntu 22.04 'jammy'. Adjust as necessary
for the distribution, architecture and package you actually want to test.
util-linux is a convenient example of an Essential package with only
trivial test coverage and few test-dependencies, hence quick to test.
Commands prefixed with # need to be run as root, commands prefixed with $
can be run as an ordinary user.
Run all this in a virtual machine if you don't want to run as root on
the host system (for qemu this requires nested KVM).
null
----
No setup required, but you are responsible for installing build-
and/or test-dependencies yourself.
$ ./runner/autopkgtest util-linux -- null
To run unit tests:
# apt-get install autopkgtest autodep8 build-essential debhelper
$ ./tests/autopkgtest NullRunner
# ./tests/autopkgtest NullRunnerRoot
chroot
------
This backend is not recommended (schroot is usually preferable).
Automated test (this is run as part of the 'autopkgtest' test-case in
d/tests/control):
# apt-get install autopkgtest autodep8 build-essential debhelper
# ./tests/autopkgtest ChrootRunner
schroot
-------
# apt install debootstrap schroot sbuild
# mkdir /srv/chroot
# sbuild-createchroot \
--arch=amd64 \
bullseye \
/srv/chroot/bullseye-amd64-sbuild
(if you are in the sbuild group)
$ ./runner/autopkgtest util-linux -- schroot bullseye-amd64-sbuild
(or if you are unprivileged)
# ./runner/autopkgtest util-linux -- schroot bullseye-amd64-sbuild
Or for Ubuntu:
# apt install ubuntu-keyring
# sbuild-createchroot \
--arch=amd64 \
jammy \
/srv/chroot/jammy-amd64-sbuild
# ./runner/autopkgtest util-linux -- schroot jammy-amd64-sbuild
Automated test:
# apt-get install autopkgtest autodep8 build-essential debhelper
$ AUTOPKGTEST_TEST_SCHROOT=bullseye-amd64-sbuild \
./tests/autopkgtest SchrootRunner
docker
------
# apt-get install --no-install-recommends docker.io python3-distro-info uidmap
# ./tools/autopkgtest-build-docker --release=bullseye
# ./runner/autopkgtest docker -- autopkgtest/debian:bullseye
Or for Ubuntu (specify --vendor=ubuntu if your python3-distro-info is out
of date):
# ./tools/autopkgtest-build-docker --release=jammy
# ./runner/autopkgtest docker -- autopkgtest/ubuntu:jammy
To run unit tests:
# AUTOPKGTEST_TEST_DOCKER=autopkgtest/debian:bullseye ./tests/autopkgtest DockerRunner
incus
-----
incus is currently only available from an upstream repository
(https://github.com/zabbly/incus), but there is an ITP for Debian
(https://bugs.debian.org/1042989).
# apt install incus
# incus init
(for a simple throwaway setup, accept all defaults)
To let unprivileged users access lxd:
# adduser user incus-admin
or use sudo.
$ ./tools/autopkgtest-build-incus images:debian/bullseye/amd64
$ lxc image list
(you will see autopkgtest/debian/bullseye/amd64 listed)
$ ./runner/autopkgtest util-linux -- incus autopkgtest/debian/bullseye/amd64
Or for Ubuntu:
$ ./tools/autopkgtest-build-incus ubuntu:jammy
$ lxc image list
(you will see autopkgtest/ubuntu/jammy/amd64 listed)
$ ./runner/autopkgtest util-linux -- incus autopkgtest/ubuntu/jammy/amd64
Automated test:
$ apt-get install autopkgtest autodep8 build-essential debhelper
$ AUTOPKGTEST_TEST_INCUS=autopkgtest/debian/bullseye/amd64 ./tests/autopkgtest IncusRunner
lxc
---
This assumes lxc (>= 1:4.0.2-1). Older versions require the lxcbr0 network
bridge to be set up manually.
# apt-get install --no-install-recommends \
ca-certificates debootstrap libpam-cgfs lxc lxcfs lxc-templates rsync uidmap
# ./tools/autopkgtest-build-lxc debian bullseye amd64
# ./runner/autopkgtest util-linux -- lxc autopkgtest-bullseye-amd64
(or)
$ ./runner/autopkgtest util-linux -- lxc --sudo autopkgtest-bullseye-amd64
Or for Ubuntu:
# ./tools/autopkgtest-build-lxc ubuntu jammy amd64
# ./runner/autopkgtest util-linux -- lxc autopkgtest-jammy-amd64
To run unit tests:
# AUTOPKGTEST_TEST_LXC=autopkgtest-bullseye-amd64 ./tests/autopkgtest LxcRunner
(Users who can sudo can run the automated test as non-root.)
lxd
---
lxd is available in Debian bookworm or newer, and in Ubuntu.
# apt install lxd
In older Debian releases it is available from third-party snap repositories.
# apt install snapd
(log out and back in to add /snap/bin to PATH)
# snap install lxd
(if you will be running it via sudo)
# ln -s /snap/bin/lxc* /snap/bin/lxd* /usr/local/bin/
# lxd init
(for a simple throwaway setup, accept all defaults)
To let unprivileged users access lxd:
# adduser user lxd
or use sudo.
$ ./tools/autopkgtest-build-lxd images:debian/bullseye/amd64
$ lxc image list
(you will see autopkgtest/debian/bullseye/amd64 listed)
$ ./runner/autopkgtest util-linux -- lxd autopkgtest/debian/bullseye/amd64
Or for Ubuntu:
$ ./tools/autopkgtest-build-lxd ubuntu:jammy
$ lxc image list
(you will see autopkgtest/ubuntu/jammy/amd64 listed)
$ ./runner/autopkgtest util-linux -- lxd autopkgtest/ubuntu/jammy/amd64
Automated test:
$ apt-get install autopkgtest autodep8 build-essential debhelper
$ AUTOPKGTEST_TEST_LXD=autopkgtest/debian/bullseye/amd64 ./tests/autopkgtest LxdRunner
podman
------
Most (all?) of podman's Recommends are necessary: at least slirp4netns and
uidmap are required when running as non-root.
# apt-get install --install-recommends podman python3-distro-info
With those, you can run podman unprivileged:
$ ./tools/autopkgtest-build-podman --release=bullseye
$ ./runner/autopkgtest podman -- autopkgtest/debian:bullseye
Or for Ubuntu (as for Docker, specify --vendor=ubuntu if your
python3-distro-info is out of date):
$ ./tools/autopkgtest-build-podman --release=jammy
$ ./runner/autopkgtest podman -- autopkgtest/ubuntu:jammy
For the mode in which we run a full init system in the container:
$ ./tools/autopkgtest-build-podman --release=bullseye --init=systemd
$ ./runner/autopkgtest podman -- autopkgtest/systemd/debian:bullseye
Or try sysv-rc or openrc instead of systemd.
To run unit tests:
$ AUTOPKGTEST_TEST_PODMAN=autopkgtest/debian:bullseye ./tests/autopkgtest PodmanRunner
$ AUTOPKGTEST_TEST_PODMAN_INIT=autopkgtest/systemd/debian:bullseye ./tests/autopkgtest PodmanInitRunner
qemu
----
This can be done in a VM:
# apt install qemu-utils vmdb2
# ./tools/autopkgtest-build-qemu bullseye ./bullseye.qcow2
This can be done in a VM if you have nested KVM enabled, or on the host
system. The unprivileged user needs write access to /dev/kvm (add them to
the kvm group if they are not going to be logged-in locally), but no
other privileges.
# apt install qemu-system-x86 qemu-utils
$ ./runner/autopkgtest util-linux -- qemu ./bullseye.qcow2
autopkgtest-build-qemu doesn't currently work to build Ubuntu images,
because vmdb2 assumes grub-install supports the --force-extra-removable
option, but Ubuntu's grub-install doesn't have that option.
Instead use a cloud image, which can be done unprivileged:
$ ./tools/autopkgtest-buildvm-ubuntu-cloud --release=jammy
$ ./runner/autopkgtest util-linux -- qemu ./autopkgtest-jammy-amd64.img
(If you're running a VM inside a VM, you might need to pass something
like --ram-size=512 after the qemu argument to make the inner VM use
strictly less memory.)
To run unit tests (WIP, currently expected to fail):
$ AUTOPKGTEST_TEST_QEMU=./bullseye.qcow2 ./tests/autopkgtest QemuRunner
ssh (without a setup script)
----------------------------
Prepare 'machine' however you want to, then:
$ autopkgtest util-linux -- ssh -H machine
TODO: Document automated test
unshare
-------
sbuild-createchroot is a convenient way to create the tarball:
$ sbuild-createchroot --chroot-prefix=unshare --chroot-mode=unshare \
--make-sbuild-tarball ~/.cache/sbuild/bullseye-amd64.tar.gz \
bullseye $(mktemp -d --suffix=.createchroot)
The unshare backend requires unshare(1) from util-linux 2.38 or later.
On a Debian 11 system, this can be compiled from source if necessary:
$ cd util-linux-2.38
$ dpkg-buildpackage -us -uc -B
$ install -D ./unshare ~/.local/bin/unshare
$ export PATH="$HOME/.local/bin:$PATH"
Then to use autopkgtest:
$ ./runner/autopkgtest util-linux -- unshare -r bullseye
Note that as of Debian 11, the sbuild-createchroot command does not update
deb-src apt sources, so a setup command might be necessary:
$ ./runner/autopkgtest --U util-linux -- unshare -r bullseye
(or more minimally)
$ ./runner/autopkgtest --setup-commands='apt-get -y update' \
util-linux -- unshare -r bullseye
Automated test:
# apt-get install autopkgtest autodep8 build-essential debhelper
$ AUTOPKGTEST_TEST_UNSHARE="$HOME/.cache/sbuild/bullseye-amd64.tar.gz" \
./tests/autopkgtest UnshareRunner
|