mini_buildd.reprepro module

Run reprepro commands

Attention

reprepro: Fails with debian/ being a symlink in Debian native packages (Debian Bug #768046)

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 desirable anyway). However, as it’s a legal setup afaik it should work after all.

Attention

reprepro: Don’t switch to reprepro 5.4 yet (Debian Bug #1017983)

As of June 2023 5.4.2, this is still in experimental.

There are still db migration problems to be fixed. Furthermore, I regularly experience lockups in full testsuite runs.

Attention

reprepro (dist.py setup workaround): Can’t handle Ubuntu’s ddeb (Debian Bug #730572)

Note

reprepro: 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 (f.e., 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 “ls” command if this is the case, i.e., s.th. like:

mini-buildd-api ls ENDPOINT my-package

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

mini-buildd handles this gracefully; the API call ‘remove’, the API call ‘migrate’ and the API call ‘port’ 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.

mini_buildd.reprepro.LSBYCOMPONENT_EXAMPLE = '\nmbd-test-cpp | 20220530080821~test~SID+1 |           sid-test-unstable | main | source\nmbd-test-cpp | 20220530070229~test~SID+1 | sid-test-unstable-rollback0 | main | source\n'

For doc/tests only

class mini_buildd.reprepro.Ls(source, ls_output, codenames=None, version=None, min_version=None)

Bases: dict

>>> ls = Ls("mbd-test-cpp", LSBYCOMPONENT_EXAMPLE)

>>> ls.rollbacks()
{'sid-test-unstable-rollback0': {'version': '20220530070229~test~SID+1', 'component': 'main', 'architecture': 'source'}}
>>> ls.filter(ls, diststr="sid-test-unstable")
{'sid-test-unstable': {'rollbacks': {'sid-test-unstable-rollback0': {'version': '20220530070229~test~SID+1', 'component': 'main', 'architecture': 'source'}}, 'version': '20220530080821~test~SID+1', 'component': 'main', 'architecture': 'source'}}
>>> ls.filter(ls.rollbacks(), version="20220530070229~test~SID+1")
{'sid-test-unstable-rollback0': {'version': '20220530070229~test~SID+1', 'component': 'main', 'architecture': 'source'}}
enrich()
rollbacks(diststr=None)
filter(ls=None, diststr=None, version=None, raise_if_found='', raise_if_not_found='')
filter_rollbacks(diststr=None, **kwargs)
filter_all(**kwargs)
changes(diststr, version, ls=None, **kwargs)
class mini_buildd.reprepro.Reprepro(basedir)

Bases: object

Abstraction to reprepro repository commands

Locking

This implicitly provides a locking mechanism to avoid parallel calls to the same repository from mini-buildd itself. This rules out any failed call due to reprepro locking errors in the first place.

For the case that someone else is using reprepro manually, we also always run it with ‘–waitforlock’.

Ignoring ‘unusedarch’ check

Known broken use case is linux’ ‘make deb-pkg’ up to version 4.13.

linux’ native ‘make deb-pkg’ is the recommended and documented way to produce custom kernels on Debian systems.

Up to linux version 4.13 (see [l1], [l2]), this would also produce firmware packages, flagged “arch=all” in the control file, but actually producing “arch=any” firmware *.deb. The changes file produced however would still list “all” in the Architecture field, making the reprepro “unsusedarch” check fail (and thusly, installation on mini-buildd will fail).

While this is definitely a bug in ‘make deb-pkg’ (and also not an issue 4.14 onwards or when you use it w/o producing a firmware package), the check is documented as “safe to ignore” in reprepro, so I think we should allow these cases to work.

classmethod clean_exportable_indices(dist_dir)
reindex(distributions)

(Re-)index repository

Remove all files from repository that can be re-indexed via “reprepro export”, and remove all files that would not (i.e., stale files from removed distributions).

Historically, this would just remove ‘dists/’ completely. With the support of reprepro snapshots however, extra care must be taken that valid snapshots are not removed (as they are not reprepro-exportable) and stale snapshots (from removed distributions) are properly unreferenced in the database prior to removing. See doc for ‘gen_snapshot’ in reprepro’s manual.

check()
ls(source, **filter_options)
migrate(package, src_distribution, dst_distribution, version=None)
remove(package, distribution, version=None)
install(_changes, distribution)
install_dsc(dsc, distribution)
snapshots_dir(distribution)
snapshot_dir(distribution, name)
get_snapshots(distribution, prefix='')
gen_snapshot(distribution, name)
del_snapshot(distribution, name)