Random Musings of an Insane Mind

My server backup script broke a while back – probably around Dec 14th, 2014 with a python update that debian pushed which broke my virtualenv. This isn’t the first time debian has broken virtualenvs and my last post was about this. In addition the backup script filled up the backup drive without triggering an exception which is odd, because the source didn’t exceed the size of the destination drive even prior to things breaking. The script just does a simple rsync so it wouldn’t have duplicated symlinks.

It finished its backup last night in about 30 minutes (usually takes 5-7 minutes) and now has 6gb free which matches my server.

I recognized my backups were failing because debian pushed another change where varnish overwrote the startup script without asking – and I had to reconstruct that file from the machine configuration.

At times, I wonder why OS upgrades push breaking changes without any mention. The conversion to systemd was also

Of course, a new upgrade to Python on my devbox and the virtualenv breaks. And, merely reinstalling the virtualenv over top doesn’t work.

This is where you need to make sure your python project has an adequate setup.py to install the dependencies or you’re going to end up reinstalling by hand.

First, deactivate and make sure you’re not in the virtualenv. Get into the virtualenv’s top level directory and:


cd /virtualenvroot
rm -rf bin/ include/ lib/ local/
virtualenv /virtualenvroot
source bin/activate


Then, rerun setup.py with either install or develop and you should be set.

Another update to Python 2.7 and the error:

ImportError: cannot import name MAXREPEAT

occurs when starting an app in the virutalenv.

To fix this, just run:

virtualenv /path/to/existingvirtualenv

    import os, sys, imp, types, tempfile, optparse
  File "/usr/lib/python2.7/tempfile.py", line 34, in 
    from random import Random as _Random
  File "/usr/lib/python2.7/random.py", line 47, in 
    from os import urandom as _urandom
ImportError: cannot import name urandom

You’re using a virtualenv, you’re probably on Debian or Ubuntu, and you upgraded python through apt-get.

To fix it:

virtualenv /path/to/your/virtualenvironment

With one of the most recent projects which clocks in at 6331 lines of code, it becomes difficult to determine whether the production and development versions are running the same version after a number of commits.

The first post I came across, Canonical Version Numbers with Git seemed like a good starting point.

The first thing you need to do is set a tag on your repository:

git tag Prod-1

and we can test to make sure our tag was set:

git describe --tags --long

Now, we create /usr/local/bin/git-revision.sh (as mentioned in one of the comments with a minor change):

#!/bin/bash
revisioncount=`git log --oneline | wc -l`
projectversion=`git describe --tags --long`
cleanversion=${projectversion%%-*}

echo "$projectversion-$revisioncount"
#echo "$cleanversion.$revisioncount"

You can use either the projectversion or the cleanversion depending on the format you prefer.

The projectversion will contain the sha snippet along with the version and looks like: 1.0-1-g8f63877-291.

The cleanversion removes the sha key leaving 1.0-291.

Now that we’ve got a version number that changes on each commit, we can use this somewhere. This version is updated AFTER the last commit, so, you’ll want to import it into your project somewhere, or, in your commit message.

Before you commit, as one of the commenters in the previous post said, execute:

git-getrevision.sh > version

For our footer.mako file, we have the following:

<footer>
${request.user.company} ${request.user.phone} ${request.user.email}
Version: 1.2.3
</footer>

We now create post-commit in $GIT/hooks:

#!/bin/bash

VERSION=`/usr/local/bin/git-revision.sh`

FOOTER='/var/www/path/to/templates/footer.mako'

CONTENTS=`cat $FOOTER`

UP_TO_VERSION="${CONTENTS%%Version:*} Version:"
CLOSE_FOOTER="</footer>${CONTENTS##*</footer>}"

echo "$UP_TO_VERSION $VERSION $CLOSE_FOOTER" > $FOOTER

You can do whatever you need with the post-commit script. I just chose to use bash to rewrite the version number present in the footer of the site. You can just output the version number to a header file that is included if that works with your system.