mini_buildd.schroot module

Attention

wheezy or older builds on amd64: Re-enable linux’ vsyscall

In Debian kernel packages since 4.8.4-1~exp1:

[ Ben Hutchings ]
* [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE.
  This breaks (e)glibc 2.13 and earlier, and can be reverted using the kernel
  parameter: vsyscall=emulate

I.e.: When running the Debian standard kernel and your mini-buildd instance needs to support wheezy or earlier, you need to re-enable this (in /etc/default/grub).

You may use local-vsyscall-emulate.cfg in examples (a symlink should do) for this purpose.

On any running kernel, this is a poor man’s check to see if vsyscall is still enabled on your system:

grep "\[vsyscall\]" /proc/self/maps

See also

Debian Bug #847154, linux package’s NEWS file.

Note

schroot: Verbosely logs commands (“Running command …”) explicitly via syslog (journalctl)

schroot seems to verbosely log any executed root-user command via syslog (user/notice). This will clutter journalctl’s (standard) log output via unit:

journalctl --unit mini-buildd.service --follow

As a workaround, specifying the (syslog compatibility) identifier like so helps to unclutter:

journalctl --identifier mini-buildd --follow

class mini_buildd.schroot.Session(name, namespace='chroot')

Bases: object

close()

Close session (including retries on failure)

Attention

schroot: ‘target is busy’ on session close (stale schroot sessions)

Occasionally, a schroot session can’t be closed properly, leaving stale sessions around. Presumably, external programs (like ‘desktop mount scanners’) can cause this.

This internal close does try hard to avoid this – however, if disaster strikes anyway, mini-buildd-cruft may help to remove these stale sessions manually (i.e., as mini-buildd user from the shell).

call(_call, user='root')

run(_call, user='root')

info()

update_file(file_path, content)

Write content to file

set_debconf(key, value)

Set arbitrary debconf value