During recent weeks, not only sbuild and buildd were changed, but also wanna-build. Many changes were small and don't have direct impact, but will ease our life in future. This includes a bunch of code cleanups. Most changes were done by Kurt Roeckx and me, but as usual Marc Brockschmidt and Philipp Kern were also involved. This round of changes was started with redoing our priority calculation. Up to now, any package had a fixed place in the list, and our list was built from top to bottom as far as buildd power was available (putting aside manual intervention by setting build-priority by admins). That meant of course that some packages could be stalled if buildd time isn't enough anymore, like currently on mipsen. (The queue order was determined by the following sort options: build-priority, (>= standard?), already built in the past, priority, section, name, and the first difference decided list order.) Now, of course >= standard packages are still built first, but waiting days increase priority so that old extra packages could be built before young optional package (in other words, they shouldn't stall. The new formula is about: required: 50, important: 40, standard: 30, optional: 5 [priority] + libs: 4, devel: 2 [section] + contrib: -20, non-free: -40 [component] + out-of-date: 20 [notes] + max(6, waitingdays) * 2 + manual priorities, and packages are ordered by this number, then by waitingdays, then by name.) While adding code to add bonus for long-waiting packages, we stumbled across the fact that there were non-C dates in the database stored, which in turn means that export of the database stopped to work. For fixing that we replaced the last change field in the database by an postgres now() on insert, and converted that field to an date field (instead of freetext). Which in turn broke mkstats and a few more things, which are fixed as of now. While doing that, we also introduced the format option, which allows to do queries like:

wanna-build --format='%t %u: %p/%v% +b B%B' -A mipsel --list=building

which gives output like:

2010-03-03 15:24:38.642988 buildd_mipsel-mayer: cracklib2/2.8.16-1
2010-03-03 15:30:00.341313 buildd_mipsel-rem: liblouisxml/2.1.0-1+b1

Of course, there are even better possibilities what one could do with that. :) More changes are pending, like the injector for log files was changed so that we record building times in the database. This will allow us to include build time on at least a few buildds, so that large packages cannot so easily stall all buildds completely anymore. So, more to come ...

Protecting our privacy is important. For example, I wouldn't like if my mailing list subscriptions get known to anybody else (except the relevant listmasters of course as part of their job), for the simple reason that this is just my own decisions which lists I get mail from (and read, but that's not necessarily the same). This is an classical example of "personal information are handed out on a need-to-know-basis" (like to listmasters if necessary), and is also in line with european laws (I don't know the legal situation in other parts of the world enough). Now, publishing mailing list subscriptions hased sounds like an good idea to protect privacy. But if thinking twice, this just doesn't work. Most peoples subscription addresses could be known by other means or are even the addresses they use for sending mails (some systems even enforce this). So this is a huge privacy fail. Getting back to debian, and speaking the obvious out: The new interface to udd is just broken and wrong. Please remove all my adresses from being displayed, either in direct or hashed form, even in restricted mode. Thanks.

This moment has finally arrived! Last Saturday (27-th) on #debconf-team decision was made, DebConf11 is coming to Bosnia and Herzegovina! Our team and myself were working on this whole candidature for last ~9 months, and even though we put incredibly amounts on energy, hard work, enthusiasm and everything else that goes along with it, suspense and uncertainty were there until the very last minute! One of our local team members (trip0d s) wife almost gave a birth to their child during the decision process that lasted full 4 hours As a remainder we were competing with Ecuador and Germany to win this bid, whole process was excruciating and very emotionally distressful in every possible aspect for every team member; at one point Germany took a slight lead ahead of Bosnian team, while in the end by points Bosnia was in slight lead by 0.25 points, and this is exactly what touched me the most about this whole bid/decision/process. This is not a great advantage or anything for that matter, but what happened is that in decision process Debian debconf team and its developers picked Bosnia and Herzegovina as a place where they want to have DebConf11! Our main competitors from M nchen, Germany showed a real fair play and at the end even yielded to our side; really to both of you, Michael Banck (azeem) and Andreas Barth (aba) it was a pleasure and honor to compete with you guys! See you in NYC for proper handshake and possibly a hug? Also I d like to thank Jimmy Kaplowitz (Hydroxide), Moray Allan (moray) who had chairs and who did absolutely incredible job I guess I ll just have to thank the whole debconf orga team for all their amazing work ( can t name names individually because I ll definitely forget someone!) This bid really reunited whole Bosnia and Herzegovina, this whole process also united all of Balkans and whole of Ex Yugoslavia, which makes me especially happy since today (March 1st) we are celebrating the day we officially separated from Yugoslavia. Now this just one small step forward, since the real work is ahead of us and we re starting it all as soon as tomorrow since there s really a lot that needs to be done. Again thank you all, we ll give our best for this to be a DebConf you ll remember (as a great one of course!), in the meantime see you in New York City! Adnan Hodzic aka AbsintheSyringe team leader on behalf of whole debconf11-team. DebConf11 Banja Luka wiki Debconf11 decision log (#debconf-team log)

For over 6 years now I've been running Buildd.Net as a service for additional information about Debian autobuilder network. The reason for running Buildd.Net was simple: until then there was a web interface running on kullervo.debian.org, but generating the webpage took more and more time on that m68k box as Debian was growing in number of packages. That webpage was always a nice plus for m68k over other architectures and it was often asked for having such a page for those other archs as well. With taking over the webpage from kullervo the other archs were added as well and Buildd.Net was born.

Buildd.Net was open for other archs and flavours, as I called the different dists like unstable, non-free or even volatile or skolelinux. Buildd.Net was always buildd centric, contrary to buildd.debian.org, which is more package centric. Yes: was - as I'm shutting down Buildd.Net soon.

The reason for this is a change of interest after m68k has been removed from Debian because of the Vancouver proposal. Vancouver caused the death of m68k. Well, anyway. Without being an official Debian arch, the development on m68k came to an end. There was no progress anymore and on the other hand there were changes in the backend of the Debian autobuilder network, which made changes on Buildd.Net necessary. Requests for help in maintaining to adopt the changes were fruitless. The changes that Buildd.Net is needing are beyond my capability of programming.

And as a consequence I'm going to shutdown Buildd.Net in the near future. Not entirely, but significantly. It will return to its origins: being a m68k (and m32r) autobuilder informational page instead of trying to follow up the whole Debian autobuilder network. Just for the chance that m68k will be revived again somewhen.
Andreas Barth told me that most of the functions of Buildd.Net is available on buildd.debian.org as well, although not yet visible. I offered cooperation and help when he wants to implement Buildd.Net functionality into buildd.debian.org. I still believe that Buildd.Net is offering a worthwhile alternative view of the autobuilder network. But, as I already said, I can't maintain Buildd.Net code source any longer on my own. So I better shut the service down instead of delivering a broken service any longer, if there's noone interested in helping.

Anyway, I hope that you all enjoyed the service in the past!

Debconf11 This evening, the final decision on which city will host Debconf11 next year will be taken. For the last half year, mostly Andreas Barth, Jan-Marek Glogowski and I have been working hard to make the Munich bid as good as possible. One thing we wanted to make clear from the beginning was that we would go for a conference in the city center - not some conference center in some nearby village or in an industrial area far away from where the city life happens. It was not easy, since the german-wide decision, we had to reshuffle venue plans a couple of times. In the end, thanks to Jan-Marek, we managed to get an excellent venue offer. Our bid consits mostly of:

• Venue: Computer Science building (recently built) of Munich University for Applied Science, we can get as much as we need, for free. The only thing we would have to pay for is additional security personell during the night.
• Network: Leibniz Rechenzentrum is the operator of the Munich Research Network (MWN), the venue is connected with at least 1 GBits fibre optics, and the MWN is connected to X-Win at the same speed. This will be free as well.
• Food: We can either take up the offer from the Studentenwerk, the organisation operating the university restaurants. Of course, the quality is not like in a Michelin-star restaurant, but I have eaten there for several years during my studies and it is on par with previous Debconf offerings. Alternatively, we could look into food catering.
• Accomodation: We tend to go for hostels, similar to Edinburgh, probably 4-6 bed dorms. Munich is pretty expensive for lodging, so this is something we decided early on to keep the costs reasonable. Again, I think this is in line with previous Debconfs. Of course, hotels at a broad price range are available.

The biggest strong points about Munich are, in my opintion:

• Our local team has lots of experience with Debian and Debconfs, as well as organizing conferences
• We have government support via the LiMux-project, and the city mayor of Munich, Christian Ude, has agreed to be the patron of the conference
• Munich is very easy to get to, both for european (via train or car) or american/asian attendees (via plane). The airport is one of the biggest in europe and has direct connections to e.g. Atlanta, New York, Boston, San Fransisco, Los Angeles, Sao Paulo and Tokio.
• Network connection via LRZ/MWN/X-WIN should be superb, especially to Debian machines hosted at euro

It the end, it seems Banja Luka seems to have the stronger bid, especially due to their 150000 EUR governemnt sponsorship. We will see who wins, I believe we did the best we could.

As Munich is currently trying to get the olympic games in 2018, I looked at what Vancouver did. I could see that there is a new streetcar operating, however the tracks aren't brand new but used to be there while I was in Vancouver (just with not so new platforms and rails). To Whistler there are Busses operating. Inside the city there seem to be Olympic Lanes (which of course makes public transport faster). I'm wondering if there are new built lines at all for the games?

Back in the Lenny release cycle, I published some statistics of the release critical bugs. As we are (try to) get nearer to a freeze of Squeeze I think it's time to start that again. But first, a small explanation follows, what these numbers actually mean. If you look at our official bug tracking system currently lists 750 release critical bugs affecting the next stable release. While this number is kind of true, it is not accurate to use it to measure the state of the release. The unofficial rc bug thingy at bts.turmzimmer.net is quite more powerful to actual get some interesting numbers, as you can ignore specific kinds of bug and filter them properly. Note, that at the very end of the detailed list of the bugs you get the total number. With that interface you can for example filter them by different distributions. For example it currently lists 650 rc bugs in total for any distribution, but if you filter for squeeze bugs, you get only 518. That's a different number as the official bug tracker shows; I'm not entirely sure why, but a part of that difference is that both the official and the unofficial web pages are only synced periodically. Should someone be able to give a good explanation about the differences, please step forward ;) But let's play more: You can filter for bugs valid in squeeze-only, but not in sid. These bugs are already fixed in sid, but the packages haven't yet migrated to squeeze. Currently that are 94 bugs. We can furthermore ignore bugs only in sid; when squeeze is unaffected, we just don't migrate the broken package from sid to squeeze. The number that is most interesting for contributors is the number of bugs affecting both, sid and squeeze, as these are the ones which really need to be fixed as no fix is known, yet. So filtering for bugs for both we are down to 424 at the moment. But of these 424 remaining release critical bugs, we can still ignore some (for now). For example bugs concerning packages in non-free or contrib (9 currently) won't stop us from release, will they? There are also many bugs marked as pending (32), meaning that the maintainer is aware of the bug has a fix prepared and is just waiting with the upload a moment. Some of this bugs have already a patch (64), but no one reviewed it and uploaded it by now. You'll also see that you can ignore merged bug reports (47). That are bug reports reporting the very same bug several times. Finally there are bug fixes already uploaded to the so called delayed queue (6). This are bug fixes which where uploaded by someone else than the real maintainer, but to give the maintainer a chance to act on himself or to comment, the upload is delayed by some days before it will actually hit the archive. Currently 6 bugs are fixed by uploads to delayed. 17 bugs are claimed meaning that someone already said he will take care of this bug (but they are not finished, yet). You could also ignore the bugs invalidated by today's britney bug category, representing bugs which will vanish after the next migration of packages from sid to freeze, but as we are only looking at rc bugs in both sid and squeeze, this number will always 0 ;) That leaves bugs somehow other marked as fixed which are bugs (39) where I honestly have no Idea what they are... If someone can explain them, please do so ;) Here is a small tabular showing the above numbers:

Total:	650
Affecting Squeeze:	518
Squeeze-only:	94
Unfixed bugs remaining in Squeeze:	424

Of these 424 bugs...

... are pending	32
... are patched:	64
... are duplicates:	47
... are in Non-free or contrib:	9
... are claimed by someone:	17
... are fixed in the delayed queue:	6
... are somehow marked as fixed:	39

Or in other words:
Release critical bugs left in squeeze, when ignoring all these:
260 That's a pretty number, isn't it? There are only 260 bugs left which need our immediate attention :) But that is a rather optimistic view of the situation. We e.g. assume that all bugs having a patch are really fixed by the patch. We also ignored, that some bugs in squeeze are already fixed in sid, but the package can't migrate because the package in sid contains a new bug. (Which happens to release wizard Marc Brockschmidt quite often.) So if we take off the purple classes and take a more pessimistic view (release mangers must be pessimists to ensure high quality packages ;) we count the bugs in squeeze and ignore only those bugs, which are:

• hinted / delayed upload (hint means a package is forcefully migrated from sid to squeeze without waiting the usual time span)
• merged
• contrib
• non-free
• bugs invalidated by today's britney (fixed in sid, package will migrate soon)

With this release managers views, 424 bugs remain to be fixed somehow before we can release. As far as I know, we can freeze once that number is reliable under 300. So we better get working ;) When asked, what is the thing mostly needed to help the release, I was told: mips porter!
As you might have read we have some problems with the mips and mipsel architectures. It seems we have all the hardware we need, but it doesn't work very reliable. I have been told, that over 300 packages are only waiting to be build on mips* architectures. So if you can help us in that regard, please contact our mips porter mailing list. Update: Andreas Barth just told me, that he already send a couple of mails to the mips list describing the problem and asking questions. Answers to these questions would be most welcome and accpeted gladly.

I'm currently looking for some backup tool, but each tool lacks some features. I'd like to

• have rsync style (i.e. small) backups;
• multiple backup-from locations per host;
• backup should end on an webdav-device (but "local" in the filesystem will do for starters);
• encrypts to gnupg (multiple keys), but restoring/looking at the diffs doesn't require to either gpg-agent-export the key to the restore location nor to transfer the content to the site where the gpg-key is;
• allows to restore the version of previous days, and allows to view the differences created since then;
• "feels like unix", i.e. configuration in some text-file etc etc.

I took a deeper look at duplicity, but the encryption to gnupg means I need to copy files around. Also the webdav-uploader has some issues if backups get too large (i.e. uploads take too long). Any other hints? Or is it worth to start to enhance duplicity? Update: I'd like to generate the backup on the backuped system, but to manage them (i.e. purge old versions) on the backup system. And of course restore to any host within my control. Without exposing any affected gpg key, but just the one-time key(s) for the affected backup(s).

Currently samba cannot transition to testing, as cups doesn't build on mips* anymore. We first thought that the issue is that cups is using PIE as build option, but even after changing cups to not do that, and making binutils to give a specific error message for using PIE instead of building corrupted binaries (thanks, Matthias for the fast change), it still continues to FTBFS. No answer from the porters yet though. And no idea what to do, at least none that I know of.

In response to Andrews request for a feed of RC buggy packages there is currently a 3 times per day changelist on http://bts.turmzimmer.net/. Converting that list to an RSS feed shouldn't be an issue if it's helpful to people. (And if you want it, just sent me an example how the two current top entries should look like as rss feed.)

It is strange to watch for the first time a debian release to happen, without being part of a though time schedule, and with the possibilities to sleep uninterrupted etc. And it is a good feeling to see how well it went. I want to congratulate the people who made it happen, especially the people who worked for it for many months or even years. To avoid the pain of not mentioning someone who did lot of work, I restrict myself to congratulating my successors in the release team - a better list of people is part of a mail Marc just sent out. Thanks, and well done!

It seems it is that time again. People seem to believe that Debian is actually able to ship a new stable very soon, and so they do actions that delay it. Good news is that this means: We're really quite near the release. Only some RC bugs to crack (anyone can help here, seriously), and we should be done. Let's work together and make this happen again!

Thanks to Thomas Viehmann for the patch on both ftp-master side (aka http://ftp-master.debian.org/deferred/ and on "client side" (and for nagging me enough to activate it), http://bts.turmzimmer.net/details.php shows now again when bugs are fixed in delayed. Thanks!

Currently, I'm together with Marc Brockschmidt evaluating which virtualization to use on our new server. We want that our virtual systems feel like real systems, and we want an open source solution. So, vserver and the like is out of the game, as well as VMware. The two remaining solutions we looked at are Xen and kvm. Xen has of course the advantage of the matured. Also, we have experience with running xen servers - and with the issues that can happen, like the chances to disconnect dom0 from xend, and then reboot the server the hard way. However, the most serious disadvantage is that development has practically stalled with the 2.6.18-kernel. Of course, even of today one could install a new server based on Etch, but that doesn't really feel right. There is some development ongoing to run domUs with newer kernels (like in Lenny), but there isn't currently any new kernel available for dom0. kvm is a more recent addition to the virtualization camp, and is basically "qemu on steroids". All looks rather promising, development happens with the recent kernels. However, kvm lacks a few features of e.g. Xen. This includes the ability to reboot dom0 (and the hardware) and just let the domUs survive. Or to have a nice management script where one could just say "xm shutdown $domU", and have basically the power button be pressed on the virtual machine. Or to just attach and detach to the virtual console whenever one wants. Nothing of that is impossible with kvm, one could attach the command-terminal to some pipe, and the linux console to some other, and attach and distach via own scripts. But - all of that should be expected to be available from some solution that calls itself enterprise ready. (And - writing own scripts has always the possibility to make own mistakes.) However, among all the worst possible issue is that kvm is underdocumented (or rather: There are lots of different places where some parts of the documentation is hidden - including the great remark in the man page "The other options are similar to those of qemu."). So, what to do? Invest more time into a solution that seems like a dead end. Or put up with the incompletness of another solution?

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

I'm currently looking for some software that user can login on the webserver, but for the scripts, it doesn't look too different from basic auth. One example of that kind is webauth, however that requires that all user accounts are in kerberos. I however want to continue to keep accounts in ldap, because that works well for most issues. So, my next step is either to set up kerberos in a way that allows the accounts to be synced with ldap, or find another software with the same effect.

The current apache ldap documentation explains that apache first looks up in the directory before performing an bind. Sometimes it would be much easier if one can just tell apache "take this dn, add the supplied user name there, and there you go". Any ideas how to do that?

I wanted to be able to not only bind with the normal dn, but also to attributes. This means I e.g. have an attribute mail, and want the people to be able to login with their mailaddress as username. Stephen Gran gave me some valuable hints to using the rwm-rewriting engine. After some time, I ended up with this setup:

overlay rwm
rwm-rewriteEngine on
rwm-rewriteMap ldap attr2dn "ldap://127.0.0.1/ou=myorg?dn?sub"
rwm-rewriteContext bindDN
rwm-rewriteRule "^anyid=([^,]*@[^,]*)" "$ attr2dn(mail=$1) " ":"
rwm-rewriteRule "^anyid=([^,@]*)" "$ attr2dn(uid=$1) " ":"
rwm-rewriteRule "^(uid=[^,]*)" "$ attr2dn($1) " ":"
rwm-rewriteRule "^(mail=[^,]*)" "$ attr2dn($1) " ":"

The only thing that doesn't work is to make rwm using ldap version 3 to log into itself, so I had to allow read-only access to the relevant attributes from peername.ip=127.0.0.1 - but well, I can live with that. Update: Added anyid for not thinking in client code, and made sure only the start of entries is used.

Since yesterday I am through with my NM procedure. Looking back I get to the same conclusion as probably most NMs have: not overly hard, but time-consuming and glad to have it over with. Anyway, so far so good, just waiting for DAM approval and my account now. There are still a couple of people in front of me but I hope for another processing before the elections close. (I guess it would at least be good for the turnout.) For now, many thanks to my Application Manager Andreas Barth who has been very responsive and always answered my mails quickly and thoroughly, and also to Martin Zobel-Helas for advocating me.

I'm currently considering how to allow users to log on with different attributes as user names, e.g. with their "real" user name or their mail adress. Unfortunatly as described on http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authldapurl, though RFC 2255 allows a comma-separated list, only the first attribute is used. Now, of course an idea would be to specify all different attributes as a new "loginas"-type one. Another solution would be to use ldap overlay modules, and just convert them "on the fly". Better ideas would be welcome. Update: Thanks to Faidon Liambotis (again!) one can probably use mod_authn_alias to combine authentication with user name, mail adress etc.