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

Call for testing: jobs-admin

Google Summer of Code ends this week, which indirectly means that jobs-admin is now ready for testing! Interested testers need only to add a PPA and install a package to begin. Within a few days the packages will be available in maverick universe.

sudo add-apt-repository ppa:jpeddicord/jobs
sudo apt-get install jobs-admin

Essentially, jobs-admin is a replacement for services-admin. Upstart support has been added, along with the ability to change settings on individual services. For example, you can tweak simple firewall settings or enable and disable Apport.

jobs-admin may be launched from the terminal, or can be found under System > Administration > System Jobs. We've hidden most jobs/services that are essential to your system, so ideally you shouldn't be able to break anything even if you wanted to. With that in mind, feel free to give it all a stress test. Shut off jobs you don't want, and change the settings of others. By testing this you'll also be testing jobservice, the daemon which powers it all. Think of jobservice as a "PackageKit" for system services: it's a generic backend to manage jobs no matter whether a system is running Upstart or a basic System V setup.

Bugs can be reported on Launchpad:

http://bugs.launchpad.net/jobsadmin

We're also open for translating:

• - for most UI elements
• - for job settings

Any and all feedback is welcome. We'll have a bugfix release in the next few weeks. I won't be responding to reports or feedback until August 16 (Monday), however.

For Maverick, you'll be able to install jobs-admin and have easy access to your system's services. The PPA will be maintained so Lucid users aren't left out. We're hoping to make this the de-facto utility (and framework) for managing services and jobs, and hopefully you'll see this in-place as the replacement for the missed services-admin in 11.04. I'll be working on getting these packages into Debian as well.

More GSoC updates

It's been a while. Well, in internet years, anyway. I've made a lot of updates to jobservice and jobs-admin in the past few weeks:

• service-level settings works
• sporting a new UI
• speed improvements
• tons of bug fixes

I'll let the video do the talking (click the image):

Shoutout to Matthew Paul Thomas who provided the feedback for this new interface. :)

You can see service-level settings in action in the video. It's shown for apport and ufw. There's been a little confusion as to what this actually is, so here's a fancy diagram:

When you click that shiny "Job Settings" button, a lot of things happen. jobs-admin tells jobservice that settings were requested. jobservice then asks each of the backends if they have any settings on that particular service. Then it goes to SLS, which first looks up an XML file, and then uses that data to parse the actual configuration files. This is all compiled together by jobservice and sent back over DBus to jobs-admin, which renders some GTK widgets with this information. When a setting is changed, jobs-admin sends the changes to jobservice, which sends it back to wherever it came from.

SLS doesn't have anything to do with services themselves, just their configuration. When you start, stop, or look up information on a job, that is all handled by the appropriate backend.

Now, there is a PPA somewhere with these changes to play around with, but I won't link it here (though it isn't hard to find). I'd like to get more things together before there's a call for testing, but I won't prevent anyone from using it.

Also: I upgraded this site to Movable Type 5. Let me know if you notice anything broken. :)

jobs-admin & jobservice new feature: it works!

So this week I've hit a semi-awesome milestone with jobs-admin and jobservice: service management works!

On a Lucid system you're now able to start and stop not only System V services, but also Upstart 0.6 jobs.

A demo video is available here.

SysV jobs are currently handled using system-tools-backends, though I may look into doing another implementation that doesn't have any external dependencies.

The Upstart 0.6 backend was pretty tricky: Upstart is able to turn the jobs on and off for us, but to disable them we need to edit the config files under /etc/init. It works, though it may need some more through testing to be sure it's all good.

The Upstart 0.10 backend has not been written yet, as 0.10 currently doesn't exist.

Service-level settings still need to be implemented. This will be tricky to do correctly, but I think it will be a valuable feature.

Finally, if you're feeling brave, branch lp:jobservice and lp:jobsadmin to give things a try, though don't expect everything to work as it should. I'll have a PPA ready within a week for testing once things have stabilized.

Bringing it Back

As you've all probably heard, Google Summer of Code "officially" began this previous Monday. I've been rather busy this week typing stuff up and getting the foundation set for the summer.

I'm working on the project titled "services-admin configuration and Upstart-ification," though the title is rather inaccurate. Trying to actually implement Upstart functionality proved to be quite a showstopper for system-tools-backends, which is what powers gnome-system-tools and in turn services-admin. So, we've decided to split off into a new project designed from the ground up to handle Upstart 0.6, the future 0.10, and existing compatibility with System V init scripts.

The project is comprised of two parts: jobs-admin, a new GTK+ frontend intended to replace the functionality of services-admin, and jobservice, a dedicated job & service management... service. Yeah, I'm not terribly creative with names. :)

The plan is to continue with the proposal submitted to Google and on the Ubuntu wiki, with the exception of replacing the existing gnome-system-tools and system-tools-backends with these new software pieces.

Here's a small mockup:

The main window on the left shouldn't feel too unfamiliar: select a service on the left, and view its status on the right. Clicking the Service Settings button will bring up the dialog on the right. This dialog is one of the special parts of the project: it adapts to whatever service you want to manage. The details for these "service-level settings" aren't finalized, but it will most likely read settings from a directory such as /usr/share/jobservice/sls in an i18n-able XML-based format. I think initially we'll ship some settings for common system services, though eventually it would be great to see packages shipping their own for easy administration.

So far I've gotten the main window to display a list of services. Doesn't sound like too much, but there's a lot of framework there for developing the rest of the features.

One of the key things I'm keeping in mind developing jobservice is that backends should be easily interchangeable. Currently there are three planned backends: sysv, upstart_0_6, and upstart_0_10. More than one backend can be in use at a time; on a Maverick system you'll likely have upstart_0_10 and sysv active. When systemd is made available, it should be pretty easy to write a backend for it.

We'll have PPAs available for Lucid and Maverick as soon as things start to stabilize. Eventually, jobs-admin and jobservice should be available in the Maverick archives. If things turn out well, perhaps you'd even see this in main or on the CD. (I'm not sure if I'm being too ambitious, here. ;) ) I'm going to write up a full specification which I should have finished tomorrow. If there's someone who can lend assistance in getting this approved, feel free to send me a ping.

There's a lot to do over the summer, but things are looking well on track. I'll keep this blog updated as things start to take shape.

Shoutout to Milan Bouchet-Valat, who maintains gnome-system-tools, for his help in determining the scope of what needed to be done (or not done, in this case) on g-s-t and for helping me realize what direction to take with the project.

And thanks to David Bensimon, who's [very patiently] mentoring me and this project and got me to wake up on time for UDS sessions. (Ah, timezones.) Looking forward to a great summer.