FAQ, Hints, Todos, Troubleshooting, Bugs

All todo items are in the sections they semantically belong to; this just brings them all together.

All todo items are prefixed:

Prefix Meaning
FAQ Frequently asked question.
DOC Hint to documentation missing.
BUG A known bug.
FEATURE A not-implemented feature that is most likely to come.
IDEA A not-implemented feature idea.

Todo

FAQ: Daemon prepare does not finish.

Increase entropy on the system, either using the physical mouse, keyboard, etc, or alternatively by installing haveged:

# apt-get install haveged

original entry

Todo

FAQ: Can’t prepare a source as key verification always fails.

You must add all keys the Release file is signed with.

To make absolutely sure, manually run s.th. like:

$ gpg --verify /var/lib/apt/lists/PATH_Release.gpg /var/lib/apt/lists/PATH_Release

for the Release in question to get a list of key ids the source is actually signed with.

original entry

Todo

BUG: eatmydata: Builds fail when linked with openvc

Only a problem in current (Jan 2014) sid. See [6].

original entry

Todo

BUG: For some distributions, schroot doesn’t work with systemd (/dev/shm).

See this [1] schroot bug for more information.

mini-buildd comes with a crude temporary workaround, see (and please read the comments in) /usr/share/doc/mini-buildd/examples/09bug728096shmfixer. Just symlink in schroot’s setup.d:

# cd /etc/schroot/setup.d
# ln -s /usr/share/doc/mini-buildd/examples/09bug728096shmfixer .

to enable.

original entry

Todo

FAQ: How to use foreign-architecture chroots with qemu.

Tested with ‘armel’ (other architectures might work as well, but not tested).

Install these additional packages:

# apt-get install binfmt-support qemu-user-static

You will need a version of qemu-user-static with [2] fixed.

In the Chroot configuration, add a line:

Debootstrap-Command: /usr/sbin/qemu-debootstrap

to the extra options. That’s it. Now just prepare && activate as usual.

original entry

Todo

BUG: debootstrap fails for <=lenny chroots on >=jessie host kernel (uname).

See [3]. This should ideally be worked around in debootstrap itself eventually.

mini-buildd comes with a workaround wrapper /usr/sbin/mbd-debootstrap-uname-2.6. Just add:

Debootstrap-Command: /usr/sbin/mbd-debootstrap-uname-2.6

to the chroot’s extra options to work around it (the default chroots created with the chroot wizard already include this workaround for lenny and etch chroots, btw).

Fwiw, this is due to older libc6 packaging’s preinst, which will meekly fail if uname -r starts with a two-digit version; i.e.:

FINE : 3.2.0-4-amd64      Standard wheezy kernel
FAILS: 3.10-2-amd64       Standard jessie/sid kernel
FAILS: 3.9-0.bpo.1-amd64  Wheezy backport of the jessie/sid kernel

original entry

Todo

BUG: Fails to build “all” packages with “build archall” flag set to arch “x” in case DSP has >= 1 arch “all” and >=1 arch “y” binary package

This is due to sbuild and in in more detail explained here [4].

A bad one-package workaround would be to change the “build archall” flag to arch “y”.

original entry

Todo

BUG: LVM chroots fail running lvcreate with ‘not found: device not cleared’

Unclear (?). See [5] or http://lists.debian.org/debian-user/2012/12/msg00407.html .

“–noudevsync” workaround makes lvcreate work again, but the chroot will not work later anyway later.

original entry

Todo

FAQ: Chroot creating fails due to missing arch in archive (partial mirror).

This might occur, for example, if you use a (local) partial mirror (with debmirror or the like) as mini-buildd archive that does not mirror the arch in question.

At the moment, all archives you add must provide all architectures you are going to support to avoid problems.

original entry

Todo

FAQ: sudo fails with “sudo: no tty present and no askpass program specified”.

Make sure /etc/sudoers has this line:

#includedir /etc/sudoers.d

(This is sudo’s Debian package’s default, but the administrator might have changed it at some point.)

original entry

Todo

BUG: reprepro fails with debian/ as symlink in Debian native packages

Please follow [6] for this subject.

In such a case, builds will be fine, but reprepro will not be able to install the package; you will only be able to see reprepro’s error “No section and no priority for” in the daemon.log.

For the moment, just avoid such a setup (which is imho not desireable anyway). However, as it’s a legal setup afaik it should work after all.

original entry

Todo

IDEA: Dependency check on package migration.

original entry

Todo

IDEA: Custom hooks (prebuild.d source.changes, preinstall.d/arch.changes, postinstall.d/arch.changes).

original entry

Todo

FAQ: aptitude GUI does not show distribution or origin of packages

To show the distribution of packages, just add %t to the package display format [3]. For example, I do prefer this setting for the Package-Display-Format:

aptitude::UI::Package-Display-Format "%c%a%M%S %p %t %i %Z %v# %V#";

The origin cannot be shown in the package display format [4]. However, you may change the grouping to categorize with “origin”. For example, I do prefer this setting for the Default-Grouping:

aptitude::UI::Default-Grouping "task,status,pattern(~S~i~O, ?true ||),pattern(~S~i~A, ?true ||),section(subdirs,passthrough),section(topdir)";

This will group installed packages into an Origin->Archive hierarchy.

Additionally to aptitude’s default “Obsolete and locally installed” top level category (which only shows packages not in any apt archive), this grouping also more conveniently shows installed package _versions_ which are not currently in any repository (check “Installed Packages/now”).

original entry

Todo

BUG: apt secure problems after initial (unauthorized) install of the archive-key package

  • aptitude always shows <NULL> archive

You can verify this problem via:

# aptitude -v show YOURID-archive-keyring | grep ^Archive
Archive: <NULL>, now
  • BADSIG when verifying the archive keyring package’s signature

Both might be variants of [5] (known to occur for <= squeeze). For both, check if this:

# rm -rf /var/lib/apt/lists/*
# apt-get update

fixes it.

original entry

Todo

FAQ: Multiple versions of packages in one distribution

This is not really a problem, but a uncommon situation that may lead to confusion.

Generally, reprepro does allow exactly only one version of a package in a distribution; the only exception is when installed in different components (e.g., main vs. non-free).

This usually happens when the ‘Section’ changes in the corresponding ‘debian/control’ file of the source package, or if packages were installed manually using “-C” with reprepro.

Check with the “show” command if this is the case, i.e., s.th. like:

$ mini-buildd-tool show my-package

you may see multiple entries for one distribution with different components.

mini-buildd handles this gracefully; the remove, migrate and port API calls all include an optional ‘version’ parameter to be able to select a specific version.

In the automated rollback handling, all versions of a source package are shifted.

original entry