Posts Tagged ‘python’

Indicator applet API changes in Ubuntu 9.10

Thursday, October 22nd, 2009

The API for the indicator applet has changed in Karmic and a little internal IBM Python application that I’ve written stopped working. Only a couple of minor changes were needed but trying to track down exactly what these were was not as easy a task as I’d have liked.

Creating the indicator
The class used to represent an indicator appears to have changed from IndicatorMessage to Indicator so I threw in the following code to try the new one and fallback to the old one:

try:
  # Ubuntu 9.10 and above
  indicator = indicate.Indicator()
except:
  # Ubuntu 9.04
  indicator = indicate.IndicatorMessage()

Drawing attention
Previously, indicators automatically made the indicator applet draw your attention with a green dot. In Karmic the green dot appears to have been replaced with a change of the envelope colour to black but it is no longer automatic. To make this work you need to set the draw-attention property:

indicator.set_property('draw-attention', 'true');

Note that they’ve also added a count property to display how many notifications are from the same source.

Building .deb packages for Python applications

Tuesday, June 2nd, 2009

Building .deb packages for Python applications

Recently I wanted to build a .deb package for an internal IBM application I was writing so that users could easily install it and also so we could distribute them through some internal repositories. This proved a bit harder than I expected so this is a quick summary of how I ended up doing it. Note that your requirements might be entirely different!

The first thing to do is to create the files required by the packaging process. I discovered that the dh_make command can create a load of sample files that can be used as part of this process. To do this, create a directory in the format [package-name]-[version] (e.g. my-great-app-1.0) and run dh_make from within it (I specified ’s’ for single binary when prompted). This will create a load of sample files in a ‘debian’ subdirectory. Delete any of these you don’t need (which is probably most of them); I kept the following:

  • changelog – change history for all versions of the app (keep to the format specified by the Debian Policy Manual)
  • compat – no idea why I needed this but things don’t work properly later if I don’t
  • control – the details of the package you are creating (see the specification for all configuration options)
  • dirs – the list of directories in which your app will install files (e.g. /usr/bin, /usr/share/pyshared/my-great-app, /usr/share/applications)
  • README.Debian – the README for your app
  • rules – a MakeFile with instructions for how to create the package (for my Python app the important bit here was in the ‘install’ section; here I created a $(CURDIR)/debian/my-great-app subdirectory and copied all files into it as if it were /, e.g. binary to $(CURDIR)/debian/my-great-app/usr/bin/my-great-app)

Once I’d created all those files and put them in my-great-app/packaging/debian and my source in my-great-app/src I created a simple build script my-great-app/bin/build. This looked something like the following:


#!/bin/bash

export VERSION=1.0
export DEBFULLNAME="Gareth Jones"
export DEBEMAIL="my-real-email-not-this@somewhere.com"

cd ../build
sudo rm -rf my-great-app*
mkdir -p my-great-app-$VERSION
cp -u ../src/*.py ../src/*.desktop ../src/*.ico ../packaging/my-great-app my-great-app-$VERSION
tar -czf my-great-app-$VERSION.orig.tar.gz my-great-app-$VERSION/
cd my-great-app-$VERSION
mkdir debian
cp -u ../../packaging/debian/* debian/
gksu dpkg-buildpackage

This should create you a my-great-app_1.0-1_all.deb and the my-great-app_1.0-1_i386.changes, my-great-app_1.0-1.dsc and my-great-app_1.0-1.tar.gz files your repository maintainer might want.

A really useful video I found for helping me fill in the contents of the debian control files (and getting me through the whole process) was here. Definitely worth checking out if you need to do this yourself.

Replacing Python on a Battlefield 2 server

Wednesday, May 7th, 2008

Lately I’ve been doing some work (I promise it is real work) with Battlefield 2. The server part of the game has a cut-down version of Python built in so that you can interact with it, modifying aspects of the game and reacting to events etc. More details on this can be found on this wiki.

Anyway, the Python version it uses is pretty old (2.3.4, current version is 2.5.2) and it’s had functionality cut, e.g. no threading support. For the work I’m doing I needed threading support and a few other things so wanted to swap out the version of Python for another – turns out this wasn’t obvious so here are the steps:

  1. Replace the Battlefield 2 Python library (e.g. ‘bf2/bin/ia-32/libdice_py.so’) with the version of your choice. I just linked to my locally installed version ‘/usr/lib/libpython2.5.so’.
  2. Replace the Python library path at runtime to use the new libraries, e.g. edit ‘bf2/python/bf2/__init__.py’ and putting the equivalent of ’sys.path = ['/usr/lib/python2.5/', '/usr/lib/python2.5/lib-dynload/', 'python', 'mods/bf2/python', 'admin']‘ after the ‘import sys’ line.

I do get the following warning at runtime: ’sys:1: RuntimeWarning: Python C API version mismatch for module host: This Python has API version 1013, module host has version 1012.’ but it doesn’t seem to cause any problems (so far!).

Am I online?

Saturday, April 5th, 2008

I’ve recently changed my broadband provider and wondered how reliable they’d be. I figured I needed a way for my house to let me know whenever the connection had dropped and for how long for etc. Remembering my post a little while ago about
publishing to Twitter about local Bluetooth devices
, I thought I could do something similar. So now I’ve written a little script (twitter-netcheck) that notices whenever my internet connection is dropped and then publishes to Twitter whenever it comes back. It also sends me a direct message so I get alerted by SMS or IM immediately. Quite handy I think – try it out for yourself

Tweetjects and Bluetooth

Friday, March 7th, 2008

Andy Stanford-Clark recently got a few people together to talk about blogjects and tweetjects after getting his house to tweet about the various goings-on there. That inspired me to think about what I could do with Twitter and remembered a while ago I’d created a little script that polled for nearby Bluetooth devices and published them via MQTT. So as a good distraction from work I thought I might integrate this with Twitter and so we now have a little python script that lets my laptop publish details of any bluetooth devices it sees appear and disappear. So what’s the use of this then? Probably very little but it might be interesting to hook it up in my flat and see who goes in and out of there…

[Update]
I failed to find the time to set this up as a proper project somewhere but here’s the scripts in case anyone wanted to make use of the application:

Christmas fun

Monday, December 31st, 2007

Ok, so I got a bit bored at some point over Christmas and decided to play with one of my presents – a USB Rocket Launcher.

The first difficulty was getting it to run on my Linux laptop as the drivers were only for Windows. A quick search and Scott Weston sorted me out. Then I thought it should really be controlled by more than just the keyboard so I hooked it into the Thinkpad accelerometer – now movements of the laptop could direct it. Finally, as I knew Andy Stanford-Clark would be a bit disappointed in me if I hadn’t, I MQTT‘d it so that the accelerometer details are published to a broker, a bridge app subscribes to that info and (where appropriate) publishes commands which are received by a final subscriber that actually sends the commands to the rocket launcher. This way you can easily swap out the accelerometer or indeed rocket launcher for something completely different.

I feel quite pleased with myself and slightly ashamed at the same time.