Elliot Peele

08:38 pm - Wordpress Appliance updated to 2.8

Originally published at Elliot's Blog. You can comment here or there.

I have updated the Wordpress Appliance to version 2.8 of Wordpress. You can read the release announcement here. Everyone should be able to update via the rPath Platform Agent or by running the following command:

conary migrate group-dist –interactive

11:43 pm - rPath Projects now on BitBucket.org

Originally published at Elliot's Blog. You can comment here or there.

rPath’s open source projects are now available on BitBucket.org under the rpathsync user. This should bring more visibility into our open source software and make it easier for anyone looking to contribute.

I would like to eventually do the same thing for GitHub now that the hg-git plugin is available.

The following projects are now available on BitBucket:

• amiconfig
• bootman
• booty
• conary
• conary-policy
• crest
• devsub
• epdb
• grubtobootman
• jiranemo
• kibot
• kisock
• nagpy
• raa
• rbuild
• rbuilder-client
• restlib
• rmake
• rpath-common
• rpath-product-definition
• rpath-xmllib
• speedbump
• xobj

As per usual our sources will continue to be posted to http://hg.rpath.com and these sites will be kept in sync.

08:53 pm - Naming a Distro Importer/Maintainer Thingy

Originally published at Elliot's Blog. You can comment here or there.

Over the past several months I have been working on importing SLES, CentOS, and Ubuntu into Conary repositories so that they can be made available in rBuilder. You can try out CentOS and Ubuntu on rBuilder Online.

One of my goals in doing the import was to have an automated way of maintaining and adding to these platforms in the future. From this “sleestack” was born, a collection of scripts and configs for importing SLES. Over the months it grew into a few thousand lines of python that is capable of coordinating updates for SLES, Centos, and Ubuntu.

Now that rPath has decided to open source “sleestack” I need a better name that actually reflects its current purpose. As it turns out, I suck at naming things. I have been hounding people for ideas over the past week, but no one has come up with anything that is quite right. I am looking for something witty, yet descriptive. The current suggestions are:

• distroteque
• CustomsAgent
• rConstruct
• rImport
• coversion

Any suggestions would be greatly appreciated.

05:52 pm - GNOME Developer Kit: much easier than building from SVN

Originally published at Elliot's Blog. You can comment here or there.

Arstechnica recently published an article on the GNOME Developer Kit that Ken put together. It is based on Foresight Linux and automatically built from a fresh SVN snapshot every night using rMake. The project can be downloaded from gnome.rpath.org for anyone to use.

read more | digg story

10:17 pm - managing sources with hg convert

Originally published at Elliot's Blog. You can comment here or there.

One of the things I do at rPath is hack on Anaconda. We have decided to mostly standardize on Mercurial for our SCM. Since Anaconda, at the time, was managed in CVS, this meant that I needed to find a tool to convert a publically accessible CVS repository to a Mercurial repository. The only tool that I could find that was capable of doing this without having local access to the CVS repository was tailor. Tailor takes pretty much any SCM repository an converts it to darcs and then converts the darcs repository to another SCM repository format. Darcs is yet another SCM.

A couple of weeks ago the Fedora Project converted Anaconda from CVS to GIT. This meant that I needed to reconfigure tailor to handle the change. Through some help from the maintainer of tailor over IRC I was able to get tailor configured to deal with the switch. Over the next week or so I noticed that tailor had some issues handling branches in GIT and decided to find a new way to maintain my Anaconda Mercurial repository.

With a bit of searching I found the Mercurial convert extension. Which allowed me to switch away from tailor to something that would be at least somewhat supported by the Mercurial project. Getting the convert extension to pick up where tailor had left off took a bit of figuring out. The convert extension uses a map file that maps IDs for each GIT commit to a Mercurial commit ID. I had to manually create this file by extracting all of the commit IDs from the GIT repository and filling in null values for the the Mercurial ID side of the map. As the last entry I included the commit ID for the tip of the Mercurial repository that matched the point at which tailor had stopped being able to convert the GIT repository. With all of this in place hg convert could now handle converting the upstream Anaconda GIT repository to Mercurial. The Mercurial repository is now updated nightly (around 4am EST) from the upstream GIT repository.

You can find the converted upstream Anaconda Mercurial repository on rPath’s public Mercurial along side rPath’s custom Anaconda Mercurial repository, that includes support for both the Conary based installer and tar archive based installer.