apple, jailbreaking, and debconf in manhattan?!

Well, while I tangle around with annoying conflicts between Xen and NetworkManager I might as well post something semi-related to computing. Today it's Apple's anti-jailbreaking plea. Right off the bat they point to their end user license "agreement" and claim that people who bought an iPhone or iPod Touch somehow agreed to this mystical EULA that's somehow signed at point of sale. Nevermind the fact that EULAs are non-negotiable, involve no transfer of title, money, or services, and frequently never even get shown to the user.

But enough about that. Apparantly DebConf 10 is going to be in New York City. Right next to where I live. That's great. I didn't go to DebConf this year, despite Arthur Liu recommending it to all the GSoCers. Mostly due to paranoia over airline security and US customs searching my laptop.

Debian is apparantly going to actually have release deadlines, albeit every other year as opposed to twice a year like Ubuntu. Still, it's nice to see a commitment to releasing. My first experience with Debian was a while back, when all the worthwhile packages were still in testing.

Hopefully, tomorrow I can get Xen working again. Xend won't start, something about an 'invalid dom0 state'. I suspect it has something to do with the fact that NetworkManager manually configures peth0 when it shouldn't, requiring me to fix up the routing tables. Worst comes to worse I'll have to try and run Xen and euca on my desktop, which is just barely compatible with Debian.

One of the things I'd like to do for VMbuilder is have it automatically package the Linux kernel and ramdisk into Eucalyptus, if the user opts for it. You can already upload new kernels and ramdisks with Eucalyptus/euca2ools provided your cert has the appropriate rights on the cloud. see [0]

[0] http://open.eucalyptus.com/wiki/EucalyptusImageManagement_v1.5.2

lenny vmbuilder with xen, debconf, I discover key visualization

Well, the current VMBuilder available on the git archive[0] now supports building Lenny on vanilla Xen. We're very close to building AMIs, I can almost taste it. (The reason why you haven't heard about this until today is that accessing Blogger is super-finnicky when not logged in for absolutely no reason at all. My apologies for the lack of updates on this blog.) Additionally we're starting to actually put documentation and stuff on the wiki [1,2,3] about the GSoC project and euca2ools.

The next step is to look at a few packages called 'ec2-init' and 'ec2-modules'. They only exist in Ubuntu right now, and I purposefully disabled VMBuilder from installing them on Debian so far since Debian doesn't have them. That, and I believe I should pick out a suitable AKI/ARI combo sometime (the AKI info in the Debian plugin is just a placeholder right now). This shouldn't take too long. I would like to get the VMBuilder changes in Debian soon, and hopefully get those changes in the VMBuilder trunk[4] too.

My project was part of the Debconf talk on the Debian GSOC projects which I believe was 2 or 3 days ago. I'd look up the presentation and watch it but right now I have my friend begging me to install Ubuntu for him so he doesn't have to use Vista anymore.

[0] git://git.debian.org/git/pkg-escience/vmbuilder.git
(that's a lotta gits)
[1] http://wiki.debian.org/VMBuilder
[2] http://wiki.debian.org/euca2ools
[3] http://wiki.debian.org/DavidWendt/GSOC09Project
[4] https://launchpad.net/vmbuilder

euca2ools, kmeisthax@Lappy-486.A, and other annoyances

Well, it's finally out so I can tell you all about it: euca2ools, the fabled free software EC2 API client! Unlike a certain other company's tools, these don't have onerous usage restrictions. Yes, our VMBuilder[0] already supports using it as opposed to Amazon's tools, it defaults to Euca tools then Amazon's tools. (Block the usage of either using --ec2-no-amazon-tools or --ec2-no-euca-tools, keep in mind you still need one or the other to bundle or upload.)

And another thing... I recently took a look at the git repo [0], and noticed it's littered with commits by "David Wendt (kmeisthax@Lappy-486.A)"... please ignore the screwed-up e-mail address, I reinstalled Debian and forgot to change it to my normal address. (which is dcrkid (a) yahoo () com)

[0] git://git.debian.org/git/pkg-escience/vmbuilder.git

My current method for tracking/gitifying changes in foriegn VCSes

In vmbuilder.git we deal with a lot of upstream branches on launchpad being tracked with bazzar. So, I have to convert those revisions to git commits. This is how I handled importing a new branch from launchpad that branched from Bzed's r344 today:

#grab the revision

bzr branch lp:~ckaenzig/+junk/lenny

cd vmbuilder

#go to the point this revision branches from - note that this is a tag and not a branch

git checkout bzed_vmbuilder_debian-r344

#make a new branch for the underlying bzr branch

git checkout -b ckaenzig_junk_lenny

#clear out the current git working area, to reflect any RMs in the bzr revision

git rm * -r

#clear out any untracked files, such as .pyc and .py~

rm * -rf

#copy the revision over to the git repo, and stage it

cp ../lenny/* . -r

git add * -r

#make a new commit on this branch, which should now reflect the underlying bzr revision.

git commit -m "New bzr branch lp:~ckaenzig/+junk/lenny"

#tag the commit by it's underlying bzr revision number for easy reference

git tag ckaenzig_junk_lenny-r346 -a

This process generally works, but it requires careful attention and is easy to screw up. For example, I have to do a second rm to remove files that aren't being tracked by git (.pyc, .py~ files) , otherwise I end up committing junk that might be from another branch entirely when I stage the new revision. Not to mention that I may miss a revision this way. Say I have a branch A in bzr that I've manually imported this way for revisions r100, r123, and I wanna import branch B which breaks off from branch A at r112, I have to either put the new git branch at r100 (and have slightly inaccurate commit history) or start moving commits around, which I've never tried and probably doesn't push well. Fortunately VMbuilder doesn't get that many commits per day so I usually am able to keep on top of 'em.

Is there an easier way to convert bzr revisions into git commits? I'm horribly unfamiliar with bzr, so I haven't really investigated automating this process.

.euca//GIFT

Over the weekend Stephen Moeller contributed a bunch of patches to the Vmbuilder repository for Virtualbox support as well as fixing up the Debian packaging. You can examine them at the usual place(1), but be forewarned that I haven't tested them just yet. I'll get these off to Bzed tomorrow once I can be bothered to go downstairs and hook up an ethernet cable for Debian. And, of course, the usual machinations of pulling in changes from the vmbuilder trunk and bzed debian branch.

(1) git://git.debian.org/git/pkg-escience/vmbuilder.git

P.S. A little background - my Dell Studio 1535, while otherwise being a good machine, is cursed with a Broadcom Wifi card. I would rather not install non-free drivers on my Debian install after having a few bad experiences using the NVIDIA drivers on Debian on an older machine. So instead I go downstairs and physically connect the Lappy-486 to the home network.

yay mass commit bombs!

More work on VMbuilder - after fixing how the Debian plugin finds Xen kernels I got it to build a Xen image. (The Debian plugin was looking for images the way Ubuntu versions them, not the way Debian versions them) Now I need to figure out building EC2 images and such.

And send bzed a patched distro.py.

Epic merge fail

(seven less than symbols since blogger can't handle them)

#import sys

#import os

#sys.path += [os.getcwd()]

import VMBuilder

=======

class Suite(object):

def __init__(self, vm):

self.vm = vm

self.isodir = '/media/vmbuilder_inst_image'

self.iso_mounted = False

(seven greater than symbols since blogger can't handle them)vmbuilder_trunk:VMBuilder/plugins/ubuntu/suite.py

This happened to come from my attempt to merge VMbuilder trunk 0.11 with the current master; Git thought suite.py was moved to debian-vm-builder and tried to merge it.

Oh and yes that also means VMbuilder trunk 0.11 is now in alioth. I can't believe I missed it. It includes all the EC2 stuff without the install_[hardy,intrepid,jaunty] cruft as well.

So, to-do list:

• Get Debian plugins working with EC2 VMbuilder. The debian plugin branch on Launchpad hasn't been updated since June 6th; maybe bzed maintains another repo?
• Try building the package and installing it. Side note: They removed packaging info from the trunk midway between 0.10 and 0.11, but I kept the /debian folder anyway in vmbuilder.git.
• Speaking of which during the merge I noticed the default sudoers template explicitly references an "ubuntu" group, something that should be changed eventually.
• Look into the vmbuilder-gui branch sometime.