A good use of buildah and podman for Fedora packagers

I maintain a lot of packages. Arguably too many. In any case, sometimes I’m working on updating several of them at once. As part of my process, in addition to a local build and usage testing, I run a mock build before committing and submitting to koji. However, you can only run one mock build per release/arch combination per machine at a time. Since I mostly want to build for rawhide, with the hardware I have, I can run 3 builds at a time. 6, if 3 of them are x86_64 and 3 are i686. I can also build on VMs, but I only have one at the moment.

That’s a bummer.

Enter podman.

I started playing with this as a concept, but I’ve actually started working it into my usual workflow, because it helps to be able to start large numbers of concurrent builds and then do other work or feed the cats or watch C-SPAN or whatever.

For the first two pieces, you need buildah and podman. For the third, you need parallel.

There are two components, one to create an image suitable for rawhide RPM builds, and one to run them. Yes the formatting is annoying.

podman image exists pod-rpm-build-rawhide
if [ $? = 0 ]; then
podman rmi pod-rpm-build-rawhide
export TMPDIR=/tmp
TEMPCONT=$(buildah from fedora)
buildah config --label "maintainer=Gwyn Ciesla" $TEMPCONT
buildah run --user root:root $TEMPCONT dnf update --releasever=32 -y
buildah run --user root:root $TEMPCONT dnf install dnf-plugins-core findutils rpm-build make -y
buildah run --user root:root $TEMPCONT useradd -m builduser
buildah commit $TEMPCONT pod-rpm-build-rawhide
buildah rm $TEMPCONT


TL;DR, this removes the old version of the image if we have one, creates a fedora container, upgrades it to rawhide, and installs what we need to build an RPM.
export TMPDIR=/tmp
RPMNAME=$(rpm -qpi $SRPM | grep -m 1 Name | cut -d ":" -f 2 | xargs)
CONTNAME=$(echo $RPMNAME | tr '[:upper:]' '[:lower:]')
TEMPCONT=$(buildah from --name $RPMNAME-worker-rawhide pod-rpm-build-rawhide )
buildah copy $TEMPCONT $SRPM /home/builduser/
buildah run --user root:root $TEMPCONT dnf build-dep /home/builduser/$SRPM -y
buildah run --user builduser:builduser $TEMPCONT rpm -ivh /home/builduser/$SRPM
buildah run --user builduser:builduser $TEMPCONT rpmbuild -ba /home/builduser/rpmbuild/SPECS/$RPMNAME.spec
buildah commit $TEMPCONT $CONTNAME
buildah rm $TEMPCONT
if [ -d $(pwd)/build ]; then
podman run -it --rm=true -v $VOLARGS $CONTNAME find /home/builduser/rpmbuild/RPMS/ -type f -name '*.rpm' -exec cp {} /build \;
podman rmi $CONTNAME

This one makes a container from the image we made, sets up the build requirements, builds the RPM, and if successful, copies the RPMs into either cwd or cwd/build, if it exists. Then it cleans up after itself. For the most part.

So far, everything I’ve tried works on mock that works on this and vice-versa.

Now to take this even further, sometimes you just need to build a whole bunch of SRPMs RIGHT NOW. Then you can do something like:
ls *.src.rpm | parallel --progress -j4 ./pod-rpm-build.sh {}

Anyway if you make use of this, or find a bug, or have an enhancement to share with the rest of us, please let me know!

distcc 3.3.2

I’ve finally updated distcc to the latest release (f31+). Python 2 retirement forced me to finally work out how to adapt to the new compiler symlink model. It should work out of the box, but if you add compilers to a server, rerun update-distcc-symlinks.

Two numpys diverged in a wood. . .

python2-numpy has split off from numpy(python3-numpy) as of rawhide/f31.  Dependencies have remained the same, so unless your Python 2 package requires numpy, you should be fine. If it does, switch to python2-numpy. Or switch to python3. 🙂

This allows us to upgrade python3-numpy to 1.17.0, while python2-numpy stays at 1.16.4, since 1.17.x drops Python 2 support.

File bugs if something breaks.

Duplicity 0.8.01

Duplicity 0.8.01 is now in rawhide. The big change here is that it now uses Python 3. I’ve tested it in my own environment, both on it’s own and with deja-dup, and both work.

Please test and file bugs. I expect there will be more, but with Python 2 reaching EOL soon, it’s important to move everything we can to Python 3.