preupgrade -- caveat emptor

A good rant every now and then?

I have been upgrading my Fedora machines by hand using yum. This seemed to work OK, for a machine with minimal tweaking there usually were not so many dependency issues that had to be solved by hand. Though it still is a time consuming process for a handful of machines.

So, I recently found out that I'm bad boy (oooh yeah!), and should have been using preupgrade. Looking at TFM I thought, "fair enough, upgrading a non live system seems like a wise thing". So I gave it a whirl. Which ended up in a strange exception in anaconda and after reboot /var/lib/rpm was missing. yay. So I trip to the reinstall Fedora 11 from DVD shops later and I was back in the mix. But there were/are still some other machines that needed updating to 11.

Once bitten, twice masocistic I thought. So I decided to try on another machine. It might have been something I tweaked on the laptop over the many Fedora updates etc that fluffed up preupgrade and anaconda...

Luckily the second time I didn't loose any data. For one thing, my /var/lib/rpm shouldn't be deleted assumption from before the first install was missing and everything was backed up (twice, I had running incremental baculas too). But preupgrade won't touch a system where /boot is on a RAID. So the second attempt stopped nice and fast.

I might try preupgrade again on the laptop next time. I left things fairly stock during the Fedora 11 install there just so preupgrade could possibly work its magic in the future. But I'm wondering if the pain of yum updating across versions makes sticking with Fedora worthwhile. I have better things to do than manually update and tweak things and if other distros don't chomp days of my life every 6-12 months then maybe I should check them out.

It's a bit sad that /boot on a software RAID-1 is such a rare setup that its not supported.

And that concludes this rant... was it as good for ya?

7th of May: A libferris talk in Ede, Netherlands.

If you are in Europe and want to hear about libferris and other cool storage stuff (register &) drop by the
NLUUG Spring Conference on Storage on the 7th of May.

I will of course have a maemo unit running libferris there as well as a laptop. Carrying a server with ferris is a bit too much though :) I'm brewing up the slides now with XQuery, KML, and SQLite goodness. Probably not the first three terms you think of when the words Virtual Filesystem are muttered.

Keeping it sorted with libferris

Click through for the 720 HD version...


Sorting directories with libferris and ego on multiple metadata values at once from Ben Martin on Vimeo.

This is the libferris file manager, it is called ego.

Although the interface looks quite simple, there
are context menus associated with most things.

There are also a vast number of sidepanels for searching,
filtering, bookmarks and editing metadata and tags.

Today I'm talking about sorting.

Of course, you can click a column to sort by it, and
click again to reverse the sort.

You can also set that sort order to be the default for
this directory, or the entire filesystem tree rooted
at this directory. Subdirectories will inherit settings
for a tree but can explicitly override them too.

You can also override what ordering you want for each
column, like using the version sort of ls for any column.

If you sort on something with many files having the same
value, you can append another column to the sort order.
For example, sorting by image width, then by file name
for files that have the same width.

You can sort by any number of columns. This is built
into libferris, so you can sort on many metadata fields
with ferrisls or any libferris client.

Packages for maemo and Fedora 10!

So, long story short, the place I was hosting my maemo repository was on a host at the university I did my PhD at. The server has been suffering unpredictable hardware issues so I have now moved the repository. There is a new subdomain fuuko.libferris.com where I'll be putting up some libferris related stuff, including packages.

In particular, the new libferris maemo repository is now up.

Also note that I have binary rpm files for Fedora 10 in both 32 and 64 bit at OBS.

10: It's the way of the future; goto 10;

So, boost 1.34.1 was released back in July 2007. It is however still the current boost shipped with Fedora 10. This is extremely unfortunate as there are many cool advancements in boost over the nearly 2 years since 1.34x. At least rawhide has 1.37, even though 1.38 has been released for over a month.

Looks like I'll have to add another switch to libferris configure.ac to drop some features to be able to compile against old boosts. めんどうくさい!

Like talking to a stranger

Now that I'm on planet Linux Australia too I thought I'd write up a brief howdee post. My main open source project is libferris which is a virtual filesystem with metadata extraction and index+search functionality. It also does a bunch of other interesting stuff, but as I've been writing it for what is getting close to 10 years now, one would imagine it has a few facets.

I mainly package libferris for Fedora and maemo because these are the platforms I tend to use it with myself. A while ago I did some packages for openSUSE and Ubuntu, but its hard to keep motivation for those when I don't use the distro personally. Plus on modern desktop or servers, stuffing ferris on a virtual Fedora machine isn't much of a hassle, given the price of even DDR3 RAM.

I'm also trying to stuff libferris itself into the main Fedora repository. But we'll see how that goes.

If you want to hear about libferris and other filesystem crack then you should come along to this NLUUG event in May. I'll be there presenting libferris and what I think the intranet metadata and search stuff should be doing (and probably will be doing in the libferris world) over the next few years.

As my blog description states, my posts are mainly about libferris but also include maemo stuff and generic C++, XML, RDF, and relational database topics. I seem to waffle on unmerciful about indexing, or so I've been told. Which is hardly surprising given the chunk of libferris devoted to implementing filesystem search through various techniques.

Also, if anybody is looking for user space virtual filesystem hacking or index and search work, then drop me a line :)

Tracker: Reading it both ways :(

Normally I refrain from criticising other projects that are "competing" with my little hobby -- libferris. I mention competing in quotes because hobbies don't really compete in a commercial sense. But having read this post recently on planet maemo about Tracker progress I was a little overwhelmed, wondering, was the Tracker code really so bad a year ago?

"In this last year, we refactor (well, almost rewrote) the daemon"

and talks about replacing the crawler code wholesale. Sure progress sometimes includes churn of functionality: reimplementing stuff with the benefit of 20/20 hindsight. But this seemed a little dramatic...