Quick tinderbox setup for testing FreeBSD ports

The proposed text is addressed primarily to FreeBSD ports maintainers and committers themselves, but even if you haven’t yet sent any ports of the ports category, but are going to do it, or simply don’t mind learning about QA methods for the ports collection, I think you will It will be interesting.



Actually, this is MarcusCom Tinderbox - a set of scripts written by Marcus Clarke associates based on those used to build official FreeBSD packages.



In short, it works like this: you specify a set of basic systems (base system in FreeBSD terminology; not necessarily a release, it can be any stable branch or -CURRENT, or even your own build), port trees and builds (combinations of the first two). Then, in a pure chroot environment, you can assemble any port as a packet, and make sure you don’t miss anything: all dependencies are taken into account, everything is correctly assembled, put and removed, without leaving anything superfluous in the system. All meta information is stored in the database (MySQL and PostgreSQL are supported), there are advanced tools for updating ports and the “substrate” of the target system, caching the assembled packages and distfiles, support for ccache and even PHP web frontend.



In fact, the installation, configuration, and usage examples are described in some detail in the documentation , but only a few use the tinderbox regularly.

')

Why?

The point here, it seems to me, is that the authors are far from first thinking about simple developers who do not need anything more complicated than just testing their port on a particular version of FreeBSD. No need to collect statistics for each port (build-logs, error types, when the last time “everything worked”, etc.) and store it. Few really need web access and tinderd service.



In this sense, the initial requirements are unreasonably high. For first of all, a person who wants to quickly test their changes before committing or sending PR (and not deploying a build farm with a full collection of statistics and then distributing it “directly to the web”) raises the question: why do I need a database at all?



A typical FreeBSD user on a desktop will most likely not have any * SQL other than SQLite. Putting MySQL or PostgreSQL just for the sake of the tinderbox is just silly for general reasons. Fortunately, quite recently the project was forknook in order to improve it (the official repository has not been updated for a long time), and SQLite support was added first. For some reason unknown to me, the author deleted all his repositories on the githaba. You can download the .git directory, unpack it and execute the git reset --hard . Now you can deploy the tinderbox in literally five to ten minutes.



Update: Recently, SQLite support has appeared in the official repository .

For the cause!

We clone the repository into a directory with a short convenient name tb and switch to the sqlite_support branch (besides, we will create scripts link to the current directory, since we will work directly in it):

 git clone https://github.com/markjdb/tinderbox-WORK.git tb cd tb git checkout sqlite_support ln -s . scripts 

At once I will make a reservation that the following commands are supposed to be executed from under the root in order to avoid potential problems (although this is not always necessary).



Now you need to initialize the tinderbox settings, answering a few simple questions (choose sqlite as the base and set the file name):

 ./tc Setup 

The script will warn that we have not installed some dependencies, but most of them are needed for the web-frontend. We only need p5-DBD-SQLite and lftp . If you plan to support, for example, -STABLE branches and update them with csup(1) , and then build through make world , you need to create the tb/scripts/etc/env/GLOBAL ./tc init running ./tc init , but we have enough releases , which we will take via FTP, so you can skip this step.



Now we need to create what I described above as a substrate (in the original jails) of all versions of FreeBSD for which we want to build packages. They have nothing to do with jail(8) , in this case it is just a matching name, so I did not translate it literally. At the heart of the tinderbox are only chroot(8) and mounting over NFS or nullfs (preferably, since there is no need to configure anything). I think, for starters, we limit ourselves to the latest releases of two stable branches:

 ./tc createJail -j 7.4 -t 7.4-RELEASE -u LFTP -H ftp.freebsd.org ./tc createJail -j 8.2 -t 8.2-RELEASE -u LFTP -H ftp.freebsd.org 

Names must begin with the main FreeBSD version number (the same applies to build names, see below). As a host (the -H parameter), it makes sense to substitute the address of the nearest mirror (we only need distsets of base , dict , proflibs and src ).



Now we need to add our working ports tree - not /usr/ports , but which checkout is from Subversion (or, in the old way, from CVS) and from where we will create diffs for send-pr(1) or commit. Let it be the directory /home/alice/fbsd/ports called wip (work in progress):

 ./tc createPortsTree -p wip -u NONE -m /home/alice/fbsd/ports 

The -u NONE option is not accidental: we explicitly state that it is not necessary to update the ports tree; usually we update it ourselves through cvs^Wsvn up (this is our working tree). There can be several trees, as well as substrates, but most often it is one on the machine of an ordinary ports hacker.



However, we are almost there. It remains to build builds: combinations of the substrate and the ports tree. Because we have two releases (7.4 and 8.2) and one tree (wip), then there will be two builds too:

 ./tc createBuild -b 7.4-wip -j 7.4 -p wip ./tc createBuild -b 8.2-wip -j 8.2 -p wip 

If we did something wrong (for example, we entered incorrect parameters in some of the commands), and the record has already got into the database, we will need to manually (using sqlite3 tinderbox.db ) delete the corresponding records (usually from the jails , ports_trees tables ports_trees or builds ).



It is logical to use the existing cache as the local cache of distfiles:

 ./tc configDistfile -c /usr/ports/distfiles 

Actually, everything! We are ready to build our first package in the tinderbox. Let's collect, for example, nmap for FreeBSD-7.4 (indicating that we prefer to mount directories through nullfs and consider problems with pkg-plist fatal errors):

 ./tc tinderbuild -nullfs -plistcheck -b 7.4-wip security/nmap 

If everything is done correctly, after a while we will have new packages in the packages/7.4-wip directory and build logs in logs/7.4-wip (if you did not manage to assemble the port or any of its dependencies, the package will not appear, but we look for error logs in the errors/7.4-wip directory and carefully study them):

 $ find logs packages -type f -name nmap\* logs/7.4-wip/nmap-5.51_2.log packages/7.4-wip/All/nmap-5.51_2.tbz 

In addition to files, symbolic links are also created by categories of the port and the The latest link to install the package via pkg_add -r :

 $ find packages -type l -name nmap\* packages/7.4-wip/Latest/nmap.tbz packages/7.4-wip/ipv6/nmap-5.51_2.tbz packages/7.4-wip/security/nmap-5.51_2.tbz 

What's next?

In principle, usually more is not needed; our goal is to be able to collect any ports in a clean environment for different versions of FreeBSD and not to litter our system with anything superfluous. Of course, the possibilities of the tinderbox are much broader, but their description goes beyond the topic, and it will no longer be “set up a tinderbox in five minutes.” In addition, retelling documentation is not good. :-)



In conclusion, I will once again emphasize the importance of clean assembly at an early stage. Remember: if the port is built on your system, this does not mean that it will be collected from all the others; Only tinderbox provides the assembly, as they say, in the pristine environment. Of course, the FreeBSD build cluster (pointyhat) does virtually the same thing, and if the package is not assembled, it will be revealed, the maintainer will receive a notification to which it will have to respond, otherwise the port will be marked as BROKEN. But it all takes time, because portmgr @ has to dig out more problematic logs, and users have to be content with a raw product. A tinderbox, with almost no gestures on your part, if used properly, can greatly simplify the work of many people and help improve the overall quality of FreeBSD ports.