During Debconf5, I voiced the opinion that all Debian packages with a priority Standard or higher, as well as packages with a high Popularity Contest rating and development packages with a priority Optional or Extra that many people rely upon for development work, ought to be team-maintained as a matter of Policy. I justified this by pointing out that Debian's Social Contract puts our users among our key priorities, which implies that keeping the packages that our users value the most in excellent shape ought to be the embodiment of this value, and that the best way of meeting this goal is to enforce a policy of team maintenance and easy NMU for those packages. While my own packages are rather modest contributions to Debian's pool and few of them rate anywhere close to the top in popularity, I honestly feel like practicing what I preach is the best example I could give. Another reason is that several business ideas that I'm working on are monopolizing my time, which means that I'm not as available as I would like to be to participate in Debian. I however see this situation as only temporary, which is why I have not orphaned my packages. Instead, I am soliciting Debian Developers to come as co-maintainers. Interested parties should check my QA page for packages that might interest them and contact me for details. Thanks! PS: in case this wasn't obvious, the whole point of enforcing team maintenance and allowing NMU on non-RC but annoying bugs is to avoid unresponsive lone wolf maintainers who let tons of bug reports pile up on their packages without fixing them or even acknowledging them. Ubuntu avoids this by allowing anyone on their development team to chip in, while Debian still clings on to each maintainer's absolute reign over their packages, which leaves users of neglected packages completely in the dust.

To a certain extend, SELinux is like TPM. On one hand, it can be used to increase security of your system a lot. On the other hand, it can be used to lock you out some more. Like from your Linux-running Motorola phone. (Note: this phone is not running SELinux, but some other LSM) The combination of both of course increases security even more. I was wondering if I should maybe starting using these on the next server I install. Make a mini boot system with an SSHD and use the TPM module to secure this boot system. Then whenever the system is booted, I connect via SSH to type in the passphrase to unlock the encrypted disks. So when some police decides to seize a TOR server, they'll not be able to read any of the data, even when they seize the complete hardware. The only attack vector (apart from breaking crypto) I see is that they use the TPM to decrypt the boot systems sshd key, and then setup a modified boot system to capture my passphrase. They'll probably need more time to set that up than me to be informed the server was seized (or wonder why it's down). They're not exactly prepared for such defensive measures, I guess. OTOH, I'm not planning to setup any server anytime soon, and for a laptop using an encrypted harddrive should be enough. Maybe add some extra SELinux policy to defend against software bugs and maybe keyloggers. Uwe Hermann just measured the overhead and to me this doesn't look very bad. I mean... it will still be much faster than my current laptop, and this laptop is fast enough for me 99.9% of the time.

Yesterday was my turn as "primary care giver" (PCG) with Amita June, so I took the opportunity to do some shopping. I was on Autoroute 40 on my way out to the Ikea on rue Cavendish around 1PM when they had a breaking bulletin on the CBC. Yes, the Dawson C gep shooting -- they were sending a reporter to the scene. For those of you outside Montreal, yes, I and my family are fine, and we don't have any friends who were affected by the shooting. It's been strange in town, but we're physically safe and sound. Thanks to everyone who's asked. tags: montreal dawson shooting

Piknic Electronik On a more cheery note, this upcoming Sunday is the last Piknic Electronik for 2006. The last picnik is always quite sweet, and as usual Ninja Tune will be closing out the season. Smart, fun Kid Koala and, my personal fave, Ghostbeard, are on the lineup. Should be a great time, and it's supposed to be sunny on Sunday, so a nice day to be in Parc Jean Drapeau. tags: piknic electronik ninjatune montreal music

Ignition 2006 Burning Man just finished up last week, and here in Montreal the local Burning Man community is having a campout and bonfire to celebrate. The so-called "regional burn", called Ignition, is going to happen 22-24 September in the wt:Eastern Townships; more info on the Br leurs wiki. Maj and I are the regional coordinators for Burning Man activities, and we've been busy the last few weeks lining up the basics (tickets, toilets, insurance... check, check, check). Now we're looking forward to seeing what folks will be doing this time around. Our local Burning Man community is fabuloso -- the people are extra cool. tags: burning man montreal regional burn bruleurs ignition

Just a quick update for SELinux in etch. With Manoj picking up work on it again (you might have noticed the large influx of new SELinux related packages these days, bringing our toolchain up to date again), and rjc having setup a SELinux development box for me, we're actually making some progress on SELinux for etch now. Uwe Hermann also blogged about SELinux on Debian recently. There are tons of small nuisances with SELinux on Debian left. I've started filing bugs and tagging them with the "selinux" usertag. It's in the details. For example mawk and gawk both try to ioctl any file they read as if it were a serial terminal. Which of course causes SELinux to log an audit error, since the init script or whichever was calling awk didn't have the permissions to ioctl a config file. Then there is /dev/xconsole - it's created by the syslogd init script (shouldn't maybe this be handled by udev), it's barely used by anyone, and SELinux policy upstream wants to keep it in the xserver policy, and claims its main use is to be able to feed it the output from programs started by the window manager (instead of .xsession-errors). Which is a seriously broken design, since it's not multiuser capable. Anyway, our current options are to

• diverge from upstream in policy, putting xconsole into logging policy
• make xserver an mandatory policy module
• convince the syslogd maintainer to disable xconsole by default
• convince upstream to at least split it out from the xserver module into a separate xconsole module and make that mandatory

Of course I was quickly flamed for filing a bug against exim stating that there currently is no SELinux policy for it, and people thus will have to use postfix or sendmail instead. But heck: people trying out SELinux on Debian will run into this problem, you know. I'd certainly prefer people to use exim instead of sendmail (I'm more of a postfix guy), but unless someone writes a policy for exim, people can't use it with SELinux. I have no idea how exim works (where its queues live, expected behaviour and so on), so I can't write a policy. Now to start a real flamewar - how about making postfix the new default MTA for Debian with etch? /me runs and hides.

Whew. Ichthux has released, and now I can breathe again! When I joined the Ichthux development team, they had produced their “proof of concept” release as yet-another-Knoppix-remaster. At that time, I encouraged them to move away from tacking their work on as a derivate of a derivative and instead become a CDD. I argued that as a CDD Ichthux would last, while as a Knoppix-remaster, it would just be another marginal custom livecd that went nowhere. They got the message. So you may well be surprised to hear our first release is based on Kubuntu, and not Debian.

So, what’s the story here? Have you defected?

Nope. It just happens that most of the team ended up being actively involved in Ubuntu development. Also, when we first started casting about for the best way to package a livecd/install disk, it seemed to us that Ubuntu already had a head start on this.

What about being a CDD? It looks to me like that idea has fallen by the wayside.

Nope again. We’re a joint team now, and though we’ve started out with Ubuntu, we’ll be pushing changes back into Debian. The goals of a CDD are well understood by the whole team: to best meet the needs of our users, we design the system to mesh well with the parent distributions, not forking and making a derivative, but working inside those distributions to improve them for our particular subgroup of users.

Hold on now, aren’t you contradicting yourself? A CDD’s development is all within Debian, but Ubuntu itself is a derivative, and what’s worse, Kubuntu is a derivative of a derivative! Aren’t you right back where you started?

Well, on the last count, you’d be wrong. Kubuntu is not a fork. And as for Ubuntu being a derivative, well, sure it is. But the Ubuntu/Debian relationship is different from other derivatives, and although there is friction, I’m enough of a crazy idealist to believe a joint Debian/Ubuntu CDD is quite doable, benefits both projects more, and serves our users better than if we were to split up and each go work on our own.

I'm delighted to announce that registration is open for XTech WebDev London. This is a one-day training event for web developers, to be held on 31 October 2006. Our first event covers web standards, Ajax, REST and Rails, with a super-duper keynote from Tom Coates of Yahoo! You can find out more about the event on its website: speakers, schedule and benefits. What I want to do here is talk a bit about the backstory of XTech WebDev. I've been chairing the XTech web technologies conference, and before that, XML Europe, for five years. If you've ever been, you'll know it's an intense four days where the latest web and standards-based technologies are discussed. We typically hold the show in a European capital: we'll be in Paris in 2007. However, the full XTech show can be out of scope either in expense, location or duration for many. So, the idea for XTech WebDev was born. Take some of the best speakers and experience from the XTech conference, figure out what's most relevant to web developers at the coalface, and create a one-day event that's easy to get to and at the right cost. For our first event, we're featuring standards-based development, best practices for Ajax development, the REST style of developing web services, and Ruby on Rails. Along with that we'll have a keynote from Tom Coates challenging the way we think about our web applications. What we're aiming for is a convenient orientation day for web developers, which will enable you get a fix on the most important trends in web development happening right now. Although we'll be in London, we're not starting until 10am, which should leave plenty of time for people coming from further afar to be able to do the show in a day trip. I reckon it should be possible from as far away as Paris or Amsterdam, and even the north of England.... Registration is 275 if you sign up before 23 September, and space is limited, so be sure to sign up you and your team quickly. I really appreciate everybody's support as we branch out into this new event, and welcome all and any feedback and requests for future events.

After a recent kernel upgrade (from a custom package to the default Debian kernel package), I noticed that printing stopped working. Reason for this is that powerpc kernels don't have support for parallel ports included, because loading that module might freeze some pmacs. (Support for that has been activated now for some powerpc variants, but as there is no new kernel uploaded yet, that doesn't really help me.) So, I tried building my own kernel again. But then something happened I definitly don't want to see at all:

  CC [M]  drivers/net/e1000/e1000_main.o
  drivers/net/e1000/e1000_main.c: In function  e1000_xmit_frame':
  drivers/net/e1000/e1000_main.c:2919: internal compiler error: in simplify_subreg, at simplify-rtx.c:2368
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See <URL:http://gcc.gnu.org/bugs.html> for instructions.
  For Debian GNU/Linux specific bug reporting instructions, see
  <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>.
  make[4]: *** [drivers/net/e1000/e1000_main.o] Error 1
  make[3]: *** [drivers/net/e1000] Error 2
  make[2]: *** [drivers/net] Error 2
  make[1]: *** [drivers] Error 2
  make[1]: Leaving directory  /usr/src/linux-source-2.6.17'
  make: *** [debian/stamp-build-kernel] Error 2

So I not only lost support for my printer up to now, but even waste more time debugging stuff I don't want to see.

Development Environment Conference(Japanese) was held in Akihabara, 8 Sep. The event was focused for that the famous geeks use what kind of tools, software configuration, or environment. Many people were using zsh, GNU screen, and vim or Emacs. In the event, I really surprised a man who use GNU screen with default prefix key!

Tenho aqui comigo um o in cio de um texto antigo, que comecei a escrever h uns dois anos atr s, sobre porque eu uso Debian. Nunca consegui finaliz -lo direito, mas achei que n o seria justo deix -lo aqui jogado em um diret rio empoeirado de meu HD (meu ~/txt tem muita coisa iniciada e n o finalizada). Um dia ainda vou termin -lo e acrescentar mais conte do, s preciso estar num dia inspirado para tirar todas as id ias da cabe a e coloc -las na forma de palavras. De qualquer forma, mesmo inacabado, espero que gostem. E lembrem-se : meu blog aceita coment rios

Por qu Debian ? Eu tamb m ou o esta pergunta quase diariamente. Para que eu n o tenha que respond -la novamente a toda vez que me perguntem, resolvi sentar e escrever uma resposta padr o para a mesma. Assim, toda vez que algu m me faz esta mesma pergunta novamente, eu simplesmente pe o para a pessoa ler este texto. Aspectos t cnicos Qualidade. Sim, qualidade. Erroneamente, a maioria das pessoas que n o utilizam Debian ou que n o o conhecem pensam que o grande motivo pelo qual o Debian se diferencia das outras distribui es GNU/Linux puramente pela exist ncia da ferramenta APT, a qual auxilia na resolu o autom tica de depend ncias, facilitando enormente o gerenciamento de softwares. Realmente, trata-se de uma ferramenta extremamente til. Por m, atualmente, diversas distribui es GNU/Linu baseadas em pacotes no formato RPM (Red Hat, Fedora, Mandriva, etc) utilizam por padr o ou suportam, mesmo que n o oficialmente, mecanismos de resolu o autom tica de depend ncias e gerenciamento de softwares similares ao APT. Algumas at mesmo utilizam um porte do pr prio APT, adaptado para funcionamento com pacotes no formato
RPM. O que diferencia o Debian das demais distribui es GNU/Linux a qualidade. O apt-get a parte vis vel qual o usu rio tem acesso e que parece fazer toda a m gica. Por m, por atr s dele, existe um componente fundamental, frequentemente esquecido pelos usu rios : a pol tica de empacotamento de softwares Debian. O projeto Debian possui um documento extenso e altamente detalhado, que descreve, em cada m nimo detalhe, ao que um pacote de software precisa estar atento para poder ser considerado um pacote oficial e fazer parte da distribui o. A pol tica de empacotamento de softwares o que faz com que o Debian seja altamente superior s outras distribui es. Ela bem definida, clara e aplicada rigorosamente. Ferramentas de apoio aos desenvolvedores auxiliam a refor ar a aplica o das regras ditadas pela pol tica e qualquer pacote de software que n o siga fielmente o que dita o Manual de Pol ticas Debian n o inclu do em uma vers o oficial da distribui o, n o importando o qu o importante seja o componente de software fornecido pelo pacote. Isso, somado s diversas equipes internas existentes dentro do projeto Debian, garante a qualidade da distribui o. Equipes de QA (Quality Assurance), de seguran a, de ger ncia de release, ger ncia de relatos de erros e diversas outras equipes garantem que um sistema operacional funcional e altamente integrado seja criado, em oposi o a mera corre o de problemas em pacotes de softwares isolados. Adicionalmente, cada software passa por um intenso processo de avalia o antes que possa ser aceito oficialmente e adicionado a distribui o. Al m dos in meros detalhes t cnicos, tamb m existe uma equipe de especialistas legais que analisam as licen as de distribui o dos softwares antes de aceit -los como parte da distribui o. O fato do Debian ser atualmente a distribui o GNU/Linux que suporta a maior quantidade de arquiteturas de hardware que o kernel Linux suporta tamb m adiciona qualidade distribui o, uma vez que, como parte do processo de porte das aplica es para uma arquitetura de hardware suportada pelo Debian, in meras falhas s o descobertas e corrigidas, o que contribui
para a qualidade final do software. Logicamente, some a isso tudo o fato do projeto Debian possuir o maior acervo de softwares livres empacotados e prontos para uso existente da atualidade, deixando para tr s todas as outras distribui es GNU/Linux, inclusive as distribui es comerciais. Atualmente, s o mais de 15.000 pacotes de softwares prontos para uso e facilmente instal veis. Aspectos estrat gicos (ou independ ncia tecn logica) Uma das grandes vantagens estrat gicas que se ganha ao utilizar Debian a independ ncia tecnol gica. L gico, a grande maioria das distribui es GNU/Linux atuais s o livres, mas nada garante que continuar o a ser livres por toda sua exist ncia. Claro, sempre existir o grupos de pessoas dispostos a iniciar uma nova distribui o com base em uma vers o livre existente de uma distribui o comercial caso algo aconte a com a empresa que a desenvolveu e que impossibilite a continuidade da distribui o. Mas criar uma comunidade e manter um projeto grande como o de uma distribui o GNU/Linux, com toda a infraestrutura j fornecida pelo projeto Debian, leva tempo, anos. E consome anos de trabalho de milhares de volunt rios. O projeto Debian j tem tudo isso funcionando e uma experi ncia de 13 anos nessa rea. Exemplos de problemas com o envolvimento de interesses privados de empresas no desenvolvimento de distribui es GNU/Linux n o s o somente te ricos e recentemente tivemos provas da exist ncia dos mesmos, com empresas privadas terminando a continuidade do acesso a atualiza es de seguran as para suas distribui es de uso livre e sem custo e, em
muitos casos, praticamente obrigando seus usu rios a migrarem para vers es comerciais de suas distribui es. O projeto Debian criou o Contrato Social Debian. O item n mero 1 desse contrato social diz que o Debian ir sempre permanecer composto de 100% software livre. De igual import ncia, o item n mero 4 desse mesmo documento diz que a prioridade do projeto Debian ser sempre seus usu rios e o software livre, o que, na pr tica, garante que interesses comerciais n o ser o colocados em primeiro plano e que os usu rios n o ser o for ados a migrarem para vers es comerciais da distribui o em momento algum. A Defini o Debian de Software Livre, mais um documento produzido pelo projeto Debian, possui grande import ncia na comunidade de software livre, tendo sido utilizado como base para a cria o do Defini o de C digo Aberto (Open Sorce), a qual individuais e empresas aderentes ao modelo de desenvolvimento aberto de software usam como base para cria o de licen as de softwares que os qualifiquem como software aberto (Open Source).

Ok, isso por enquanto. Um dia ainda termino e acrescento mais conte do. Quem quiser comentar e dar novas id ias, esteja a vontade, nos coment rios ou por e-mail.

David Cunliffe has just announced this morning that the Government has finally decided to approve 5 of the urban Broadband Challenge applications to build urban fibre networks. Hamilton is one of the accepted proposals, getting $3.3m of government funding to help cover the start-up costs of the network. Under the conditions of the Broadband Challenge the networks must be open access and provide a full duplex transfer rate of at least 1Gbps. Should be interesting to see how this develops! Press Releases:

• Ministry of Economic Development
• Hamilton City Council

We got back from Europe 36 hours ago, and I've spent most of the time sleeping. We'd had a pretty rough flight across the Atlantic -- although of the three of us the baby was the least grumpy. I'm a terrible jet-lag victim, though, and just a few hours of time change really messes with my wp:biorhythms. Yesterday was Amita June's first birthday, and although we were all tired we had a good time just the three of us. My parents, Maj's parents and our siblings all called, and we picked up a few presents that had been shipped here while we were gone. Amita got a trip to the toy store (net haul: 1 rubber ball, one Caillou book, one crapload of block toys) and a special breakfast. Sadly, she and her papa fell asleep together before she got her birthday dinner. We're having a birthday party at our house on Saturday, "from 3PM to bathtime". It should be a little more lively than our quiet day at home. tags: europe jetlag amitajune birthday

Malm I don't think I've posted anything in a little while, since before we went to wt:Malm . We had a really nice time while we were there. I had corresponded with Sean Finney, another Debian developer who lives in Malm , before we left for Europe, and he'd offered a meetup. We had a free day in wt:Copenhagen so I figured I'd take him up on the offer. Malm is only about 40 minutes from Copenhagen by train, so we were able to take a trip over quite easily. There's a beautiful bridge between wt:Zealand and wt:Scania which we crossed by train -- the water was beautiful. We managed to miss Sean at the train station -- I'd given some pretty tenuous instructions on how to meet us -- but we managed to get out and see the town a bit for ourselves. The old city has two squares -- the Stortorget or Big Square and Lille torg or Little Square -- right next to each other. The Lille torg is circled by restaurants and we had a decent lunch at a place called the Moose Bar -- Scandinavian staples like salmon with a Thai presentation. A good idea. Sean managed to catch us as we were walking around, so we had a nice coffee together at a caf on the main drag. He's been in Malm for more than a year, and is taking classes at nearby wt:Lund. We managed to exchange GPG key signature preliminaries (what Maj calls the "Debian butt-sniffing ceremony") and had a good time talking about the state of Debian and Free Software. We split up at the train station and Maj and I went off to explore the towns small castle. It has a number of museums, but it was late in the day on a Sunday, so we opted instead for a walk to the beach, looking out to the bridge and ultimately the skyline and wind turbines of Copenhagen. After a long walk circumnavigating Malm 's distinctive Twisted Tower, the tallest building in Sweden, we headed back to Copenhagen for a dinner at Tivoli Gardens (probably my favorite spot in Copenhagen). tags: copenhagen malm travel sean finney debian

Z rich We made a special stop on the way home to Montreal through wt:Zurich. We flew on Swiss Air, which has a hub in Zurich, and they gave us a free 24-hour layover in town. Fortunately for us, we got to spend some time with our good friends Mark Jaroski and Allegra Biava. They're friends of ours from SF who moved to Switzerland around the time Maj moved there, and they now live in wt:Lausanne. Both are extremely funny, intelligent and clued-in people. They were passing through Zurich on their way back to the US for a family visit there. I'm glad we got to see them, since I got to meet No ma, their 2-year-old daughter. No was born about 8 months after we last saw Mark and Allegra -- they weren't even telling people they were pregnant at the time. She's a barrel of laughs -- a real fun little person. She and Amita June got along great. We spent most of our time walking around central Zurich, seeing some of the sights and taking it easy. There's only so much tourism you can do with one toddler, and two toddlers raises the requirements considerably. I think the big downer for Zurich for me was how many people we didn't see. I'd hoped to connect with Alex Schroeder, founder of CommunityWiki, and also Martin Krafft, another fellow Debianista. Most disappointing, we missed Marco Prestipino, who's doing work at the University of Zurich in information transfer in online communities. tags: zurich mark allegra no ma

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.

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?

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.

It was inevitable, really... With the merger of the uClinux project's code into the official Linux kernel as of version 2.6, and the against-all-odds development of the EMILE boot loader, one might say this day was destined to come (I'd have more details from a mailing list, but unfortunately its archives appear to be broken). Laurent Vivier, I don't care what the Vancouver Prospectus has to say about your work — you rock. :-)

Short version first: those in Oldenburg who are expecting me to arrive at the Bremen airport on Friday afternoon, don't. Expect me on Saturday at 11:10 instead, assuming there are no further setbacks. I got to the Indy airport today in time for my flight, except my flight was going nowhere fast. "No problem," I thought to myself. "I have nearly a three-hour layover in Newark. They can dicker with this flight for quite some time, or I can get switched over to the flight on the commuter jet that Continental also has going to Newark this evening." Silly me. My flight has a "wing indicator light" problem — that's what the gate agents called it, shrewdly deducing that a pilot otherwise has no way of determining whether the lifting surfaces are still attached to the aircraft — that amazingly takes hours to resolve, and the other flight? Well, Continental's headquarters are in Houston, and apparently some of their employees startlingly decided to evacuate their families out of the expected path of Hurricane Rita instead of showing up to work in Indianapolis to be the flight crew. Or something like that. So instead of getting to switch over to the flight that would get me to Newark safely in time to catch my connecting flight to Paris, the airline shunts all those passengers onto my flight. So we take off about 3 hours and five minutes late, and when I land in Newark, there's nothing left of my flight to Paris but wing tip vortices spiraling out over the hypodermic-syringe-strewn New Jersey coast. Apparently airports both in the U.S. and Europe have a problem with flights leaving or arriving in the middle of the night, so the soonest I can leave for Europe is now 1845 on Friday. This means I'll miss nearly a full day of the conference, which I was only going to be at for 2.5 days anyway. Joy. Oh, and they also close down baggage claim at 11pm (or five minutes before you land, whichever comes first), so my checked bag which couldn't make the same flight I couldn't is now being held hostage somewhere in the bowels of Newark Airport while I sleep at the Howard Johnson's in a room that one dare not view in ultraviolet light. Well, technically, this hotel is joint venture with Holiday Inn, an enterprise which no doubt serves the sole purpose of frustrating class-action liability suits by people who contract scabies in the course of their stay. I don't even know if my beloved dismantled Quadra is in better accommodations, or if my machine, tortoise.deadbeast.net, stuffed into a suitcase and crudely protected with towels and masking tape, has been obliterated with patriotic fervor by the TSA, swinging their hammers to pulverize it. I guess I could be in worse places, like Galveston. Any DDs in New York wanna give me a wake-up call in the morning and meet for lunch? (I'm at +1 973 589 1000 x217.) If not, I was thinking I might try to go see the Statue of Liberty in the late morning. I've been in the NYC area twice before but never went to see it. Air travel sucks. Maybe this is the real reason, unadmitted to myself until now, that Contact resonates with me. I can almost forgive Robert Zemeckis for that brown smear he did with Tom Hanks three years before. Then I remember that other brown smear he did with Tom Hanks three years later. Okay, I won't blame Hurricane Rita or even Continental Airlines. I'll blame Robert Zemeckis instead. :-P I'm okay to go... I'm okay to go...

On Friday afternoon I'll be arriving in Oldenburg, Germany, for the eleventh annual Linux developers' conference. Historically, this conference has had a strong focus on non-x86 ports of the Linux kernel, boot loader development, the GNU toolchain, and so forth. At long last, it looks like this may be my opportunity to get my Macintosh Quadra 840AV out of mothballs and back into commission, thanks to Wouter Verhelst. I should be able to fit it into my luggage if I don't bring many clothes... :-) This year, however, in addition to that, a couple of mini-conferences are being piggybacked onto the Oldenburg meeting. These include the GNU Classpath and Debian Java DevJam and the Debian Security Summit. The Java programming language is a divisive issue in the Free Software community, and has a degree of controversy that sets it apart from the usual language wars. The dominant factor in this controversy stems from what Richard Stallman refers to as the Java trap; with the specifications controlled, and the reference implementation kept unavailable on DFSG-free terms by, an industry consortium dominated by large corporations, a Free Software hacker might fear that using Java will consign them to either having to compromise their principles by using non-free class libraries (for example), or being doomed to chase the taillights of standards that could conceivably be tailored to disadvantage competitors. (Java is not alone in this respect; many people fear that Microsoft's .NET, despite being openly standardized through ISO/IEC, will in actuality be completely controlled by Microsoft.) Despite this peril, Java is attractive to GNU/Linux-using organizations. The Free Standards Group, developers of the Linux Standard Base, has received inquiries about a Free Java standard and implementation from organizations already committed to GNU/Linux. In my job, I've encountered an interest in Java from several customers and prospects. Intriguingly, these institutions are, by and large, very much aware of the Java Trap. They like the language, and are not strong advocates of Free Software, but they too are worried about vendor lock-in. They've seen the success of community-driven development as GNU/Linux moves from strength to strength, claiming territory formerly held by Microsoft and proprietary versions of Unix. Even if I can't persuade a customer to adopt a Free Java stack, I can exhort them to only code against Java standards that have seen a free implementation. That way, their development bets are hedged against any "madman theory" of the controlling vendor. Furthermore, this way they only code to standards that are seeing independent implementations, and they leave their engineers free to switch between varieties of development kit. Engineers like flexibility because it enables them to work more efficiently; sales people, marketing personnel, and strategists like efficient engineers because they make a firm more nimble. That's where the GNU Classpath and Debian Java DevJam comes in. Free Software Java enthusiasts want to see their implementations fully mature, and are working hard to make it so. The Free Software community has the opportunity to make its Java implementation not just an available alternative, but a compelling alternative to the proprietary ones on technical as well as licensing grounds. The recent release of GNU Classpath 0.18 shows just how vigorously this opportunity is being seized. Having mature software is only half the battle, however; that software has to be coherently put together and easy for the user and developer to manipulate. For many of these folks, it's not enough just to have good, Free Java virtual machines (like Kaffe and SableVM), class libraries (GNU Classpath), compilers and interpreters (gcj and gij, respectively, from the GNU Compiler Collection), and application servers (Jakarta Tomcat, JBoss, and JOnAS, among others). They also want these technologies to be mutually integrated and easy to install and use. Good software and good packaging complement each other to drive adoption of the technology, and that's what the DevJam is all about. I'm glad to see that representatives of Debian's Java packaging team will be joining not just upstream authors, but their counterparts at Fedora, Ubuntu, and Gentoo in furtherance of this goal. I've approved a budget of EUR 2000, which Petter Reinholdtsen will administrate, to support the expenses of Debian's participation in the DevJam. We've received 1500 USD in sponsorship of this event from a corporate sponsor that chooses to remain anonymous. The other mini-conference I'll be attending is the Debian Security Summit. We're bringing together the heads of our Stable Security and Testing Security teams — the two Joeys, Joey Schulze and Joey Hess, as well as a bevy of other security-minded people, with the goal of revitalizing and streamlining our security processes. Several members of the Stable Security Team have gone dormant over the past several months (or longer), leaving an increasingly small number people to handle, as of Sarge's release, not one but two stable releases. This is because we do not terminate security support for our previous stable release (in this case, Woody), until some time has passed. We've had other challenges on the security front. We had what amounted to a security support hiatus for about three weeks in June, which caused much consternation. More recently, klecker.debian.org, which provides the security.debian.org has suffered some occasional availability problems, and it hasn't always been clear what's caused them. It's my understanding that we have new hardware in place that can serve in a backup, supplemental, or failover capacity. The general feeling at DebConf 5 was that our security apparatus was in need of attention to make sure it keep pace with the demands being placed on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and others over the past several weeks, and I look forward to a productive few days.