All todo items are in the sections they semtically 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-impl feature that is most likely to come. |
IDEA | A not-impl 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
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 222.)
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.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 245.)
Todo
IDEA: Allow pseudo distributions “unstable” in changes (aka ‘Debian Developer mode’).
This would practically mean you could use a dedicated, private mini-buildd repository to upload the very same package designed for a proper Debian upload to mini-buildd first for QA purposes. Maybe there are other uses as well...
Currently, we are bound to the triple CODENAME-REPOID-SUITE as distribution in changes files to identify the repository from incoming. A global (i.e., not per repository) additional mapping would be needed, like ‘unstable’ -> sid-myrepo-sid.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 276.)
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 [1] 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.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 337.)
Todo
BUG: debootstrap fails for <=lenny chroots on >=jessie host kernel (uname).
See [2]. 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
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 353.)
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 [3].
A bad one-package workaround would be to change the “build archall” flag to arch “y”.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 373.)
Todo
BUG: Lvm chroots fail running lvcreate with ‘not found: device not cleared’
Unclear (?). See [4] 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.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 379.)
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.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 386.)
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.)
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 395.)
Todo
FEATURE: Chroot maintenance (apt-update, fs checks).
[REGR] 0.8.x path: ‘lib/chroots-update.d/10_apt-upgrade.hook’.
Regular apt-update for source chroots would be nice to have, especially for rolling distribution like unstable/sid or testing. fs checks would only really make sense for LVM chroots.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/admin.rst, line 404.)
Todo
IDEA: Dependency check on package migration.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/user.rst, line 61.)
Todo
IDEA: Custom hooks (prebuild.d source.changes, preinstall.d/arch.changes, postinstall.d/arch.changes).
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/user.rst, line 63.)
Todo
BUG: lintian version from host is used for all distributions
We use sbuild’s –run-lintian option, which is currently runs lintian from the host, see [1].
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/user.rst, line 73.)
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 [2]:
aptitude::UI::Package-Display-Format "%c%a%M%S %p %t %Z %v %V";
The origin cannot be shown in the package display format [3]. However, you may change the “default grouping” to categorize with “origin”. I prefer this:
aptitude::UI::Default-Grouping "task,status,pattern(~S~i~O, ?true ||),pattern(~S~i~A, ?true ||),section(subdirs,passthrough),section(topdir)";
setting which will group installed packages in “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 conveniently shows installed package _versions_ which are not currently in any repository (check “Installed Packages/now”).
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/user.rst, line 78.)
Todo
BUG: apt secure problems after initial (unauthorized) install of the archive-key package
You can verify this problem via:
# aptitude -v show YOURID-archive-keyring | grep ^Archiv
Archiv: <NULL>, now
Both might be variants of [4] (known to occur for <= squeeze). For both, check if this:
# rm -rf /var/lib/apt/lists/*
# apt-get update
fixes it.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/user.rst, line 100.)
Todo
FAQ: Multiple versions of a 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 package 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.
(The original entry is located in /mnt/host/home/absurd/src/debian/mini-buildd/mini-buildd/build/sphinx/user.rst, line 119.)