I've done a needed upgrade to my blog software. In this process, I've also been changing my blogs GUIDs. Unfortunately, this probably means that some planets or feed readers will recognize all of my postings as 'new'. Sorry about that. I'm not sure if I can somehow prevent it from happening.Every now and then I receive a mail from someone complaining that the links to my blog entries are broken. Well, they aren't. The link tag has an appropriate value. However some applications (usually involving planet) prepend the feeds base URI to the GUID field or use it in other RDF places. And then some readers seem to not know about the link tag and use that instead. So I'm now using the permalink as GUID, so it should be a bit easier for some people, since they now can just click on my entries.

The desktop enviroment is not a religious thing for me. IMHO, they all (3 of them) have missing parts which are present in the others. I never really used Xfce.

OTOH, I have been switching back and forth between GNOME and KDE during my time as a GNU/Linux user. Since I always found that one of the environments was missing things which were present in the other, I think I have switched at least 3 times both ways by now.

Now, with the release of GNOME 2.18, I will have one less reason to think to move away from GNOME, which is the current desktop environment. One of the apps I was missing in GNOME was a filelight-like application that would show usage in a very intuitive graphical way. Now it seems that baobab (commonly known as Disk Usage Utility) has a ring chart similar to filelight's. Yay!

Now, if somebody would take the task of rewriting granslator, I would be more than glad to drop kbabel...

Note: I was disapointed that GNOME Space Chart never made it to public... that disappointment lasted until now.

I've been a bit offline during the last two weeks due to being in the middle of a ISP switch at home, which took me offline for a longer time than expected. Additionally, when I finally got the connection up, it was Easter time, and I ended up going to Vall, after cancelling a cycling trip with some friends down the Via Verda Ojos Negros (but this time, not during the night and spending a few days to complete the route) in the last minute, due to the horrid weather forecast. It apparently was a good idea: the river that goes along Vall overflowed, and for some reason the mobile phone service went down for more than 3 days. On Monday night I came back to Val ncia, and I figured that the DPL election results would be out by the time. When I opened Debian's webpage, I found out some other big news: Debian 4.0 was released the day before! Soon after, I looked for the vote results, to find Sam, my candidate of choice, was the winner, very closely followed by uncle Steve. Congrats Sam, no nos falles! And congratulations to the rest of the Debian project for yet another successful, well done release. Reading comments on news sites gives a fuzzy warm feeling. Even though we were slightly delayed, people show how etch is going to make their lives easier, or how trustable Debian is at work and at home. That's the kind of stuff that keeps me and many Debian people going. I'm pondering improvising some Etch Release Party (as the release managers deprived me of a IRC party by secretly releasing while I wasn't looking) this weekend in Barcelona, where I will be visiting, after giving up on being able to be in A Coru a for DudesConf. Anyone up for it?

I’ve just released Webconverger (Web kiosk) USB&ISO versions built with stable Debian etch. Webconverger has received some good feedback and press. I would like to thank Daniel Bauman for his rather excellent Debian Live work on which Webconverger is based. I was hoping that Webconverger could support every locale, now it looks like I need to produce a separate ISO/IMG (or at least apt-get hooks) for every locale. One reason is that Iceweasel/Firefox extensions don’t scale very well. Try install every locale and dictionary extension. I dare you. :) Sidenote: I wonder why no one has packaged the dictionaries for Iceweasel. In other news, I’ve been playing around with scim (keyboard switcher) and Korean locales. It seems to work though the title bar didn’t render hangul characters right in dwm. After some investigation I discovered there isn’t such a thing as a single “generic” Unicode font. This came as a shock to me. :) Typical ttf only have 65536 glyphs, so no one font will do. Jeff Zhang also informed me about free Unicode fonts. Though I think especially in CJK environments proprietary fonts are unfortunately more common. Or I don’t know why microsoft-gulim isn’t in msttcorefonts. Anyway the Korean version of Webconverger turned out OK, though I doubt any Koreans will be using it. It’s all sadly ActiveX out there. My package wordpress 2.0.10 didn’t quite make it to etch in time as I was waiting for CVEs! 2.0.10 will be coming soon though… It always amazes me how much work can get done in breaks like Easter. It’s great that etch is out. And whoa, the weather is great.

DebianMuc release party, add yourself now. Saturday, at the Flaucher (Isar).Weather forecast for this week is great. Probably around 24 C on saturday, the warmest day this week I've heard. It will still be getting cold at night (after all, it's not summer yet, though we like pretending it is); so maybe we should meet rather early. Also make sure to bring some warmer clothes, too.Anyway, there is the Wiki and our mailinglist for organizing the party.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script. Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway. So what does a typical init script in /etc/init.d do? If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts. A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code. The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable. Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there). The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message. An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

There are many good reasons not to do it that way, but it will work. Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script.Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway.So what does a typical init script in /etc/init.d do?If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts.A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code.The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable.Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there).The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message.An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

There are many good reasons not to do it that way, but it will work.Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.[Update: next part]

Until September 2006, I lived in King's Lynn, so I still have friends there and look out for some topics to do with it. I'm also still helping to update some community websites for that area. On Wednesday 11 April, Friends of the Walks will meet in St John's Church at 6pm. Topics for discussion include the group's future role after the heavy work has finished. There will be more updates to the website in the next few weeks. (Apologies for late notice - I only got the letter second-class cross-country.)

etch is finally out of the door! Hooray! Congratulations to everyone involved, forget about what the /. crowd is saying, this looks likely to be a very solid release. If you happen to be in Hong Kong, there will be a Debian etch release party this Sunday afternoon. Please do come along, it’ll be fun. I’ve also translated the etch release announcement into Chinese, but it seems a bit more work needs to be done before it will appear on the Debian website. In the meantime following is a copy of the Chinese translation: (more…)

Via BBLUG I've heard about

"a monthly public demonstration of Free Open Source Software (FOSS), aimed primarily at beginners. It's not specifically for Linux, as the software will be demoed on a WinXP system to lure people in ;) -- however, I will make some live linux distro CDs for the event. Here's the details: Title: Introduction to Free Software
Date: Wednesday 18th April
Time: Lunchtime 1-2pm
Place: Cube Cinema, Dove Street South, Bristol BS2 8JS
Map
Price: Free
The website"

Anyone going?

Yesterday I was happy about SUN, because I saw an announcement that WTK 2.5.1 was released. And it includes a Linux version. The versions 2.3 and 2.5 were Windows only. The only available Linux version was 2.2. It worked nice but missed some features and had an annoying bug that signing of midlets were not possible. This bug was introduced in WTK 1.1 and fixed in WTK 2.5. Today I download WTK 2.5.1 for Linux and installed it. I tried to run a first midlet and got this error message:

java.lang.UnsatisfiedLinkError: /home/mkoch/local/WTK2.5.1/bin/sublime.so: /lib/tls/i686/cmov/libc.so.6: version  GLIBC_2.4' not found (required by /home/mkoch/local/WTK2.5.1/bin/sublime.so)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647)
        at java.lang.Runtime.load0(Runtime.java:770)
        at java.lang.System.load(System.java:1005)
        at com.sun.kvem.Sublime.(Unknown Source)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at com.sun.kvem.Lime.createLime(Unknown Source)
        at com.sun.kvem.KVMBridge.(Unknown Source)
        at com.sun.kvem.KVMBridge.getBridge(Unknown Source)
        at com.sun.kvem.midp.MIDP.run(Unknown Source)
        at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown Source)
        at com.sun.kvem.environment.EmulatorInvoker.main(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.kvem.environment.JVM.main(Unknown Source)

I run a pure Debian Etch system as my desktop. So its not too old. I know there are releasons for etch not to include Glibc 2.4. Thats really okay. But I really wonder why builds against Glibc 2.4? What feature introduced in Glibc 2.4 is needed? I guess none.
They are just stupid and built against a new, shiny Glibc without caring about their users. SUN: Please care about your users and release a new build against Glibc 2.3 soon. Not everyone will update his/her development machine just to be able to run WTK. When you release proprietary software, do it right. If you are not able to, make it open source, so the community can fix it.

I've changed the urls of everything in my website, including the blog. Feeds are limited to displaying new items to avoid flooding aggregators. Old urls will continue to work thanks to rewriting, and the rss feed url didn't change at all for the main blog (though some of the minor feeds urls did change and will redirect). Nothing you haven't seen a million times before, move along..

BOF stands for Birds Of a Feather, it's an informal session run at a conference usually without any formal approval by the people who run the conference.

Often conferences have a white-board, wiki, or other place where conference delegates can leave notes for any reason. It is used for many purposes including arranging BOFs. To arrange a BOF you will usually write the title for the BOF and the name of the convenor (usually yourself if it's your idea) and leave a space for interested people to sign their names. Even though there is usually no formal involvement of the conference organizers they will generally reserve some time for BOFs. Depending on the expected interest they will usually offer one or two slots of either 45 minutes or one hour. They will also often assist in allocating BOFs to rooms. But none of this is needed. All that you need to do is find a notice-board, state your intention to have a BOF at a time when not much else is happening and play it by ear!

My observation is that about half the ideas for BOFs actually happen, the rest don't get enough interest. This is OK, one of the reasons for a BOF is to have a discussion about an area of technology that has an unknown level of interest. If no-one is interested then you offer the same thing the next year. If only a few people are interested then you discuss it over dinner. But sometimes you get 30+ people, you never know what to expect as many people don't sign up - or have their first choice canceled and attend the next on the list!

To run a BOF you firstly need some level of expert knowledge in the field. I believe that the best plan is for a BOF to be a panel discussion where you have a significant portion of the people in the audience (between 5 and 15 people) speaking their opinions on the topic and the convener moderating the discussion. If things work in an ideal manner then the convener will merely be one member of the panel. However it's generally expected that the person running the BOF can give an improvised lecture on the topic in case things don't happen in an ideal manner. It's also expected that the convener will have an agenda for a discussion drawn up so that if the panel method occurs they can ask a series of questions for members of the BOF to answer. My experience is that 8 simple questions will cover most of an hour.

One requirement for convening a BOF is that you be confident in speaking to an audience of unknown size, knowledge, and temperament. Although I haven't seen it done it would be possible to have two people acting as joint conveners of a BOF. One person with the confidence to handle the audience and manage the agenda and another with the technical skills needed to speak authoritatively on the topic.

Some of the BOFs I have attended have had casual discussions, some have had heated arguments, and some ended up as lectures with the convener just talking about the topic. Each of these outcomes can work in terms of entertaining and educating the delegates.

But don't feel afraid, one of the advantages of a BOF is that it's a very casual affair, not only because of the nature of the event but also because it usually happens at the end of a long conference day. People will want to relax not have a high-intensity lecture. One problem that you can have when giving a formal lecture to an audience is nervous problems such as hyper-ventilating. This has happened to me before and it was really difficult to recover while continuing the lecture. If that happens during a BOF then you can just throw a question to the audience such as "could everyone in the room please give their opinion on X", that will give you time for your nerves to recover while also allowing the audience to get to know each other a bit - it's probably best to have at least one such question on your agenda in case it's needed.

Note that the above is my personal opinion based on my own experience. I'm sure that lots of other people will disagree with me and write blog posts saying so. ;)

The facts which I expect no-one to dispute are:

• BOFs are informal
• Anyone can run one
• You need an agenda
• You need some level of expert knowledge of the topic

I took some days off-line so the iBook story hasn’t progressed very much. On the other hand I’ve spent some time with my family and finaly finished Neil Stephenson’s Quicksilver. Sound Had some problems with the internal soundcard. I’m not quite sure what the porblem was, but the right module is snd_powermac and not anything like snd_aoa. Probaly did something else wrong along the way too. The fun part would be playing music throug AirTunes. raop-play claims to solve this problem. They got debian packages for i386 and a nice debian/ in the source tar-ball. The build-deps is missing fluid and libglib2.0-dev but other than that it builds nicely — but no sound… Nearly giving up I looked at the alsapcm module not part of the debian package, just to see how it worked in theory. And suddenly I could play music with mplayer -ao alsa:device=hw=1.0 music.ogg. Problem is that raop-play isn’t endian safe, but the alsapcm module forces use of little endian somewhere before the real raop-play. Afterward I’ve tested raop-play on amd64 where it works nicely. Java Java seems to be a problem. None of the packages of ibm-jre packages I’m seem to be able to find is supported by java-package. My Bank uses java, so that is kind of a show stopper, but I havn’t really looked into it yet. Flash, Youtube and the like Flash isn’t really a showstopper, but it would be nice to be able to see all the funny video clips people are refering to. None of the free flash plugins seems to work (swfdec, libfalsh-mozplugin), but youtube-dl and mplayer do the job. Futher work… Java is a major show stopper. I can’t switch for real without java support in my browser. The other problems is something I can live with. I migth even prefer to use AirTunes from my amd64 server instead of my laptop so I will probally ITP raop-play soon. Some people have asked why I want to switch away from wonderfull OS X. I’ll try to wirte something up one of the days - and no it’s is not anything personal against mac fans.

I'm really excited this morning. Wikitravel has been nominated for a Webby Award in the Travel category. It's amazing to get this kind of recognition for the work that our community has done over the last four years. I think that Wikitravel has a good shot at winning the award. I also hope that the Open Source and Open Content community, as well as wiki enthusiasts, will turn out to vote for us in the People's Voice Awards (open to voting by the entire Web community). tags: wikitravel wiki webbyawards webby awards webbies nominee travel

AboutUs.org has OpenID Looks like Portland (Oregon)-area startup AboutUs has implemented the OpenID extension for MediaWiki. Meaning that anyone can log into AboutUs with an OpenID! This moves AboutUs into a nice single-signon network with Wikitravel, Wikevent, and wikiHow, as well as a number of other OpenID-enabled sites. Great for them. tags: aboutus openid mediawiki

One version of pilot-qof went into Etch (0.1.1-3) with 0.1.2-1 uploaded to unstable after the freeze and just migrated into Lenny. A new release had sat in the NEW queue for a month due to the final stage of the Etch freeze. Finally, it is moving into unstable. 0.1.3-1 separates the pilot-qof binary from the perl, XSL and documentation making four packages in all, three under the new title: datafreedom. See data-freedom.org.

Hopefully, splitting existing Debian packages will not require a spell in the NEW queue in future - or at least a reduced queue, after all these packages have been checked once already. (Hence Sam was my first choice as DPL - congratulations again, Sam.)

If you previously used the XSL stylesheets from pilot-qof, you will now need the datafreedom-qsfxsl package. Note that the location of the XML catalog (and the XSL stylesheets) has changed too. See NEWS.Debian in the pilot-qof package. (zless /usr/share/doc/pilot-qof/NEWS.Debian.gz).

The intention is that the datafreedom packages will now mature to support a wider range of small utilities like pilot-qof - there is already support for calcurse, contacts, dates, gpe-expenses, gpe-calendar and a few others - justifying the package name change.

The XSL is (predictably) limited to converting from XML so if XSL is used to convert to a non-XML format, you'll also need the datafreedom-perl package to support conversion of non-XML data back into XML for inclusion into pilot-qof or conversion to other formats via XSL. The perl scripts also include support for aggregating data sources to create new data sets, e.g. combining addressbook, expenses and contacts data sources into a simple invoice. If, like me, you enter new data into your Palm whilst travelling around on business, you can HotSync the Palm and generate all your invoices in one script!

The perl package includes a number of new scripts and brings in a few new perl module packages and this is where the majority of updates are likely to occur in future.

Enjoy!

Oh well... today I upgraded a server at my workplace from Sarge to Etch. This went fairly well EXCEPT that the machine was quite slow afterwards and Samba didn't work anymore. No problem, I thought, because during the upgrade the Samba was displaying a note that I'll need to change the passdb line, because it doesn't support chained backend lists anymore.
The problem was, that this didn't help. To make a long story short:
During the upgrade the file /etc/libnss-ldap.conf has been overwritten without any notification. There's even no /etc/libnss-ldap.conf.dpkg-old file.
Apparently the QA of the Etch release failed in this particular case. Am I the only one who's using LDAP?

Update:
Meebey hinted me to have a look at the config file. The problem is, that the config file has a Debconf header, which indicates that it is handled by debconf. I'm used to edit those files anyway, because usually debconf (or the package scripts) notices if the file was changed manually and gives a warning about this issue. Well, the libnss-ldap package seems to be rather dumb and doesn't recognize when something has been changed within its configuration file. So, removing the debconf header will prevent this from happening again. Thanks, Meebey!

Coq: Happy to See it as a Geek Toy Daniel, I'm really happy you defined Coq a geek toy. Usually such pieces of software are more seen as academic toys, seeing it promoted as a geeky software is a joy to me. I'm a developer of Matita, a concurrent system of Coq (yet less mature a of today). I'm happy to give some more info about Coq (and hence about Matita, which is based on the same logical foundation of Coq). Coq is not really a programming language (even if the CoqArt book says so, to attract the developer community), it is mainly a proof assistant; i.e. a software in which you give definitions, state theorems and prove them. The added value of the system wrt plain pen and paper is that it grants that you won't be able to produce incorrect proofs (of course you are still free to prove useless theorems ). It is more expressive than predicate calculus, technically it is based on the Calculus of (Co)Inductive Constructions, but the most important differences are that you can give inductive definitions of predicates (or define recursive data structures) and the system will let you play with them freely automatically constructing recursors on these data types. You can even define infinite data structures (using co-induction) mimicking lazy types available in languages as Haskell. Regarding the synergy of Coq with OCaml: yes, you can prove in Coq the correctness of OCaml program, but actually not more than you can do with programs written in other programming languages (see for example Why, Krakatoa, and Caduceus for some practical tools to prove properties about Java and C programs). Yet the synergy with OCaml is even more than that: once you proved properties like the existence of, say, a prime number greater than a given prime number, you can ask Coq to generate for you (using a feature called extraction) an OCaml program which consumes as input a prime number and returns the next one. More generally you can extract programs from (suitable) proofs. Some info on the Debian side: thanks to smimou Coq has been in Debian for a long time now and Why/Krakatoa/Caduceus are coming soon. Happy hacking!

I've now moved lots of things to a new (old) server which should be noticeably faster than the old (old) 500MHz PIII-based server. Of course since Etch was released I'm now running on Etch. This also meant an upgrade to PHP 5.2, so I spent some time getting bitten by this bug with Drupal 4.7.4 and PHP 5.2 and had to upgrade to 4.7.6. Consequently there has been a wee bit of bouncing up and down today... In the process I have also upgraded my packages for eAccelerator so that they would work with Etch. Since Andrew Hutchings had taken them off me and played a bit further I have now taken his packages and built some newer ones, including a patch for 0.9.5 to work with PHP 5.2, and an additional build dependency. My new (old) server is still 32-bit, so these packages are only built for 32-bit as yet. I'm currently trying to find a 64-bit Etch box I can build them on as well, but everyone at work seems to have gone home. You should be able to fetch them from my package repository by adding it to your sources.list with:

deb http://debian.mcmillan.net.nz/debian etch awm
Naturally that repository is signed with my public key (8f068012), which is in turn signed by lots of people in the Debian community and should be readily identifiable - not that that implies trust, of course :-). Also, since my new (old) server is in a different location (and to ease the transfer) everything is on a new IP address (and a new IPv6 address). Hopefully the system's accessibility over IPv6 on http://ipv6.geek.nz/ will be slowly improving as we incrementally improve our IPv6 connectivity with the rest of the world.

Erich, the Gecko version number is pretty meaningless. With mozilla releases, the date reflects when the build was done. Which means if you build Firefox 1.5 today, it will get a Gecko/20070410 string. With Debian releases (except icedove), the date reflects the date for the client.mk in the source tarball, which is one of the last file upstream touches before a release. This helps having the same date for all 11 architectures (even after a binNMU) and is somehow more significant, but still not that much. There are, at the moment, 3 main branches for Gecko-based code: MOZILLA_1_8_0_BRANCH, MOZILLA_1_8_BRANCH and HEAD. The latter currently contains Gecko 1.9 alpha, Firefox 3.0 alpha, etc., and will eventually be branched to a MOZILLA_1_9_BRANCH or something similar when going in beta. The other branches are respectively for Gecko 1.8.0.x (Firefox 1.5.0.x, Thunderbird 1.5.0.x, Seamonkey 1.0.y, Xulrunner 1.8.0.x) and Gecko 1.8.1.x (Firefox 2.0.0.x, Thunderbird 2.0.0.x (not yet released), Xulrunner 1.8.1.x). [ In Debian Etch, we have Iceweasel 2.0.0.3 (Gecko 1.8.1.3), Iceape 1.0.8 (originally Gecko 1.8.0.10 but patched at version 1.8.0.11), Icedove 1.5.0.10 (Gecko 1.8.0.10 ; changes from version 1.8.0.11 didn’t make it, but they don’t affect the mailer code), and Xulrunner 1.8.0.11 (Gecko 1.8.0.11). The latter is used by kazehakase, galeon and epiphany. ] Whenever a new security release for Firefox 1.5.0.x and other products from the Gecko 1.8.0.x branch are done, the Gecko date obviously changes, and doesn’t reflect the fact that it’s an older Gecko than that of Firefox 2.0.0.x… Now if you take a closer look to the user agent string, you’ll see something that is actually more significant than the Gecko date, i.e. the Gecko revision, such as “rv:1.8.0.11″ in “Mozilla/5.0 (X11; U; Linux i686; ja_JP; rv:1.8.0.11) Gecko/20070324″