This is just the usual Fedora testing workflow but with a container in the middle, so nothing really relevant, to be honest.
I made a massive mistake in the Fedora release process a few Go minor releases ago (around 1.16.1, I think). Basically, the Go package was stuck in the previous version.
So now that I’m making another two releases (1.15.12 for Fedora 33 and 1.16.4 for Fedora 34 and Rawhide), I wondered how I can try my ready-to-be-published version in a container.
Yes, I participate in the Fedora community but I never tested a package. Shame on me.
The release
First of all, let’s check what is included in Go 1.15.12 by looking at the upstream milestone. At some point in the release process, we’ll need to specify if we solve something with this release already tracked in the Fedora bug tracker.
/me looks bugs and reads comments…
Alright! It looks like we only have issue 45711 which seems to be bug 1958343.
Well, I guess we can start the release process:
# Clone the fedora repository
fedpkg clone golang && cd golang
# Switch to the target release
fedpkg switch-branch f33
# Bump up the version
rpmdev-bumpspec golang.spec
# 99.999% of the time we'll need to edit the golang.spec
vim golang.spec
# Let's download the upstream sources
spectool -g golang.spec
# Include them in the Fedora cache
fedpkg new-sources go1.15.12.src.tar.gz
# Commit the changes
git add -A && git commit -m "Update to go1.15.12"
# Perform a scratch build before submiting the code
fedpkg scratch-build --srpm
# Wait...
git push
# The real build
fedpkg build
# After a while we can do the release with the information of the bug
fedpkg update
A quick summary of what we have:
The testing
Now that our release is on testing, we can create a container, subscribe to that testing channel, and see if I screwed it again :). And this is an excellent excuse to use Toolbox.
toolbox create --release 33
toolbox enter --container fedora-toolbox-33
Now we should be inside a container. A nice thing about Toolbox is that we don’t have any of the packages installed on the host, just those that came with the image. Still, we have access to all of our configurations and files. Pretty neat to test stuff, isn’t it?
We can install Go, check the version, and then, once the package we submitted reaches the testing state, update it by using the updates-testing repository:
# First we need the stable package
sudo yum install golang
# Output: go version go1.15.11 linux/amd64
go version
# The magic trick
sudo dnf upgrade --enablerepo=updates-testing golang
# Output: go version go1.15.12 linux/amd64
go version
If you use VSCode, you can now jump into the container using
Attach to Running Container.
If you are interested in helping out the Fedora community, feel free to read the wiki, and if you don’t have spare machines to try new and potentially unstable stuff, you can use this container approach with a lot of different packages (forget about kernel testing for example) or swap the container for a VM.
Happy testing :)
Top comments (0)