python-gstreamer1-1.19.3-2.fc35
This fixes a bug opening or creating a project in Pitivi in Fedora 35 and greater.
Please install, test, and give karma here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-9bc6cc53b1
python-gstreamer1-1.19.3-2.fc35
This fixes a bug opening or creating a project in Pitivi in Fedora 35 and greater.
Please install, test, and give karma here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-9bc6cc53b1
I’ve updated python-slackclient from 2.7.3 to 3.2.1. The module has changed from slack
to slack_sdk
. The new version is backwards compatible for now, and will just emit deprecation warnings. The full porting guide is at: https://slack.dev/python-slack-sdk/v3-migration/.
Thank you to Miro HronĨok, who’s completed the update of Trac in Fedora to Python3. If you need a plugin that still needs Python2, now is the time to work with the maintainer and/or upstream to get it ported.
It’s a _scope_id bug affecting Salt on Python 3.9. There’s a patch submitted upstream, and 3002+this patch is headed to updates-testing.
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.
Headed to rawhide, f32 and f31. Please test and give karma while maintaining proper social distancing.
Finally, it’s on it’s way to updates-testing. This is 0.8.09, with Python 3. Please test, give karma/feedback, and enjoy!
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!
I’m curious if this can actually be a viable replacement for Facebook. If you’re curious, use my invite link!
Want to use docker-compose.yaml files with podman on Fedora?
Review podman-compose! I’ll even review one of yours, no extra charge!