Overview about piuparts

Description: .deb package installation, upgrading, and removal testing tool

piuparts is being run constantly on the main archive, the results are public on piuparts.debian.org. piuparts itself has a README and a piuparts manpage, for the piuparts.debian.org setup there is also an FAQ available. Below is an overview of information not covered elsewhere.

Developing piuparts

• alioth project: https://alioth.debian.org/projects/piuparts/

  • source code: Browse: https://alioth.debian.org/scm/browser.php?group_id=30965 Get: git clone git://anonscm.debian.org/piuparts/piuparts.git

  • mailing list: piuparts-devel@l.a.d.o

  • commit diff list: piuparts-commits@l.a.d.o

• todo

  • codebase related: http://anonscm.debian.org/gitweb/?p=piuparts/piuparts.git;a=blob;f=TODO;hb=HEAD

  • piuparts.debian.org related: http://anonscm.debian.org/gitweb/?p=piuparts/piatti.git;a=blob;f=README.txt;hb=HEAD

• there was a SummerOfCode2007/PiupartsImprovements

• code analysis and more on ohloh

Developing piuparts, the rewrite of version 2

• stalled at planning stage

• in bzr: bzr get http://code.liw.fi/piuparts2/bzr/trunk/ (may move to bzr.debian.org later)

From the BoF at Debconf9

• new output format: http://lists.debian.org/debian-devel/2009/07/msg00662.html

• piuparts should not fail just because dependencies fail

How piuparts is setup on piuparts.debian.org

Running piuparts is the boring, automated part and is supervised by Luk and Holger, who can su into the piupartss (slave) user. piuparts-slave is run in a shared screen session and seldom needs interaction. The piupartss user needs to be able to run piuparts and thus can use sudo without restrictions.

The slave automatically starts the master, to reserve packages to process and to pass logfiles to the master.

Ideally all members of the Debian-QA group can su to the piupartsm user and process the logfiles - currently it's again only Luk and Holger. piupartsm has no special privileges. If you want to help, please join #debian-qa and say so there.

Once a day piuparts-reports is run as piupartsm by cron to generate the html output of the logs.

For more information see http://anonscm.debian.org/gitweb/?p=piuparts/piatti.git;a=blob;f=README.txt;hb=HEAD

Machine info

• piuparts.cs.helsinki.fi aka piatti.debian.org aka piuparts.debian.org

• hosted at Department of Computer Science, University of Helsinki

• donated by HP

• dual AMD Opteron(tm) Processor 275, 2.2 Ghz
• 8GB RAM
• 300 GB physical volume for data
• currently capable of testing sid in 3 days and squeeze in 12. using schroot and lvm snaspshots this can be improved, but filing bugs and adding more tests (see the bts...) is more important and interesting today for me.

Howto setup a piuparts test-instance for development

*most of this is still to be written*

Setup a private repo

To be able to run piuparts on packages outside the archive, they need to be in a repository, which is available via http.

A private repo can be created with reprepro. TODO how

Create pbuilder tarballs

This step cna be skipped, but if you create tarballs with pbuilder first, creating the initial chroot is faster, because there is no need for a debootstrap each time.

For each distro (eg wheezy) and each arch (eg amd64), create a configfile.

/etc/pbuilder/pbuilderrc.i386-wheezy:

ARCHITECTURE=i386
DISTRIBUTION=wheezy
BASETGZ=/var/cache/pbuilder/base-$DISTRIBUTION-$ARCHITECTURE.tgz
BUILDRESULT=/var/cache/pbuilder/result-$DISTRIBUTION-$ARCHITECTURE

MIRRORSITE=http://ftp.de.debian.org/debian

PKGNAME_LOGFILE_EXTENTION=.buidlog

Then just run

pbuilder --create --configfile /etc/pbuilder/pbuilderrc.i386-wheezy

run install test

run upgrade test squeeze2wheezy

run upgrade test lenny2squeeze2wheezy

CategoryPermalink