Contents

  1. Overview about piuparts
  2. Developing piuparts
  3. Developing piuparts, the rewrite of version 2
    1. From the BoF at Debconf9
  4. How piuparts is setup on piuparts.debian.org
    1. Machine info
  5. Howto setup a piuparts test-instance for development
    1. Setup a private repo
    2. Create pbuilder tarballs
    3. run install test
    4. run upgrade test squeeze2wheezy
    5. run upgrade test lenny2squeeze2wheezy
    6. run custom scripts

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

Developing piuparts, the rewrite of version 2

From the BoF at Debconf9

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

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

In this example, /ram is a ramdisk which is large enough to do the piuparts run.

run_piuparts_squeeze2wheezy: 

#! /bin/bash

PKG=$1
LOCALREPO=http://localhost/debian

piuparts \
 --tmpdir=/ram \
 --warn-on-others \
 --no-eatmydata \
 --warn-on-leftovers-after-purge \
 --skip-logrotatefiles-test \
 --scriptsdir /etc/piuparts/scripts \
 -d squeeze \
 -d wheezy \
 -m http://ftp.de.debian.org/debian/ \
 -m ${LOCALREPO} \
 --do-not-verify-signatures \
 -b /var/cache/pbuilder/base-squeeze-i386.tgz \
 --apt \
 $PKG | tee ${PKG}.`date +%s`.log

run upgrade test lenny2squeeze2wheezy

run custom scripts

CategoryPermalink