My terminal emulator of choice is xterm: it's fast, light, and (since it's pretty much the reference implementation) it has excellent support for everything a console user could desire... except for one thing that would be very, very convenient: making URLs clickable. Other terminal emulators have this feature, but they also have problems that make them inferior to xterm in different ways. Over the years people have come up with various workarounds for this situation, like screen scraping utilities (urlview, urlscan) that can be hooked up to other console programs to extract and browse URLs, but they're still not as convenient as just using the mouse, and often require the program to run on the same machine as the browser. Fortunately, xterm #277 (released in January 2012) added a new feature that provides almost exactly what I had been looking for: it can now spawn programs using the exec-formatted action and give them as argument the contents of the current selection or clipboard. So you can add the following to your ~/.Xresources: *VT100*translations: #override Meta <Btn1Up>: exec-formatted("x-www-browser '%t'", PRIMARY) which makes xterm run x-www-browser on the selection when it receives Alt + left click. (Adjust for whatever your Meta key is.) This is advantageously combined with a charClass setting to make xterm treat URLs as a single word, so that you can just double-click on them to select them: XTerm*charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48 With both of these enabled, opening URLs is now just a matter of:

1. Double-clicking the URL to select it
2. Doing Alt + click anywhere on the xterm window to run the browser

which, while more involved than a single click, it still much faster than having to copy the URL manually to the browser.

I've decided to take over the maintenance of the unofficial emacs-snapshot Debian packages that were maintained by Romain Francoise. They are available on a dedicated page.

Back in August 2007 I looked at the state of embedded md5sums in Debian packages and found that approximately 3% of the files in the archive didn't have checksums. Three years later, things have improved: only 0.76% of the archive is now missing checksums (sid, main/contrib/non-free). (See this lintian report for the list of affected packages.) Since then there's also been various discussions on this subject and there is now a policy bug open to make md5sums a requirement (at the "should" level). There is also a wishlist bug against debhelper to turn dh_md5sums into dh_checksums with a stronger hash algorithm, but MD5 still being good enough for simple integrity checking, it seems rather pointless to upgrade the algorithm without a trust path in the form of in-package signatures ala RPM... Anyway, what's perhaps more surprising is the growth of the distribution in only three years: sid has gone from 20774 to 30314 packages, a 45% increase. Similarly, the number of regular files has gone from approximately 2 million to just above 2.9 million. Indeed, looking at our last five releases, the distribution's growth is impressive:

• woody (2002): 8273 packages
• sarge (2005): 15195 packages (+83.7%)
• etch (2007): 18043 packages (+18.7%)
• lenny (2009): 22277 packages (+23.5%)
• squeeze (2010?): 28870 packages (+29.6%)

Whether or not that is a good thing is, of course, yet to be determined. As a data point, I used the UDD to know how many of these thousands of packages are actually used, and to my surprise, 22321 binary packages have a popcon installation count that is less than 500! (By comparison, dpkg's installation count is 89393.) So while each new release adds lots of packages, the majority of them have very few users. (If you want to check yourself, the query I used is select p.package, version, insts from packages p, popcon where (p.architecture = 'i386' or p.architecture = 'all') and p.release = 'squeeze' and p.package = popcon.package and popcon.insts < 500 order by insts;.)

How exactly are these packages DFSG-free? (via, via)

I have now finished converted most of the packages I maintain (part of the official archive or not) to the new 3.0 (quilt) source format. I first had to switch from dpatch or cdbs simple-patchsys to quilt, which was easy thanks to Romain Francoise s old blog post. Also note this quick adaptation for cdbs: The rest was much easier than what I thought, thanks to the related page on the wiki. I have already tried uploading a package to my personal repository, and reprepro just worked as expected.

The 0.3 release of Zeya is now available in unstable. If you haven't heard of it, Zeya is a web music player that brings your music to any <audio>-capable browser like Iceweasel/Firefox or Google Chrome, turning your collection into a personal online streaming service, using only Free Software (Zeya is licensed under the Affero GPLv3).

Phil has more details about this release, as you can see I contributed a few new features like a search function (100% client-side) and some performance improvements. It's been great fun hacking on Zeya in this cycle and there's plenty of interesting new stuff to add in the near future; feel free to join the team if you want to contribute!

So, the first thing I do when I boot up my laptop is to dist-upgrade it, and I was getting a little tired of staring at the (Reading database ... message you get when dpkg is busy reading its file database (laptop disk + dm-crypt + cold cache = slow). To preserve my sanity, I contributed a minimal patch to add a progress report, which Guillem turned into a generic facility in libdpkg and is now in the new dpkg in unstable (1.15.1).

It doesn't make dpkg any faster, but at least now I know how slowly it's really going. :)

I meant to blog about this last year but never got around to it. So, better late than never: Tom Tromey has a great blog series about his (and others') ongoing work on integrating Python into GDB. It starts with how to build a Python-enabled GDB, covers defining commands and functions, pretty-printing custom types, and a lot more (or perhaps you just want to jump to the conclusion).

I hope this will reach mainline GDB in my lifetime, it's very promising. There's no timeline on the wiki but the branch is still being actively worked on, so there's hope. :)

In case anyone's interested, here are some notes on the ASUS Eee Box, more specifically the b202 model, Linux edition:

• I use the box as a media center, so I initially wanted to connect it to my 720p HDTV using a DVI/HDMI cable. Unfortunately it's apparently impossible to use the TV's native screen resolution (1360x768) via HDMI, the best you can get is 1280x720, which results in a somewhat blurry image. Worst yet, the HDMI input has an overscan problem, approximately 50 pixels on each side are missing... which means that your GNOME panels will be invisible. I'm not sure if this is caused by the Eee Box or by my TV set but if you absolutely want HDMI, waiting for the b204/b206 model with its built-in HDMI might be a good idea. (In the end, I used my TV's VGA input.)
• It's more powerful than I thought. The Linux version ships with a 160GB SATA hard drive and 2GB of RAM (instead of 1GB for the Windows version) and the Atom N270 CPU is pretty fast. It plays 720p MPEG4 video (such as this file) with lots of CPU to spare, and the quality is really great.
• The optical S/PDIF audio output doesn't work under Linux, as far as I can tell.
• It's extremely silent despite the fan and hard drive.
• The Gigabit Ethernet controller is a nice touch, netperf reports a speed of 611 MBits/s. In practice the drive's speed will be the bottleneck, of course.
• To avoid tearing issues when playing video with Xv, use the Intel Video Overlay adaptor instead of the (default) Textured Video adaptor. (Use xvinfo to get the port number.)
• OpenGL performance isn't great; Compiz with basic effects will run fine, mplayer can play most video files using the gl/gl2 output without frameloss, but games will be slow. (Not that I expected much from the Intel GMA950 anyway...)

All in all I'm pretty happy with the Eee Box. If you have any questions, feel free to email me or leave a comment below.

Emacs 23.0.90 was released yesterday, it's the first pretest for the upcoming 23.1 version. Debian packages for etch and lenny/sid are here; Ubuntu packages for hardy, intrepid and jaunty are here. If you find any bugs please use M-x report-emacs-bug (unless it's a packaging issue, in which case feel free to email me directly).

This week's emacs-snapshot release (20090118-1) reached a new milestone with more than 700 downloads in just under a week. I guess this is quite an achievement considering that not everyone wants to download 25MB of Emacs packages on a weekly basis, so thanks to all my users for their continued trust and support!

Here's a quick update on the status of the Emacs 23 release: the last remaining feature on the roadmap was finally completed this week with the merge of the rmail-mbox (pmail) branch into rmail. The pretest (GNU lingo for beta ) phase could start as early as next week, which is not to say that the release itself is right around the corner since a few major tasks need to be finished first, like updating the manuals. The release could also be delayed by the proposed (and long overdue) switch from CVS to Bazaar, pushed by newly-minted Launchpad evangelist Karl Fogel.

That being said, aiming for a release in 2009 isn't entirely unrealistic, and I really can't wait to see Emacs 23 reach a wider audience. It is the culmination of many years of work in lots of areas (Unicode support, font backend, multi-tty, Cocoa, ...) and is by far the best Emacs version to date!

Today I decided to give Twitter a second chance and reactivated my account after almost 12 months of inactivity. Since this time I won't be protecting my updates I had to delete all my previous (possibly embarrassing) tweets before making my timeline public. But I didn't want to lose my data, so here's how I took a backup:

1. Install twyt (python-twyt in Debian)
2. Determine how many pages of tweets you want to save (let's say 10)
3. for i in seq 10 ; do twyt usertl -u <user> -p <password> -P $i >>twitter-backup.txt; done

You now have a text file with all your Twitter data.

Zack's post on git colors is a perfect opportunity to recycle this old post of mine on how to make git diff look more like quilt diff and vim.

For good mesure I'll also throw in this snippet (stolen here) which adds a git rlog alias, very handy when you just want to grab the short hash of a recent commit:

[alias]
    rlog = log --pretty=format:\"%h %Cblue%cr%Creset %cn %Cgreen%s%Creset\"

It looks like this:

• Why coding after a long drinking night is not a good idea
  Heh.
• Extension Developers - Better Background XMLHttpRequests
  Background content fetching that isn't canceled when the window closes, silences authentication prompts and SSL certificate dialogs... and this is supposed to be a good idea?!
• Jed s Other Poem
  Still love this video.
• Monsters

In the productive procrastination department: I repackaged rcs using debhelper (it feels like the future) and while I was at it, I implemented MadCoder's git maintenance scheme where changes from upstream are maintained in a rebased integration branch and serialized as patches in the Debian branch (master in my case) using git format-patch. It's pretty nice:

• I can use native Git commands to edit/refresh patches, which beats quilt any day;
• Changes to upstream are visible both as a git branch and as separated, commented patches in the Debian branch;
• If necessary (e.g. in case of NMU), outside contributors can just dump a -p1 patch in debian/patches and be done with it.

Of course this is a very low-maintenance package (the last upstream release was 13 years ago) so it doesn't matter very much which maintenance strategy it uses, but after implementing it I'm pretty confident that it works and I might switch my other packages to it.

If you're interested in knowing more about clever ways to use modern VCS for packaging, you may want to join the vcs-pkg mailing-list.

Emacs CVS has an interesting new feature: it now accepts a --daemon command line option which makes it start up as a Unix daemon; it detaches from the controlling terminal, starts up a new process session, goes to the background, starts an Emacs server and just waits for connections. The user can then use emacsclient to create new frames (console or graphical) for the background Emacs, using the new multi-tty abilities of Emacs 23. Since frame creation is virtually instantaneous, this makes the editor start up much faster than in the usual case (and a lot more so if you have an extensive configuration). Also, if your X session goes down, the editor is still running in the background with your buffers and applications, safe from harm. Very neat! (Get it from the usual place if you run Debian.)

(Note: this new --daemon mode is a cleaner replacement for the old screen-based preload-emacs script that was distributed with the multi-tty branch.)

Five years ago today, I became a Debian Developer! My account was created just a few weeks after Debian's 10th birthday and we recently celebrated the 15th, so I've been around for about a third of the project's life. In that period, we released sarge and etch, had two compromises, approximately 300,000 bugs were filed in the BTS, Ubuntu was created, three DPLs came and went, dunc-tank was launched and subsequently abandoned, and the Debian Maintainer status was created (among other notable events).

For me personally there have been ups and downs, but mostly it's been fun. I'm still proud of taking part in what is perhaps the largest volunteer project to date, and one that can produce a distribution of outstanding quality and versatility. The Debian community is huge, diverse and sometimes frighteningly technical, but always focused on making Debian (both the product and the project) better for everyone; it's worth being part of it if only for the amazing melting-pot of cultures and (sometimes antagonistic) technological philosophies.

I think that after fifteen years Debian is still relevant both as a basis for derivative distributions, and as a product for end users. I like to think that I've played a part, however insignificant, in Debian's success in the past five years and I hope that I'll be given the chance to continue contributing in the future. Rock on, Debian!

After two weeks of well-deserved vacation and other delays, I'm back to doing regular updates of emacs-snapshot. Here's a quick summary of the notable changes in Emacs CVS since my last post:

• longlines-mode was replaced by a more complete and reliable implementation of the same concept, visual-line-mode. It's based on a new low-level change to the display engine to support line wrapping at word boundaries.
• Fonts can now be customized on a per-buffer basis. S-Mouse-1 shows a new menu which allows to change the font used in the buffer, increase/decrease its size, or reset it to the default font setting (Options > Set Default Font). A new minor mode variable-pitch-mode enables non-proportional fonts in the current buffer, which is useful in Gnus articles or Info buffers.
• There's a new NeXTSTEP port which provides support for GNUStep (on GNU/Linux) and Cocoa (on Mac OS X).
• M-s is a new global binding for all things related to search like Occur, Hi-Lock, etc.
• Serial port access: Emacs can now be used as a serial terminal (like minicom), see M-x serial-term.
• Project-local variables: like file variables but for directories.
• New SVG splash screen images for Emacs and Gnus.
• New packages: proced.el, zeroconf.el, xesam.el, linum.el, ...

I use the FriendFeed API (launched in March) to build the blog widget mentioned in my previous post, and I'm rather disappointed to see that the data it exports is not the same as the data FriendFeed shows on my profile page (which is collected from the various services linked to my account). The Flickr service data in particular has two problems:

• There is no obvious way to distinguish between photos I've added to my favorites and my own photos, other than looking at the URL of the photo and extracting the username. On my profile page the photos are correctly labeled, so FriendFeed does have the information.
• When I add several photos to my favorites in a row, if FriendFeed notices them in the same update batch then they're exported in the JSON feed as a single entry with multiple thumbnails. Which means that I can't add links on each image to the corresponding photo page on Flickr as per Flickr's Community Guidelines; the entry's link property points to the photo page of the first photo in the batch.

Annoying. Now, I can't think of a good technical reason that would prevent FriendFeed from exporting my data properly over their API. Are they doing this for anti-competitive purposes? It's weird. I'm a big fan of data aggregation, but not if it's lossy like that!

It seems this is an infrequently asked question, so if you ever need to extract files from a Windows self-extracting installer executable that's been created with the Nullsoft Installer (NSIS): p7zip can do it, and it's apparently the only readily available tool for the job. The command to use is 7zr (shipped in the regular p7zip package) or 7z (shipped in p7zip-full):

$ 7zr X Firefox\ Setup\ 3.0.exe
7-Zip (A)  4.58 beta  Copyright (c) 1999-2008 Igor Pavlov  2008-05-05
p7zip Version 4.58 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Processing archive: Firefox Setup 3.0.exe

Extracting  localized
Extracting  localized/chrome
Extracting  localized/defaults
[...]
Extracting  localized/searchplugins/google.xml
Extracting  localized/searchplugins/wikipedia.xml
Extracting  localized/searchplugins/yahoo.xml
Extracting  nonlocalized/components/browser.xpt

Everything is Ok

Folders: 26
Files: 185
Size:       24930294
Compressed: 7496920