Jacob Peddicord

Programming, Projects, and Packaging Problems

It's time for some long-overdue updates on some software projects of mine. I'm posting this not only to show some things I've got planned, but also to motivate myself to do something about them. When something is written down and shared, I'm much more likely to get things done, I've found. So this is going to be a bit of a braindump, but read on if you're interested.

Project Hosting

First, I want to get this out of the way. I can't stand Launchpad. I'm sure it works great for many, many people (I hear this distribution called Ubuntu uses it) but there are far too many small things that prevent me from developing effectively with it. Project pages are a bit of a mess, code hosting is definitely a bit more convoluted that it should be, and releasing software becomes a burden rather than something exciting. Additionally, it only supports Bazaar, which is a decent DVCS, but I'm more of a Git fan. (Launchpad developers, please don't take this as blatant criticism, but see it as a challenge against the other offerings out there!)

So, I'm migrating my projects to GitHub. There are quite a few things that I really like about GitHub. For one, it's really easy to release software versions. Just tag a revision. Done. It will show up in the Downloads section, can have reports attached to it, and is all around easy to use. One thing I will miss from Launchpad, however, is bug reporting. Launchpad has the most complete bug and issue tracking around, though GitHub is certainly making some strides in that area.

Packaging

I'm not going to lie: I despise Debian packaging. It's just not my thing. There are too many variables to keep track of, too many subtleties, and too much politics. I'm sure some people love to dissect and create packages to distrubute the software we use, and I salute you.

It's getting to the point where I dread releasing a bugfix update, because I have to package it. And then it needs to go through a review process to make it into various software archives. That's fine; you want your processes to keep your archives of high quality. But it just takes too much time. When I was working on jobs-admin and jobservice last summer, I had to set aside a day practically every week to fix packaging quirks and go through archive processes. It's mundane, and I'd much rather be working on software itself than the logistics of distribution.

Not to say that I don't respect a typical software release process. I just dislike packaging specifically. If anyone has some words of wisdom on this, I'd love to hear it.

Projects

Enough of that, here are status reports on the software projects I've been working on:

jobservice and jobs-admin

These two have been suffering the worst from the packaging problem. Maverick, Natty, and soon Oneiric will all have jobservice/jobs-admin 0.8.0. Unfortunately, there was an API change in Natty's Upstart + DBus that causes Upstart jobs to not work in either of those. I've got the fix as 0.8.1 on GitHub, but have been unable to find an ample amount of time to get the packaging done.

And I feel really bad about this. That's why I'm writing this post; to convince myself to do something about it. jobservice and jobs-admin have had some sizable changes for a version 0.9 (to-be 1.0), but there are some things I still want to get done:

• Recovery mode functionality (it doesn't work 100% at the moment)
• Cleaned up settings interface
• Complete Upstart support: it works in 0.8.1, but doesn't use override files
• systemd support -- I want to make this largely distro-independent
• GitHub migration
• An actual support/project website
• Independent packaging repository (maybe)
• More complete SLS files for newer system services

Once I'm at a point where things are fairly stable, I'll release 0.9 and then 1.0 after testing.

Mound Data Manager

Mound Website

For those who are unaware, this is an older project of mine. "Mound Data Manager is a tool that can manage data in the context of other applications. You can take snapshots, delete, and move data from many of your favorite applications."

Someone bugged me about this on IRC last night. As far as I know it's in a working state, but I'm going to open this up today and see what can be improved. Tentative list of goals:

• More application support
• Configurable snapshot storage (Ubuntu One, maybe)
• Triggerable snapshots over DBus
• GitHub migration

Commandeer

Commandeer Website

Another older project: "Commandeer allows you to run a command and lock the desktop for the duration of the command. It is useful for technical support situations or remote backup where you do not want the end user doing anything while the command is running."

This one worked right out of the box when I downloaded it, and there's not a whole lot to be done with it. Unity seems to interfere with the locking mechanism, so maybe I'll look into that. And there's the GitHub migration.

End

There you have it: goals. If you notice I'm not making good progress on any of these, feel free to send me an email or ping. It'll help me Get Things Done™.

Commandeer: Lock the display to run a command

Just to get this out of the way, I created this application this week as a Vala learning experience. It is by no means complete, but for the use cases I think it fits the bill nicely. Let's jump right in to those cases:

1. Bill is a system administrator who needs to run a backup on the computers on the network, but employees can not be using them while this happens.
2. Jane is running some important system operation and needs to make sure none of her friends use the computer.
3. Bob wants to put his system on standby every night at 11 PM, but not if he is using it.

Enter Commandeer. It is a small application that is able to lock the display to run a command. Sounds simple, right? It is.

Commandeer allows commands to be started with a variety of options presented to whoever is currently using the computer. Commands may be optionally cancelled before they start, stopped and paused while running, and.. well that's all for the moment. Stopping and pausing are a little hacky; they just send SIGTERM, SIGSTOP, and SIGCONT to whatever child process is active. When the command starts, the above window becomes on-top, sticky, and fullscreen. Enough to keep out most users for now; hopefully I can improve on this "locking" support in the future.

For the first example: commandeer -d 60 --title "Backup" --text "Please save and close all work before the backup begins." /sbin/crazy-backup-plan. This would start a forced launch in 60 seconds.

The second: commandeer -d -1 important-command. A delay of -1 disables the timer, meaning that the Start button must be pressed to activate it.

And the last case, this could be started on cron: commandeer -c -d 30 --title "Standby" standby.sh.

For the above examples, the help output for context: Application Options: -d, --delay=SECONDS Delay before execution. If -1, disable the timer. -p, --pause Enable execution pausing. -c, --cancel Enable cancellation before command is run. Only valid if --delay is set. -s, --stop Enable cancellation during execution. Implies --cancel. -t, --title=TITLE Command title. --text=TEXT Dialog text.

Commandeer will try to be somewhat smart about what to say and how the UI is presented, depending on what options are given on the command line. If --cancel is given but not --stop, then a Cancel button will appear and become insensitive when the command starts. If both --cancel and --stop (or just --stop) are given, the Cancel button will change to a Stop button on run. When --pause is active, a Pause button will be visible and will be enabled when the command launches. Pausing causes the Commandeer window to revert back to a small box to be resumed later.

A PPA is available here. Quite surprisingly, packages are only 11 KB, but are lacking some things (manpage).

Vala source is hosted, where else, on Launchpad, and is only about 300 lines long. I'm aware that I probably made some programming blunders with Vala -- for example, I'm still trying to figure out the whole construct statement vs a method with the class name... but hey, it's all working fine. I've been testing this code on my machine and it feels stable, but don't blame me if you somehow lock yourself out. If you want to play around with it, feel free. Got improvements? File a bug or merge request.

Enjoy it or not, I definitely had a good time learning how to write it.