Elliot’s Blog

Had a lot of fun last night at the Raleigh Wars Assassin’s Ball. Posted photos from last night’s Assassin’s Ball.

Winning trophy

My prize for 3rd most kills

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

I have been toying for awhile with what I want out of the photo management software that I use to process, organize, and publish my photos. My requirements are as follows:

• Good support for tagging or some similar sorting method.
• Storing files on disk by date. Preferably $YEAR/$YEAR-$MONTH-$DAY. This is not a hard requirement, just prefered.
• Good support for Nikon raw files.
• Usable editing interface. This could be another application, but needs to integrate with the management app.
• Handle exporting to both flickr and gallery2.

I have asked around amongst people I know that have Nikon cameras and have found solutions to this problem that work for them. The each recommended different software:

• Apple Aperture 2 – This is Apple’s proprietary management and editing software. At first glance it looks to have all of the features that I require, along with several plugins that implement more features. I need to do more research and testing to figure out what I think.
• Adobe LightRoom 2 – Adobe’s photo management software, includes some features of PhotoShop. Looks like this probably includes all of the features I need. I still need to take a better look at it.
• Nikon CaptureNX 2 – This is of course targeted at Nikon owners and requires a separate application (ViewNX) for organization and export. My main problem is that ViewNX doesn’t seem to have all of the features that I want. Although from looking around it looks like some people use LightRoom to do there organization and export while using CaptureNX for editing, which isn’t out of the question, but kinda pricey.

Once I have evaluated all three I will post my results.

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.

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.

As some people may have noticed Firefox 3 Beta 5 has been pushed to Foresight Linux 2 QA and will soon be default in Foresight Linux 2.

The first thing that I noticed when I updated was that none of my extensions worked. After a few minutes of googling, I found that there are a couple ways to work around this. Some projects have development builds of their extensions that work with beta 5 and some don’t. For those that don’t you can try disabling extension compatibility checks.

Note that both of these options are potentially dangerous and may cause firefox to become unstable.

I disabled compatibility checks and downloaded the developer release of Tab Mix Plus, an extension that I can not live without. All seems to be working so far.

Disabling compatibility checks:

• go to “about:config” in your address bar
• right click to get to New -> Boolean
• set extensions.checkCompatibility for the key
• and false for the value

Developer versions that you might be interested in:

• Firebug
• TabMixPlus

Thanks to the following two blog posts that were great resources.

1. http://aralbalkan.com/1335
2. http://www.ilovebonnie.net/2008/04/22/finally-firebug-and-tab-mix-plus-for-firefox-beta/

Finally got around to posting a few pictures from Flourish.

http://photos.bentlogic.net/v/Flourish+08/

It was really nice to have the chance to talk to people about Foresight and finally meet a few more people face to face. There was a lot of interest in the KPC from many of the attendees and in Foresight overall.

I’m headed to Flourish this weekend in Chicago. I’ll be helping out Kevin with the Foresight and Gnome booths.

Stef is going to be giving a talk on building appliances with Conary and rBuilder.

The conference is on Friday and Saturday, but we don’t fly out until Sunday night, so I want to find something to do Sunday. Does anyone have any suggestions?  We are staying here.

I spent a couple of days last week figuring out what it would take a make an installable USB key of Foresight Linux 2. I knew going in that Anaconda could handle installing from hard drive, but I wanted to make sure that the installer had the same sort of automated feel that it has when installing from CD (ie, no user interaction in the loader).

Through testing I found that hard drive install from USB mass storage needed a bit of work to get it like I wanted.

I noticed that when the loader asks for the device to install from it doesn’t always list the device that you want to install from. This is due to the fact that it takes a few seconds for usb devices to come up once the usb mass storage module is loaded. I have added a patch to the loader that waits for the USB bus to settle and automatically probes for a device to install from, which can be enabled by passing “method=hd:auto” on the kernel command line.

After fixing that I found that the source device was showing up during partitioning and bootloader configuration. Normally when installing from HD you might want to install from one partition on a device to another partition on the same device. However, this is not the case when installing from a USB key. So I added another option, “hidesrcdev”, that tells Anaconda to ignore the device that you are installing from.

Here is the first sample that I have put together if people would like to try it out:

http://people.rpath.com/~elliot/foresight-1.9.9.alpha4-x86.img.gz

To use this image you will need at least a 2GB USB mass storage device. Here are a few easy steps to get you started:

1. download
2. gunzip foresight-1.9.9.alpha4-x86.img.gz
3. dd if=foresight-1.9.9.alpha4-x86.img of=/dev/sdb (substitute your usb device for sdb) Be warned that this will overwrite any data that is on the USB device.

If you have any questions or comments feel free to ask.

PacakgeKit 0.1.5 was released today. This release includes several fixes to the Conary backend:

1. Better error handling – The backend reports errors to PackageKit rather than just silently failing. Now when you try to update your system if there is an error you should get a nice message in your notification area that details the error. This might be rather verbose for now, depending on the error. If you see any really long errors that you think could be handled better please let me know.
2. Better flavor handling – The backend passes around both version *and* flavor information, whereas before it only really passed versions. This means that people that had issues updating because the backend sometimes got confused about what flavors it should use.
3. A bug in the get updates code that was triggered when packages are being erased as part of an update has been fixed. Unfortunately PackageKit doesn’t have a good way of differentiating between install, update, and erase in the GUI when getting updates. For now PackageKit will display the old version/flavor that is being removed.

PackageKit and gnome-packagekit have already been updated for Foresight Linux 2 Devel and should be updated for Foresight Linux 1 soon.