% % preview (shell-command (concat "xpdf " (replace-regexp-in-string "tex$" "pdf"(buffer-file-name)) "&")) \documentclass[a4paper]{article} \usepackage{graphicx} \usepackage{url} \usepackage{wrapfig} \begin{document} \section{What's up with pbuilder?} This is a document to explain what is pbuilder, what has been happening recently with pbuilder, and what will probably happen in the near future. \subsection{Concepts of using pbuilder} \begin{wrapfigure}{rt}{0.25\hsize}\includegraphics[width=1\hsize]{pbuildercycle.eps}\end{wrapfigure} pbuilder facilitates clean-room environment testing of package building through using a chroot image and extracting a fresh chroot image for every build. There are several simple commands for operation. \texttt{pbuilder create}, \texttt{pbuilder update}, and \texttt{pbuilder build}\footnote{pdebuild command is often more convenient} commands are the typical commands used. If you need more details, see pbuilder manual, \url{/usr/share/doc/pbuilder/pbuilder-doc.html} When everything is set, \texttt{pbuilder build} will accept \texttt{.dsc} file (the Debian source-package) and build the package inside the chroot. \begin{table}[h] \begin{tabular}{|l|l|l|} \hline operation & operation frequency & context \\ \hline create & once per base.tgz & create the base filesystem \\ update & once per day (unstable update) & update the base filesystem \\ build & once per package & build the Debian package inside chroot \\ \hline \end{tabular} \end{table} Let me examine a typical sequence of events in a day of a Debian Developer. %\begin{wrapfigure}{rt}{0.4\hsize}\includegraphics[width=1\hsize]{develcycle.eps}\end{wrapfigure} \begin{center} \includegraphics[width=0.6\hsize]{develcycle.eps} \end{center} pbuilder is built in to the process as a checking system to ensure package quality. \footnote{This is an example. Some people do not build package locally and entirely work inside chroots.} This is useful for initial testing of Build-Dependency, and as basic regression testing framework. \subsection{pbuilder Development structure} Let me mention a little bit about how pbuilder itself is developed. Currently pbuilder is co-maintained using resources provided by Alioth. Development is done mostly by Lo\"ic Minier and Junichi Uekawa, and occasional commits from Matt Kraai, and Mattia Dongili. Project page is available at \url{http://alioth.debian.org/projects/pbuilder} and home page is available at, \url{http://pbuilder.alioth.debian.org/} which provides the pbuilder manual. git is used for source code management, and the repository can be checked out by any of the following commands\footnote{ssh access requires account on alioth}. \begin{verbatim} git-clone git://git.debian.org/git/pbuilder/pbuilder.git git-clone http://git.debian.org/git/pbuilder/pbuilder.git git-clone ssh://git.debian.org/git/pbuilder/pbuilder.git \end{verbatim} \subsection{Derivatives and their status} There are several derivatives of pbuilder supporting different 'backends'. They use different methods for providing a clean-room environment. Let me explain some of them. \subsubsection{LVM port} Someone did a port to using LVM snapshot for base.tgz-management. There was some e-mailing, but not quite gone into pbuilder. LVM method still uses chroot as the method for segregation. The advantage is that LVM snapshot process is much faster than extracting a tar archive for base image. \subsubsection{user-mode-linux port} pbuilder-uml port exists. Apparently, it is working for most people. Mattia Dongili and others have been actively working on this port. base.tgz extraction is replaced with UML cow device support, and thus is faster. chroot is replaced with user-mode-linux session, which makes system calls a bit slower. \subsubsection{cowdancer port} Junichi Uekawa has been working on the port to cowdancer since 2005, and it is somewhat stable. This replaces base.tgz extraction with \texttt{cp -la }, which is much faster. Because of the way cowdancer hooks libc calls like open/close, it may interfere with package building. \footnote{etch release unfortunately was faced with Bug 413912} \subsubsection{qemu port} Junichi Uekawa has been working on the port to qemu/kqemu/kvm since early 2007. QEMU has COW block device support, so it eliminates the need to extract base.tgz. qemu port has an interesting advantage in that it adds cross-architecture-building support for pbuilder. I can potentially build and test ARM packages on my i386 box. \subsection{Further development ideas} \subsubsection{Installation testing} There are other projects such as piuparts which can be leveraged by pbuilder. pbuilder does provide example script for testing installation: \url{/usr/share/doc/pbuilder/examples/execute_installtest.sh}. \begin{verbatim} pbuilder execute \ /usr/share/doc/pbuilder/examples/execute_installtest.sh \ pbuilder \end{verbatim} This command will try to install the package using apt-get into the chroot. \subsubsection{Package testing} Package testing is a feature that is usually useful, especially since developer time is limited, and repeated manual testing is no fun. pbuilder includes an example hook script \url{/usr/share/doc/pbuilder/examples/B92test-pkg} which will test package after a successful build. The test files are shell scripts placed in \verb!debian/pbuilder-test/NN_name! (where NN is number) following run-parts standard for file names \footnote{no '.' in file names!}. \subsubsection{aptitude} pbuilder exclusively depends on apt-get. It might be time to look at what is missing to get aptitude working. \subsubsection{apt-key support} pbuilder currently lacks apt-key support. Since apt-key support is definitely available in the current stable releases, it is about time to start considering supporting apt-key. \subsubsection{build-dependency parser} Build-dependency parser has been somewhat old and suboptimal. Lo\"ic Minier has been working on refreshing it. \subsubsection{buildd.net-like support} pbuilder creates a bunch of useful build logs, but it lacks the notion of history. It does not have an infrastructure to aggregate and put them to use. \footnote{Some projects to create \texttt{pbuildd} did exist, but I am not sure if it still exists today. } Collecting past build logs even locally and comparing them between builds may alert problems, used in conjunction with tools like debdiff. \subsection{References} \begin{itemize} \item \url{http://pbuilder.alioth.debian.org/} or \url{/usr/share/doc/pbuilder/pbuilder-doc.html}: pbuilder manual \item cowdancer package \item piuparts package \item autodebtest: Ubuntu automatic testing system \item schroot / dchroot \item buildd \end{itemize} \end{document}