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™.

So I heard you like data

Released Mound Data Manager 0.4.0 final early this morning, just before the DST switch.

If you have no idea what that is, see this post before reading the rest.

Click the above image for a video.

Main features of this release:

• New UI that shows snapshots on the main window
• Importing/exporting of snapshots
• Translatable

The biggest feature is probably the exporting of snapshots. If you want to quickly take your data to another computer or deploy it to multiple systems, you can now easily do so.

Imported snapshots are checked to make sure that the data matches the application. This means that you can not actually modify the snapshot or Mound will refuse to import it. (Technical details: Mound modifies the gzip header when exported and checks it upon import to prevent importing of any random archive.) You can, however, still extract them like regular tar.gz archives to quickly get your data out or use scripted deployments.

If you're interested, give it a try! It's been fairly well-tested since 0.2, and the snapshot logic has not changed much so your data should still be as safe as it always was.

Launchpad source downloads:
PPA: (ppa:jpeddicord/mound)

If you're feeling productive, why not help out translating Mound Data Manager into your own language? See Launchpad Translations for more information.

Also, congratulations to Paul Tagliamonte on his new role as the team contact for Ubuntu Ohio! It's been a fun couple of years with the Ohio team, and I'm sure Paul's got the skills to make the Ohio team kick some ass.

Another project: Mound Data Manager

In the trend of short, quick applications comes Mound Data Manager. If you've ever swapped out profiles for applications or wanted to snapshot them, this is your new friend.

Mound will try to find applications it is able to manage on your system. Any application that appears can have snapshots taken of its data and have data deleted, among other tricks.

In addition to plenty of sanity and safety checks, snapshots are taken and restored using tar, so your data should be just as safe as its always been.

As an example, I took a snapshot of Htop above, which manages only my local .htoprc. I then was able to mess around with some Htop settings and take another snapshot. These two snapshots can now be used to either restore default settings, or my custom ones. (Another quick way to restore defaults is to simply delete the data, which is available on the Application menu.)

In the future it will be possible to export these snapshots for use on other systems. They are stored as plain tar.gz archives currently, so you can do so already yourself, but there are no checks to make sure the data is valid yet.

Mound works by reading through your installed applications. Inside each application it will attempt to look for an X-UserData line inside the desktop entry, and if found, makes the application visible in Mound for managing. If one is not found, it will search through /etc/userdata (supplied) in attempt to find a default to show.

A UserData line in the desktop entry or in /etc/userdata tells Mound what files are available to manage. See a line for Empathy as an example:

empathy $CONFIG/Empathy;~/.gnome2/Empathy

$CONFIG is a shortcut for ~/.config using XDG directories. (Others are available, such as $CACHE and $DATA.) The two directories there are then scanned by Mound, and then the user is able to take snapshots of this data, delete the data, and revert older snapshots in place.

The shipped userdata defaults file currently only has support for 36 applications (those that are currently installed on my system). Give Mound a try, and if you see some applications that aren't listed that should be, be sure to let me know.

There are two ways to allow your application to be managed:

1. Add an X-UserData line to your application's shipped desktop entry, with a value of a semicolon-separated list of files/directories to manage.
2. Add a default line in /etc/userdata by contacting me or by making a merge request in Launchpad with your changes. No packaging changes required on your end.

I understand that most people will pick the second option -- this is perfectly acceptable, especially since this stuff is completely new. :)

And finally, the download links:

Download, give it a try, and let me know what you like and what you don't. Enjoy.