Somebody bought The Crying Tree by Naseem Rakha for Sarah as a present and she asked me to read it so we could talk about it, so I did. It's a novel about a family tragedy, Southern-state U.S.A. and the death penalty. A little boy is shot dead, a man is arrested for the crime and faces the death penalty. The book chronicles what happens to the family and to the killer during the 19 years or so that passes before the execution takes place. The book could be accused of having an anti-capital punishment agenda, but I have no problem with that. At least until about half-way through the book, the plot and happenings follow the synopsis with little in the way of surprise, but then there's a twist. I felt that the twist diminished the message of the book. Without trying to spoil what happens, I felt that you didn't need the core details of the story to be varied or expanded upon or U-turned to push that agenda. In my opinion, it's perfectly possible for someone to construct a story about a killer who faces death, who was unambiguously guilty of the crime they are charged with, and still leave the reader feeling remorse for the killer, and questioning the justice meted out. In fact I thought Rakha was doing a fine job of just that. However, a twist (or twists) occur, and the facts are called into question, and so you ask even further questions about the practise of killing criminals, in my view redundantly. It's a good book and worth a read, regardless of what your position is on the issue. It does a great job of describing the unbearable pain of losing a child, but also of the power of forgiveness for the victims.

Looks like installing iceweasel backport packages from

deb http://mozilla.debian.net squeeze-backports iceweasel-release

causes installation of backport of libcairo2 1.10 which breaks printing from GIMP, as described in this ubuntu bug. Does anybody know a fix/workaround? Update: looks like running gimp with LD_LIBRARY_PATH set to directory containing library files from squeeze libcairo2 package (1.8.10-6) workarounds this. But this story makes me think again that bundling libraries with applications is not that bad idea at least for users who need to get things done.

Bugs I've hit in GNOME 3, in the last 5 minutes:

• gnome-shell's "run" pop-up lost focus and I couldn't get rid of it. Nor could I launch another "run" dialogue, which is my normal route for starting software.
• I tried to coax my web browser into launching a terminal by browsing to file:///usr/bin/gnome-terminal. Instead, it downloaded a copy to ~/Downloads. Fine, no problem, because after another click it launches nautilus to handle the file. (This is not a bug).
• nautilus doesn't know what to do with the file. Apparently I haven't installed a handler for viewing executable files. I'm guessing the copy of gnome-shell isn't +x. nautilus does sensible things when another file (such as a picture) is marked +x, so why doesn't it do so for the opposite case?
• This is such a bizarre error message I try to take a screenshot of it. I take one, then take another (cropped). I try to save the second picture over the first one, but gnome-screenshot complains that it cannot find a file somewhere in /tmp.
• The flash plugin crashed in the middle of streaming an album. I'm almost not allowed to complain about the flash plugin crashing.
• After and around and inbetween all that, I downloaded an .amz file (an Amazon MP3 download file, in fact, of the album I'm failing to stream) which I hoped to run through clamz (a command-line, open source tool that can interpret AMZ files). nautilus offers clamz as a launch option in the right-click menu, but it's not the default handler. If I select "properties" to set the default handler, clamz is not in the list of available handlers.
• After sending the HUP signal to gnome-shell, I've got rid of the "run" pop-up, but now something has happened to it's $PATH and future "run" pop-ups can't find anything in the standard locations, like /usr/bin.
• since the flash plugin died, nothing else seems to be able to make any sound, so I can't play the album I downloaded anyway.

I didn't set out to bug-hunt this morning, I'm actually trying to get some work done. Whilst this is a particularly bad case of stacked-bugs, it's unfortunately, pretty representative of what it's like to try and use a Linux desktop at the moment. Every day I go through a similar experience. I've just had to give up and log out and back in again. The shell path bug above has re-surfaced in a new session. Great. I'm waiting on a delayed laptop at work. I'm very tempted to cancel the order and just use a Mac Air instead (we have one spare). It seems I'm walking the inevitable path of F/OSS desktop frustration and the end for many people seems to be the Mac perhaps I should spare myself the pain of the journey. In the mean time, It's bye-bye to GNOME and off to Xfce for me.

Today, six months have passed since the massacre I survived at Ut ya. It strangely feels simultaneously as if it happened ages ago, and as if it happened yesterday. I will write a longer post at some point, to try to sum up some thoughts, feelings and reflections I have made in the aftermath. But this post is actually intended to be somewhat, albeit weirdly, cheerful because today, of all dates, I was given a link to a web album by the Police where they post photographs of items they have recovered and cleared for re-release. And I got a kick out of this. Check it out!

I m getting my OpenVMS shirt back! Yay for conference T-shirts!

Something I've picked up from reading about economics is the concept of "the margin". It's a way of thinking about problems that more people ought to take into consideration. What is "the margin"? It's that space on a line, in the middle, between two extremes, where the transition from "yes" to "no" occurs. If I offered you a million dollars for the computer you're reading this on (for broad definitions of 'computing device'), you'd probably take me up on the offer. For 0 dollars, you would not. Somewhere, in the middle, is a number where you'd change your mind from "nope, won't sell" to "well... sure, what the heck". That is, loosly defined, a margin. As an example, when people debate about "intellectual property", they often use terrible examples: companies like Microsoft, or performers such as Lady Gaga. Those are bad examples because they are complete outliers, way off on one end of the curve. It's hard to disagree with "so what if Lady Gaga earns a bit less revenue from her music, she's got plenty to live on" when you talk about copyright being a means for artists to support themselves with. Thinking "at the margin" is about those bands that currently barely sell enough music to work professionally as musicians. In scenario A, they are able to work creating music, thus creating more, and likely better music than if they merely pursued it as a hobby. In scenario B, they fall on the other side of the margin and therefore have to get 'real jobs'. This means that their music takes a back seat, and they produce less of it. Now, copyright and company are a complex conundrum with many facets; my point is simply that when thinking about big changes, we should think what will happen at the margin, not what will happen to the outliers.

PHP 5.4.0 is around the corner, with RC6 released this weekend. With the courtesy of Ond ej Sur it s already available in experimental. Earlier this week, Raphael Geissert, tested some PHP extensions with the new version and reported 16 bugs (severity: important) against those who failed to build with PHP 5.4. As they will become RC bugs when 5.4.0 will enter unstable (probably around mid February), I preferred to handle them sooner than later. The result is 3 patches sent (one already uploaded) and 5 NMUs done. During the process I poked through a lot of upstream SCMs. In the way I found out a trivial change was done in PECL s SVN two years ago for all the extensions located there, which got me suspicious regarding some extensions we have. For non PECL hosted extensions, I had to track if and when a fix was done and use it for building or do a trivial fix myself. Packages using the 3.0 (quilt) source format were extremely easy to fix, and I was quite happy it generally went fast. In general I m a passive subscriber to the Debian PHP Maintainers mailing list, and finally could help actually and not just reply emails. For me it s also doing some Debian work after a few months of focusing on the coming LibreOffice 3.5 release. update [26/1/2012]: From the 16 issues, only 2 aren t fixed already or will be on the next upstream release. As their upstreams are dead, this is in the hands or the debian people, at least till they ll FTBFS on unstable (instead of experimental).
Filed under: Debian GNU/Linux, PHP

Hard to believe I've consumed all of 1981's Usenet posts now on olduse.net, and it's been running for 7 months already.

---

Last night, there was a "very long" post, describing nearly every node on usenet in 1982. There had been a warning about this post the day before, since it would take many sites half an hour to download at 300 baud. It was handily formatted as a shell script, which created per-node files. So, I ran this code nobody has run since 1982. It worked. I got files. I tossed them on the olduse.net wiki, and used some ikiwiki code TOVA contracted me to write just a few months ago, to make clickable links on my usenet map. The map data was contributed in another post a while back. By 1982, usenet is getting nearly impossible to map with 1982 technology of ascii art. I enjoyed throwing graphviz, git, wikis, and the web at it. So, we have a collaboration across time, me and "Mark" and a lot of people who described their usenet nodes and piles of technology that make creating a mashup easy. Awesome!

---

I blog about stuff I find on the olduse.net blog. It's an open blog; Koldfront also blogs there, and we welcome other bloggers. Some of the highlights for me have included: As the space shuttle program is winding down, reading the excitement about the first shuttle flights, and the play-by-play coverage of a launch, posted to net.columbia by a high school student borrowing his dad's account. (A usegroup name that's hard to read without remembering its fate). The announcements of the Motorola M68k, the IBM PC, and the CD-ROM. Reading the TCP-IP digest, and Postel's plans for launching IPv4 soon, while the world IPv6 launch is being planned now. (The nay-sayers are especially fun to read. Including the guy who was concerned about the address space size, in 1981!) Learning that nethack ascention tales have a history streching back 30 years, to rogue, and that the stories back then had much the same flavor as they do today. Various celebrity sightings. Dennis Ritchie teaching C and Unix. Bill Joy talking vi. RMS talking .. nuclear politics? The general development of usenet. B-news being rolled out, groups proliferating, many first inklings of what will be major problems and developments in 5 or 10 years. A shift in tone is already apparent, by now usenet is not only about announcements, there are already some flames. Still 9 years to go!

I really should write these a bit more often. Wow, I can't believe it was over 4 years ago that I started having occasional face to face meetings with the ISC DHCP folks. The entire ISC DHCP team (of 5) was in town for an all-hands meeting, and Larissa Shapiro, the Product Manager for DHCP (and BIND) suggested it would be a good opportunity for another catch up. Given the current (bad) state of DHCP 4.2 in unstable, I thought this was an excellent idea, and so we all had lunch on Tuesday. I pretty much set the agenda, and it was

• general state of 4.2.2 in Debian
• situation with GNU/Hurd and their patch to fix an FTBFS (#616290)
• the current FTBFS issues with kFreeBSD (#643569)
• the embedded BIND sources in the DHCP source
• removal of the RFCs from the embedded BIND source (#645760)

The general state of 4.2.2 in Debian In a nutshell, it's a bit of a mess. We've got release critical bugs, build failures, the whole cat and kaboodle. It makes me very sad, because 4.2.2 was the first 4.2 series that I had a chance to upload, and I was very excited to do so, because it contains the hotly desired LDAP patches merged upstream. Unfortunately, it's also got the beginnings of the BIND/DHCP merger that's going to be BIND 10, and that is all a bit of a mess. It's directly responsible for the kFreeBSD FTBFS and the introduction of the RFCs, which are both keeping 4.2.2 out of testing. I gave the ISC folks a high-level overview of how Debian development works, and the normal progression of packages from unstable to testing to stable, and the release process and whatnot, and impressed upon them the implications of the current release critical bugs. I also showed them how Ubuntu development fitted into the picture. Finally, I showed them the popcon statistics for DHCP. I think they found it useful. FTBFS issues on kFreeBSD This was a good segue to #643569. The issue is actually with the embedded BIND sources. I'd already forwarded this bug upstream when it first happened, but I don't know what had happened to it. They seemed to act as if this was the first they'd heard of it. I'm hoping that they can get this fixed in 4.2.3, which is due around the end of the quarter. Embedded BIND sources Since we were already talking about an issue caused by the embedded BIND sources, we moved on to talking about #645760 and the existence of the embedded BIND sources in general. It should be pretty straightforward for them to strip the RFCs out of the source. They've already done it in the past for the DHCP sources, so I'm also hopeful that this will get resolved in 4.2.3. The issue of the embedded BIND sources is apparently a bit more complicated, although the day before our meeting, Michael Gilbert filed #643569 and #645760, so I hope that the ISC folks can take a look at these patches and see if it's feasible to adopt them. Patches for GNU/Hurd Finally we talked about #616290, which I know is near and dear to the GNU/Hurd porters' hearts. We probably spent the most time talking about this. The DHCP developers have concerns about accepting a patch for an OS that they do absolutely no testing on, and also questioned the viability of the OS in general. They stressed that they're fairly thin in numbers relative to what they have on their plate to achieve this year, and so pushed back pretty firmly on accepting the current patch. I relayed the frustration that the Hurd folks were having about a lack of dialogue around the patch (most of the interaction has been via an ISC support person). There was actually a bit of a split between the developers, with one of them appreciating that the Hurd was unlikely to go anywhere as a platform without a working DHCP client, so in some regards, they were condemning the platform by taking the position they were taking. They're going to go away and take another look at the patch and try to come back with some actionable feedback on what needs to change to make it more acceptable to them, so we'll see what comes of this. I'm not particularly optimistic that anything acceptable to the GNU/Hurd folks is likely to happen any time soon, but maybe if the patch gets cleaned up a bit more, I'll just bite the bullet and start applying it to the Debian package. BIND 10 One of the guys is more involved in BIND 10 than DHCP, and asked if I could help out with the packaging of a build dependency for BIND 10. It seemed like #578387 was languishing so I offered to pick it up. I've not packaged a library before, mainly because the library packaging guide has scared me off it (I feel I lack the deep C fu that seems necessary), but I figured that this would be a good learning opportunity, so I'm going to dive in.

So the site http://megaupload.com/ has been taken offline, amidst allegations of knowingly conducting in piracy. There are probably a lot of legitimate users who have lost access to their uploaded files, even if they were offsite backups you can imagine a user owning a website which now has a million dead-links. This reminds me of a conversation I overheard on Jon Dowlands blog - the summary is that he'd written a (useful) tool to extract attachments from Maildir folders and was wondering how to store and access those attachments. The upshot seemed to be magical URLs of the form:

• https://file.example.com/sha1/509c2fe2eba509e93987c3024a74d74583c274bd

The comments covered an alternative which was hash:///sha1/xxxxxxxxxxxxxxxx, which then becomes close to the magnet:// schema. I've not yet thought things through, but I can't help thinking that with the redundency already present in the internet we should be looking at non-server-specific links. Yes there are times right now when you might want to address a specific file on a specific server - but otherwise? Wouldn't it be nice if you could just access a file from "anywhere" which happened to have the right contents? Already my nonporn-but-definitely-adult-site makes its images available as /img/$md5sum.jpg - and similarly the storage at the back-end of my random image upload site uses SHA1 hashes to store the actual files. To make this more complete what we need is something that crawls the internet to find files by hash; then add support in browsers. Obviously this must be async and could introduce timing issues, but fundamentally it seems like a reasonable approach to the problem of a single host going offline. (Consider what happens if imgur.com disappears. All those links would die, yet 99% of the images would still be available somewhere.) I'm tempted to suggest microformat format but I need to consider the matter. Right now I'm going to immediately update my current image hosts to use, at the very least:

 <a href="/foo" rel="sha1:xxxxx md5sum:xxxx">
  <img src="foo.jpg" alt="img name">
 </a>

The unfortunate thing is you cannot have a 'rel="xx"' attribute for an image. So you either have to encode it in the parent link, or add it to the alt attribute which is suboptimal. ObQuote: "Now, they tell me I paid my debt to society." - Oceans Eleven (2001)

Yep it s pretty simple. Just press CTRL+ALT+* (from numerical keyboard). Peter Hutterer, an X.org developer, posted an interesting article about this. And the link to the original blog entry about it.

For the sake of anyone else who s fighting their screens, I ve got a script that will do this (but very very slowly) setup script

xrandr --output VGA1  --auto
xrandr --output LVDS1 --auto
xrandr --output VGA1  --rotate left
eval " monconf "

monoconf script

#!/usr/bin/env python
import subprocess
output = subprocess.check_output(["/home/tag/.bin/mon.ls"])
output = [ item.split() for item in output.split("\n") ]
mons =  
for mon in output:
    if len(mon) > 0:
        if mon[1] == "connected":
            res=mon[2]
            res=res.split("x")
            for item in res[1].split("+"):
                res.append(item)
            res.pop(1)
            mons[mon[0]] = res
BOTTOM_LEFT = "LVDS1"
TOP_RIGHT="VGA1"
LEFT_WIDTH  = mons[BOTTOM_LEFT][0]
LEFT_HEIGHT = mons[BOTTOM_LEFT][1]
RIGHT_WIDTH  = mons[TOP_RIGHT][0]
RIGHT_HEIGHT = mons[TOP_RIGHT][1]
print "xrandr --output %s --pos 0x%s" % (
    BOTTOM_LEFT,
    (int(RIGHT_HEIGHT) - int(LEFT_HEIGHT)))
print "xrandr --output %s --pos %sx0" % (
    TOP_RIGHT,
    int(LEFT_WIDTH)
)

and the mon.ls command

xrandr -q   grep "^[^\ ].*"   grep -v Screen

All of this is super hacky, but it works.

There s been a lot of weather here in Seattle this week. It looks like the Tukwila DC s power blipped this morning. It gave me an excuse to update some configs on a few of the OpenVPN endpoints, re-configure some of the shorewall6 stuff, and enter a bunch of hosts and IPs into the BIG-IP s node list. It gives me a quick way to know what needs fixing first when things start breaking and is a lot easier to configure than NAGIOS. If I really wanted to get fancy, I could even write me some hot external monitoring scripts in perl. I am growing fond of this machine.

Kim Jong-Il is gone. That said, he continues to live on, looking at things, on the popular blog Kim Jong-Il Looking At Things which continues to be updated with new content from the archives. It is now joined by Kim Jong-Un Looking At Things. I think I agree with Jo o Rocha, creator of the original, that the younger Kim seems to be missing some hard-to-pin-down quality that made the original work well.

Debtags for derivative distributions Sometimes I do cool stuff and I forget to announce it. Ok, so I recently announced a new Debtags website. I forgot to say in the announcement that the new website does not only know of Debian packages: see for example this page, at the very bottom it says: "Distributions: oneiric, precise, sid, testing". This means that already, here and now, debtags.debian.net can be used to tag packages from both Debian and Ubuntu, and can easily be extended to cover the entire Debian ecosystem. If you are a package maintainer, you will notice that your maintainer page shows your packages from everywhere. If you want to filter things a bit, for example hide obsolete packages from an old Debian Stable or Ubuntu LTS, just click on the "Settings" link on the top right to configure the page. How it works The magic is in this mergepackages script, which is run daily, and exports merged Packages files at dde.debian.net. The debtags.debian.net concept of Packages and Sources files are just those all-merged.gz and all-merged-sources.gz. The merging is simple: that rebuild script processes files in order, and the first version of a package that is found is chosen as the base for the one that will go in the merged Packages file. Some fields like "Description" are just taken from this pivot package, others like Architecture or dependencies are merged into it. It's arbitrary, but works for me: the result has all the packages with all their possible architectures and dependencies, and is ready to be indexed with apt-xapian-index. At the moment I pull data from Debian and Ubuntu, but you can see that the script can easily be extended to pull data from any Debian-style ftp archive, so any Debian derivative can go in. I've already started negotiations with the Derivatives Census on how to add any Debian derivative and keep the list up to date. How to export tags for your own distribution I'll use Ubuntu as an example since the data is already available. The way you add Debtags to the Ubuntu packages file is just this one:

1. Get the full reviewed tag database
2. Optionally filter out those packages that you are not interested in
3. Tweak this script to build an overrides file.
4. Give the overrides file to your favourite ftp archive building tool.

The make-overrides is a bit rusty: if you improve it, please send me your changes. That is it, nothing else required, no excuses, it's ready, here, now! Hitches and gotchas This merged Packages file is a bit of a hack, and suffers from name conflicts across distributions, where two different softwares are packaged in two different distributions with the same name. Ideally, name conflicts should not happen: if a derivative decided to package kate and call it gedit, they deserve to have it tagged uitoolkit::gtk. I think it's rather important that the whole Debian ecosystem works as much as possible with a single package namespace. However, that reasoning fails if you take time into account: packages get renamed, like git and chromium, and may mean completely different things, for example, if you compare Debian Stable with Debian Sid. This last is a problem caused by debtags only working with package names but not package versions. I have a strategy in mind based on being able to override the stable tag database using headers in debian/control; it still needs some details sorted out, but I'm confident we will be able to address these issues properly soon enough. Why stop at the Debian ecosystem? Why indeed. I'm clearly trying to use FOSDEM, and the CrossDistribution devroom as the venue to discuss just that.

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1563
Affecting Wheezy:	928
Wheezy only:	192
Remaining to be fixed in Wheezy:	736

Of these 736 bugs, the following tags are set:

Pending in Wheezy:	51
Patched in Wheezy:	116
Duplicates in Wheezy:	46
Can be fixed in a security Update:	22
Contrib or non-free in Wheezy:	12
Claimed in Wheezy:	0
Delayed in Wheezy:	3
Otherwise fixed in Wheezy:	41

Ignoring all the above (multiple tags possible) 495 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 827 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

A small tutorial I made about an effect I used in the previous interviews (in English), so, for consistency, I had to recreate it, even after Kino was no longer available in Debian Wheezy.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/6y-6V1Dj1p0" width="480"></iframe>

I'll probably upload more videos like this about cinelerra, pitivi, gimp, audacity and other software I use for the work I do for our Sceptici n Rom nia / Skeptics in Romania podcast (The podcast is in Romanian, but we are preparing also a project for the international audience, too).

And in case you are wondering, yes, this podcast is part of the reasons I wasn't able to do any work for Debian lately!

So since my last post about perl tutorials, the Perl Tutorial Hub has leaped from page 2 to be the top result for the relevant Google search. The Leeds tutorial has dropped off the first page. I couldn't figure out how such a dramatic reversal could have happened, until I asked Mithaldu on IRC; the admins of the old Leeds tutorial have added a (delayed) redirect. So, Google has interpreted that as a 302 status, and given perl-tutorial.org all the old inbound links, presumably. Perhaps there is hope for Perl yet. :)

I'll be in Great Britain next week. I'll come to the Debian Party 2008 in Cambridge on Saturday 23rd August and will be back to London to visit 'till Wednesday 27th August. I'm staying by myself in a nice little hotel in Bloomsbury.

It will be very interesting to meet Debian people and probably do some pitching for my Aptitude GTK project which is making nice progress.

I've never been to London before. In fact, I've been once when very young and all that I can remember is that the hot dogs seemed nice :). I'm currently reading the Lonely Planet book about London and filling my program. Hi, London!

Hi folks!

We're almost done for the official Summer of Code program and I thought that I couldn't let it end without another update, so here we are (you may thank Daniel Burrows for additional poking).

The Gtk+ interface for Aptitude is making great progress. The product is not final yet but already implements many of the planned ideas, with others to come.




So, let's see the tasks presented in my previous update:

• A real user interface <- much progress here


• Being reliable <- check! we don't crash all the time anymore


• Packages dependencies, pre-dependencies, etc. <- check!


• Hyperlinks between packages <- check!


• Advanced package search <- check!


• Tags support (tag clouds ?) <- well, no clouds yet, but we have tags


• Linking with interesting data sources like popcon <- not done yet


• A lot of interesting things <- well..

In some more details: we are now much closer to the final interface. Some things are not done yet, for example, notification bars la Iceweasel (or is it Firefox ?) are in the works for unobtrusive notifications about important things and a little guidance.

We are much more reliable now. We eliminated lots of memory management problems that resulted from, mmh, imperfect coding discipline. We also lock the interface when important backend stuff reload to prevent the user from shooting himself in the foot when triggering an install when the APT cache is reloading for example.. The backend refactoring took a sizable part of this second term but it was worth it. The code is now much cleaner and uses no more (at least much fewer) ugly unscalable hacks.

One very important feature of Aptitude is the ability to easily display all kinds of dependencies and navigate through them by hyperlinking. It's now working in the Gtk+ interface as well. Feel free to click on whatever looks like a package or a package version.

We now support the powerful Aptitude package searching syntax. Daniel Burrows is talking with Enrico Zini to bring the power of apt-xapian-index to Aptitude: autocompletion! lightning fast full-text searches! tag clouds! ponies!

There is still a lot to be done. I'm not going away after the GSoC program. I'm here to stay, for Aptitude and Debian. Daniel Burrows has been very helpful and supportive. The Debian community is as awesome as I knew it before participating in the program.

Daniel Burrows is planning to merge the Gtk+ interface into the main branch in September and packages may appear into Experimental. With the very interesting evolutions of the upcoming Adept-3, Lenny+1 will show very interesting changes in the area of packages managers.

Now for you. I need you to test my interface. All necessary instructions are on the development trac : http://dev.graffit.net/aptitude/trac.

Long time no post. Anyway, I have some good news.

The Gtk code for Aptitude has been merged some time ago into the main development trunk and we now have a release in Experimental.