Earlier this week my Amstrad E3 2.6 patch was accepted into the linux-omap-2.6 tree. This is pretty cool; I'm a big believer in pushing changes to upstream where possible and thus it's great when they take them. I'd thought that once this base patch was in it would be a simple matter of cleaning up my patches for the LCD, USB, keymap and NAND support, ready for submission. I have all of these working fine on my 2.6.15 tree, so it should have been easy, right? Of course not. I've spent most of the week (well, the bits I wasn't working or doing late night router upgrades) trying to solve the ohci: Unlink after no-IRQ? Controller is probably using the wrong IRQ. problem. No, I know it's not the wrong IRQ. It works fine with 2.4 and 2.6.15. Gah. What's worse is Google only showed up people having the same issue; a number apparently x86 with ACPI being suggested as the culprit, but there were a few that were also with the OMAP5910 (the E3's processor). The most recent from Ladis but he's already turned up on #emailer to ask me how I'd got it working in 2.6.15. Anyway, I think I've finally solved it (the 5910 needs the local bus clock enabled for USB according to the datasheet and this wasn't being done), though I'm waiting to see if my solution works for anyone else before deciding it's a success. Assuming it does I can actually start to look at getting the other bits ready too; I think the LCD stuff has changed a bit and I dread to think what the MTD guys are going to say about my attempts at a driver.

The coldfire development kit of which I made mention in a somewhat recent -devel-announce post has arrived about a week ago. Mine was the last one to arrive; the other four have already arrived. It took a while, because mine apparently got lost in shipping, so they had to ship me a second one. That, and the fact that I said I'd ask around in my neighbourhood whether it'd been delivered at the wrong address (but then eventually forgot to tell the Freescale folks that I had done so and that, no, it wasn't) meant it took a bit over two months to arrive here. But it finally has. Whee! The box contains a number of things I do not and will not likely ever need (the CodeWarrior Development Studio, for example, or power cables for other places of the world, like the US, the UK, and Japan), but, well—that's not important. It also contains some things that are interesting, such as a serial cable—even if I already have a few of those. The box contents also smells funny. Oh well. In the mean time, however, I've come across a bit of a problem: I can't seem to boot the thing. Well—I can, except it seems to be mangling the serial output it's sending for some reason. I can see that some output is being sent to the serial console, but it's not readable. And I can also see that it doesn't find it's root file system—I'm doing NFS root currently, and there's no network activity. Not sure what the problem is, though. Update: someone suggested that it is the baud rate. Yes, obviously it's something like that; however, I did try every baud rate between 9600 and 115200, but none of them worked. Besides, I have my command line say "console=ttyS0,19200n8", and it's still not working. I suspect a driver problem at this point...

The coldfire development kit of which I made mention in a somewhat recent -devel-announce post has arrived about a week ago. Mine was the last one to arrive; the other four have already arrived. It took a while, because mine apparently got lost in shipping, so they had to ship me a second one. That, and the fact that I said I'd ask around in my neighbourhood whether it'd been delivered at the wrong address (but then eventually forgot to tell the Freescale folks that I had done so and that, no, it wasn't) meant it took a bit over two months to arrive here. But it finally has. Whee! The box contains a number of things I do not and will not likely ever need (the CodeWarrior Development Studio, for example, or power cables for other places of the world, like the US, the UK, and Japan), but, well—that's not important. It also contains some things that are interesting, such as a serial cable—even if I already have a few of those. The box contents also smells funny. Oh well. In the mean, however, I've come across a bit of a problem: I can't seem to boot the thing. Well—I can, except it seems to be mangling the serial output it's sending for some reason. I can see that some output is being sent to the serial console, but it's not readable. And I can also see that it doesn't find it's root file system—I'm doing NFS root currently, and there's no network activity. Not sure what the problem is, though. Update: someone suggested that it is the baud rate. Yes, obviously it's something like that; however, I did try every baud rate between 9600 and 115200, but none of them worked. Besides, I have my command line say "console=ttyS0,19200n8", and it's still not working. I suspect a driver problem at this point...

I’m taking Rojo for a spin, mostly because of recent upgrades that add some interesting features, including a “sort by relevance” function that lives alongside the usual “sort by date”—a “personalized digg”, as some have called it. One thing I like about Rojo is that it’s a River of News style aggregator, which means all feeds get combined into a single stream that’s very easy to scan for interesting items, rather than serving as just another way of filling my inbox with stuff I won’t have time to read anyway (the “aggregator as an extention to the email client” model). With River of News style aggregators, it’s no big deal if you miss something, kinda like it’s no big deal if you don’t read every last article in the newspaper every morning. Trouble is, how do you make sure you read the most important stuff first, so in the event you don’t get through everything, the likelihood you miss something is small? “Sort by relevance” would appear to solve this problem nicely. Rojo appears to calculate “relevance” by analyzing a few things: What I read (i.e., what I click on), what I tag (either by giving it “mojo” or by tagging it in the Web 2.0 sense of the word), and what my contacts read and tag. That seems like a reasonable enough algorithm. Problem is: 1. most of the things I read Rojo doesn’t know anything about (they’re in my browser clickstream); 2. I already have about a year’s worth of tags accumulated at del.icio.us, and I have no intention of moving those tags anywhere else (ironically enough, because del.icio.us gives me the ability to do just that); and 3. I already have more social networks and contact silos than I know what to do with, and I certainly don’t want another one. So, Rojo’s new features are less interesting than they appear at first glance. Guess I’m going to have to continue doing without, either until I decide to dump all my stuff in one place (ahem) or until small pieces loosely joined evolves a bit further. Update: On second look, it looks like relevance is actually calculated by the total number of reads and tags rather than by the number of reads or tags by me or my contacts. Not sure how that can be called personalized, but I guess those are the words of others, not Rojo’s.

After playing around half a day with my new iRiver T10, I'm quite satisfied now. Using gphoto2 2.1.99, it was possible to upload a modified UMS firmware file (MTP devices like my T10 don't accept the original UMS firmware files, details here), the device detected the new firmware and flashed itself. From now on, it's possible to flash the device with the original UMS firmware, what I did, to get rid of a bug with the display introduced by the modified firmware. The result looks good: usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
  Vendor: iRiver        Model: T10           Rev: 1.00
  Type:   Direct-Access                      ANSI SCSI revision: 02 I really don't know why iRiver doesn't ship the UMS firmware by default, and I still think choosing this device was a wrong decision. It works for me (and others), but usb-mass-storage support is a must-have for an mp3-player, which should work out of the box.

Jim Gettys wrote about a problem regarding localisation that the OLPC project will face in the future. The One Laptop Per Child project aims to provide the famous $100 laptop to children in the developing world. They are Free Software based, and as most GNU/Linux distributions, the bundled software will be available in a number of languages. For now, it'll only be ten or so, but as OLPC grows, the number will skyrocket... just think about the number of languages spoken only in Africa. The $100 laptops don't have a hard drive. Instead, they have a 1 gigabyte of compact flash memory, which is enough to run the software, but it can't store that much extra data. The most common way of internationalising and localising Free Software is to use GNU gettext, which provides an easy to handle text file format for translations, with a series of sentences and labels that the translators need to fill in in their language. The applications ship these translations in .mo files, which are the same .PO files, in compiled binary format the gettext enabled programs can read. Each application installs one .mo file per language it is translated into. When the apps are big enough, these files can amount to several megabytes per application, which is a problem for embedded systems or projects like OLPC. Ubuntu has been trying a different approach to the distribution of translations. Instead of packaging all the translation files with the applications .deb packages, they are stripped off from the packages, and provided by language packs. Language packs offer the translations for all the applications and libraries of the main component of Ubuntu. This includes GNOME, KDE and many other popular applications. When you install Ubuntu, you select the main language of the interface, and the installer program will download the appropriate language pack, plus a selection of useful localisation-related packages like dictionaries, translated manuals, etc. These language packs are generated periodically by Rosetta, a web-based translation portal which is sponsored by Canonical, Ubuntu's and Launchpad.net's parent company. Rosetta offers a very easy to use translation infrastructure, and Ubuntu users can start translating the applications they are running with just two clicks on the application's interface. With Rosetta lowering the barrier for people wanting to translate Free Software, Ubuntu can have, and is now having, lots of people improving the translations of not only the next version of the software, which is what translation groups have traditionally worked on, but also the version you are running at that same moment. There is no need to wait for the next version of Ubuntu to see your translations complete. Help your team translate whatever is missing, and wait for the next language pack update. Voil ! If the OLPC project adopted the language pack scheme and Rosetta, they could install a raw OLPC laptop without translations, and only install the language packs that are needed in the target country or area. The langpacks are currently split into GNOME, KDE and the rest , but any derivative could fine-grain the components they wish to include. Furthermore, the system helps improving the localisation of the system after the laptops have been deployed. Just stick a USB drive to the laptop, and use your usual package manager to install the updated language packs contained in it. Or just use the Internet if it's available. In environments where network access is completely impossible, making the availability of updated packs from a remote server a no-op, as well as online translation in the Rosetta server, other solutions could come in place. Generating langpacks from a set of local PO files should be pretty easy.

Yesterday, I added Wolfgang Kechel as a committer to the Hecl project, because of the good work he's been doing on it. He's demonstrated consistency and quality over a number of months, and has also shows he understands where I want to go with the language, so it was a natural thing to do. Adding a new committer is not always so clear cut, though, and it's sometimes a difficult decision, especially with smaller projects. I find that it's much more fun to work on projects with other people, so I want to encourage them to get involved, and granting access is something that ought to give people a bigger stake in the project, and reward/encourage them in their efforts. In practice, it doesn't always work out that way, though. Often, after a bit of initial work, they dissappear, which means they weren't really that interested in the first place, and you shouldn't have bothered granting them access to the code - they could get by just fine by submitting patches. The question of openness vs control also plays a strong part in the difficulty of the decision. I think the Apache Software Foundation way of doing things (decisions by consensus of those who work on the code) is pretty successful for well established projects, but I'm also convinced that the "benevolent dictator" model is best in some cases. Design by committee doesn't work very well for projects like a programming language where you really want to have one coherent vision, rather than some sort of frankenstein mishmash of pieces. (As an aside, Larry Wall, has done a fine job of proving that you can have - even revel in - a mishmash, even with a 'dictator'!). The point being that it's a little scary to hand someone the keys to your project, because you take a risk on them working counter to your goals, especially in new projects without a self-propagating culture in place. An established language like Python has a fairly large number of people who can instinctively tell you if a new feature is "pythonic" or not. But for a small, new project like Hecl, the risk is that there is more room for unproductive arguments, or having to back out "bad" changes should someone really take off in a direction you don't like. Of course, with Hecl, I think it is at a great point in its life. There *is* a lot of room to hack, because it isn't used by many people, so we don't have to worry about angry users if we break it while trying to improve it! All things considered, it's a positive step to get more people involved, but it's important to start building a culture in order to keep your code going in a healthy direction. Depending on the project, that culture might include a healthy dose of what is and what isn't within the project's scope, or it might simply regard the quality of code considered acceptable. For instance, Tcl's standard library is pretty open to whatever people want to implement, however you must accompany your code by either tests or documentation, and preferably both. I think the most interesting phase is when you are "bootstrapping" - going from just one person to a group. Judging by the number of small projects that have fallen by the wayside without ever getting more than one person to work on them, it's also the most difficult period in a project's life. What do other people think? What tactics do you use to get people involved, yet still make sure they are the right people?

I downloaded Serendipity 1.0beta2 over the weekend and started trying it out. My initial thought after setting it up was: *wow*. It really is incredibly easy to set up. No hand-editing of config files. No weird menus or scattering things all about. The whole system speaks of elegance and good coding practices. Except the fact that it ships some files world-writable in the tarball. As I looked at it some more, I noticed a few problems, though. I submitted bugs or feature requests to the project as appropriate, and am including links to them here:

• No option to display the number of reads for each story. SF 1459385
• No tracking of HTTP referers (or, at least, no integrated interface for viewing them). SF 1459389
• Spartacus, the tool to automatically download and install new plugins over the Web, was broken. The netmirror.org site was unresponsive and the s9y.org site gave a 404 to it. SF 1459370
• It doesn't seem to offer an RSS feed for the comments on individual posts. SF 1459391
• There's no RSS feed for individual categories. SF 1167982
• Captcha support is built-in, but seems broken out of the box. (It rejected every attempt to post). SF 1459374

Despite these problems, this looks like a very strong contender. And I was using a beta. Next up for testing: Wordpress.

DIY Canadian farm-style, or “what I did this weekend.” First, you pack about ten people into the back of a pickup truck… …and walk through the fields… …to empty the buckets on the trees, spiles having been drilled previously. Back home, you cook in the ancient, homemade sap cooker (which was once an oil drum, long ago). Sometimes, you need to feed the fire. Make sure to keep adding sap when the level gets low, or when the pans threaten to boil over (overzealous fire feeders!). If you’re bored, you could always go exploring and fall through the ice on the half-frozen flooded field. Late afternoon is the best time to take advantage of the fact that boiling liquid kills bacteria, by sampling straight from the pans–with the same spoon. By now the sap’s thick enough to actually taste good. The day’s cooking is done when the sap’s about 60% sugar. (Damn, I don’t have a picture of the sugar-measuring gizmo.) The sap pans are unloaded… …into pots, to be brought inside and finished on the stove to 66% sugar. A more controlled environment, to prevent accidental burning/overcooking/sludgification. Which would be a Bad Thing. A fun weekend. It’s something I do just about every year (the farm belongs to my grandparents), but this year I managed to drag a couple friends along to slave have fun.

Have you ever been bitten by a problem that resets all wifi settings like mode, essid and whatnot just some seconds after you set them? A certain mister Dreker suggest to simply shut down wpa_supplicant on that machine if it is running, as it always resets such settings to be able to receive all packets from all access points. So, after doing so I now know why my wifi access point, which is just a normal Debian box, wasn't working for the last couple of months. For some reason wpa_supplicant was installed and running.. I just can't remember to have installed it as it hardly makes sense to me. Anyway, after I could set the wifi settings again I thought it wouldn't be much of a problem to get hostapd with WPA-EAP working again. Wrong! wpa_supplicant on the client side somehow thought it was authenticated, but it actually wasn't. So I checked the debug output of hostapd which said something like that:

  ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long

and after that line it said the it deauthenticated the client because of a local request, so I thought that's the problem. It pretty much looks like a binary incompatibility to me. I updated the madwifi drivers before in an attempt to to fix the essid reset problem, so hostapd, which needs to be compiled against the madwifi headers didn't work properly anymore. So I tried to recompile it and things got even worse:

  ioctl[unknown???]: Operation not supported

I had no idea what to do about that, so I joined #madwifi on freenode. I have been told that I'll need at least hostapd 0.4.whatnot to make it run with madwifi-ng. Unstable has 0.5.0, so I downloaded that package, which contains madwifi-ng includes do build against, and compiled it on my sarge box. Almost exactly in the moment I was done I found out that I would need hostapd 0.5.2 to make it work with madwifi-ng and WPA2. Grr... So I compiled it again, installed it and everything should have run fine. For some reason it didn't. After a while starting and stopping it to take a look at the debug output it somehow started to work and it keeps working up to now. I have actually no idea what could have caused that problem. Stijn Tintel on #madwifi could think of re-keying at the wrong moment or something like that, but isn't quite sure about that. Anyway, wifi is up and working again and that makes me happy. :-)

Craige, it might be the first time that the exhibition has run under the Linux World Expo banner, but I recall an earlier one after the last linux.conf.au in Sydney. Indeed, a bit of Yahoo!ing reveals this from the Internet Archive, linuxexpo.com.au and the front page. It looks like I might have been there too at the Debian stand. Ah, memories.

I'm looking for a calendaring application with the following features:

1. Must have a (limited) command line interface. I want to be able to view my appointments of the day in plain text format, so that I can put that in my .profile; it'd be nice if it allows me to view my appointments on any random date, but that isn't required. Moreover, when someone sends me a meeting invitation, I want to be able to pipe the ical file into something which puts it in my calendar, with optionally also sending an email to the person who sent me the invitation that I'm accepting it (optionally, as in, it must have the feature, and it should allow me to decide whether to send the mail on a case-by-case basis, not as in it would be nice if the feature existed.)
   More command line features are nice, but not necessary.
2. Must have the ability to export ical files to a text file on my local hard disk; must not require me to set up a server with some weird login scheme and ditto protocol so that I can please put my webcalendar somewhere—and no, I won't sign up for one of those "free" webcalendar services. I'll put it online myself, thank you very much.
   This requirement rules out evolution, unless I missed some plugin somewhere (I don't think so).
3. Must have basic calendaring functionality. I.e., I should somehow be able to get an overview of my appointments of any given day, to get a weekly, monthly or yearly overview, to print out things, etc.
4. Must not require ages to start up. This, definately, rules out evolution. When I have a phone call, I want to be able to see within a few seconds whether I'm available at any given time.
5. The ability to synchronize my calendar with my cellphone somehow would be nice, but isn't absolutely required. I'm willing to jump through a number of hoops here. Note that gnokii supports my cellphone.

Suggestions are welcome.

The Latin American Infest finally ended yesterday. In Caracas, it was a week of hard work with people of the Science and Technology Department and the IT Office (government offices) but the event in Caracas ended succesfully. It was a world-class event featuring renowned keynote speakers who spoke about Web Development using Frameworks (featuring TurboGears, Rails and Catalyst) and software development paradigms migration from privative platforms to GNU/Linux (Gambas and Mono). Other talks included basic security in Debian GNU/Linux and a speak about electronic signature security by an officer of the Venezuelan Government CA. We had a speak about Clusters, hosted by a female member of the Venezuelan Free Software Community and Debian User, and a speak about Free Software in the Venezuelan Education, by a 16-year-old Venezuelan GNU/Linux user and a willing Debian Maintainer. Of course, the Installation Festival took place in the Knowledge Square, in the Auditorium Building Lobby, with the extraordinary support of the Venezuelan Free Software Users Community. Debian GNU/Linux Sarge netinst and CD1 was distributed (several hundreds) as well as Knoppix and Ubuntu Hoary. Ernesto Hern ndez-Novich (maintainer) and me wore Debian T-Shirts on Saturday, and he made a great speech about the Project, named “Debian is inexorable“. We had demonstrations of Linux on a Mac Mini, using XGl and presenting several applications, as well as Debian running Enlightenment on an old Presario 1246 laptop. I would like to thank all the speakers and the attendees for making of FLISOL Caracas a great event. More information about FLISOL Caracas is in my blog and the homepage (spanish). Pics are here.

Please do not hide the arguments given to the compiler from me.

It's hard to realize something is going wrong if you do not see what is happening. If the argument list is too long, do something against that instead of hiding it.

Make sure you follow policy when packaging software

Debian packages should be compiled with -Wall -g, but more and more do not. Please check you do, but check at the correct place. Do not look into the debian/rules file, but in the build log. If the Makefile sets a default with a single equal sign ("="), running 'CFLAGS="-Wall -g -O2" make' will not suffice. Try 'make CFLAGS="-Wall -g -O2"' instead. (Actually, there is no good reason to put them before the command. Always try to put things as arguments first, both with make or with ./configure)

It really makes everyone's live easier if those options are set.

Keep the argument list tidy.

Many argument lists are longer than necessary. If there is some -I/ in the argument list on a Debian system, there is something fishy. (It's not the universial collection of different stuff all going whereever it wants, after all). Common cases are:

- buggy scripts to add -I/usr/include

Better fix those scripts. Also make sure they do not cause other problems, like linking your program against libraries your program does not use directly. (Possibly causing funny segfaults when those libs link against other versions of those libraries)

- -I/usr/X11R6/include

For upstream packages this might perhaps be useful to support older operating systems and people unable to give it to CFLAGS themselves. But for FHS systems, this is not needed at all, as it mandates this handy /usr/include/X11 -> /usr/X11R6/include/X11 symlink. And newer X directly puts the headers in the correct place.

- packages working around upstreams breaking compatibility

Life would be too easy if upstream would not break APIs. But if they make a new incompatible version, and even change the library name for that, would it have been that difficult to also change what programs written/ported for that new incompatible API have to place in their #include line?

- plainly broken upstreams

putting stuff in $ PREFIX /include/subdir/ and #include'ing other files from that subdirectory without the subdir deserves application of some large LART.

- oversight

often it is just not necessary, and everything gets much more readable and easier if left away.

Other things makeing things unreadable are large armounts of -Ds generated by ./configure. AM_CONFIG_HEADER can help here a lot with non-path stuff. Stuff containing paths is suprisingly often not used at all.

After a phone call from Urs Kellermann, I noticed that this year’s Special Bikes Show (German: Spezialradmesse or short “Spezi”) is in parallel to the Vintage Computer Festival Europe 7.0: Spezi is from 29th to 30th of April while VCFe is from 29th of April to 1st of May. So I can’t visit Spezi this year since I’m usually helping the VCFe organisators here and there. Fsck! But dino has even less luck: He told me, he knows five events he would like to visit that weekend. :-) He has chosen to visit the Anime Marathon and VCFe with switching events on Sunday.

Over the last 2.5 weeks I have built the complete Debian archive on a quad-core MIPS machine donated by Broadcom using the recently released version 4.1 of GCC. In parallel, I have done the same on an EM64T box donated to Debian by Intel. The purpose of this exercise was three-fold:

• Find out about compiler problems in GCC 4.1 itself as well as in packages that may fail with the new version before GCC 4.1 is uploaded to unstable. GCC, in particular G++, is becoming stricter regarding adherence to standards and packages may fail to build with 4.1 due to invalid code that was accepted previously.
• Find out about MIPS specific problems in GCC 4.1 and to answer Matthias Klose's question as to which platforms can move to GCC 4.1 as the default compiler once it is uploaded to unstable.
• Find MIPS specific assembler warnings and create a list of all users of xgot (a MIPS specific toolchain problem).

Executive summary GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. There are, however, a large number of packages using code (especially C++) which GCC 4.1 treats as errors. Fortunately, most of them are trivial to fix. By compiling about 6200 packages, over 500 new bugs have been discovered and submitted, 280 of which are specific to the increased strictness of GCC 4.1. Patches for 2/3 of those GCC 4.1 specific bugs have been submitted. Based on my findings, Ben Hutchings has prepared a summary of the most common C++ syntax errors (that weren't treated as errors before G++ 4.1). Most common programming errors Basically, it all boils down to broken C++ code. There were a few bugs in C code, but the majority was in C++. The most common errors I found are:

• extra qualification
• reliance on friend injection
• wrong escape characters (e.g. "\.", most commonly seen in regular expressions)
• iterator problems (such as assigning 0 or NULL to an iterator)
• template specialisation in wrong namespace
• template reliance on a function declared later
• use of template's base class members, unqualified, where the base class is dependent
• use of assert without #include <cassert>
• dereferencing type-punned pointer will break strict-aliasing rules (a warning) combined with -Werror

I've posted a detailed report to debian-devel. Acknowledgements (abridged)

• Broadcom for supporting our MIPS port through the donation of hardware to the project and developers. Without Broadcom, our little and big endian MIPS ports would have a hard time meeting the release criteria regarding autobuilders.
• Google for supporting my PhD, thereby allowing me to spend two weeks compiling the archive with GCC 4.1 and sorting out failures.
• Intel for supporting some PhD work which led to this experiment.
• Ben Hutchings for explaining many of the C++ bugs I found to me. I've learned more about C++ in these two weeks than I ever wanted to know. ;-)

Yay to Bicycling! I don't think I've been on a bike in what.. 5 years? I didn't ride most of my last year in Vancouver, and it's been almost 5 since we left (eep!) Benjamin Mesing had been here in Montr al from Germany for a year and was selling his bike on his way back home a month or so ago. Today, I went out and bought a helmet, then hopped on the bike to take some library books back.<br /><br />The bike is in fairly rough shape. I'm a bit spoiled in that I'm used to buying new hybrid bikes, but as I work from home there's no point. In Vancouver I would travel up to 40km/day on my bike. I've taken it into the shop, and should get it back next friday. Handlebar alignment, rear wheel trueing, replace front tire, align all breaks, grease and tune gear cables, and generally hose the thing down with oil.<br /><br />On the walk home, I discovered that there's a fairly large Rachelle-B ry at Rachel and Berri. (I don't know why I never looked there...) All told, a very wonderful day.

According to this interesting and funny article in Forbes, Windows Vista is in fact so boring that journalists that were excited to cover it didn't even bother to keep their voices down while they were mocking it in front of Steve Ballmer. Apparently laughter broke out about some of its "features".