A while back Frans filed an interesting bug explaining the reason why digits width should always be the same.

Finding out if the previous condition is true, is just a matter of creating a sample text file

FONT="DejaVu Sans Oblique"
OUTFNAME=$(echo $ FONT    sed -e "s   _ g")
numdigits=100
for i in $(seq 0 9) ; do
   for j in $(seq 1 $ numdigits ) ; do
   echo -n $i >> numeri.txt
   done
   printf "\n" >> numeri.txt
done

and creating a waterfall image:

pango-view --font="$ FONT " --waterfall --dpi=72 -q -o $ OUTFNAME .png numeri.txt

The resulting image shows how Dejavu Oblique is victim of a regression at size 9 and 10 (credits to fjp who spotted it once more!)
bugreport filed.

Planet Debian now has Javascript to facilitate the persistent hiding of particular feeds. The code is still in flux, but appears to work. Comments welcome, especially from people better at Javascript than myself! The way it works was chosen to minimise the changes requred:

• Each entry is wrapped within a new <div>
• The DIV has an ID & a CLASS attribute added.

At load-time the function hideHosts() is called. If a comma-separated cookie called "excludes" is present this is split and iterated over. For each domain-name in the list the current document is searched for elements having a class prefixed with that hostname - if any match and they have an ID defined (regardless of what that might be) they are hidden. And thats it. The changes to the template were minimal; each index entry already has a "link" attribute, so I just had to add this:

 <div class="<!-- tmpl_var name='link' escape='html' -->"
         id="<!-- tmpl_var name='link' escape='html' -->" >
 ....
 </div>

Because the ID and LINK attributes are URLs there is a little mangling, and inefficiency. But I didn't want to change the core of the PlanetPlanet to define a "hostname" attribute for each feed member... In an ideal world I'd add "class='feed, $link'" and then iterate over that at load-time to attach handlers, and an ID appropriately. But that is a little scary.. If it works in IE great. I've tested Firefox & Ephinay ObQuote: Terminator II Update: Moved javascript into external file, and removed the image toggling, it seemed to fail and I'm not sure why. I will investigate.

(This was one of those pesky “oh, it’ll only take an hour” ideas.) AptFs is a FUSE-based filesystem that provides a view to unpacked and patched Debian source packages as regular folders on a filesystem. Binary packages are modelled as symbolic links pointing to their respective source package. This arrangement allows one to:

• Use standard UNIX utilities to perform queries across the entire Debian source tree
• Save keystrokes and time when downloading (and subsequently deleting) source packages
• Do really awesome things easily, like perform static analysis on the archive, count swear words, etc.

The program maintains a sliding window of unpacked packages to perform automatic cleanup of unpacked packages — it would not be very helpful if commands such as

% find /path/to/aptfs

…unpacked the entire archive into your temporary directory. Source (GPLv3) is available in Git:

% git-clone git://git.chris-lamb.co.uk/aptfs  # or
% git-clone http://git.chris-lamb.co.uk/repo/aptfs.git

Patches always welcome, and shout if you like it; I’ll file an ITP and try and upload it.

I've uploaded a new make package to fix the memory corruption bug which I recently tracked down, with kind permission from the maintainer. I've also been working on a Debian Planet filtering/exclusion system. I've put together a (working) online demo, and I think I could probably inject it via greasemonkey without too many problems. (I'm a little reluctant to install that addon, because I suspect the security implications are severe). Still it was a nice hack, and actually reminds me that I like javascript these days. The demo will probably disappear in a week or two, but otherwise works as expected - just a couple of GUI issues to solve. (As with the Debian Planet search this isn't tied to our install, and could work on any PlanetPlanet installation.) Maybe it isn't the friendliest of ideas, but I think it is a good one regardless. ObQuote: Last King of Scotland

I spent the night doing all these normal things in my dreams: washing dishes, coding, shopping, cleaning up my desk, etc.. The only thing that was common to all was that I sang Bohemian Rhapsody all along. In the morning, I was afraid I could have kept my flatmate awake, but he denied hearing anything. Regardless, I am declaring today Queen Day and I m already grooving. NP: Queen: A Night at the Opera

Bubulle asked about whether anyone has computed the number of bugs open (and by inference close) and I've just found a link from the DD statistics pages:
Debian Bug Tracking System News - These are the bugs touched during the last four hours. The data will be updated in 40 minutes.
Active Bugs 110443 (+9) 9230042 kb
Archived Bugs 366389 (+0) 24156850 kb
Debian NEW closable bugs 41
Source packages in incoming.debian.org 19
Package movement for testing +17 -2
Orphaned packages 360
Popularity contest Debian 76404 (+0) Ubuntu 448702 (+0)
Total registered dpkg/apt Users 525106

There's an RSS feed too.

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

I have just watched The Wire’s last episode. For those who don’t know about it, The Wire is the greatest TV series ever created (Salon and Slate back me on this). It’s been acclaimed by critics, but widely disregarded by audience. I’ll never forget Jimmy McNulty, a troubled Irish American dipsomaniac murder detective (played by brilliant Brit Dominic West) or Omar Little, a Robin Hood-like stickup homosexual man in west Baltimore. The rest of the deeply portrayed characters of the show are great too, but above all of them, the real starring role belongs to Baltimore. I am sure Baltimore’s reality goes way beyond this show, but I don’t think a show can get more real than The Wire. Each season focuses on a different topic, such as drug-dealing, unions, politics, the press, always keeping the police department around. The story arcs are really long and complex, The Wire is not the kind of show you can enjoy watching a single episode of, but more like, as its own creator - a former Baltimore Sun journalist - put it, a “66 hour movie”. Well, I could keep praising it for hours, but lots of people have done that already, even Barack Obama loves it (:P, let’s ride the hype). Praise available in Spanish too Besides, Eliot Spitzer has made wiretaps really popular again these last days Really, you must see it.

I finished reading the electronic advance reader’s copy last night. Overall, I’m glad I read it, though it was quite infuriating. The book is set about a decade in the future. In the book’s world, anthropogenic climate change and global warming turned out to be a hoax; instead, a global cooling (caused by solar variation) was beginning. At the same time, the bird flu (H5N1) became a major pandemic. The United States was governed by the democrats and “the bitch” (a thinly disguised demonisation of a certain democrat presidential candidate), who handled everything wrong. The book is a fictional autobiography (or a series of blog posts) by a US army officer who became famous during those turbulent times, first commanding a company finding its own way back home after being abandoned in the Middle East (the later stuff I won’t describe to avoid spoiling the book). The Last Centurions is a television propaganda show featuring his unit in action, intended to counterspin anti-military news reports. Several chapters early in the book are pure political ranting by the narrator: how anthropogenic climate change is false, how socialized medicine is bad (and causes lots of unnecessary deaths during a pandemic), how republicans are good and democrats are evil et cetera et cetera et cetera. (Then again, it’s a Ringo book, political ranting is a given.) Given my political persuasion, it was not easy to read: I kept yelling, “where are your footnotes!” I actually tried to verify some of the claims the narrator makes, and found nothing persuasive. Still… in the end, it all turned out to be justified. It explains the character, and it explains the world. Perhaps it should be a bit trimmed during editing (remember, I read the author’s submission draft which has not been through the usual editing and copyediting cycles), but a lot of it is necessary for the story. The premise that anthropogenic global warming is a false theory made it very hard for me to suspend disbelief. However, given that premise (and the premise of a totally incompetent government in the USA), the story is compelling and interesting. There’s a quite a bit of military action as we have become to expect from Ringo. The beginning grabbed me, – apart from the couple of chapters of exposition – held my attention tightly to the end, and left me shell-shocked. I especially liked the wife’s edits. I’m sorry that we didn’t get to see their courtship. I don’t know if I’ll ever want to re-read the book, but I’m still rating it at 5/5. The book is now available as an e-ARC, and will be released as a regular book in August. There is a companion site at www.thelastcenturion.com.

I think that Matt Hartley is spot on on his Top 10 Linux Desktop Hurdles. Commented:

1. Regression testing is hard. Assuring that hardware that worked will still work in the next version of the distribution is where many Linux distributions fall down. At least I think Debian here does better than some others.
2. Mobile devices. I've written about this already some months ago. I want to just plug in my smartphone and sync it with my calendar application. I don't think this is too much to ask.
3. Software compatibility. I don't do video editing and I'm comfortable with the Gimp, but I witness people having difficulties with OpenOffice.org all day. Mostly, it's because either they were MS Office power users and stuff like form letters are different between the packages, or it is because the state issues silly form/macro based MS Office documents.
4. Wireless. Hmm. I haven't had real problems with Wireless in quite some time. But then, I know that I need to watch what kind of hardware I buy, so YMMV.
5. Hardware compatibility lists. Debian doesn't have one, so that's apparently a good starting point ;-)
6. Compiling drivers. I don't understand this complaint. The user should never even come to the point where he needs to compile a driver. But I think here Debian with module-assistant is quite good.
7. The Patent Trap a.k.a. I Want To Watch DVDs. This is a serious issue, and will probably not be going away unless some heavy duty political stuff is happening. Organisations like PubPat and the new End Software Patents initiative will help. In my opinion, though, these are not taking it far enough. Patents are monopolies granted by the state — in all other areas (post, railways, telecommunications), it has been agreed that monopolies are bad, so why not just abolish the broken idea of patents, too?
8. Off the Shelf Software. Hmm. My clientele is not the lone Linux user at home but the business user who has an IT support dept, so I don't see this issue for me.

Issues #9 and #10 is just “the community sucks” in nicer words. He's not wrong as such, but I think Matt's view is pessimistic on these.

Last week I did again some work on nagios-plugins. After the announcement of Dann Frazier to upload NMU to fix a trivial bug, I thought it’s time again to give some extra care to the package. So I prepared 1.4.11-2 fixing the important bugs and uploaded it. I also commited some minor fixes to the svn, so these issues will get fixed by the next upload. Since the development of policyd-weigh stalled and unfortunately maybe get stuck, I was looking for an alternative, which maybe found with postfwd. It’s quite flexible but it also will take more time (and care!) to get a reliable configuration, which maybe effective as policyd-weight (still) is right now. While checking the dependencies for postfwd I noticed that Net::DNS::Async isn’t available in Debian (yet). So I decided to create a package starting with dh-make-perl, join the Debian Perl Group and let it review. Damyan Ivanov was so kind to review and upload it, Gregor Herrmann did also give some much useful hints. Thanks to both! And yes, I also found time to step forward with NM, since I was overloaded the last weeks with usual work and life. Thank to my AM to be so appreciative.

In case you didn’t know, I’ve decided to resign as atheme project lead. This is for a few reasons:

• Firstly, I have felt overall ineffective in this role since late 2007. This is probably due to the fact that disagreements between me and several other people have resulted in people leaving the organization to work on other projects, and the fact that atheme has not grown in any significant way since last year’s Summer of Code event.
• Secondly, I am busy with a lot of other things and do not have time to give the proper attention this role needs. This role is basically defining the direction that atheme grows in, and capitalizing our strengths to expand the project and promote it. I see the lack of growth and proper promotion as a personal failure.
• Thirdly, at the moment I am under a lot of stress due to dealing with various issues at the moment, which is leaving me irritable and generally quick to anger. This is not a quality we want in our project leadership. In short: I’m fucking up, and it needs to stop. So right now, I am resigning as project lead. If people want me back when I am under less pressure in general, then that’s great.
• Fourthly, we need to see new leadership in atheme anyway, to keep things interesting. Without a regular change in leadership, people will start to see us as someone’s personal project, and that’s not the case with atheme.

However, just because I’m resigning as project lead doesn’t mean that I will stop working on projects I care about inside atheme, like audacious, mowgli, and mcs. These projects are critical components of the modern FOSS desktop, and I intend to continue working on them. This is purely an administrative change, so that any mistakes or stupidity I do have no effect on atheme.org’s overall health. I hope to see many other Atheme members step up and try to become project lead. Under the right leadership, atheme’s projects could become a much more notable platform in FOSS development within a short amount of time. Update: Due to popular demand, I have changed my mind. I’m no longer resigning as project lead of atheme.

This October, our church celebrates its hundredth anniversary. All this year, every so often, we are having brief "historical moments" during church.

Today, our temporary choir director -- and my high school band teacher -- was a Vorsanger. He got up during church and discussed how hymn singing was done in the early days of the church. Today, our Mennonite church sings in a variety of styles, most commonly 4-part music accompanied by a piano, and no director. But we also sing more "contemporary" styles.

Back in the earlier days, the church didn't have hymnals with music for everyone. The Vorsanger -- song leader -- would sing each phrase, then the congregation would sing it back in unison, throughout the whole song. Hymns that the congregation already knew well would just be sung normally, in unison, with the Vorsanger directing.

Not only did the Vorsanger lead the singing, but he or she also chose the music -- not the pastor. As the church purchased first a pump organ, and later a piano, the instruments would sometimes be used to accompany the singing. The musicians never knew what would be sung in advance. One 80-year-old member of our congregation remembered the she started to play for church at 8th grade. But much of the time, there would be no instrument, not even to pick the starting pitch.

This morning, we sang Holy God, We Praise Thy Name with the Vorsanger. It's a familiar song in our church, but we generally sing it in English. The Vorsanger taught it to us in German, the older people in church would have remembered it. He finished his introduction, stepped away from the microphone, and rang out with the first phrase.

Gro er Gott, wir loben dich

Then we all sang the phrase back to him, in unison. On to the next phrase, back and forth for the rest of the hymn. Terah and I were in the choir area, behind him, but could hear him -- and the rest of the congregation -- just fine.

At the end, our Vorsanger for a day said he thought we got it, so we sang through it again, still in unison, but without him leading us on each phrase.

Gro er Gott, wir loben dich,
Herr, wir preisen deine St rke,
Vor dir beugt die Erde sich
Und bewundert deine Werke.
Wie du warst vor aller Zeit,
So bleibst du in Ewigkeit.

What a powerful way to feel connected to the people that worshiped at the same place so many years ago.

As our director said before we sang in choir this morning, music can say so much more than words.

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

1. emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.


2. emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.


3. emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.


4. libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.