A Christmas gift some years ago of The Dream Hunters introduced me to Neil Gaiman's work. As an amateur of folk tales, I was entranced and delighted by the beauty and craft of The Dream Hunters, and then started reading earlier works in the Sandman series; my introduction to the graphic novel. Neverwhere and Stardust next captured my attention, followed quickly by most of the rest of Gaiman's books.

In my second and third readings of Stardust, I grew conscious of one of the characteristics of Gaiman's works that I find deeply satisfying: What I first saw as "loose threads" were actually precisely woven through the text.

For many authors, it appears to me that internal structural integrity is achieved in a tradeoff against narrative flow; or, more often, that narrative flow is achieved by ruthlessly discarding internal structural integrity. Speaking as an engineer, this is a reasonable tradeoff, since most readers seem not to care about structural integrity. But internal inconsistencies drive me up the wall even when perpetrated by my favorite authors. (I have read — and own and love — dozens of C. S. Lewis's books, but try piecing together the chronology of Narnia!)

Gaiman is in a delightful but rare class of writers who have the means and inclination to combine compelling narrative with extraordinary structural integrity. I consider Dorthy L. Sayers, J. R. R. Tolkien, and Rudyard Kipling well-known exemplars. Each time I re-read most of their published works, I generally notice additional internal consistency, rather than become annoyed by discovering small inconsistencies. This adds delight to re-reading, and helps me slow down while I read, increasing my joy in reading. A virtuous cycle.

Imagine, then, my delight to receive a copy of Gaiman's The Graveyard Book. I paid almost no attention to the title, as usual. I dove in and read the whole book, rudely ignoring everyone around me for hours. As I finished it, I took a deep breath of satisfaction, leaned back in my seat, and said to myself, "Wow. The Jungle Book, set in a graveyard... Oh." I am a little slow on the uptake, I guess.

Like several of Gaiman's other works, you probably won't like it if you are squeamish. There is Death, and Blood, and Violence, and even War. It differs from prime time television news in three ways: it involves magic, it tells of creatures that are literally rather than figuratively inhuman, and it is well worth your time.

Several readers of advanced copies have complained that The Graveyard Book is episodic; almost a collection of short stories. That complaint misses the point in several respects. The first is that Gaiman is a master of the short story; a few words tell a long story. The second is that this story is particularly well-suited to this presentation. It is short enough not to scare away a (say) middle school reader — good! If you want the story to last longer, read slower! True to form, Gaiman's narrative and construction reward careful reading. Finally, this book, in this form, is an homage to another great work worth re-reading, and worth reading out loud.

• Amazon
• Barnes and Noble

Foresight Linux has gotten a lot more popular recently, in part due to the release of the new Foresight Mobile Edition and Foresight Linux Kid's Edition.

Every silver cloud has a dark lining, it seems. The new attention has caused the system that runs the Foresight repository to run out of resources, and get much, much slower — particularly as Foresight developers are simultaneously doing major rebuilds in preparation for the combined GNOME 2.24 and Foresight 2.0.5 release.

We are now doing emergency maintenance on the Foresight repository system, applying more resources to handle the additional load. Unfortunately, this means that Foresight system updates are not available during some or all of this maintenance. This process will take several hours to complete.

Thanks for your patience!

Update: The Foresight repository is now available for reading, but not for committing. System updates will work. However, the repository will again go offline briefly when the maintenance is completed in order to transition the load.

Another update: The repository is now backed by a more capable database server (more memory, more and faster disk) that seems to be handling the load much better — we were essentially simply running out of memory. We'll be watching performance. And working on the software side too for better scaling.

I have welcomed the opportunity to do real-world testing of rBuild by working on LochDNS again — this time with a tool that makes the process take less time and attention. I'm pleased to announce LochDNS 2.0.

Again, we're fixing bugs throughout the ecosystem. I even managed to expose a long-standing corner-case bug in Conary that no one had hit for years.

One of the interesting things about LochDNS is that I build lots of images so that people can use it to demonstrate rPath's technology on lots of different platforms. The thought of manually clicking through lots of individual web forms to build about 20 images tended to keep me from spending the time to update LochDNS in the past. My odd case caught one more bug shared between rMake (RMK-907) and rBuild (RBLD-92) that we'll be able to fix shortly.

Having worked all the way through the process once with rBuild, and fixed the relevant bugs in rBuild along the way, I expect that future updates to LochDNS should be easy; mostly a background task.

Update: I have rebuilt rMake for RMK-907 with the critical fix so that all the images will be built. Later, I'll fix rBuild so that it reports which images it is building, instead of a generic Image_1, Image_2, etc. This change to rBuild will require the API change made in rMake for RMK-907 to function, so it won't work with released rMake. In short, update rMake before/if you update rBuild.

Ken VanDine has been using rBuild to build all sorts of projects. He has filed a few bugs, but has also been really enthusiastic about how easy it makes the whole process. Among his projects have been several variants of Foresight Linux. Derived packages are one of Ken's favorite Conary features and are perfect for making lightly-customized variants.

Unfortunately, rBuild didn't deal very well with derived packages. It turned out that this was due to two bugs; one in rBuild proper (RBLD-86) and one in rMake (RMK-906). With those two bugs fixed, Ken is much happier!

I released rBuild 0.5 alpha and built an rmake snapshot. Update to or install the latest versions of the stack with:

conary update {conary,rmake,decorator,rpath-{common,xmllib,product-definition},rbuild}=mkj.rpath.org@rpl:2


Remember, these are a combination of alpha code and un-validated snapshots. They worked for me in a few tests. Your milage may vary — and if it does, please do tell us about it.

In the past week of using rBuild for some real tasks, we've discovered several bugs. In particular:

• rBuild being reluctant to rebuild groups (RMK-903)
• rBuild not building images in rBuilder Online (RMK-897)
• rbuild rebase not working in non-standard label case (RPCL-36)
• rbuild rebase failing to update product definition (CNY-2971)

We have fixed all those bugs (in the current source code) without touching rBuild itself — note that all those issue IDs are for other components: rMake, rPath Common Libraries, and Conary.

In addition, we have found other bugs that we haven't yet fixed. For example, rbuild update stage not correctly updating packages (RBLD-89), and cannot publish certain rBuilder images built with rbuild build images (RBL-3386)

I have built some new packages, including conary and rmake snapshots with conary and rmake bug fixes included:

conary update {conary,rmake,decorator,rpath-{common,xmllib,product-definition},rbuild}=mkj.rpath.org@rpl:2


Remember, these are a combination of alpha code and un-validated snapshots. They worked for me in a single minor test. Your milage may vary — and if it does, please do tell us about it.