With Kathy being away I thought I'd have a look at setting up webmail so she can get hold of her mail easily whatever setup she ends up with. My only experience so far is sqwebmail but it's not that great UI-wise and ties to Maildir. This is good because it means it's lightweight, but I figured if I was investigating systems I should keep Black Cat (who currently use sqwebmail along with various other bits of Courier) and the (which is largely mbox at present) in mind. apt-cache search webmail produces a list of things to try. My heart sinks as I realise lots of them require PHP. And others want MySQL. I go and have a look at Prayer, which I've vaguely prodded before. It's not packaged, but I decide to try it out. It builds easily enough, I wrestle with roughly packaging it up into a deb to make removing it less hassle and install it. It doesn't like my earth.li CA signed cert on localhost. I eventually find the novalidate-cert option and manage to connect. My home box runs dovecot with Maildirs. This leads to my next problem; Prayer wants to create a folder called .prayer for it's config info. This doesn't work with Maildirs as folder directories tend to start with a . Changing it to prayer-config fixes that, though leaves it visible in the web interface. It's possible I can hide it if I look harder. So, I'm ready to send a mail. I do so. It gets delivered (modulo me remembering not to try to send from my internal domain to the outside world). A sent-mail folder gets created. Prayer failed to show any messages in it. I verify there is a message there by looking on the filesystem. I curse. I try creating another folder and sticking a message in it. No joy. I try Prayer against a Courier server. Same thing; it shows the mail folders as directories but no messages. I try it against a Dovecot server with mailbox. It works fine. I curse some more. At this point I decide the statement "Consequently, the user interface distinguishes between mailboxes and directories: this will not work well with servers which provide dual use mail folders." on the Prayer website should be heeded. So I decide to try postman, which the Prayer docs suggest they'd have used if it had been around when they started (it also does persistant IMAP connections with a backend daemon). I give up once I actually start trying to figure out the config file and how it all fits together. So. Out come the IMAP RFCs. I attempt logins to the different servers I have access to and I find that the mbox server reports \NoInferiors for mailboxes while the maildir server reports [\=HasNoChildren]. And that \NoInferiors implies [\=HasNoChildren]. So I hack Dovecot to always return \NoInferiors. And it works and I can see messages in folders. Yay. But hacking dovecot is annoying and won't help me with Courier. Leading to the following patch to Prayer:

--- prayer-1.0.18.orig/prayer/dirlist.c
+++ prayer-1.0.18/prayer/dirlist.c
@@ -172,7 +172,8 @@
 
     dl->next = NIL;
     dl->name = pool_strdup(callback.pool, name);
-    dl->isdir = (attributes & LATT_NOINFERIORS) ? NIL : T;
+    dl->isdir = (attributes & (LATT_NOINFERIORS   LATT_HASNOCHILDREN)) ?
+               NIL : T;
 
     /* Insertion sort algorithm */
 

ie if there are no child folders we assume the current folder is a mailbox rather than a directory. Now to actually run it for a while and see if it does the job.

After you have installed a minimum SELinux setup in QEMU, you might want to tweak and edit the policy to fit your needs. A nice, graphical method to do so is to use SLIDE, written by Tresys (and released under the terms of the GPL). SLIDE is an Eclipse (>= 3.1) plugin, which you can install easily:

• Click Help->Software Updates->Find and install...
• Click Search for new features to install, then New remote site
• Enter "http://www.tresys.com/files/eclipse-update/" as URL, click Finish.
• After that, select the new entry, and install SLIDE (will restart Eclipse).

Of course, you can also easily use your favourite text-editor to edit the plain policy files (if you use the te.vim file from Thomas Bleher you get syntax highlighting, at least for *.te files). After placing the file in the ~/.vim/syntax directory, add this to your ~/.vimrc:

if has("autocmd")
  filetype plugin on
  augroup te
    autocmd BufRead,BufNewFile          *.te set filetype=te
  augroup END
endif

I almost submitted this to the excellent Crypto-Gram newsletter, but I think it's not actually all that evil. It's still pretty depressing for what I considered a security-competent online bank, though. The First Internet Bank of Indiana has announced that they will be enabling a new feature next week: First IB Security+. You have to answer additional questions about yourself to gain access to your account. But the questions, or at least the answers, will be selected by the user, from what I can tell - which means probably not hard for a determined adversary to acquire the answers, especially given that they must already have your online banking password. But sometimes they won't be asked the questions: if your account is configured to allow store a cookie on a particular computer, and the cookie is present, the questions will be skipped. They're increasing the security of my online banking experience using _cookies_? Which, if your computer was hacked - one of the most likely ways to get ahold of your password - the hacker could have already copied (along with the question answers, probably)? They can't be IP-based cookies, not with modern web proxy farms used by a number of ISPs and dynamic IPs still in use. I think that what they're trying to accomplish is an anti-phishing technique: if you don't expect to be asked questions, but you are, then there must be a man-in-the-middle attack in progress or something similar. So it's an extension of making sure that you're looking at an SSL-protected web page and that the certificate really is the one you think it is. There really must be a better way to do this - in fact, I think upcoming web browsers (both IE and Firefox) are supposed to have related features. At least they're not making anything worse. You still need the password, of course. So I think this is mostly a benign version of what Bruce Schneier calls "security theater", neither harmful nor especially helpful.

Some semi-random photographs taken with the new camera. (resized to 800×600).

• Some dead things
• A moth of some kind - similarly dead
• Interesting moss
• Some broken paving and moss
• "Misery"

I think I’m getting the hang of using the camera now, and will probably go back and attempt to understand the manual over the weekend. Talking of the weekend we have a Debconf 7 related meetup in Edinburgh. But still no real plan about what is going to happen …

Debian on the desktop? Thats unpossible. Actually it works for me just fine. I bought a few new toys recently - a new camera (Canon Powershot A620) and a USB2 card-reader to allow me to read the images from the 1G card I bought to go with the camera. I figured that was worth doing since it came with a paltry 32Mb card. After getting confused by the manual for a while I randomly played with it until I got the basics, I think I took a couple of hundred pictures of my feet, my desk, my hands, and etc. Afterwards I figured it was time to see what the images looked like when displayed for real, instead of via the LCD panel. So I plugged in the USB card reader to my desktop. No response from the system but I figure that is normal when there is nothing actually in it. Once I took the SD card from the camera and pushed it into the reader I got a nice popup from my GNOME desktop “A new device has been found - do you want to import photos now?” (or similar). I said no, and a window popped up showing me /media/usbdisk. Nice. I wasn’t quite sure if I could just pull the card out, or whether I should explicitly unmount it. In the end I did the latter - better safe than sorry. So .. a rambling entry to say that USB card devices and GNOME just work^tm. I’ve not experimented with the USB cable the camera has - which apparently allows you to control a lot of functions via software, but I figure that I don’t need that kind of thing anyway. After all 99% of the time I’m going to be taking pictures away from my house and desktop machine! In related news I was chatting to somebody local recently and they asked what MSN software I was running. I said “GAIM”, then later “I don’t use Windows”. That didn’t even get a raised eyebrow. It seems that even a non-technical user has heard of Linux, if not necessarily Debian.

The Debian Desktop Artwork meeting was a success, some members of pkg-kde, pkg-xfce and pkg-gnome and others were there. Thank you guys!

We focused in 8 (some of them dupes) artwork artifacts - basically login screens, wallpapers and splash, and the 4 items that were previously in our agenda. It was consensus that we need some guidelines and probably we can use one single source package (desktop-base) to build multiple binaries (at least one per desktop environment).

If you want to join this effort, join us at debian-desktop mailing list. I'll post a summary of our meeting there and the full meeting log will be available soon. There will be other meeting where i'll talk about the guidelines status and we will discuss the technical details raised on the list.

I'm living on the Etch...

Today, as it was widely anticipated, the Superior Tribunal of the Judicial Power of the Federation (TEPJF) declared Felipe Calder n, of the currently right-wing governing PAN party, elected as president for the 2006-2012 period.
My regular readers will know that my political views are against his party's, and that I completely oppose him - Of course, being consequent, in June I started, together with some friends, FeCal.org.mx, a site destined to show the incongruencies and incoherences in the official version - and that evolved to a site I am quite fond of, having good and deep analysis of the political situation. Of course, it is time now to redesign and think forward for this site, now that FeCal is no longer a candidate - but lets leave it aside for now.
Today, we are mourning. We are not mourning an electoral loss - Wherever there is democracy, there are losers, and it might be right that we lost this time. Furthermore, in political systems such as ours, it is practically guaranteed that the majority of the citizens will lose (this means, it is terribly hard for any candidate to get over 50% of the votes - If Calder n wins with almost 35% of the votes, or if L pez Obrador wins by a similar amount, we will anyway have 65% of losers). But what we are mourning goes far beyond that: We lost faith in our electoral institutions, which we were so proud of a couple of years ago. They proved not to be serious, not to be adequate for a hard decision. Why am I saying this? Lets analyze a bit.
First of all, the Federal Electoral Institute (IFE)'s main function is to organize the federal elections, and to make sure they are run with neutrality. Since the early months of the formal competition (as the campaigns themselves started way too early and we Mexicans are sick of the eternal electoral climate), the IFE has not acted in time to stop a dirty campaign, made not only by the PAN party but by the nation's President himself and by groups that, being privately owned, are said to be outside the reach of the IFE's regulatory spectrum. The IFE's general council should have been built with representants of all of the main political forces, but only PRI and PAN (which means, center-right and right wing) were represented.
Secondly, over the last six years, President Fox seems to have made constant efforts not only to prove us all he is a complete fool and inept as a statesman (examples abound, there is no rush to prove Vicente Fox just cannot be trusted to run a country), but that his fight for democracy was nothing but a race for personal power. He took every oportunity he could to promote his party - while the Mexican law requires him to remain neutral during the electoral period. There are many proven examples of irregularities and corruption inside his cabinet (most notably those carried out by Josefina V zquez Mota, who was in charge of all of the federal programs to fight poverty, and was the coordinator of Calderon's campaign) leading to inject resources into the campaign. Yes, this should have been stopped by IFE as soon as they were detected - But it was not. And, thank you Mr. Fox, by doing this you severely undermined the respect there should be for the Presidential figure.
Now, IFE's role ends shortly after the elections. After that, it is TEPJF's role to qualify the elections - To ratify they complied to the required equity, legality and certainty. Many of us had more trust in TEPJF than in IFE, mainly because of the series of personal and group connections that came up between IFE and the power groups. Most of us were quite vocal on the voto por voto, casilla por casilla front - Demanding from TEPJF to request to recount all of the votes. Having only 0.58% distance between the top candidates, with lots of statistical anomalities, with tons of reports of illegal tampering of the ballots, having a wide recount would surely make many among us believe and accept the results - Of course, the PAN repeated ad nauseam that the ballots had been counted and we should not go again over the same excercise, quoting all kinds of arguments that came from a too narrow interpretation of the law. And, in the end, too narrow was the response of TEPJF - Only 9% of the booths were reinspected, and not all of them were recounted. In fact, one week ago, they decided to discard over 300 appeals (this means, 300 requests for trial on a specific booth or on a whole district), without yet disclosing which appeals were they, on what basis were they discarded, what geographical areas did they impact, or anything. They nullified about 235,000 votes - And this number is quite scary, as it practically matches the official difference between the two lead candidates (244,000 votes before this partial recount, 233,000 after it). We can now state for certain that the difference between the candidates is smaller than the error margin.
Today, with a very important portion of the country in doubt on whether their decision was legal and correct, TEPJF ratified Felipe Calder n as the elected president. This would be good news. I would like to accept Felipe as my president - Sadly, I cannot, just because all of the TEPJF's principles were violated:

• Equity: The process didn't progress with equity. Illegal publicity was repeated over and over. Just as one example, the Presidency has had the equivalent of 24h a day of ads in the national electronic media for over six months - And IFE acknowledged it was used in a way that promoted the vote for their candidate. The final message was very subtly changed, many people were left unsatisfied, and... That was it.
  Andr s Manuel L pez Obrador was often protrayed as a puppet of Fidel Castro and Hugo Ch vez, and there are still people who believe he was setting to create a communist regime in Mexico. Of course, this was also a direct result of what is now known as the hatred campaign that the ruling party and an important group of industrials pushed. So, no, we had no equity.
• Legality: Most of this posting has dealt with the ilegalities of the process, they are really not in short supply. The sad and alarming thing is that it was the TEPJF itself which commited the last and most important illegal acts.
• Certainty: In a strongly contested electoral scenario, I perceive this to be the sole most important principle. How many votes were cast for each of the top candidates? We have repeatedly stated that the difference between them is below the statistical error margin for a process where a million people counted the votes. And after last week's results where nearly 240,000 votes were discarded, the difference is objectively and undoubtely smaller than the error margin. Even if no fraud was made, people make mistakes, and it is too na ve to assume not even one out of each 200 votes was incorrectly accounted. And even if no fraud was done, not allowing the society to ensure the results of the process really match the reality is by itself a fraud. We will now probably never know if Felipe Calder n cheated, the same as we still don't know who won in 1988 and by how much. Then, official records say that Carlos Salinas had over 50% of the votes, Cuauht moc C rdenas almost 30% and Manuel Clouthier close to 20% - But both C rdenas and Clouthier were sure they had won. And while C rdenas (founder of the PRD, which now supports L pez Obrador) called off the civic resistence to start creating a strong political movement for future, PAN's Clouthier did exactly what his party criticizes L pez Obrador for. In fact, our president Vicente Fox was the Agriculture Secretary in Clouthier's parallel government. Only that Clouthier had a misterious accident some months later and died - giving way to the dark period of PRI-PAN concertacesiones led by Diego Fern ndez de Ceballos.

So... In short, what comes now? We are exhausted by this long process. As too many people, I just cannot accept the imposition of yet another fraudulent president. I had the hopes that Mexico had changed in the last 18 years - But it has not. We are still in a strong presidentialist regime, and we still don't have hopes of getting a democratic government. If we do have a democraticly elected president, perfect, I will accept it. Of course, criticizing and keeping a close eye on his government, as I don't think the social and economic principles they push, but accepting. But there are too many signs of a fraud, there are too many stinky bits in the decision. The stinkiest of them all, the refusal of their opportunity to shut us up. Is it better to have millions of angry citizens closing important streets and giving Mexico a bad name by writing about our trip back to the stone age than to allow for a legal recount? Is it too much asking giving some certainty to our elections? Is there any doubt we will keep fighting this imposition?

There's some discussion going on in Debian about firmware in main. Some people want it, others don't. The main argument by the firmware-in-main advocates seems to be that we can't install hardware if there isn't any support for it in the installer, and that the installer can only install by using stuff that is part of main. The obvious answer to that would be to modify the installer so that it would support retrieving stuff from non-free, but then that would require some changes to the installer which, according to Joey Hess, are rather significant. So we now have a GR proposal to allow for firmware in main anyway, so that we can support non-free hardware. Obviously the proposal includes overriding the social contract. And huge and insane flame wars. I don't like the sound of that. And I'm not convinced that the only way to get non-free udebs on a system is to download them from the Internet; Windows, RedHat, SuSE and other operating systems have supported the concept of "driver disks" for ages; I don't see why we couldn't do the same. And since our system is way more flexible than theirs anyway (it being modular and all), we can easily implement this using udebs. So rather than engaging in flame wars, I just sat down and wrote some code that would allow the concept of "customization disks": CD-ROMs, hard disk partitions, USB keys, or floppy disks with udebs on them that will be installed if the user chooses the right option in the installation menu (requiring expert mode to get there, however). This can be used for all kinds of interesting things: non-free modules, but also OEMs (say, HP) providing udebs on their driver CD-ROMs so that they can have the installer support their hardware which is supported by the latest version of the Linux kernel, but occasionally not by the version that Debian Stable ships with, by backporting a kernel driver to the right version. Should they so choose. Or people could use it to test new modules without having to upload them and without having to set up their own repository. Or third-party developers could use it to add extra code to the installer to support some automagic stuff, whatever. It hasn't been tested at all yet, but at this point it's not much more than a proof of concept anyway. Comments are welcome, but please read the thread on -boot on the subject, too.

Or, BEID of the same version. Oh well. It took me a while, but I finally managed to jump through all the hoops[1] required by backports.org correctly and in the right order for the package of the above version to appear there. So if you're running sarge, have an electronic ID card and a smartcard reader, and want to see what the government knows about you, then go ahead and install them. More info on how that works can be found on the backports.org website. There are two known issues as of now: first, you may get wrong root certificate errors; second, you need to install all packages from the belpic source package, or some things may fail. I intend to properly fix these two bugs Real Soon Now(TM), but I'm having issues reproducing the first one and am trying to wrap my head around being policy-compliant and produce working packages at the same time, which is required to fix the second one. It's slightly ugly; believe me, you don't want to hear the details. Speaking of ugly, SCons is not ugly. It's downright hideous. I'll have autotools any day. If you're not running sarge but are using Ubuntu 6.06 'Dapper Drake', then you will need different backports. Luc Stroobant was kind enough to provide them; use deb http://www.stroobant.be/eid ./ in your sources.list to get them. [1] they are not many, but I managed to break my upload three times or so before it actually worked. And since I don't know about any status page or so, I needed to ask people every time—which I don't want to overdo, so I give them a while before investigating. Next time I probably won't...

For a long time I've enjoyed reading books by David Brin. Not only does he have some good sci-fi ideas and a good writing style, but he's also a cool guy when you meet him at a signing. One of the core concepts in a number of his books is the idea of uplift, whereby advanced races use a combination of breeding programs and genetic manipulation to raise animals to a similar level to humans in terms of intelligence and ability to use tools.

I believe that it's a necessary step in the development of the human species to encounter other species as equals. It seems obvious that a person who was raised in isolation would not be able to reach their full potential (there are many examples of children being abandoned and living with animals, the results are not positive). It also seems obvious to me that a species that is raised in isolation without interacting with other equal species will also be unable to reach their full potential. I believe that the human race needs to meet with another species of an equal level as the next stage in the development of our civilization.

Given the lack of success of SETI programs it seems that uplifting a species such as dogs, monkeys, or dolphins is likely to give better results in this regard than trying to contact non-human intelligent creatures.

Dogs might be a good first choice for uplift because they are well domesticated, this means that you are permitted to own them in residential areas without a license and there are good veterinary services for them. A possible way of starting an uplift program would be for people around the world to buy dogs of some particular breeds and then measure them by some objective scales. There are intelligence tests for animals that could be applied to dogs, the ones that get the best scores would be permitted to breed. Also we would want to breed them for communication ability (the ability to talk) and dexterity (evolve their toes into fingers). The statistics of the dogs and their lineage (don't want in-bred dogs) could be stored in a database and the breeding program could be done in an open-source manner over the net.

Most domesticated dogs are in-bred to some degree so we would want to cross-breed them to some extent. Poodles are reasonably intelligent and live for a long time so may be good for a start to this program, also blue-heelers, terriers, and labradors are reasonably smart and could be included.

Or, BEID of the same version. Oh well. It took me a while, but I finally managed to jump through all the hoops[1] required by backports.org correctly and in the right order for the package of the above version to appear there. So if you're running sarge, have an electronic ID card and a smartcard reader, and want to see what the government knows about you, then go ahead and install them. More info on how that works can be found on the backports.org website. There are two known issues as of now: first, you may get wrong root certificate errors; second, you need to install all packages from the belpic source package, or some things may fail. I intend to properly fix these two bugs Real Soon Now(TM), but I'm having issues reproducing the first one and am trying to wrap my head around being policy-compliant and produce working packages at the same time. It's slightly ugly; believe me, you don't want to hear the details. Speaking of ugly, SCons is not ugly. It's downright hideous. I'll have autotools any day. If you're not running sarge but are using Ubuntu 6.06 'Dapper Drake', then you will need different backports. Luc Stroobant was kind enough to provide them; use deb http://www.stroobant.be/eid ./ in your sources.list to get them.

I'm still browsing around (Google doesn't want you to google for such things, but "search", remember?) for a laptop to buy next, when my thinkpad finally dies (or I need to be mobile again, which might be in some weeks). I've found another wishlist candidate: the Panasonic Toughbook T4. It's small and tiny, extremely solid, it needs no fan, has a touchscreen (and you can carry it book-like, since it's light and comes with a hand strap) and extreme battery life. Apparently it does actually run over 9 hours in third party benchmarks. But it also has some drawbacks:
There are next to no reviews, especially no information on Linux compatibility (which shouldn't be an issue, embedded Intel graphics, and very little hardware in it, but e.g. the touchscreen might or might not work) - and it's not very widely used or known. It's also very expensive (Thinkpad X60 1500 Euro, Toughbook T4: 2500 Euro with the two big plusses for me being better battery life and the touchscreen, thats too much) and said to be quite ugly. I sent an inquiry if there will be a successor with maybe a Core CPU - I don't know if there is an ultra low voltage core - or if there will be a version without windows (it's expensive enough, I'm going to use Linux, I don't want to pay 200 Euros for Windows). I got a quick reply - that my questions will be answered when a certain colleque is back from vacation... This probably means that despite me loving the idea of being able to read papers on the laptop just like with a real book (with a pen, and as mobile), another candidate has dropped off my list... Guess I won't be buying a new laptop until my old one is completely dead and then I'll be going for something used and cheap as "temporary" solution... I guess I'll browse the web for the HP tc4400 and Toshiba M400 next. I didn't actually intend to go for a tablet PC, but apparently these are more designed for weight and power consumption than regular notebooks with their nvidia and ATI power wasters. P.S. Yes, I am aware of Thinkpads. But they are either to heavy for my liking, have too bad battery performance or have too low screen resolution (X series).

Over the past three years, my girlfriend's computer has been running slower and slower. This isn't a huge surprise, as it's running Windows XP, which seemingly becomes bloated as time passes. Thus, it came time for a reinstall, or at least some major clean up.

First, she backed up all her files, and checked there was nothing else needed. She found the original software that came with the laptop, and gave them, an d the laptop itself to me. It didn't come with a Windows XP cd, but being a Toshiba laptop, from PC World, it has a 'System Recovery' CD. So, I duly inserted that, and started the full install. After about an hour, the system rebooted into Win98. I wasn't happy.

This computer has a valid WinXP product key on the base, so I decided to find my own media and install using that. After finally getting hold of a copy, I install, and it states that the product key is invalid when I try and activate windows. I decide that something must be wrong, as it's on a sticker on the bottom of the laptop, so call Microsoft. Microsoft then nicely tell me that the product key is indeed valid, and if the installer isn't accepting it, I should contact the people I bought it from.
For the benefit of non-uk readers, PC World are the lowest of the low (IMO) when it comes to computer services. They really do not know their arse from their elbow. I will not be calling them, as they want to charge £1 per minute to talk to me about fixing their fuckup. Which they won't do, because this is out of warranty. I've been through this before.

So, despite this computer having a LEGAL licence for Windows XP, it now is happily running an ILLEGAL copy of Windows 2000 Pro.

If anyone from PC World, Microsoft or Toshiba read this: congratulations for making the installation of Windows XP so hard to illegally install that legal licences don't work.

This blog should serve both as a reminder of the planned BSPs around the world the upcoming weekends and as a proposal for some tasks to tackle then. At this point there are two “real-life” BSPs planned for this weekend, 08th-10th September in Vienna (Austria) and Z rich (Switzerland) and another two BSPs planned for the weekend 15th-17th September in J lich (Germany) and San Cristoba (Venezula). If you would like to attend one of these parties, you can find additional links regarding these events here. First a few necessary words on coordination: #debian-bugs on irc.debian.org will be the main channel for overall coordination. Do not hesitate to ask there before tackling any task; there will certainly be people available that can advise against tackling problematic tasks or tasks already worked on, and give general advice. When working on specific bugs, please claim them or let a DD claim them for you. See also here for list of claims. Tasks that can not be expressed by a claim but are big enough to warrant a notice for others should be noted on http://wiki.debian.org/OngoingBSP or pages linked from there. There should be plenty of bugs for all levels of complexity, programming language or legal skills and time requirements. So if you never attended to a BSP before and want to help, now is the right time to start. The RC Bug Squashing HOWTO by Steve Langasek gives a good introduction and is probably a must-read for beginners. But don’t hesitate to ask questions in #debian-bugs, we will be eager to help you to do some work. Non-DDs can also easily contribute by creating patches and/or testing existing ones. Just send them to the related bug report, a DD can easily pick it up from there. See also the end of this mail for a list of useful links. Procedures:
During the BSPs we should use a 0-Day NMU policy again, that means uploads that fix RC bugs that are more than a week old can be uploaded directly. If you feel unsure about a patch and/or if the patch is rather invasive, please consider asking on #debian-bugs for review and/or giving the maintainer some time to react by uploading to the DELAYED queue. If you are unsure whether your package upload might break an ongoing transition, PLEASE speak up on #debian-release and ask for advice there. Help Etch forward:

• RC-Bugfixing. One way to help is fixing release critical bugs. Here you can find a list of RC bugs affecting Etch.
• Test the installer. d-i beta3 was just released recently and should be tested by many people to help the people working on it judge whether it is a worthy release candidate (they sure hope it is See the Debian Installer Website for more information on how to get it, known issues, etc.
• Test Sarge->Etch upgrades. This is particularly useful with “real” systems since you might notice problems that will never occur in more or less clean chroots (hint: there is no one saying you can’t use a copy of your real system
• Verify Release Goals. As one of our major release goals is pervasive IPv6 support, all network related applications should be able to work with both, IPv4 and IPv6. If you have the possibility to do so, please test IPv6 integration in all packages you use and report bugs to the BTS or even better, fix them.
• Translate. There are quite a few .pot files out there waiting for you. Debian’s l10n website is a good starting point. (If you’re new to l10n and/or new to l10n in Debian, try to find someone at your BSP or on IRC to guide you through the first steps. This helps avoid wasted effort and frustration.)
• Fix bugs in orphaned packages. In the list of packages maintained by the QA Group you can find all bugs in orphaned packages, free to be squashed by anyone.
• Fix bugs tagged “help”. This this list.
• Fix bugs in your own packages and in packages you often use. Also help on reproducing bugs, if there are unreproducible.

I personally will attend the BSP in J lich and hope to see many of you during that weekend there or on IRC. Community

Simon has a similar view of the situation. With the stuff I proposed in my last entry and earlier (e.g. bug masters) - I'm well aware that this means someone needs to write a lot of infrastructure code. But given recent improvements e.g. on our bug tracking (user tags, subscription, version tracking) this seems to be working okay. I've never really used launchpad, so I can't comment on what it offers that we might need and where it sucks. And I've said a dozen of times that I hate bugzilla. Next I'm usually hard to convince that any "infrastructure improvement" will help solving "social" issues. But here it might, if it "weakens" the formal DDs power (isn't god on how the software is packaged and on how patches come in) and strengthens the "occasional contributor" (pending patches repository, DDs can easily approve patches and trigger an upload without being deeply involved with the package, since NMUs are easier to do). And I'm also aware that my point of view isn't consequent. On one hand I'm convinced that any big "steering" won't work anyway, and those who do the job (read: write the code, write patches) will largely be those who set the direction. Linus didn't just pick a VCS and decide that everyone will have to use it, but actually wrote his own to suit his needs. And others liked it, picked it up, improved it. On the other hand I'm asking people to use packaging practises that allow others to easily contribute. I almost suggested to make it policy to use debhelper and CDBS... Well, it's one of the things I've learned myself: make it easy for others to contribute - and you'll enjoy it more, because more people will contribute. If it's hard to contribute, people will complain, will file bugs, will argue. If it's easy to contribute, they are more likely to send patches and enhancements. Read: more fun. It's also one of the reasons I blame for my SELinux work being not too rewarding: it's hard to get going, it's hard to contribute (well, that has improved with the public readable SVN repository for the policy). Less people, less contributions, less fun. Anyway, I don't see the need for any steering or "global picture". We're not lacking the big goals, but the low-level fun at development. That doesn't mean I'm strongly "opposed" to the commitee. I just don't see the benefits (but certain costs for electing it. Do we take group applications and vote among groups? Then we could just have the DPL nominate the steering comitee. Or will we vote on individuals, with the top n becoming the board? Then we'll have lots of platforms to read (=boring, not fun), and we'll probably have the same problems at a different level, different opinions in the board. And, given that the DPL has no real power, will the board have any? We also have a technical comittee. Does it have any power (well, it's supposed to, but was it ever enforced)? Did anyone ask it about something recently?

My father was not a typical family father. While we were children, he did not much of the things from the father stereotype, like playing in the garden every saturday afternoon. Instead, he did show us in an indirect but even more effective way what he considered some of the most important values of live: Constantly aiming for perfection, selflessly offering help to whoever needs it, and being humble. These three key values did determine his acting thoroughly, but they also determine what I am, what I will be and hopefully also what I will have been when I am not anymore. Today, my father decided to leave this world by his own will. I am already missing him, although I never missed him before...

Debian has always defined itself as "the universal operating system", which to me means that, given two options A and B, each with their own advantages and disadvantages, we will incorporate them both, because there are people for whom A is better, and people for whom B is better. This is one of Debian's greatest strengths, and this is what makes it the "universal" distribution. Now there has been discussion lately about whether Debian needs some sort of central authority to pull the project into a certain direction. The thing is, while everyone seems to agree that we lack direction, we cannot disagree more on which direction it would be if we had one. At present, we have a number of groups pulling in different directions:

The "release" group

Debian's primary goal is/should be to make stable releases. In the time between releases, people should run the release candidate and iron out bugs, so we can release faster; new features are to be added only right after a release.

The "usability" group

Debian does not have any use if we do not support every user. As the admin users can already help themselves, we should focus more on the average user and make the system more simple to use and administer. Integration is a must, as is closed-source firmware.

The "hacker" group

Debian's purpose is essentially to give us a distribution we can use for ourselves, where all the tools that exist are there.

The "freedom" group

Debian is supposed to be only free software so I don't accidentally come into a situation where I'm in breach of a license.

The "large installations" group

It should be as easy as possible to deploy Debian to a set of boxes and remotely administer them. It should be easy to install the software the users need and to customize it for our organization. Users are not supposed to administer machines, and non-free software and drivers need to be clearly marked and easily avoidable so as to not put us at legal risk.

The "supermarket" group

Debian is a repository of packages that makes our lives easier when we build either a system or a distribution, but we don't really care whether stuff is integrated already, because in order to feel comfortable with it, we need to redo it anyway.

The "small but beautiful" group

The system should be as modular as possible, allowing me to leave stuff out that I don't need. I don't mind installing stuff later on.

There are others, and I have represented each only with their most extreme positions. These groups are not usually disjunct, and in some places, some groups share goals. But, for example the "usability" group and the "small but beautiful" group will always disagree on what should be in a base installation. All of this is not new. What is new is that people are asking for a strong leader to strike down the unbelievers rather than discussing stuff on the mailing lists. This is generally a thing I wouldn't like to see happen in Debian, because anyone you pull into the discussion is either uninformed (so not qualified to answer) or already has an opinion (which will most likely conflict with either party's opinion). By forcing a decision, you essentially give one party the right to dismiss arguments with "we've already had this, it has been decided" and do not solve the problem at all, because the other party is still unhappy. You might want to argue that a committee evens things out a bit as more groups are represented there. That is true to a certain extent, however you'd have to have a way to determine who gets to be on the committee, and to do so in a manner that noone is left out (even if there are new groups forming all of the time) and without giving any group too much power. We might just include everybody, which brings us to status quo, except that everyone got a job title now and people might feel more inclined to decide things by majority vote (because that is what committees do after debating, right) instead of based on actual merit. Scott writes that implementing the same thing he just did in Ubuntu would have taken him ages to do in Debian because there are so many more people to coordinate in Debian. I have to disagree here, the number of people to coordinate is probably the same if not higher, except that the Ubuntu model seems to be that every core team member has commit access and is supposed to read up on the changelog when touching a package, making the coordination more implicit. I happily give out Ubuntu CDs, which do have non-free drivers, firmware and documentation, to users. Telling them that they cannot use that driver or have a manual because it's not free will not help anyone, and it is unlikely that they will be taken to court over it. This is all fine and dandy considering Ubuntu's target audience. However, Debian has a much larger target audience, including Ubuntu itself. If Debian were to interpret licenses less strict for some perceived benefit for the users (cdrecord springs to mind here), then all derivers, including Ubuntu, would have to carefully cross-check all of the licenses for possible violations. Thus, I oppose GFDL documentation in Debian main, because when we say "our priorities are our users and free software", that includes all of our users, not just end users. So, what I ask of you people reading this via Planet Debian is the following: Ask your "opponent" whether he'd be interested in finding a common solution that fits both use cases. Present it as a technical challenge. Accept that the outcome of such an endeavour might be that the other person is right. Accept that not everyone shares your views and/or priorities. It is hard to accept for me that a lot of people still think that svn is superior to git, or emacs is superior to vi. So if you have a different opinion on some matter, keep in mind that the other person may be looking at things from a different angle, where his choice is the only "logical" choice. Oh, and that goes for both of you. To conclude: Debian's strength is its lack of a clear direction. If we were to decide that the end users are what matters, we'd become another Ubuntu, which would be quite unnecessary because we already have one, and they are pretty good at being Ubuntu. If we decided only releases mattered, we'd probably release more often, but right after a release, unstable would be really broken (the elders might remember how it was before the "testing" distribution was introduced). In the same way, the release team takes care to include your pet project in the release if at all possible. Every package that is added delays the release because they have to wait for autobuilders and make sure that everything is internally consistent. So, they are already respecting your goals. Are you going to respect theirs, and join the release effort even if all your machines run unstable? So in my opinion it is a good thing that we did not decide on a direction, because there is no right one. We'd always leave some people behind if we had to make a choice. What needs to change is our attitude that software is to be used in one particular way, because the people actually using it would disagree. After all, free software is (also) about being able to do things your own way, and Debian as a whole should be supportive of that.

Some Debian developers have finally decided that it's time to get things done and solve the trouble around cdrecord. They've taken the last version that was released really free and used it as basis for their own forked project. For years there has been discussions with the author of cdrecord and current upstream maintainer of the cdrtools package that lead to nowhere. Debian's stance on software in main is that the software and its build system, which usually contains of scripts written in different languages (shell, perl, make), need to be sufficiently free (i.e. compliant with the DFSG). Introducing a build system released under a license which is said to be not compatible with the GNU GPL and which Debian developers consider problematic with regards to the DFSG was not exactly helpful. Other GNU/Linux distributions also had problems with recent versions of cdrtools, some of them were still using older versions to bypass avoid problems. In the end this new project seems to be the only path out of this dilemma of disagreements over licenses. Hopefully, other vendors will join the effort so that they can benefit from the fork earlier and more easily, and also contribute code on their own. Whether or not it'll be accepted and used, the future will tell.

I recently wrote two two new Perl modules. The first is called Linux::Sysfs and is a library binding for libsysfs. It offers a convenient interface to sysfs (/sys). After releasing the first version of it for peer review and, later on, to CPAN, I received a lot of reports about test failures because of a missing or outdated libsysfs. Therefor I wished to have something like GNU autoconf for Perl modules. It would be possible to write something similar in pure Perl (someone actually tried it: Config::Autoconf), but compiling C programs from Perl in a portable way isn't much fun. Therefor I decided to write some Perl glue around autoconf and autoheader so those tools are easy to use from Makefile.PLs and such. I did so and the result is ExtUtils::Autoconf. It'll be on CPAN within the next few hours. Until then the current version is available from here. It currently has some documentation about using it from an ExtUtils::MakeMaker-based Makefile.PL. Instructions about how to use it with Module::Build and Module::Install are still missing. The Module::Install part will be done by an extension called Module::Install::Autoconf, which I'm currently about to write. For the Module::Build part I don't really have an Idea on how to do that, so any help from some Module::Build people would be very appreciated.