Linux 4.0 ate my docker images

I have previously written about the gitlab CI runners that use docker.  Yesterday I made some changes to procps and pushed them to gitlab which would then start the CI.  This morning I checked and it said build failed – ok, so that’s not terribly unusual. The output from the runner was:

gitlab-ci-multi-runner 0.3.3 (dbaf96f)
Using Docker executor with image csmall/testdebian ...
Pulling docker image csmall/testdebian ...
Build failed with Error: image csmall/testdebian: not found

Hmm, I know I have that image, it just must be the runner so, let’s see what images I have:

$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE

Now, I know I have images, I had about 10 or so of them, where did they go? I even looked in the /var/lib/docker directories and can see the json configs, what have you done with my images docker?

Debian, WordPress and Multi-site

For quite some time, the Debian version of WordPress has had a configuration tweak that made it possible to run multiple websites on the same server. This came from a while ago when multi-site wasn’t available. While a useful feature, it does make the initial setup of WordPress for simple sites more complicated.

I’m looking at changing the Debian package slightly so that for a single-site use it Just Works. I have also looked into the way WordPress handles the content, especially themes and plugins, to see if there is a way of updating them through the website itself. This probably won’t suit everyone but I think its a better default.

procps using GitLab CI

procps-ciThe procps project for a few years has been hosted at Gitorious.  With the announcement that Gitorious has been acquired by GitLab and that all repositories need to move there, procps moved along to GitLab. At first I thought it would just be a like for like thing, but then I noticed that GitLab has this GitLab CI feature and had to try it out.

CI here stands for Continuous Integration and is a way of automatically testing your program builds using a bunch of test scripts.  procps already has a set of tests, with some a level of coverage that has room for improvement, so it was a good candidate to use for CI. The way GitLab works is they have a central control point that is linked to the git repo and you create runners, which are the systems that actually compile the programs and run the tests. The runners then feed back their results and GitLab CI shows it all in pretty red or green.

Backporting and git-buildpackage

For working with Debian packages, one method of maintaining them is to put them in git and use git-buildpackage to build them right out of the git repository.  There are a few pitfalls with it, notably around if you forget to import the upstream you get this strange treeish related error which still throws me at first when I see it.

Part of maintaining packages is to be able to fix security bugs in older versions of them that are found in stable and even sometimes old stable (jessie and wheezy respectively at the time of writing).  At first I used to do this outside git because to me there wasn’t a clear way of doing it within it.  This is not too satisfactory because it means you lose the benefits of using git in the first place, and for distributions you are more likely to need collaboration with, such as working with the security team or help with backporting.

Mudlet 3 beta

Mudlet - Graphical MUD client

A break from wordpress, I was trying to get the beta version of mudlet 3.0 compiling. On the surface the program looks a lot like the existing v2.0 that is currently within Debian.  The developers have switched from qt4 to qt5 which means a lot of dependency fun for me but I got there in the end.

As it is only a beta and not their final release, the package is located within the Debian experimental release. Once 3.0 hits a final release, I’ll switch it to sid.  If you do use the current mudlet, give 3.0 a try. I’d be interested to know what you think.

WordPress 4.0.1 fixes for Debian stable

Previously I posted a short article about the WordPress package for Debian and how that SID was getting the updated WordPress 4.0.1 which had some security fixes.

The question a lot of people were asking was: What about stable (or Wheezy).  After way too much time due to other pressing issues, I have just uploaded the patched WordPress debian package for stable.  The fixed version has the catchy number of 3.6.1~deb7u5.  This package has all of the relevant patches that went in from WordPress 3.7.4 to 3.7.5 and there are even CVE IDs for this package (and 4.0.1 which all this stems from).

WordPress 4.0 for Debian

Yesterday WordPress released version 4.0 or “Benny” of WordPress. I have now downloaded it and packed up for Debian users. The files just hit the ftp-master a few minutes ago and will then be distributed out to the various Debian mirrors. The upgrade should go smoothly but you will probably need to upgrade the twentytwelve/twentyfourteen