unburden-home-dir uploaded to Sid //at 02:54 //by abe

Most popular web browsers cause quite a lot of I/O on a user’s home directory and their cache’s also take up quite some disk space – with Google’s Chrome/Chromium you can’t even configure how much disk space should be used for the cache.

This causes unnecessary network traffic and no more makes sense if the home directory itself comes over the network, e.g. via NFS or Samba. And on laptops it spins up the disks and unnecessarily costs battery power and therefore lowers the potential battery life.

Such caches also costs scarce disk space on SSDs or flash cards as common in laptops, netbooks and other mobile devices, and often get backed up without any real use.

To take some of this burden off our NFS servers at work I started to develop an Xsession.d hook which moves off such caches to the local disk and puts in symbolic links instead into the user’s home directory when the user locally logs in.

This hook quickly became a standalone Perl script named unburden-home-dir and the Xsession.d hook just a wrapper around it. Due to some unsolved issues I didn’t feel it’s good enough for Debian Unstable, so I uploaded it just to Debian Experimental back then.

Pietro Abate’s recent blog posting about unburden-home-dir on Planet Debian gave me the right kick to make another try to solve the remaining issues.

And the mental distance gained over the time indeed helped and I could fix the remaining issues. So I added some polish to the package and uploaded it to Debian Unstable.

If you used the previous version from experimental, you have to take care of a few things:

• Previously some configuration files sported unburden_home_dir as base name while others used unburden-home-dir as base name as that’s also the package name. Now all configuration files use the package name, i.e. unburden-home-dir as base name.
• “Conffiles” under /etc/ should be renamed by dpkg automatically, but per-user configuration files ($HOME/.unburden_home_dir and $HOME/.unburden_home_dir_list) must be manually renamed to $HOME/.unburden-home-dir and $HOME/.unburden-home-dir.list.
• By adding UNBURDEN_HOME=yes to $HOME/.unburden-home-dir every user can decide himself if he wants the Xsession.d hook to be used when he logs in under X. On managed workstations with many users this eases testing of unburden-home-dir with just a few users a lot.

You can follow the development of unburden-home-dir also on GitHub and on Gitorious as well as on Ohloh.

Enjoy!

aptitude-gtk will likely vanish //at 01:06 //by abe

As Christian already wrote, there’s an Aptitude revival ongoing. We already saw this young team releasing aptitude 0.6.5 about 6 weeks ago, more commits have been made, and now we’re heading towards an 0.6.6 release quickly.

But this revival mostly covers the well-known and loved curses interface (TUI) of aptitude and not the seldomly installed GTK interface, which unfortunately never really took off:

While aptitude itself (i.e. the curses and commandline interface) is installed on nearly 99% of all Debian installations which take part in Debian’s “Popularity Contest” statistics, aptitude-gtk is only installed on 0.42% of all these installations.

One reason is likely that aptitude-gtk still hasn’t all the neat features of the curses interface. And another reason is probably that it’s still quite buggy.

Since nobody from the current Aptitude Team has the experience, leisure or time to resurrect (or even complete) aptitude-gtk, the plan is to stop building aptitude-gtk from the aptitude source package soon, i.e. to remove it from Debian for now.

Like the even less finished Qt interface of aptitude, its code will stay in the VCS, but will be unmaintained unless someone steps up to continue aptitude-gtk (or aptitude-qt, or both), maybe even as its own source package.

So if you like aptitude-gtk so much that you’re still using it and want to continue using it, please think about contributing by joining the Aptitude Team and getting aptitude’s GUI interface(s) back in shape.

Another option would be to find a mentor so that resurrecting (one of) aptitude’s GUI interfaces could become (again) a potential project at Debian’s participation at Google’s Summer of Code.

Please direct any questions about aptitude-gtk or aptitude-qt to the Aptitude Development Mailing List. Or even better, join the discussion in this thread.

Conkeror usable on Ubuntu again despite XULRunner removal //at 00:08 //by abe

Because of the very annoying new Mozilla release politics (which look like a pissing contest with the similar annoying Google Chrome/Chromium release schedule), Ubuntu kicked out Mozilla XULRunner with its recent release of 11.10 Oneiric. And with XULRunner, Ubuntu also kicked out Conkeror and all other XULRunner reverse dependencies, too. Meh.

Sparked by this thread on the Conkeror mailing list, I extended the Debian package’s /usr/bin/conkeror wrapper script so that it looks for firefox in the search path, too, if no xulrunner* is found, and added an alternative dependency on firefox versions greater or equal to 3.5, too.

From now on, if the wrapper script finds no xulrunner but firefox in the search path, it calls firefox -app instead of xulrunner-$VERSION to start Conkeror.

With the expection of the about:-page showing the orange-blue Firefox logo and claiming that this is “Firefox $CONKEROR_VERSION”, it works as expected on my Toshiba AC100 netbook running the armel port of Ubuntu 11.10.

From version 1.0~~pre+git1110272207-~nightly1 on, the Conkeror Nightly Built Debian Packages will be installable on Ubuntu 11.10 Oneiric again without the need to install or keep XULRunner version from Ubuntu 11.04 Natty.

For those who don’t want to use the nightly builds, I created a (currently still empty) specific PPA for Conkeror where I’ll probably upload all the conkeror packages I upload to Debian Unstable.

New upstream versions of xrootconsole and keynav in Debian Experimental //at 16:45 //by abe

I recently uploaded new upstream versions of two neat small X tools to Debian Experimental:

• xrootconsole displays on a transparent or shaded layer on the root window what it gets as input on STDIN, from a FIFO or from a file, and
• keynav, a way to control your mouse cursor efficiently with the keyboard.

Both packages introduce several new features and I’d be happy if users of these packages in Debian Sid or Debian Sid users curious about them could test the versions in Debian Experimental.

xrootconsole 0.6 + patches

xrootconsole saw no love since 2006 with the last maintainer upload having been in 2002. Nevertheless it never got kicked out of Debian just because of this. The package had been forcibly orphaned just less than a year ago. So it’s no big wonder that this new upstream version I packaged was released already back in 2004. :-)

But besides packaging a new upstream version, bumping Standards-Version and debhelper compatibility, fixing tons of lintian warnings and some bugs, I also added two patches which add new features not (yet) available upstream:

• UTF-8 support: Upstream xrootconsole just drops all bytes where the 8th bit is set which only allows ASCII. Miroslav Jezbera submitted a patch to allow at least displaying localized text containing single byte 8 bit characters as used in all ISO-Latin encodings. Inspired by the patch to add UTF-8 support to ratmenu, I wrote a patch to add UTF-8 support for xrootconsole, too.
• ANSI color support: Last year, Julien Viard de Galbert, who is also active in Debian, posted a patch in his blog to support ANSI colors as produced by many log colorizers like e.g. loco (RIP), colortail, lwatch, or ccze. (Didn’t get colortail and lwatch to work with xrootconsole yet, though.) I included this patch and made it compatible with my UTF-8 support patch. The patch raises the memory consumption per displayed character by one byte, but effectively I just saw an overall memory usage increase of about 25% which seems acceptable.

Of course I informed upstream about these feature patches, but I haven’t got any feedback yet.

But I got feedback from Julien Viard de Galbert, and he’ll join me in packaging xrootconsole as co-maintainer.

keynav 0.20101014.3067

I adopted the Debian package of keynav recently, subscribed to the keynav mailing list (well, it’s a Google group), got a nice welcome mail from the very friendly upstream developer Jordan Sissel who offered to help with any keynav issues.

I told him what features I’d like to see in keynav to fit better the setup where I’m using it. And just a few days later there was a new upstream release including both features I suggested, some more neat new features, and one bug fix. Jordan Sissel writes in the upstream changelog (emphasis and italic text by me):

• Added ‘restart’ command. Makes keynav restart. Useful for binding a key to reload the config.
• Added ‘loadconfig’ command. This lets you include additional config files to load on the command line or in one of the default keynavrc files. (requested by Axel Beckert) … and already in use here.
• keynav will now restart if it receives SIGHUP or SIGUSR1
• Map ‘Enter’ by default to ‘warp,click 1,end’ (requested by Axel Beckert)
• Fix a bug causing the point under the mouse cursor to not click through the keynav window in certain conditions. Reported via mailing list by Eric Van Dewoestine and Krister Svanlund.

Both packages will be reuploaded to Debian Sid (Unstable) after the release of Debian Squeeze (currently “testing”).

Thoughts on Gitorious and GitHub plus a useful git hook //at 11:36 //by abe

When I took over the developement of xen-tools, I looked around for an appropriate git hosting. I especially had a look at GitHub and Gitorious.

If you just regard the features, GitHub is definitely more targetted on single developers and Gitorious more towards projects:

At GitHub, every repository has its URL under the URL of a user page which makes it nearly impossible to have user independent, “official” repositories for projects which have more than one official developer.

At Gitorious, every hosted repository needs to belong to a project, even if it’s only a published configuration. But a project can have more than one git repository. You only seem to be able to have personal repositories if you clone some existing Gitorious repository.

So from a feature point of view, the xen-tools git repositories fit way better to Gitorious’ hosting while the git repositories with zshrc, conkerorrc and desktop configuration files defintely have a more fitting addresses on GitHub, in my case http://github.com/xtaran/$repository. On Gitorious, they are now together under a “project” called “Axel’s configuration files” at http://gitorious.org/abe which contains git repositories of my on grml’s .zshrc based .zshrc, my configuration for Conkeror and all the files necessary for my ratpoison/xmobar based netbook/laptop desktop.

I though feel a little bad for giving the project the very short “slug” name “abe” instead of “abe-config” (as I did initially) since “abe” is IMHO not a proper “project name” for my configuration files and possibly other projects would have a more reasonable claim for that project name on Gitorious. But that way it suites more its purpose: Gather some of my git repositories which don’t belong to a proper project.

But there’s another important point when comparing Gitorious and GitHub: Free Software needs free tools as Benjamin Mako Hill posted recently on Planet Debian. Despite my (probably well known) distrust against Google and therefore also Google Code, and despite knowing the history of SourceForge becoming non-free, I was not that much aware that GitHub’s software is only partially open source and therefore also not free software while Gitorious is both as it’s licensed under the GNU Affero General Public License (like StatusNet/identi.ca for example) which is basically GPLv3, but its ideas applied to hosted web applications scenario (where the GPL itself doesn’t grasp), too.

Initially I just had the xen-tools git repositories on Gitorious and all my small one-repository “projects” as copies of the repositories on my own git server on GitHub to get some more publicity for them and allow “social cloning”. After reading Mako’s article, I decided to at least have repository clones on Gitorious of all repositories I mirror at GitHub, too.

That way I force nobody to use the non-free tools on GitHub for “social cloning” one of my git repositories. And of course I have copies of my code somewhere on the net as backup. Or to say it with Linus Torvalds’ (slightly updated) words: Only wimps use tape backup: real men just upload their important stuff on git, and let the rest of the world clone it. ;-)

But isn’t that tedious to always push your code to three repositories? No, it isn’t. I just push my code to git.noone.org where I have configured the according remotes and the following post-receive hook:

#!/bin/sh
                                                                     
read oldrev newrev refname
git push gitorious ${refname:t}
git push github ${refname:t}

The only other thing necessary is to use ssh-agent and SSH agent forwarding to at least the host you’re pushing to.

Dear Aunt Google, //at 23:45 //by abe

… this is “Do no evil”—urchin.js isn’t.

For luck, urchin.js and friends can be easily blocked using e.g. Firefox plugins like AdBlocker or NoScript, or with filtering proxies like Privoxy. And a line like

address=/google-analytics.com/0.0.0.0

SCNR, via Symlink

Google Open Source Jam and Webtuesday Hackday //at 22:45 //by abe

I was at two geek events in Zurich this week: At the Google Open Source Jam Zurich on Thursday evening and at the first Webtuesday Hackday on Saturday.

Somehow I expected both events to be quite similar, but they weren’t.

Google Open Source Jam

When I read “Jam” or “Jam Session” I think of Jazz musicians spontaneously playing together. So for me “Open Source Jam” sounded like a hack session where some spontaneous coding is done. But there was no spontaneous collaboration at Open Source Jam at all. It’s just (more or less spontaneous) talks about different topics and chatting. So I was quite disappointed from that event.

There were though quite a lot of people I knew from e.g. Webtuesday, Chaostreff or Debian. I even met some people I just knew from IRC until then.

Half of the talks were sole propaganda talks though, e.g. for Webtuesday Hackday, OpenExpo and Soaring as a geek sport. Not really wrongly placed talks, but not what I expected in talks at Open Source Jam.

The few rooms and floors I saw reminded me very much to IKEA Children’s Paradies, just even more motley. Though it felt all sterile and wasn’t by far as cool as I expected after what I read elsewhere of Google offices.

I also think that several of the Google employees showed some contrived friendlyness, and questions I asked e.g. why I have to give them my e-mail address and employer’s name (what do unemployed or self-employed people do?) got answered with answers I do not really believe – like “for security”. A leopard doesn’t change its spots. A data squid probably neither, even not at events labeled with OSS and said to be for the community.

I suspect that finding new employees is one of the reasons behind such events at Google. But after my first visit at one of their locations, this company still makes me feel uncomfortable. And I’m even more sure than before that I wouldn’t want to work there.

Not sure if I’ll attend the Google Open Source Jam a second time.

Webtuesday Hackday

Webtuesday Hackday also was not as I expected, but still more close to my expectations: the Webtuesday crowd gathers for hacking instead of having long talks. :-)

There were surprisingly many people from outside Zurich, from Munich and Belgium, from Lake Constance and Lausaunne – not only the usual suspects (who were there anyway ;-).

The event took place at Liip’s new office. They still look a little bit empty and steril, but all the toys (mini rugby balls, Wii, plush figures on floor lamps) and people around made them very alive. And they had very cool lamps in the form of their company logo in the office. They sure have a good interior designer. :-)

Although most participants found time to do some hacking, many found less time than they expected so we hope that we can glue the talks a little bit more together in regards of timing to cause less interruptions of the hacking.

The food was also better at Hackday, too, but mostly because we ate outside. ;-) For lunch we were at Lily’s Stomach Supply at Langstrasse (very recommendable!) and in 6he evening we were at Pizzeria Grottino 79 near Helvetiaplatz. Had a Pizza Vesuvio with Gruyère cheese there.

Hackday also had a surprise for me: The IRC channel at Hackday was but when I entered the channel there were someone in I didn’t expect there: tklauser aka Tobias Klauser aka tuxedo. Even more surprising, he read about my project idea for Hackday – a semantic feed cache proxy – and liked it, so he decided to come over to Zurich and join the project.

We didn’t came that far until Tobias had to leave again, but the progamming language and partially also libraries had been nailed: Ruby and it’s WEBrick framework. After the Hackday I worked on it a few more hours and it now already saves feeds to a cache. The Mercurial repository is at http://noone.org/hg/sfc-proxy.

There were several reasons which spoke for using Ruby instead of Perl (my favourite progamming language and the one I’m most experienced in): Ruby brings HTTP and RSS support already in it’s standard classes and Tobias is more experienced in Ruby than Perl. I started to learn Ruby a few years ago to look beyond my own nose and to get my hands dirty on some object-oriented and nice programming language, but I hadn’t found an appropriate project until now, so this was one more reason to not do it in Perl.

I also worked on my Debian package of Conkeror during Hackday. It’s already usable and I now use Conkeror as primary web browser on my EeePC, but e.g. the man page is still missing. As soon as I have the minimum in necessary documentation ready I’ll let it upload to Debian Experimental (since its dependency XULRunner 1.9 is also only in Debian Experimental yet). The Mercurial repository for the Debian packaging of Conkeror is at http://noone.org/hg/conkeror/debian

Those who were still at Hackday in the evening decided that the Webtuesday Hackday should become a regular institution and should take place approximately every two months, but stay a one day event (for now). I already look forward to the next Webtuesday Hackday.