by

Tools to automate parts of my Fedora packager workflow

"I maintain a lot of packages for Fedora. Too many, really."

I’ve just set up a Codeberg repo for some of the scripts I’ve been using to help reduce the number of keystrokes I need to perform daily task without breaking anything for anyone else.

If you’d like to read more, try them out, or propose improvements, they’re here.

Advertisement
by

My podman-based services stopped responding! (with fix)

So I run a local web application I wrote, in the following configuration: Two podman pods of 3 containers each, sitting behind a haproxy instance, with the containers talking to a mariadb backend. This makes it easy to update the containers to a new image without downtime, and I use scripts that handle updating the systemd unit files, etc. I had to set the SELinux boolean haproxy_connect_any=on, and it’s all working wonderfully.

Until this morning. I updated the Fedora 32 box this all runs on and I could no longer access the app.

To save you some time, the breaking change was a new SELinux boolean. Once I set container_connect_any=on, all was well again.

by

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.


#!/bin/bash
podman image exists pod-rpm-build-rawhide
if [ $? = 0 ]; then
podman rmi pod-rpm-build-rawhide
fi
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.
#!/bin/bash
export TMPDIR=/tmp
SRPM=$1
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
VOLARGS="$(pwd)/build:/build:z"
else
VOLARGS="$(pwd)/:/build:z"
fi
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!