When you cancel a Jenkins job

Unfinished draft; do not use until this notice is removed.

We were seeing some unexpected behavior in the processes that Jenkins launches when the Jenkins user clicks "cancel" on their job. Unexpected behaviors like:

  • apparently stale lockfiles and pidfiles
  • overlapping processes
  • jobs apparently ending without performing cleanup tasks
  • jobs continuing to run after being reported "aborted"

"Vendoring" is a vile anti-pattern

What is "vendoring"?

From a comment on StackOverflow:

Vendoring is the moving of all 3rd party items such as plugins, gems and even rails into the /vendor directory. This is one method for ensuring that all files are deployed to the production server the same as the dev environment.

The activity described above, on its own, is fine. It merely describes the deployment location for various resources in an application.


Toward a common Package Manager

This is a collection of notes, that I expect will progress from the perspective of a naive outsider to resigned pessimism. I started it as a naive outsider just to keep notes, and I hope that the document will remain accessible for other naive outsiders when complete. I suppose it's also a remote possibility that we might actually make progress toward the stated goal, as well.

One of the major incompatibilities between competing Linux distributions is their [package format][]. Red Hat uses rpm packages; Debian and Ubuntu use deb packages; slackware uses tarballs (following particular conventions?); experimental package formats cause whole new distributions to arise, for example NixOS. Non-Linux systems have package management tools as well: FreeBSD has a ports/packages system; MacOS uses pkg files; Windows uses MSI files.

Furthermore, most of the popular system package formats are built around the idea that the software they install will be the only version and only

View .gitignore
View gist:2199506

Virtualenv's bin/activate is Doing It Wrong

I'm a Python programmer and frequently work with the excellent [virtualenv][] tool by Ian Bicking.

Virtualenv is a great tool on the whole but there is one glaring problem: the activate script that virtualenv provides as a convenience to enable its functionality requires you to source it with your shell to invoke it. The activate script sets some environment variables in your current environment and defines for you a deactivate shell function which will (attempt to) help you to undo those changes later.

This pattern is abhorrently wrong and un-unix-y. activate should instead do what ssh-agent does, and launch a sub-shell or sub-command with a modified environment.



When are Python circular imports fatal?

In your Python package, you have:

  • an that designates this as a Python package
  • a, containing a function action_a() that references an attribute (like a function or variable) in, and
  • a, containing a function action_b() that references an attribute (like a function or variable) in

This situation can introduce a circular import error: module_a attempts to import module_b, but can't, because module_b needs to import module_a, which is in the process of being interpreted.

But, sometimes Python is magic, and code that looks like it should cause this circular import error works just fine!

View ackermann.asm
#!/usr/bin/spim -file
# ackermann.asm
# (c) 2015 Michael F. Lamb <>
# License: AGPLv3+
# A naive implementation of the two-argument Ackermann function:
# / n+1 if m = 0,
# A(m,n) = { A(m-1, 1) if m>0 and n=0,
# A meager re-implementation of debian's run-parts in shell script, for
# platforms that lack a working one (e.g. Centos 5).
# Copyright 2013 Michael F. Lamb <>
# License: GPLv3
N="`readlink \"$1\"`"
mv -T "$1.stage" "$1"
ln -s "$N" "$1.stage"
rm -rf "$N"
cp -aH "$1" "$N"

Launch a one-off git server from any local repository.

I [tweeted this already][1] but I thought it could use some expansion:

Enable decentralized git workflow: git config alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

Say you use a git workflow that involves working with a core "official" repository that you pull and push your changes from and into. I'm sure many companies do this, as do many users of git hosting services like Github.

Say that server, or Github, goes down for a bit.