It’s here! In contrary to the estimated delivery time of about ten weeks, my Brompton arrived at Velofix at Saturday the 16th of February after only three weeks. The orange color is much nicer than the apple green I initially favourited from what I saw in the catalouge and the axle dynamo also proved to be a good idea, so I’m really happy about my choice. I used the Brompton to go to work everyday the last two weeks, even when it’s snowing like today: Although I’m starting slowly and taking the bus (hey, it’s a folding bike! :-) for the steepest parts (either from Am B rtli to Waidbadstrasse or Gsteigstrasse)… I even managed to fold the bike although I saw the bus already coming around the corner when I still was in the saddle. That was the day I was at work in less then 10 minutes — Perfect timing. :-) Since the local H ngg bus (route 38) only makes it’s round every 30 minutes, with the bike I’m now much more flexible and don’t have to hurry in the morning to catch the bus. (OTOH I had to notice that “being more flexible” doesn’t mean “having more time”… :-) I also use it on the campus for visits in other buildings. Although there are mostly stairs between the different levels of the campus, it’s no problem with the Brompton since it’s easy to carry, even if not folded. It’s much more comfortable than daduke’s little kickboard scooter whose hard wheels don’t feel healthy for bones and especially knees on ETH H nggerberg’s paths made out of washed-out concrete. Air tyres and rear suspension are much better… :-) Regarding the choice of gears: The MountainDrive would surely be helpful in hilly Z rich, especially since my fitness isn’t the best one at the moment, but 6 ears are ok, too, and will be even more ok as soon as my fitness gets better. The slower transmission wasn’t a bad choice either, although a wider transmission range would have been better.

Texas Instruments (TI) joins Linux foundation. Congrats.

TI will help foster the growth of the Linux platform and collaborate with industry leaders who define both technical and operational best practices around open source software. .... TI will further ensure that its customers have the necessary tools to create innovative and differentiated Linux-based mobile devices that use the OMAP platform and DaVinci technology.

How about starting with

• Releasing the OMAPx TRM (Technical Reference Manuals) available to Linux community
  
• Documenting your DSPs and providing a OSS bios for them (compilable with a OSS toolchain)
  
• Release drivers for _all_ parts of OMAP chips, such as the AES accelerator, Jazelle java acceleration, powerVR 3d and so on.
  

If you continue providing documentation only for "high volume customers", your membership in Linux Foundation is a PR stunt at best.

On this year’s Chemitzer Linux-Tage (CLT, engl. “Chemnitz Linux Days’) I attended a few talks of which especially formorer’s ikiwiki talk was very interesting. I attended his talk since I found out that ikiwiki is command line wiki compiler in contrary to the thousands of solely web based wikis out there. As a big fan of statically generated content this idea sounded very interesting to me. But just having a short look at ikiwiki’s web page didn’t help to get started and it seemed as if I had not the right idea of how ikiwiki works to get started. So formorer’s talk seemed to be a good possibility to get an idea of how ikiwiki works without much effort. During the talk I noticed that ikiwiki can many things I do with the Website Meta Language (WML), but can do some more things WML can’t do out of the box:

1. It’s not only a framework to generate web pages, it’s more like a content management system (CMS).
2. Versioning is intergal part of ikiwiki without reinventing the wheel: It works out of the box with — beyond others — Subversion, Git and Mercurical (Hg).

And when formorer showed that even Tobi Oetiker uses ikiwiki, I noticed that ikiwiki probably could be a WML killer, since I knew Tobi as a WML fan. And ikiwiki looks very appealing for the WML fan inside me, too… OTOH: Intergrating WML as a backend to ikiwiki could be an interesting idea, though. Hearing what kind of input files ikiwiki can process, I also got the idea of using hnb (Hierachical Notebook) files as input for ikiwiki. hnb files are already XML and so a conversion to XHTML shouldn’t be that hard. But when searching the web for “ikiwiki hnb” I found the blog postings of a few people switching away from hnb, e.g. to vimoutliner. Since I’m an Emacs addict and don’t like vim very much (if I use a vi, I use nvi or elvis), I searched for “emacs hnb” and indeed found someone who switched from hnb to org-mode – of which I never heard before. Unfortunately org-mode doesn’t seem to be in Debian (Update 00:23: Yeah, yeah, I now know it’s included in emacs22, but emacs22 hasn’t made it into kfreebsd-i386 yet, so I didn’t notice. See the comments. :-) but I’ll play around with it a little bit. Unfortunately a first test wasn’t that promising. But we’ll see.

Now playing: Men at Work — Down Under

Finally. With notification implemented I’m able to release the latest and greatest of AcmeCal. At the moment AcmeCal can do notification by either mail or XMPP (aka. Jabber). Still some polishing to do, like having the XMPP plugin test for presence before notifying. Having notification implemeted makes it even more clear that I need to improve the argument handling code. At the moment I’m using this in my crontab: acmecal-notify –type XMPP –from “$(date +”%F %R”)” –to “$(date -d “now + 30 min” +”%F %R”)” This version also brings AcmeCal right at the 1 KLoC-mark and it is now my primary calendar. Download AcmeCal version 0.3 - hey, it works this time

I love 2.0: Raquel has released a small interesting personal project as a tumblelog. Spanish spoken, I love 2.0 (although I prefer calling it I 2.0 ) features some interesting small chunks of information and news on Web 2.0 and related topics. Way to go!

Update (3/3/2008): We’re also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers. Here is my writeup of yesterdays Android Code Day in London. Eclipse 3.3 is needed to get the plugin working. Only eclipse 3.2 is in Debian unstable. Download the Europa release and re-setting up the plugin will do it. I’m no Eclipse fan boy, though the integrated debugger works. The iteration cycles are really short for trying stuff out. Very good. Developers, mainly from a Symbian background grilled Jason Chen over security and wanting C API access. Lot of people didn’t seem to like the idea that users were controlling security. I like Google’s “empowering the users” stance, though I think representatives from operators don’t. I heard that poor argument about users asking their operators for android support. Jason argued well that it’s up to user education to contact the right people. When a computer crashes in the UK, who do people call? VirginMedia? Please! :) How about Breakpad crash reporting on Android?. Jason used the OHA to defend Google from looking like they have all the political power… Hmmmm. :) I can understand the tight rope that Google are walking. They are trying not to fragment their platform before it’s properly released. OEMs, operators will feck it up if they have the chance to play with the source code before a Google co-ordinated release. Once they release Google claim they will release everything under the Apache 2 license. So I asked could we see Android on desktops? Jason said there is nothing stopping you. I hope not. Their opened fonts and multimedia codecs on desktop PCs could really make a big difference for Linux take up, especially in Asian (growth) markets. I have studied and implemented Asian fonts and Android’s font rendering even on that nightmare Website sina looked good to me. Despite the “Symbian developers” giving Jason hell in the beginning I had impression they actually liked Android. It fealt almost staged. Scary. Symbian C++ programmers learning Java and jumping ship! Same old problems with images. People are concerned about how bitmap images will scale on different target screens. There is four ‘skins’ already supported in the emulator (QVGA-L+P, HVGA-L+P). We need scalable images too on the Web. ;) Though there are some workarounds demonstrated which seemed OK to me. During the hackathon, I wanted to write a backup/sync tool. Since only Jason Chen seemed to know Android and there was a filled audience, I didn’t get to ask him how really to go about coding it. Though with the help of Dave from Zyb, we eventually found out about content providers. Took some debugging to find that out, but we got there. Having a working debugger is really really nice. We discovered we needed “android.permission.READ_CONTACTS” in the manifest to make our little application that read out the contact on stdout. Cool, though I’d rather use Javascript and the Web stack. Anyway, Android seemed like a good platform, but I have concerns. My biggest concern is basically where is Google Gears on Android? Jason could neither confirm or deny this, so perhaps they have it. Though gears is an opensource project and you can see code reviews… no Android mentioned. What happens if the Android platform is wildly successful? Then we are going to see two major platforms. The Android platform on mobiles and the Web platform on everything else. I worryingly saw no support for Web application device APIs on Android. Encouraging people to write for their Android/java-esque platform undermines their main Web platform! It’s like Microsoft’s mistake of undermining their own platform all over again. From Android you can use Webkit and the Web stack. But from the Web API stack you can’t seemingly access their Dalvik VM APIs. I disclose I am an employee of Aplix (opinions etc. are my own), also a OHA member. I am actively working on a plugin technology that exposes APIs as familiar JS APIs to Web developers. I have already done a proof of concept implementation of Google Gear’s Location API on mobile devices with Aplix technologies. Google you should really do the same and make Web applications equal citizens on your mobile platform by implementing Gears on Android (if you haven’t already).

I was a bit surprised when a letter from UEA arrived with a new logo on it. It looks like someone turned up the brightness until the thin parts of the letters started to vanish. IE+1? What's that then? There's confirmation on UEA's wikipedia page which includes the above logo. Ironically, the letter I got looks like it doesn't conform to the linked guidelines. I think this change weakens UEA's links with its alumni a bit, don't you? The old logo was everywhere while I was there. I'm going to miss the square logo with rounded reflex blue letters. Maybe I should stock up on UEA mugs, although a gold-on-blue UEA mug looks a bit wrong.

While most of you people and readers are doing quick and great works in Python, Ruby, or any modern language, there's still people like me fighting with The Low Level. I like that, but the X architecture is just the proof of concept of an architecture which wrongly evolved because it was not designed to. Xlib and all concepts it is based upon where probably fun and sufficient in the 80's, but nowaday, it can really be a joke. I really hope that somedays Xorg will break things and start a new fresh X design (at least from Xlib point of view). It's not that I think Xorg people are doing bad stuff, but there are mostly bailling out from a long code and design history IMHO. So, last weeks I was trying to fix the sloppy focus in awesome. I've found a real interesting Web page from Alex Hioreanu about various issues that we encountered too. I've been trying ahwm hack, but it's not really reliable. And then I've been trying a lot of things, and this morning I figured out something which works pretty well. It just fails in some corner case with GTK+ apps that are not reporting XMotionEvent when the pointer move, and I don't know why and how get them. Let's see.

I found a few people asking how to automate scripts using ssh with the -f option but not many solutions. Th -f option makes the ssh process fork into the background once started, but since it doesn't give you it's PID it becomes hard to kill it once the script ends. The solution is to setup a control channel with -M. This allows you to communicate to the ssh process and close it down when your process finishes. For example, here is how I open a VNC connection to my desktop at work, which involves going through a corporate ssh firewall box.

As you know I implemented the support of symbols files in dpkg-shlibdeps/dpkg-gensymbols, and I would be very pleased if libc6 could start using it as most packages would then benefit from weaker dependencies on libc6 and be more easily installable on previous versions of the distribution (sid package directly installable on etch in some cases). Some time ago I tried to get the ball rolling by providing a first patch in #462444. Unfortunately the glibc team has not been able to finish the work up to now and the base freeze is approaching… so it would be great if some people could jump in, make the required changes, test and propose a new (fully working) patch. I just sent a message to give some indications on how to get forward, hopefully that will help anyone who wants to tackle this. Thank you for your help! Partagez cet article / Share This

I was snowboarding with some friends last week, and in the evenings I had a little rush of uncontrolled creativity: I wrote a new entry in my (German) tech parody news about guitar hero in music education and two new parody songs: Pain of Boarding instead of Sound of silence and a snowboard-variant of I will survive . I ve also hacked up my XML/XSLT/make-website-system to include the songs, so you can find all my songs there now as well.

Ah, back to Epiphany this week and I came to a realisation. All of the time that I was using Firefox I had completely stopped using bookmarks. Strange I know, but I had stopped adding or even using any of my existing bookmarks. I would instead just leave pages open and let Firefox open then again each time it started. It was during the switch when I realised that in order to continue with the pages I had open in Firefox I would have to bookmark them before I switched. Now that I am back using Epiphany I'd like to let people know about my favourite feature, tag based bookmarks. Instead of placing each bookmark in a folder, you simply tag each one like del.icio.us and a bookmark hierarchy is built automatically. So if you haven't tried out Epiphany recently, or at all. Please give it a try. Now if I could just get Epilicious to sync with del.icio.us properly I'd be very happy.

I like autotools, I use them widely and I'm happy that I understand autotools sufficiently that I can be confident in using them and helping others with theirs. All my own upstream C projects rely on autotools and I have a personal rule that I always preserve make distcheck compatibility during CVS/SVN changes and without fail prior to ALL releases.
Lenny will be the second Debian release with which I've been involved and as I prepare to round on the RC bugs once again, I'm noticing a pattern in autotools bugs from other upstream teams.

1. If more upstream projects enforced rigorous testing with make distcheck, a lot of bone-headed numbskull errors would be prevented in the upstream codebase. Fixing make distcheck isn't that hard because it is a test of the build system files, not necessarily the source code. Once an upstream build is fixed, subsequent make distcheck failures are both rare and serious. Other failures in the test suite should be easier to spot too. The important point is that make check only tests the current build on the upstream system. make distcheck goes a long way to ensuring that the package will build in the same way on lots of systems, including cross builds.


2. autotools expects such fixes to be made upstream and fixing things after the release can be a serious PITA, so fix it before release.


3. The single greatest weakness of make distcheck and autotools in general is bit rot. It is so important for upstream to refresh the autogenerated files on an intermittent basis. With a big development team, this can be easy - especially if new people are regularly joining and building the source for the first time from CVS/SVN. Once that rotation stops, the difficulties of trying to fix the upstream code get more and more noticeable. Maybe one day autotools will fix this and become more resistant to bit rot but, for now, it is a significant problem.


4. As a consequence of file rotation, it is seldom a good idea to keep any autotools generated files in any form of RCS, even distributed ones. This is where I fall foul of many who want to package directly from SVN CVS foo. The mantra of lots of RCS helpers is "everything must be in the RCS" which is just plain wrong IMNSHO. The only things that must be in any RCS are the bits that upstream needs to write. So Makefile.am is, Makefile.in is not. configure.ac is, configure is not. Same for libtool, ltmain.sh, config.* and a host of other autotools generated files. If autogen.sh can generate or symlink them, don't have them in RCS. If, as upstream, you have not had to edit the file or copy it into place using a patch supplied by someone else, it should not be in the RCS. This discipline ensures that when someone starts from a fresh checkout, the build system is refreshed (and is why many autotools upstreams add a "make rcsclean" rule that goes one stage beyond make distclean by going back to raw RCS). If you maintain a helper that is meant to build packages like this, ensure that the helper has support for getting from raw RCS to make distcheck and ensure that the helper uses the tarball created by make dist not one of it's own.

Yes, bit rot is the curse of all software but when combined with the lack of usage of make distcheck prior to upstream falling quiet, I sometimes wonder about the merits of trying to fix bugs in the build system of packages with a most recent upstream release that precedes Etch. I get a real chill thinking about upstream packages with a most recent release that precedes Sarge.
So, if you're working on an upstream project using autotools, just do everyone a favour:

 svn cvs  ci -m "make sure things work"

make uninstall

make distclean

./autogen.sh

./configure --prefix=... 

make

make check

make install

make distcheck

Repeat the last stage until it completes without errors, commit the changes and retest from the beginning.
I'm not proposing something I do not do myself - as above, I do these tests on my own (released) upstreams on a regular basis. I just wish more upstreams would do so too. If every upstream did this prior to that final release, it would be so much easier to do all kinds of cool things with your code, long after you lose interest in it yourself.

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

Like Meike already told, it was a nice event, like always. IMHO it’s based on the good balance of community and a small amount of business booth and of course the visitors.
This year we was apart the Sidux Project. Didn’t heared about (much) before, but their slogan is Hot & Spicy! Maybe ‘hot’, cause it’s based on Debian unstable. Hopefully you won’t get tears if it’s too spicy. Anyways … if you want, you could take a look. My opinion is, this would be a good case for a Custom Debian Distribution, if there would be a requirement for it. But he.. everybody is free to do, what ever he want, if nobody else is restricted.
The talks I attended was in most cases excellent, some of them was funny … only one of them did really suck. Desktop Virtualision … after the talk, my question if there could anything else virtualized then the OS from Redmond, was answered with ‘Unfortunetly only XP’ … how lovely!

So, as I previously mentioned I want to be able to tag messages in Mutt. There exist folder-based solutions already, using the X-Label header. There doesn't appear to be any existing solution allowing you to view all messages with a given tag across mailboxes. So I wrote a simple shell script to create virtual mailboxes, such as ~/Maildir/tags-debian for all messages with a debian tag, using hardlinks. My conclusion is that this solution will not work properly in practise, primarily because of deficiencies in mutt. The simple case works just fine. I add a tag to a message, and later when the indexing job runs the virtual folder is created. I can open it and work on it just fine. So where's the problem? Well in my case I tend to tag messages with a label such as "todo". Once I've done whatever I was supposed to I can remove the tag. Using this hardlinking scheme I cannot remove the tag(s) in the virtual folder - I have to remove it in the original message which is a real pain. Why? Well quite simply mutt will not let me work on my virtual message without destroying the hardlink.. If I use the edit function, for example, I am presented with a copy of the mail for editing - and the hardlink is replaced when that copy is saved. Even the edit-label patch which allows you to edit the X-Label header from within mutt ends up replacing the hardlink with a new file! So whats the solution? Well I guess I want to be able to run an external command against a message in mutt - passing the filename of the Maildir message as an argument. That way I can edit the live file. Right now I don't believe that is possible, but I'd love to be told different. If anybody has any solutions of editing, or even just deleting, a header from a message within mutt - in such a way that the hardlink isn't destroyed please do let me know. Simple reproducer:

mkdir -p ~/Maildir/.foo/cur
mkdir    ~/Maildir/.foo/new
mkdir    ~/Maildir/.foo/tmp
cp 'validmessage' ~/Maildir/
ln validmessage ~/Maildir/.foo/cur

Now edit the message - start mutt open the message in the index and press 'e' - the hardlink is now gone. Replaced by a new file with the contents, so the original mail message is unchanged. Update: I've got an "edit-inplace" primitive working, via the very hacky header-fu patch. It is not complete, but it demonstrates that it can be done. My world is now complete.

Soon after Bernd Zeimetz joined our company, he infected me with the geocaching virus. In the meantime, I bought a GPS receiver, and am now endeavoring around the town and the nearby woods, searching for caches. There's not that much free GPS and/or geocaching software around. gpsd works quite well, but I don't take my computer to the woods ;) Viking is very nice for visualizing waypoints and sorting them in categories, but is still somewhere between alpha and beta state. gpsbabel reads and writes a zillion different file format and talks to a vast array of receivers, but often needs several attempts to upload data to mine. Things are moving fast though and the GPS community looks active. Last week I started looking into OpenStreetMap and already added a few roads in my neighborhood. Compared to commercial maps, there's still much to do, especially for smaller tracks and features like foot bridges or woods outside bigger cities. I'll keep collecting GPS data :) For the free software side, neither OSM's online editor worked here (flash), nor the recommended tool for local use (java), so I tried merkaartor (qt4) which works nicely. It also has some bugs, but feels very usable (though sometimes slow). Starting from upstream's debian/ dir, building packages was straightforward, and after some more editing, packages are now in unstable. (The svn repository is in collab-maint, contributors welcome.)

After xf86-video-ati 6.8.0 got released, George Sapountzis split the old r128 and mach64 subdrivers out of the common ati wrapper. So, starting from 6.8.1, the xserver-xorg-video-ati package only contains the radeon subdriver. The other subdrivers have been moved to their own xserver-xorg-video-r128 and -mach64 packages. All of them just landed in experimental. Your existing xorg.conf should work as before. I don't have any Mach or Rage board, so please test these new packages and report back if they don't work. Note that if your xorg.conf contains Driver "ati", you'll need to keep xserver-xorg-video-ati installed. If you only have the mach64 or r128 package installed, you need switch to Driver "mach64" or "r128" in xorg.conf. On the radeon side, the upstream developers are still very active. The last feature that has been added is Textured Xvideo. The Xvideo extension is usually implemented using the hardware overlay, which basically inserts the video on screen at the very end of the rendering. While working very well, this feature conflicts with compositing managers such as Compiz which cannot transform the Xvideo image. The radeon driver now exposes a Texture Xvideo adaptor which is composite-aware, which means you can have wobbly Xvideo players in Compiz. The Overlay adaptor is still the default since the Textured video isn't considered stable enough yet. To enable it, you can use something like:

    mplayer -vo xv:port=74 foo.avi

Where do I get this port 74 from? Just look at the output of xvattr or xvinfo:

    $ xvattr
    Found Xv 2.2
    Adaptor: 0
    Name: ATI Radeon Video Overlay
     Port: 73
     [...]
    Adaptor: 1
    Name: Radeon Textured Video
     Port: 74
     Port: 75
     [...]
    $ xvinfo
    X-Video Extension version 2.2
    screen #0
     Adaptor #0: "ATI Radeon Video Overlay"
      number of ports: 1
      port base: 73
      [...]
     Adaptor #1: "Radeon Textured Video"
      number of ports: 16
      port base: 74
      [...]