I started a new repo called sid-builder which provides a docker based development environment for debian packaging. This project follows all of the best practices that were outlined in the Guide for New Maintainers. The benefit of this approach is that you should be able to easily reproduce your development environment on any machine that supports docker. It also allows you to easily run sid without worrying about breaking your system.
I have not actually built any packages using this setup just yet, but I am going to give it a try over the next few days and report back here.
I’ve been using debian for as long as I remember. I’ve always wanted to play a more active role in debian development but for whatever reason I never got around to it. Now that I am 30, older, wiser, I am starting a new push to become a debian developer.
So far I have gotten involved in the debian-qa team. Specifically I have been working on fixing some of the newcomer bugs on the distro-tracker project. It’s actually been really fun. The code base is django which I am pretty comfortable with. For the first time in many years, I have been rushing home after work so that I could keep hacking on the bugs that I am working on.
Code contributions are one thing. The thing that I am going to need more practice on is debian packaging itself. This is pretty complex process and I think that becoming someone who can debug and perform packaging issues would bring a lot of value to the project.
I am going to start working on some of the RC bugs (which typically involve at least re-packaging software) to get more comfortable with how other folks have been doing packaging.
In the next few months I would love to bring a new package through it’s full lifecycle.
I hope to be able to look back on this blog post in the future and see how far I have come.
One of the most frustrating things to deal with in Continuous Integration is flakey commands. Whether it’s flakey tests, or intermittent networking issues, when your build fails for issues outside of your control not only does it cause frustration, it reduces the trust in your CI process.
One strategy for dealing with this type of issue is to introduce some retry logic into your commands. This can easily be accomplished with good old bash.
For example, pretend that I have
$FLAKEY_COMMAND and I want to retry it three times before finally failing my build. I could wrap the whole thing up in a bash loop like this.
while [[ $? -ne 0 && $counter -lt $max ]]; do
This script will run my command, if the exit code (the output of $?) is non zero (i.e something went wrong) and my counter is less than three, then it will retry the command. You can increase or decrease the number of attempts by adjusting the
This is not a foolproof strategy, but is one approach to handle flakey commands in your CI pipeline.