It’s pretty obvious, that me maintaining the debian kernel repository which I announced in this post is a lot of work as I offer up to 4 flavors – which are ‘vanilla’, ‘vm’ and both for the gentoo patchset, I had to improve my setup. First of all, the introduction of ccache did shave off a few seconds on compiling (the cache hits are still not crazily high around 12-15%) – but it wasn’t all great.

Second, I created a script to build the kernel I wanted to, to shave off some time as I didn’t want the system to wait for my input during the whole build process. It wasn’t magic at first, but it was sufficient to run all the commands I needed. This way of doing things works well as long as there are no errors and all goes like plan as in a perfect world which we sadly don’t have and it went well for one way of building it.

Now it was time to improve the script:

The first thing I did was introducing some kind of config management to keep the configs consistent over my builds without dropping important modules or any unwanted changes. Git did a great job and the configs are even backed up on github and everywhere I mirrored my repo. Sweet.

Next I had to do a ‘one for all’ solution – merging my four “flavor” scripts into one and break it up into a lot of functions for every step I want the script to perform. While I was at it, I threw in a couple of IFs to act differently per kernel as required. Still not perfect, but another big step into the right direction.

Still, the script itself wasn’t what I needed. For me, the biggest issue was a broken patch or anything that messes my builds up. As I had it all broken down into functions, it was easy to grab them one by one and add failure conditions like patches not applying cleanly or the compiler suddenly dying on which we just exit without saving the config back into the repo. This step was crucial for my build as it saved me a lot of rollbacks on broken builds.

But the script was still a bit too clunky for me. I wanted some more comfort in it as I do not want to look up the exact version number of the kernel as it’s sufficient to know that it is ‘new’. A little bit of grep magic did that for me – which allowed me to be more relaxed about that point too.

KERNEL_VERSION=`curl -s https://www.kernel.org | grep -A1 latest_link | tail -n1 | egrep -o '>[^<]+' | egrep -o '[^>]+'`

A quick reminder here: This script is pure bash for the sake of keeping it simple and easy to maintain. Compiling it into C code wouldn’t give me any benefit here as I would have to run a lot of shell-exec calls anyways and recompiling it for testing and fixing bugs is all way too much for the CPU cycles saved.

The script itself now worked for now, but it led me to some issues when I wanted to give it to a friend for looking over it to check for stuff I could improve on. My credentials were still in there and I do not want to pass them on – even to another trusted person. So I had to deal with an external config file which is part of another blog post here to keep this post slim and on topic.