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
Showing posts with label launchpad. Show all posts
Showing posts with label launchpad. Show all posts
Monday, July 27, 2009
Wednesday, June 24, 2009
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.
Subscribe to:
Posts (Atom)