More updates:

* I can now walk to the mailbox on my own, and I only need to rest once on the way.
* I'm generally leaving the walker alone. It causes me more grief than it solves.
* I feel confident making the three steps up and down the balcony - which is good because the main doors are still too heavy for me.
* I've had a shower. I smell much better.
* We're starting to take visitors now - Jim and Sarah were here last night, Andrew and Sarah are coming tonight. It'll be nice to feel a little less isolated.
* I haven't spoken to my dad in a couple of days, but they were still scheduling his angiogram when I last spoke to him. All the walking and stuff that I've been doing means that I'm spending the balance of my day sleeping, so hopefully I'll catch up later today.

At this point, I'll probably post updates a lot less frequently, because it feels like the initial touch-and-go part is done. I'm looking forward to being off the steroids, and slowly spacing out the medications and such, but we're just in that zone where I'm getting up and around and am just waiting for lifting restrictions and such to be removed.

In the last few days, I've managed to sort out the various school extensions I need, the short term disability paperwork, the DMV disabled sticker paperwork, and all that.

Phone calls are much appreciated - the number is in my Orkut and Facebook profiles, it gives me a chance to interact with people and I'm starting to worry that I have too much time and am bothering the ones I talk to al the time. I'm still quite behind on emails, mostly because typing on the blackberry gets to be a bit much after a while.

I suspect I'm about to go into that annoying phase of recovery where nothing is urgent anymore, and we're coping, but we go stir-crazy because I'm not actually better enough to interact with the world yet and Angie still has to do almost everything for me. Any suggestions on making that part of the recovery suck less are appreciated! I've watched it a pile of times, but everyone seems to forget about it (including the people going through it).

Sunrise is 7:11 here this morning, I think I'll try to sit outside for it.

Do you know some web sites sporting an Art Deco or Roaring Twenties web design? I find that period (the Swing and Jazz age, where Gangsters were still stylish) very fascinating, and I'm looking for things to get inspired.Art Deco is usually described as being "simple shapes, geometric, vibrant colors", which would fit to web design restrictions quite well, wouldn't it? Other important aspects seem to be the use of materials; which obviously isn't really possible in web design (mind you, textures are only a bad approximation).If you know some sites where you'd say "this is Art Deco Webdesign", please let me now via EMail, erich (AT) debian (DOT) org[Update: Web Designer Wall has a list with a couple of nice pages. Not all of them are Art Decoish or Roaring Twenties, but some a pretty nice.I'm looking particularly for Art Deco and Twenties, but any Vintage and Retro Design can be inspiring.And I'm not looking for pages to blindly clone, but to get some inspiration from. I don't copy, since I do pages in my own particular (XMLish) way anyway.]

Like many people interested in bringing computer security awareness to the public at large, some eight years ago I was thrilled to get acquinted with sudo. A great tool for giving specific admin rights to specific users in a very granular way, with great semantics... And allowing for a degree of flexibility much higher than my needs, honestly.
I think it was the Canonical crew who first thougt of using it backwards, "solving" (for some definition of solution, of course) the long-known problem that desktop users cannot be bothered to understand they are using a normal account which is, for their own personal security, completely separated from the priviledged account.
So, in short, Ubuntu uses a passwordless sudo to grant users (at least I understand it is limited to the first system user, am I right?) access to whatever and whatnot... And most users seem to like this.
Yes, the same way they like Windows: Because it is the no-brainer solution. Now, give a person with no brains some choices... Guess which choice they will pick.
Now, it's assumed by most semi-newbie Linux users that sudo basically means "go ahead". I have tried to get this point across to people complaining that Debian ships a b0rken sudo because it is not basically a ALL ALL = NOPASSWD: ALL
So, as it is currently used... I do feel sadness: Unix systems tend to Windowsification, where real administrator privileges are just a matter of asking whether you are sure. Assuming single, local users for local machines.
[update] Oops! lots of comments explaining my world-view is somewhat flawed... Anyway, I'll reply to the comments themselves.

For various reasons, I have the kernel and the initrd that my notebook needs to boot Linux on an USB stick. I recently added the Debian Installer and grml to the stick to allow additional uses of the stick. Usually, USB sticks are formated with FAT32 and when they’re used to boot Linux, Syslinux or some derivative is used. I do it differently on my boot stick, most prominently because I’d like to have Unixoid privileges on the stick, and because I’d like to continue using grub. So, my stick is formatted as ext3, and feels like an additional hard disk. Booting from an USB stick is sometimes tricky. I have made the best experiences with formatting the USB stick as an USB ZIP, which basically means having 64 heads, 32 sectors and a single partition in the fourth primary partition slot. This can be done using mkdiskimage and is documented on Debian in /usr/share/doc/syslinux/usbkey.doc. Partitioning and generation of the file system is as straightforward as is installing grub using the standard, documented methods for hard disks. I tried using grub 2, but have found it not sufficiently well-documented and stable to be used in this kind of critical environment. I am therefore still using grub-legacy despite the fact that the grub maintainers have ceased fixing grub-legacy bugs some months ago, refering to the pending release of grub 2. I use unison to keep /boot on the stick in sync with /boot of the Linux system, which is on a crypted filesystem on the hard disk and thus unuseable until the system has booted. The hard disk /boot thus serves only as installation target and sync source so that the stick does not need to be plugged in during upgrades. update-grub is configured so that running it creates a menu.lst which can be used from the stick. This concludes booting the production system from the stick. For the other systems, I have decided not to put them in the “default” boot menu from menu.lst, but instead include foo.lst files to the root of the stick, and when I need them, shell out from the grub menu to a command line by pressing “c” and then pulling in the new grub config file with the “configfile /foo.lst” command. grml is my favorite rescue system. I use it all the time once a system starts acting up. One of its biggest advantages is its extremely flexible bootup process. That made it predestined to be the rescue system on my USB boot stick. grml is currently making a transition to a new build environment, which has had the side effect that the boot process has changed in some details. grml-small, the 60 MB variant that I had been using before, has been discontinued and replaced by grml-medium, a 170 MB variant which does definetely not fit any more on a business card CD, but 128 MB USB sticks have become relatively seldom. For both grml flavours, all one needs to do is mount the .iso file loopback, copy the file’s contents to a subdirectory of the boot stick, and to drop this menu file to the stick:

title           grml-small
root            (hd0,3)
kernel          /grml-small/boot/isolinux/linux26 toram grml_dir=/grml-small/GRML/ grml_name=GRML ramdisk_size=100000
init=/etc/init lang=us BOOT_IMAGE=grml
initrd          /grml-small/boot/isolinux/minirt26.gz
title           grml-medium
root            (hd0,3)
kernel          /grml-medium/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs
lang=us boot=live noeject noprompt keyboard=de
initrd          /grml-medium/boot/grmlmedium/initrd.gz

Since grml-medium works reasonably well, I do not expect to need grml-small very often any more. The Debian Installer guys have published an initrd which can browse nearly arbitrary media for an debian-installer .iso file, mount it and install from that image. I have made use of that feature to allow Debian to be installed from my boot stick. /d-i holds a current debian-testing-i386-netinst.iso, and vmlinux and initrd.gz from http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/hd-media/. With that, this d-i.lst:

title debian installer
root (hd0,3)
kernel /d-i/vmlinuz
initrd /d-i/initrd.gz

does the trick and boots up the Installer, ready to start. I guess that it would be easily possible to include these grub config stanzas to the default menu.lst, including grml and the Installer into the main grub menu, but I deliberately decided not to have these options directly in the menu for the time being. It is always amazing how flexible today’s systems have become when it comes to boot Linux. For both rescue and installation, this is needed, and the respective authors have done a remarkable job.

I just read an interesting blog post about Montenegro [1]. Apparently a key to the process of becoming a country was acting like it was inevitable. It seems that this method can be applied to many areas, one of which is the contest between Linux and some proprietary OSs. For many years monopolists have convinced people that it was inevitable that they would monopolise all areas of software development. Why use any other software (even if it is more reliable, faster, has more features, and is cheaper) if a monopolist is about to dominate the market? The monopolist changes sometimes, the monopolist from ~1990 to now is different from the monopolist of the 1970’s, but the tactics of a computer monopolist remain the same. The way to beat this is largely to just ignore them. There is an ongoing debate in some circles about when Linux will be “ready for the desktop“. I’ve been running Linux as my primary desktop environment since about July 1998, it’s almost 10 years of having Linux as my primary desktop environment. It seems inevitable that the Linux will take over the desktop - it’s far better for desktop use than it was 10 years ago when I switched. Some people claim that Linux lacks driver support. Every piece of hardware that I’ve wanted to use over the last 10 years has had adequate support. Often second-hand hardware works best with Linux, hardware vendors have no reason to continue to support their old products on newer operating systems (they make more money if you buy new hardware to run the new OS). Not only is hardware support for Linux adequate, but long-term support is far superior (and I often get to use cheap second-hand hardware). Now that an increasing number of hardware vendors are supporting Linux for their new hardware (Intel, AMD, and most laptop vendors are doing some good work in this regard). It seems that everyone who has tried both says that writing drivers for Linux is easier than writing drivers for proprietary OSs, so it seems inevitable that Linux will end up with better driver support by all metrics. Linux is designed for users. DRM (Digital Restrictions Management) is not something that interests Linux developers. Run Linux and your computer will obey you and give full quality audio and video. It seems inevitable that Linux will dominate the AV section of the market (it already dominates the computer work involved with creating movies). Free software (of which Linux is merely the most famous and popular example) is based on the principles of open design and open standards. When you use a free software program to save a file then you can be reasonably sure that you will be able to read it back again in a few decades. Most free software uses file formats that are well documented and standardised. Sometimes there are bugs in programs and new versions will use files in a different way, this is sometimes a case when you rely on a bug in an old version. Using the older version of the software is sometimes required to properly access old data. Fortunately when you have the source to the older programs they can be compiled on new systems (so different types of CPU won’t matter). Also the lack of DRM means that an OS image can be virtualised. One thing that is on my todo list is to create a set of virtual machine images of some of the most commonly used distributions of Linux so I can easily compare distributions of 10 years ago with modern distributions - it’s not technically challenging and there is no particular technical or legal obstacle to doing this. This would also mean that if someone gave me a file in some strange format from 10 years ago I would have a better chance of reading it. It seems inevitable that as the value of data increases the desire to avoid OSs that prevent people from accessing their own data will also increase, and that will eventually squeeze out most closed software from the market. This doesn’t mean the end of proprietary software, merely the end of software that holds user’s data hostage. The majority of the world’s population does not use computers. The computers that they end up using will be cheap because they can’t afford to waste so much money on new hardware. To make cheap machines means that there will be limited resources in terms of RAM, mass storage, and CPU power which require more efficient software. Also to properly take advantage of machines with small screens and other limitations changes to the design of the software will be required. It seems inevitable that the most open software will be adapted to such environments more readily than proprietary software. Now this doesn’t mean that we can take a break from development. In the free software community there are usually many different programs to perform a particular task with competition between the developers of the various projects. The fact that a monopolist is inevitably going to lose it’s position is of little relevance to the competition between the various free alternatives.

• [1] http://www.airs.com/blog/archives/115

Share This

Hello World, When I have absolutely nothing useful to do (which has been quite a while ago now), I sometimes like to play with povray. Not that I'm very good at it—I'm a programmer, not an artist—but it still is good fun. What I usually prefer doing is creating an animation. This is rather easy with povray; you can have it modify certain values in your scene based on some "clock" variable, and then generate a series of different frames based on that one scene description. This creates a large number of image files in the format that you specified (say, .png) in your output directory. Of course a number of frames is not an animation yet. If you want that, you need to do some postprocessing on these images. ImageMagick to the rescue.

convert foo*.png foo.mpg

This works, but I don't like the low quality which the MPEG2 format gives me; and it also requires me to install the non-DFSG-free and slightly buggy MPEG2 reference implementation before it'll work. That's not very nice. What I'd really like is for something similar that will work with Ogg Theora. So, dear lazyweb, is something like that even possible? This would preferably not require me to know too much about Ogg Theora, but just take a bunch of files and output a .ogg file—much like the above convert command line. Thanks,

• Translation From MS-Speak to English of Selected Portions of Joel Spolsky s Martian Headsets
  Haha.
• Robots are getting better...the Big Dog robot can recover itself...
  Watch the video!
• Apple iPhone bootloader attack
• APIs: "Easy to Use" vs "Hard to Misuse"

This could be fun - gpe-filemanager is not currently available for Emdebian because it depends on libgnomevfs which in turn brings in a variety of other dependencies ending up with liborbit2 which simply does not (and appears cannot) cross build.
Thankfully, GNOME 2.22 deprecates libgnomevfs in favour of GIO which is already part of libglib2.0-0 and only needs other stuff via plugins.

I need now to port deb-gview to GIO and, in the process, probably see if gpe-filemanager can also be ported to GIO. After all, a GUI without a file manager is going to look a little odd.

I'm still working on libqof2 upstream too so it looks like I won't be doing much on Lenny for a while - not directly at least.

I expect to have deb-gview 2.0.0 depending on GIO and in Lenny and maybe quicklist too. (Typical, no sooner does quicklist migrate from Gtk1 than it also needs to migrate from libgnomevfs.) Then there's all my usual Debian and Emdebian stuff.

The status page speaks for itself: most of GNOME 2.22 is now available in sid. A few packages are being staged in experimental to avoid breaking too much stuff, and a few of the remaining missing pieces are waiting in NEW. Special thanks to Sebastian Dr ge who's done an incredible work with more than 90 uploads over the past week!

For the past few years, Google has been running their Summer of Code events where Google offers $5000 for college students who are asked to code for a summer for the benefit of various Open Source efforts. And just like in 2006 and 2007, I put up proposals and offered to act as a mentor. The first one is up at both Debian and R: an opportunity to help with the ongoing efforts of 'turning more CRAN package into Debian packages'. The second one is only at the R page: a proposal to fill the missing link of DBI database interface modules with a matching one for PostgreSQL. More details for either idea are at the respective pages. Anybody interested should ping me by email.

Since there aren't only serious grave and critical bugs we have to fix for the release, the RM Team spontaneously decided to make a front attack to the g++-4.3 FTBFSes. All in all we did probably more than 110 to 120 NMU to fix g++-4.3 FTBFS bugs. Our champion is definitely Marc Brockschmidt who uploaded 50 packages. I NMUed 22, and also did one QA upload. Add to that 5 sponsored NMUs for Cyril Brulebois, and one for Arthur Loiret who happens to be my NM, and fixed one of those bugs for his T&S. There are still twice as many to fix, those are really easy bugs to deal with, just give it a try ! I'd like to thank Cyril Brulebois for his awesome work on the g++-4.3 release goal. A shame that he's still elmo-ed, as he wrote more than 150 patches, and could have uploaded them himself if not still waiting for his account. Shame on us.

I've been critical of the almost abusive terms in the user agreements of most user-harvesting-based services (sometimes called Web 2.0) for a while now. There are quite a few services that I simply won't use because their owners want me, all my web "content" (whether explicitly posted to their site or not), my first born child, or similar. There are even more sites where I'm careful not to put much beyond the bare minimum and try to make sure that I keep backups of nearly all of it. Usually that means keeping a copy of the input, as getting my data back out of most sites is a pig. So far, when I've criticised aggressive user agreements, I've felt like a lone voice in the wilderness. It's been heartening to spot two user-harvesting services geting some abuse over the last week or two. First, the Swift online community platform for conferences has been attacked by both David Lee King and librarian.net for its over-zealous user agreement demands. Particularly "nice" is the feature where one rule of Swift club is that you don't talk about Swift club (see last paragraph of David Lee King's post). Swift's owners have responded. I'll watch and see whether it improves enough to get a follow-up post from either blog. Secondly, the Phorm advertising system has faced hard questions from both Open Rights Group and Sir Tim Berners-Lee over its mysterious user tracking. Phorm hasn't yet replied properly about their potential to harvest user-generated content (web histories and so on) without consent, as far as I can see. If you know anyone on Talk Talk, BT or Virgin, tell them to start planning the exit route. If you'd like to refer them to our agency for The Phone Coop that would be great. I suspect the owners of The Phone Coop would get quite vocal if it ever tried to track users like this and a comment on the ORG post suggests someone else has asked Are we seeing the start of a user-harvesting backlash?

I've been sucked into this alternate reality game, "The Lost Ring", which involves 6 people who woke up with amnesia in labyrinths around the world, blindfolded, with a tattoo "Trovu la ringon perditan". It involves a lost Olympic sport, lots of Greek mythology and history, and lots of puzzles and detective work. Currently 26 pages of a codex are being tracked down from hiding places all around the world, with ones in Cardiff and Austin recovered over the past few days, one in Shanghai that I hope will be reached soon, and a location just discovered in Stockholm (in a bread store!), that someone needs to go check out. (Update: Jon read about it in my blog and went and got photos! page 1 page 2.) This is the first time I've played an alternate reality game, but the way the story is told, through blogs, podcasts, youtube videos, email with the characters, and recovered documents like this, is quite compelling. Also interesting is all the use of Esperanto, as well as characters who speak Spanish, French, German, Chinese, Japanese, and Portuguese, so that translation is an ongoing part of the game.

Ldap seems like a good database to store accounts in: Lots of tools can use it, it's easily integrated into pam, and lots more. But one sometimes just hits borders in the data model of openldap: There are no semantics available. So, let me give you an example. Take e.g. the dnsZoneEntry attribute in the debian.org-ldap. Actually, one wants to allow anyone to write into that attribute in his own entry. But - and that's a big but - one wants to have two additional checks before writing: One is that one cannot claim any dns entry already used by someone else. And the other is that the format needs to comply to specific standards. Now the question is, is there some way to use ldap with more semantics? Or does one need to write ones own backend to do that (and in all the non-plain-db*-backends, it is specified that one needs to write his own authorization code as well). Or some other recommended way to do that? (Or is the only existing incarnation of that ActiveDirectory?) Update: Thanks to Faidon Liambotis I know now about the overlays in openldap. The standard overlays unique and constraint will probably solve the case above - of course, I have a few more complex cases, but that are at least good starters.

emacs-goodies-el

• Test debian-mr-copyright-mode and report suggestions to Vincent Fourmond: done. Next todo: include it, probably in dpkg-dev-el.

pkg-games

• Prepare latest Bos Wars upstream, ask for a sponsor: done. Bos Wars is a futuristic real time strategy game. It used to have copyright and license troubles, but upstreams kindly addressed that.

pkg-phototools

• Finish libpuzzle packaging: done. Libpuzzle is a library to compare images, which also comes with a simple puzzle-diff binary scoring image similarity. Next todo: Wait for a review of the PHP bindings by Emmanuel Bouthenot (who already kindly rewrote upstream's manpages in a proper manner), then ask for a sponsor. Another todo: Check upstream status of CLSimilarImages, see whether it might be worth packaging it, and point the upstream authors to each others.
• Check LuxRender's upstream status: done. LuxRender is a rendering system for physically correct, unbiased image synthesis. The packaging has been ready for weeks, waiting for a released tarball (rather than working on a CVS snapshot). RC5 is on its way.

Misc.

• Suggest an option for fork()-based rendering to Blender upstreams: done. Blender is a free open source 3D content creation suite, including modelling and animating tools, as well as an internal renderer. For some reasons, one might want to use a fork()-based solution rather than one (only) based on threads (limited to 8 by default through a #define), when it comes to using a cluster. Next todo: try and hack it myself.
• Check appletouch's bug #465278 with latest kernel: done. appletouch is the mouse driver on iBook G4 machines, and tends to break badly when resuming from suspend2ram: it's unusuable until the next reboot. Not any better with 2.6.25-rc5-powerpc. Next todo: Report it upstream, following Maximilian's request.
• Check the status of a nasty xfwm4 bug: done. When the switch back to previous workspace option is enabled, and one keeps the key for switching to another workspace pressed too long, xfwm4 starts flickering between both workspaces, endlessly. Restarting X helps. That was previously reported to happen only on low machines, but it's easy to trigger this bug by lowering the delay before character repetition in the keyboard settings.

Of course, that's just an excerpt of the actual todo-list

I've just finished reading "Don't You Have Time to Think", a collection of letters written to and from Richard P. Feynman. A birthday present from my wishlist. Previously I've read the collection of letters to/from Tolkien. (Several times actually. Very nice collection!) It suddenly struck me that over my lifetime I've probably written <200 letters to people. When I was young I had a couple of pen pals, and when I was entering university I was involved with a couple of play by mail games which involved writing random letters involving strategy & etc. Personal letters though? I've written very few, and I think they've mostly consisted of letters to my partner/partners of the time. (For example Megan went home for a few months at the end of a university year about two months after I initially met her. So there were many letters back and forth. Recently she spent two months working in the USA; counting eggs and avoiding alligators so again there was a flurry of written letters, maybe 20 total during the duration of her trip.) I guess that most of my (hand)written messages to people have been in the form of postcards whilst on holiday. A long time ago I offered to mail postcards to Debian developers. I know I sent at least two, and I received at least one back - but the thing I remember most was exchanging addresses with Amayita and getting into character set issues. Her emails, containing her Spanish address, were difficult to understand as my mutt/console refused to display the foreign character set properly. I can't recall whether she did ultimately receive a card from me, but I'm sure she'll remind me if she did. Anyway I have no resolution, intention, or expectation that I will suddenly start writing more physical mails to people. But I think it almost counts as something we do less of these days. The telephone and internet have become the norm. In some ways this is fantastic. In others it less good. On the left my handwriting is so bad that maybe this isn't necessarily a problem. ObQuote: E.T.

Today's bugs:

• downgrade of 459726: no, having emacs cruft at the end of a debian/changelog is not RC (or we have kind of a problem since there are quite some packages with this issue afaict).
• I proded the bioperl maintainer who pretends to have a FTBFS fix pending for months.
• thanks to HE, who uploaded a new upstream for libsimple-test-perl, 466624 got a reminder that this bug can be closed.
• NMU/2 for 456856: long standing FTBFS, due to a incoherent C guard.
• NMU/2 for 465251: I wrote a proper debian/copyright using the machine parseable proposal to please our DPL as it's one of his packages after all :P

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU: GCC 4.3 transition Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug. PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor. gfortran transition Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names. apbs and psicode already have been transitioned. Other bugs Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:

#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’

Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.

#438694: gabedit: Crashes when loading any XYZ format file

Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.

#442223: openbabel: some connect information lost when convert from pdb to txyz

Nothing examined yet to solve this bug.

#464867: extrema: conflicts with psi3 package

Hope, my team will cover this asap.

#465723: mopac7 — please do not use g2c.

There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.

For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622. New upstream releases It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days). In all other cases, new upstream releases should be easier to handle. ITPs All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:

docbook-xsl-ns

See the above note about docbook-xsl and the source package split.

html-xml-utils

Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.

DocBook 5

I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I’m not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.

QA work/fixes Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded. I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won’t be ready this week-end. It’s always when you come closer to the goal that it gets farther… And I still haven’t decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue. Considering we will more than probably have both schemes in use within reverse dependencies, I’m not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul… That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though. I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI. The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package. I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast ! For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I’m planning to package a new Webkit snapshot soon after I’m done with xulrunner and Iceweasel, we’ll see then how it performs. While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn’t crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0). Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I’m testing on x86-64).

I've been writing a bit about Trac and Redmine lately. For approximately the 1/3 of the publically-available software that I've written, I maintain a Trac site for it at software.complete.org. This 1/3 is generally the third that has the most interest from others, and there's a bug tracker, wiki, download area, etc.

Trac is nice, and much nicer than one of the *Forge systems for a setup of this scale. But it has long bugged me that Trac has no integration between projects. To see what open bugs are out there on my software, I have to check -- yes -- 17 individual bug trackers.

To keep track on the wikis to make sure that nobody is adding spam, I have to subscribe to 17 different RSS feeds.

It took me some time just to hack up a way so I didn't have to have 17 different accounts to log in to...

So, mainly, my use case for Trac isn't what it was intended for.

Enter Redmine. It's similar in concept to Trac -- a lightweight project management system. But unlike Trac, Redmine allows you to have separate projects, but still manage them all as one if you please.

Redmine didn't have Git support in its latest release, but there was a patch in Redmine's BTS for it. I discussed why it wasn't being applied with Redmine's author, and then went in and fixed it up myself. (I used Git to make a branch off the Redmine SVN repo -- very slick.) Unlike Trac's Git support, Redmine's is *fast*. I tested it against a clone of the Linux kernel repo on my local machine.

There are a few things about Redmine I don't like, but I have learned that they mainly have to do with Ruby on Rails. As someone pointed out on Planet Debian lately (sorry, can't find the link), the very nature of Rails makes it almost impossible for OS developers like Debian to include Rails apps in the distribution.

Not only that, but it seems like Rails assumes that even if you are just going to *use* an app, you know how to *write* one. For instance, this is pretty much the extent of documentation on how to set up a Rails app to be able to send out mail:


# See Rails::Configuration for more options


And of course, googling that turns up nothing useful.

Redmine is a rails app, so it cannot escape some of this. It seems to be a solid piece of work, but Rails seems to make things unnecessarily complex. That, and I've found some bugs in the underlying Rails infrastructure (like activerecord not quoting the schema name when talking to PostgreSQL) that make me nervous about the stack.

But the site is up and running well now, so I'm happy, and am planning to keep working with Redmine for quite some time.