Elliot’s Blog

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.

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

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.

This past weekend I completed the migration of my gallery from a custom install to a proper appliance. In the progress of doing so upgrading to the latest release. This meant migrating a database and several gigs of images. I was amazed at how easy it was to pickup and move just the database, image data, and config file and have everything just work.

I did some testing with the Appliance Installer with Foresight Linux 2 today. Turns out that end to end time to install for a complete GNOME based Linux desktop is 7 minutes. That’s right 7 minutes. That includes user interaction and everything.

Looks like anaconda is shaping up for an alpha release of Foresight Linux 2. Ken is making good progress trying to get anaconda-templates built so that we should be able to get some sample ISOs out later this week or early next week.

Also, gmail has imap support….finally http://digg.com/software/Gmail_gets_IMAP

Today we released rPL 2 Alpha 4. This has been a long time coming. It involved a few rebuilds of the distro from scratch and switching away from our old internal build mechanism to rMake. Hopefully now that we have alpha 4 out the door beta 1 will be coming down the pipe soon.

One of the major changes in Alpha 4 is the addition of splashy for graphical boot. With splashy you get a splash screen and progress bar at boot and shutdown instead of the normal initscripts output. (Don’t worry for those of you who like to watch initscripts run, you can disable splashy by removing the “splash” and “vga=” kernel options from your grub.conf.) We are still working out some of the kinks, but don’t let this stop you from testing out splashy and remeber to file an issues that you happen to run across in rITS.

Another major addition in the alpha 4 release is the support in anaconda for the “Appliance Installer”. The Appliance Installer is significantly faster and has a smaller memory footprint than the “Installable ISO” that we normally use. How do we do that? We first let rBuilder generate a tarball of the group, split the tarball into chunks, and then add the chunks to the ISO. On the install side of things we feed the tarball chunks to tar over a pipe until the tarball is complete and then let anaconda write out some of the hardware specific configuration. This makes the Appliance Installer faster than *any* anaconda base that I have ever seen. Unfortunately there is no way for rBO projects to consume the Appliance Installer at this time, however there are some rBuilder features in the works to make it easier.