Happy New Year Everyone! Aside from taking some time off for the holidays, I set up a Debian-Sid USB stick in order to test gnupg version 2.1.16-3, the version to be included in Debian Stretch. For now, I m using the package rng-tools to speed up the key creation for the purpose of testing gpg commands. By running sudo rngd -r /dev/urandom before the gpg command, you can create the keys in about a second. Here are some of the sources that I ve been using that inform the workflow and secure practices for gpg that we ll be including in the Clean Room:

• The Project Wiki
• Offline GnuPG Master Key and Subkeys on YubiKey NEO Smartcard from Simon Joseffson s Blog. This is really helpful! I m adapting a lot of the workflow for gpg2.1.16.
• OpenPGP Best Practices
• Debian Wiki: Creating Subkeys
• Debian Wiki: Keysigning
• Smartcard Guide

Some feature suggestions that were made by Neal Walfield that could be included in the workflow:

1. Use a smartcard for the primary key and a smartcard for the subkeys
2. Support subkey rotation the creation of new subkeys
3. Upon finishing a session, write a script to the USB that sends mails with the signed keys and imports the user s public keys.

This year, Outreachy featured internships from organizations such as Debian, Fedora, GNOME, the Linux Kernel, Mozilla, Python, and Wikimedia, just to name a few. Each organization features mentored projects and in order to apply, applicants must contact the mentor, introduce themselves on the appropriate channels and make a small contribution to the project. After that, applicants might be required to fulfill additional tasks to demonstrate their abilities. Successful applicants will make quality contributions, communicate effectively with mentors, ask questions, fulfill tasks, help out their peers via mailing lists, and/or blog about their experience. One of the projects I applied to was the Clean Room for PGP and X.509 (PKI) Key Management. The project aims to create a Live Disc that enables users to create and manage their PGP keys easily and securely, using a text-based UI. I ve been a Debian user for about a year, but before applying to the project I didn t know much about GnuPG or public key encryption. Since then, I ve made some contributions and attended my first keysigning event in San Francisco featuring a lecture by Neal Walfield (more on that below). For my initial contribution, Daniel Pocock, the mentor for this project, asked that I write a script that lists the USB flash devices connected to the system and specifies which device the system booted from. Here s the bash script that I wrote, and that was enough to submit an application for Debian. My next task was to write a dns hook script for the dehydrated project, a shell client for signing certificates with Let s Encrypt (for free!). The script completes a dns challenge sent by the ACME-server by provisioning a TXT record for a given domain in order to prove ownership of the domain. I chose to write it in python and used the dnspython API. I posted my solution on github and there are many more here. At the lecture, Neal talked about good practices for key creation and management. Here are a few of those points:

• Don t store your master key locally
• Store your master key offline on a smartcard such as GnuK or NitroKey and store backups on a USB stick.
• Neal mentioned that the OpenPGP card is not open hardware and according to this recent post neither is the Yubikey
• To manage the key, use a dedicated offline computer such as a relatively cheap x40 or x60 Thinkpad (my two cents: use a Thinkpad like X200 or T400 flashed with Libreboot, which solves the proprietary firmware problem) and remove the wireless network card.
• Use Tails which wipes memory on shutdown.
• Use subkeys an encryption subkey is automatically created with gpg2 --gen-key. Create an additional signing subkey.
• Generate a secure passphrase for your master key using 5-12 words. Example: pipe after harm horse split seize radar bulb
  • Funny cartoon illustrating this concept
• Refresh your keys regularly for new preferences and revokation certificates. An alternative to gpg2 --refresh-keys is parcimonie, which uses tor and refreshes keys one at a time.
• Don t back up .gnupg/random_seed
• More OpenPGP Best Practices

See the slides for Neal s full presentation.

This year, Outreachy featured internships from organizations such as Debian, Fedora, GNOME, the Linux Kernel, Mozilla, Python, and Wikimedia, just to name a few. Each organization features mentored projects and in order to apply, applicants must contact the mentor, introduce themselves on the appropriate channels and make a small contribution to the project. After that, applicants might be required to fulfill additional tasks to demonstrate their abilities. Successful applicants will make quality contributions, communicate effectively with mentors, ask questions, fulfill tasks, help out their peers via mailing lists, and/or blog about their experience. One of the projects I applied to was the Clean Room for PGP and X.509 (PKI) Key Management. The project aims to create a Live Disc that enables users to create and manage their PGP keys easily and securely, using a text-based UI. I ve been a Debian user for about a year, but before applying to the project I didn t know much about GnuPG or public key encryption. Since then, I ve made some contributions and attended my first keysigning event in San Francisco featuring a lecture by Neal Walfield (more on that below). For my initial contribution, Daniel Pocock, the mentor for this project, asked that I write a script that lists the USB flash devices connected to the system and specifies which device the system booted from. Here s the bash script that I wrote, and that was enough to submit an application for Debian. My next task was to write a dns hook script for the dehydrated project, a shell client for signing certificates with Let s Encrypt (for free!). The script completes a dns challenge sent by the ACME-server by provisioning a TXT record for a given domain in order to prove ownership of the domain. I chose to write it in python and used the dnspython API. I posted my solution on github and there are many more here. At the lecture, Neal talked about good practices for key creation and management. Here are a few of those points:

• Don t store your master key locally
• Store your master key offline on a smartcard such as GnuK or NitroKey and store backups on a USB stick.
• Neal mentioned that the OpenPGP card is not open hardware and according to this recent post neither is the Yubikey
• To manage the key, use a dedicated offline computer such as a relatively cheap x40 or x60 Thinkpad (my two cents: use a Thinkpad like X200 or T400 flashed with Libreboot, which solves the proprietary firmware problem) and remove the wireless network card.
• Use Tails which wipes memory on shutdown.
• Use subkeys an encryption subkey is automatically created with gpg2 --gen-key. Create an additional signing subkey.
• Generate a secure passphrase for your master key using 5-12 words. Example: pipe after harm horse split seize radar bulb
  • Funny cartoon illustrating this concept
• Refresh your keys regularly for new preferences and revokation certificates. An alternative to gpg2 --refresh-keys is parcimonie, which uses tor and refreshes keys one at a time.
• Don t back up .gnupg/random_seed
• More OpenPGP Best Practices

See the slides for Neal s full presentation.

Review: Familiar, by J. Robert Lennon

Publisher:	Greywolf
Copyright:	2012
ISBN:	1-55597-535-6
Format:	Hardcover
Pages:	205

This is the first book of an experiment. I'm fairly well-read in science fiction and fantasy and increasingly well-read in non-fiction of interest (although there's always far more of that than I'll get to in a lifetime), but woefully unfamiliar with what's called "mainstream" literature. Under the principal that things people are excited about are probably exciting, I've wanted to read more and understand the appeal. Powell's, which I like to support anyway, has a very nice (albeit somewhat expensive) book club called Indiespensable, which sends its subscribers very nice editions of new works that Powell's thinks are interesting, with a special focus on independent publishers. So I signed up and hope to stick with it for at least a year. (The trick will be fitting these books in amongst my regular reading.) Familiar is the first feature selection I received. Elisa Brown is a mother with a dead son and a living one, a failing marriage, an affair, and a life that is, in short, falling apart. Then, while driving back from her annual pilgrimage from her son's grave, the world seems to twist and change. She finds herself dressed for business, wearing a nametag and apparently coming back from a work-related convention, driving a car that's entirely unfamiliar to her. When she gets home, everything else has changed too: her marriage seems to be on firmer ground, but based on rules she doesn't understand. She has a different job, different clothes, a different body in some subtle ways. And both of her sons are alive. I'm going to have to have a long argument with myself about where to (meaninglessly) categorize this on my review site, since in construction it is an alternate reality story and therefore a standard SF trope. Any SF reader is going to immediately assume Elisa has somehow been transported into an alternate reality with a key divergence point from her own. But that's not Lennon's focus. He stays ambiguous on the question of whether this is really happening or whether Elisa had some sort of nervous breakdown, and while some amount of investigation of the situation does take place, it's the sort of investigation that an average person with no access to special resources or scientific knowledge and a completely unbelievable story would be able to do: Internet conspiracy chatrooms and some rather dodgy characters. The focus is instead on Elisa's reaction to the situation, her choices about how to treat this new life, and on how she processes her complex emotions about her family and herself. I had profoundly mixed feelings about this book when I finished it, and revisiting it to review it, I still do. The writing is excellent: spare, evocative, and enjoyable to read. Lennon has a knack for subjective description of emotion and physical experience. The reader feels Elisa's deep discomfort with her changed body and her changed car, her swings between closed-off emotions and sudden emotional connection with a specific situation, and her struggle with the baffling question of how to come to terms with a whole new life. The part of the book from about the middle to nearly the end is excellent. Video games make an appearance and are handled surprisingly well. And when Elisa starts being blunt with people, I found myself both liking her and caring about what happens to her. On the other hand, Familiar also has some serious problems, and one of the biggest is the reaction I feared I'd have to mainstream literature: until Elisa started opening up and taking action, I found it extremely difficult to care about anyone in this book. They're all so profoundly petty, so closed off and engrossed in what seem like depressing and utterly boring lives. I'm sure that some of this is intentional and is there to lay the groundwork for Elisa's own self-discovery, but even towards the end of that self-discovery, everything here is so relentlessly middle-class suburbia that I felt stifled just reading about it. I think it's telling that no one in this book ever seems to have any substantial problem with money, or even with work. Elisa walks into a job that she's never done before and within a few weeks is doing it so well that she can take large amounts of time to wander around for plot purposes. This is a book about highly privileged people being miserable in a bubble. While those people certainly do exist, and I can believe that they act like this, I'm not sure how much I want to read about them. Thankfully, the plot does lead Elisa to poke some holes in that bubble, if never get out of it entirely. This is also another one of those stories in which every character has massive communication problems. Now, this deserves some caveats: Elisa's communication problems with her husband are part of the problem that starts the book and are clearly intentional, as are her communication difficulties with her children. And she's not really close enough to anyone to confide in them. But even with those caveats, no one in this book really talks to anyone else. It's amazing that anyone forms any connections at all, given how many walls and barriers they have around themselves. As someone with a bit of a thing for communication, this drove me nuts to read about, particularly in the first half of the book. But the worst problem is that Lennon completely blows the ending. And by that I don't just mean that I disliked the ending. I mean the ending is so unbelievable and so contrary to the entire rest of the book, at least the way I was reading and understanding it, that I think Familiar is a much better novel if you just remove the final scene entirely. It was such a bizarre and unnecessary twist that I found it infuriating. I don't want to spoil an ending, even a bad ending, so I'll only say this: it felt to me like Lennon just wasn't comfortable with his setting and plot driver and couldn't leave it alone. I think an experienced SF author wouldn't have made this mistake. There were two obvious possible conclusions to draw from the setting, plus a few interesting combinations, and I think someone comfortable with this sort of alternate reality story would have taken one of those options, any of which would have been a reasonable dismount for the plot. Alternately, they could have left it entirely ambiguous to the end and explored why the explanation may not actually matter. But Lennon seemed to me to have a tin ear for plausibility and for the normal flow of this sort of story and seems to have taken it as license for arbitrary events, thus completely violating the internal consistency and emergent rules that he'd spent the rest of the book building. I've mostly talked about my reactions to the characters and the writing and have not said much about the plot. That's somewhat intentional, since figuring out where the story will go is one of the best parts of this book. It's surprisingly tense and well-crafted for not having that much inherent dramatic tension. The excellent writing kept me reading through the first part, when I hated everyone in the story, and then Elisa started taking responsibility for her own life and actions and I started really enjoying the book while being constantly surprised. I think it's the sort of story that's best to take without too much foreknowledge of where it's going. I'm going to call this first experiment a qualfied success. Familiar was certainly interesting to read, and quite different from what I normally read despite the SF premise. If it weren't for the ending, I'd be recommending it to other people. Rating: 6 out of 10

Woodchuck and FrOSCon

At the end of August, I attended FrOSCon in Bonn again, after skipping it last year. The evening before FrOSCon however, I visited Neal Walfield, his wife Isabel and their little son Noam in D sseldorf. Besides having a great time and a lovely dinner, I was most impressed by their collection of Maemo devices (they had at least two N770s, an N900 and, to my jealousy, an N950) which Neal is doing research on these days. He works on woodchuck, which is a project investigating how to improve data availability on mobile devices and our conversation prompted him to implement ATP Woodchuck, which makes smarter decisions when to run APT upgrade on your Maemo device then the standard updater. As part of the research, they also run a user behaviour study which I joined, where one installs a client which records various data off your N900 and sends them anonymized (he seems to be doing a good job at that) to figure out how people use their mobile devices and hopefully enhance the experience. So if you have a N900, you should consider joining the study so they get better data.
The next day, I picked up Martin Michlmayr nearby and we headed for FrOSCon. I was quite impressed by the Makerbot at the Tarent booth, but I still don't know what they are really doing and why they had it on display... In the afternoon, I attended a couple of talks in the PostgreSQL developer room and a talk about a big OpenVPN deployment, before ending the day with the excellent as always social event barbeque. On Sunday, I went to quite a few talks, but I thought that two of them were particularly interesting:
Michael "Monty" Widenius of MySQL gave a talk titled "Why going open source will improve your product" about starting businesses on an open source project, or how business can/should open-source their product. Besides a detailed discussion about the various forms of Open Source licenses and the Open-Core model, he proposed the idea of "Business Source" (see slide 20 of his presentation), where a startup would distribute the source code under a non-commercial (but otherwise open-source) license with the explicit guarantee that the license would be changed to a true FLOSS license at some defined point in the future, giving the company a head start to develop and nurture their project. I asked whether this has been already implemented in practise and how the community could be sure that e.g. lawyers after a hostile takeover would not just remove that part of the copyright notice, as long as a true distribution under a FLOSS license has not happened yet. Monty wasn't aware of any real-word cases, and he did not seem to be concerned about this and said the original intent would be clear in a possible court case. This was the first time I heard about this approach, I wonder how other people think about it, whether it would work in practise and be a useful thing to have?
Second, I attended a talk by Gregor Geiermann, a Ph.D. student in linguistics on "Perceptions of rudeness in Free Software communities". He conducted an online survey about the perceived rudeness of several forum thread posts on Ubuntu Forums. Survey participants were first asked a couple of generic questions about their gender, nationality etc. and were then presented with a series of posts. For each post, they were asked to rate how rude they thought it was on a scale of 1 to 5 and they also had the possibility to highlight the parts of the post they considered rude as well as add comments. He presented a neat web application for analyzing the results, which makes it possible to select different groups (he did male vs. female and Americans vs. Germans in the talk) and have their overall rudeness ratings as well as the highlighted texts visualized as different shades of blue. Comments can be easily accessed. There were quite a few interesting differences e.g. in how Germans perceived rudeness compared to Americans (RTFM comments were considered less rude by Germans for example, IIRC). In response to my question, he said he intended to release the web application as open source and this might be an interesting tool for FLOSS projects to analyze how their public communication channels are perceived by various groups. Unfortunately, I cannot find any other resources about this on the web as of today, so I should try to contact him about it at some point.

The svn repository used to draft the Debian Project News just passed the sixth hundreds commit. If my calculations are correct, that's quite more than the number of edits done, back when the DPN was drafted in the wiki. I take it as a hint, that the new work flow works better than the old one. However, playing a bit with statistics (done by horrible shell one liners ;) I noticed, that - while every Debian Developer may commit to the subversion repository - not that many commits from other DDs where made: Of the 602 commits so far, only 70 where done by other DDs:

alex@melusine:~$ svn log --xml svn://svn.debian.org/svn/publicity \
 xmlstarlet sel -t -m "/log/logentry/author" -v "concat(.,' ')"   \
sed -e "s/ /\n/g" sort uniq -c sort -n grep -v guest grep -v tolimar
      1
      1 abe
      1 hertzog
      1 holger
      1 mika
      1 paravoid
      2 pabs
      3 alfie
     15 zobel
     20 gio
     25 spaillard

To give credit where credit is due, here are the guest commits:

     16 tpeteul-guest
     21 jeremiah-guest
     25 gmascellani-guest
     36 madamezou-guest
    122 taffit-guest

Many thanks so far, but I would like to advertise the Debian Project News and invite every DD to help us and to commit directly. It's quite easy: Run svn co svn+ssh://svn.debian.org/svn/publicity/dpn/en/current, edit the index.wml file, and then commit your changes back to the repository. (Well, ideally you would also honor Status flag and won't commit, if it's not open-for-edit.) As for the format: While we indeed use wml, you just need some basic HTML knowledge. To add a paragraph just use the following with proper content:

<a name="X"></a>
<h2>Fancy title</h2>
<p>More details about the topic.</p>

Usually the articles are kind of sorted by importance, so unless you are pretty sure it might be the easiest to just add your article at the end of the regular news, just before the other news sections. Should you not be able to fill an entire paragraph, feel free to just a one or two sentences to the other news section (just add a <p>...</p> with your content to the end of the other news). Don't worry about style, your English or syntax: It won't end up on the web page directly, it's reviewed and checked, so you can't do anything wrong. More details are available in the wiki at http://wiki.debian.org/ProjectNews/HowToContribute. Feel free to ask any questions unanswered on the publicity list at debian-publicity@lists.debian.org. Feel also free to contact us there, if you would like to help by translations or reviews. The more people help, the less work it's for everyone :) If you are not a Debian Developer, but still would like to help us, it's no problem. All you need is an account on our Alioth System (very easy to get, you just need to ask) and request to join the publicity project. See http://wiki.debian.org/ProjectNews/HowToContribute#Becominganeditoryourself for the respective links.

Debian always was known for its communication "style". There were even shirts sold in memory of Espy Klecker with a quote he is known for: Morons. I'm surrounded by morons. Yes, I bought me one of those shirts too in the early days. And there were the talks that promoted Debian as a place to have Good flamewar training. And people considered that to be the fun part. After some years it got tiring. It got stressful. It got annoying. Bad feelings popped up, stirred you into the next flamewar, and it went down the gutter from there. It was almost becoming impossible to not be the target of a flamewar when one was doing more than just basic maintenance. Snide and extreme terse responses became the standard. In the end people are starting to give up and leave. The Ugly thing about this is that human resources are crucial. They aren't endless and can't be replaced as easily as broken hardware, especially when capable people or when people leave who invested an enormous amount of their spare time and effort. And given that a fair amount of people do put their heart into Debian, it feels like a small suicide to them and the public thinking about leaving is meant as a call for help which wasn't and isn't given. The solution to this death swirl? I'm not sure. When one looks over the edge of the plate and ignores for a moment all the bad feelings they one might have built up against Ubuntu because of their success and possibility to find new contributors on a regular basis one is able to find a much friendlier and productive environment there. This might be attributed to the Code of Conduct about which I wrote about last year already and which is an extremely well intended and useful document (the point I raised in there is already solved for a while, so I became a MOTU). And even if it might be hard to follow it at times, Mark Shuttleworth reminds and encourages its contributors to stick to these principles even in tough times. The result? When following the planets, one finds on Planet Ubuntu a very good rate of blog posts on things that had been done, compared to the good rate of blog posts of rants on Planet Debian. And even though people regularly complain about the communication style within Debian, the answers of this year's DPL candidates to the question about a code of conduct for Debian were rather rather disappointing. So it is just well too understandable that people go the path that hurts themself, take a cut and leave the project behind in its mess. For myself? I'm not too far from that point on a regular basis, and I can understand those who did the final step only too well. Regular abuse, especially when doing stuff that others neglect on a regular basis but needs to be done anyway, being belittled on that grounds and not being taken serious and getting disrespectful responses isn't improving the situation. It happens to way too many people, and the only thing that still keeps me on tracks is that I do not want to give in yet, that I don't think that it would improve Debian to leave the grounds to various destructive people. On the other hand, there is only so much abuse one can take...
ObTitle: Ennio Morricone - The Good, The Bad and The Ugly

/debian permanent link Comments: 5

Alright, get ready for the next round of music links. This time I stumbled upon an old (and still) favorite band of mine while looking for references to Max Headroom: Art of Noise. You most probably have heard the one or the other song from them, they are featured pretty often. Here they are:

• Moments In Love: Well known song, I suspect.
• Peter Gunn: Also very well known and used often. You have to wait a bit for the music to hook in, there is an intro in the video.
• Paranoimia: Third great song you might have heard somewhere already. Absolutely lovely song indeed.

It's really sad to see such great bands to pass away. But it's still the perfect music to have running in the background when hacking along. Highly motivating, great to hum along. Oh, and you might ask, where is the connection to Max Headroom. Here it is, in a special version of Paranoimia featuring Max Headroom! Enjoy!

Recipe for RCBC - Release Critical Bug squashing Contest: It has been a while since my last post in the RCBW tradition. Luckily, the tradition is in very good health of its own, thanks to many others that have picked up the habit of SPAM-ing planet with good news for Debian, encouraging others to do the same. With all that RC-obsessed people around and with the Squeeze release forthcoming, can DebConf10 be devoid of geeky RC-squashing activities? Of course not! Thanks to the orga team we expect the conference to contain a 2-week long RC bug squashing pride with tutorials, BoFs, a permanent bug squashing party, ... and a contest! I won't indulge much on the contest as the wiki page contains all rules and gory details. Obviously, all usual rules and best practices of bug squashing parties will apply; coordination will happen on #debian-bugs. Get involved, it starts today, and it's open to everyone (DebConf10 attendees as well as Debian enthusiasts abroad, regular RC squashers as well as casual bystanders, etc). All this wouldn't have been possible without the help of many people that love Debian, so many thanks to:

• the sponsors of RCBC:
  • Marvell, for offering a GuruPlug
    (of course, the winner of this device is expected to help with Debian support for it *g*)
  • HP, for offering t-shirts
  • Pearson, for offering books
• micah - who dragged me into this (it hasn't been hard)
• gregoa and mehdi - the almighty judges - who have been transitively dragged into this (it hasn't been hard either)

PS a corresponding announcement is in the debconf-announce pipeline already

I got convinced to hold an IRC talk on usage of the Debian BTS in #ubuntu-classroom and thought it might be interested to other children distributions of Debian, too also for regular Debian users. So feel invited to attend it. It will be held in #ubuntu-classroom on irc.freenode.net on Thursday, 22nd of July, at 18:00 UTC. For those who have never attended such a session yet, you might want/need to also join #ubuntu-classroom-chat too and raise questions in there, the main channel will be set to moderated. I will try to cover basic usage like querying the web interface, reporting new bugs and also more deeper handling of bugs, including version tracking issues, and will try to address raised questions as good as possible. Hope the session will be helpful to some and be able to address some questions like why some bugs aren't getting archived even though they are closed for ages. :) IRC logs will be available for the convenience of those who can't make it. So long!

Working on and for Debian for the whole millennium already it would had been hard to not notice Ubuntu through the times. Given that fixing bugs in the package is in the interest of all involved parties I started to get curious for the packages I maintain in Debian what users of Ubuntu might have filed against them. Given that a fair amount of those actually do also apply to Debian I started to fix them too. Though, some bug status isn't able to use as an outsider, and given my approach to perfection not wanting to have packages in a bad shape in a release I started to dig a bit further into the procedures and applied to be accepted as a Ubuntu Developer, more specifically as a MOTU, which gives me the possibility to directly ask for syncrequest instead of having to go through a sponsor, or set wontfix status for bugreports in my packages that simply doesn't make sense to get implemented. Last week I got accepted into that state and I'd like to thank for all the nice and encouraging feedback along the path (including some "What? I thought you were MOTU since ages already??" responses). Let's see how much I really need it, my approach is rather to reduce Ubuntu diffs instead of having to work on them. I though understand that at times close to the releases there can be a need for them, as can be seen in that the package I have to put most effort into (wesnoth-1.8) has a Ubuntu diff in the last lucid release. And because Ubuntu already is in DebianImportFreeze I did a syncrequest for gitolite. Thanks for accepting me so quickly and rather bureaucratic! And no, Laney, I won't give the talk tomorrow because of this just on my own. ;)

This Monday I was again at concert of Grossstadtgefl ster, and it was again one of the best concerts I've visited. Their new album again has again great songs on it like the former two, and their live performance is truly worth it. Besides they are charming like hell offstage, too. Jen, Raphi and Chriz, I simply love you! It's hard to choose which songs to put here because there are way too many great ones, so feel free to dig around yourself if you like them:

• Weil das morgen noch so ist: Their current single, great video, giving a good impression of their style and the fun they have doing this.
• Lebenslauf: Great song from their former album.
• Fehler: So much truth in the lyrics, so much touching the heart.

Enjoy!

"Today is the greatest day I've ever known," this is the line that is spinning around today in my head because of many little things that happened. And it's this time of the month anyway for putting up another band feature into this little blog of mine. So here they are, one of the great bands of the nineties, and like many of them, back after a break again: The Smashing Pumpkins, and these are their featured songs:

• Today: The song with the initial mentioned catchphrase. Unfortunately not the official video because in those versions the music is strangely broken. If you want to match it yourself, you can still watch it here: Today (true video, broken music)
• Disarm: From the same great album, and one of their songs that gives me goosebumps.
• Bullet With Butterfly Wings: Another of their great songs and videos for which they are known.

Hope you enjoy this small distraction once a month. I hope I can keep up with it, it's not a question of material, there are too many great bands out there that I'd like to share with others. :)

First of all, THANKS Rhonda for pushing me to do that! I did plan to integrate the Debian menubar for a long time, but it never made it high enough on my todo lists up to now.

So, what am i talking about? For those of you who don't follow debian-www@l.d.o too closely, there was a recent thread about debian.org's page layout, where Rhonda pointed the initial poster to the layout proposals from Kalle S dermann. Rhonda was so kind and mainly documented in the recent blog post how to convert the gitweb theme to that layout.

I took that documentation and sat down Friday evening and converted the layout of my local instance of the DSA internal wiki to that new layout. While not everything looks perfect yet, it took me less than an hour. WOW, that was fast.

Now i became megalomaniac. After copying over the current list archive to an other machine (to not destroy the current archive while playing with mhonarc), I started playing with the same layout for lists.debian.org. The whole scripts for lists.debian.org were a bit more complex than the ikiwiki code we use for dsa.debian.org, but i managed to render usefull pages yesterday early morning.

Not everything was easyly convertable, and I still have some smaller issues to work on, but if you compare for example the following posting using the old and the new layout, i think we can use my work as basis for further improvements of the layout. Eg. i am aware that the new HTML code does not fullly validate using the w3c validator.

Many thanks also go to Kalle, who responded to my problems with the CSS immediatly.

Not all lists are converted to the new layout yet, as a full list archive rebuild seems to run about 24 hours. Also i adjusted some minor stuff in the templates while the rebuild was running, so you will see some smaller differences in the breadcrumbs. That will go away when I start the next rebuild.

So what is next? Rhonda, do we want to see if we can take over qa.d.o? ;-)

PS: if someone wants to generate new icons for the thread view arrows, i am happy to integrate them.

We ain't dead. A long time has passed since I last wrote on this topic, and much happened unfortunately (for this effort) in other areas. This doesn't mean that this effort is being abandoned. So here is the next big step: A gitweb theme using Kalle's proposal. I enabled it on my own gitweb installation so that people can see it live and test it. Feel free to clone it from there, too. Enjoy!

Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package. The longer answer which also answers Why the name change? goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch. So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages. Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!

My SO did had an extremely good idea for my birthday this year: We went to a concert of Ich + Ich. We both were a bit sceptical beforehand but actually we were both in agreement about that it was one of the finest concerts we have been to. I want thus to share some of the great songs of the band with you:

• Universum (Universe): I am thinking of my son when listening to this sweet song.
• Stark (Strong): Not only the title but the lyrics.
• Dienen (Serve): Probably the best known of their songs.

Enjoy!

RCBW - #26 It is getting down, even though the current number is scary. My personal RC bug count is not so mystical and as low as 205 RC bugs to go, which is quite encouraging. Without any further ado, here are this week squashes:

• Debian bug #571817 - python-data - avoid spurious py2.4 dep (sponsored NMU for Obey Arthur Liu)
• Debian bug #574020 - h5utils - switch to octave 3.2 (sponsored NMU for Obey Arthur Liu)
• Debian bug #559609 - hstore-new - drop pgsql 8.3 package (sponsored NMU for Obey Arthur Liu)
• Debian bug #575384 - ethos - add inter-lib dep to avoid dangling .so link (patch by Andreas Henriksson)
• Debian bug #460338, Debian bug #565153 - apt-proxy - requested removal RM/RoQA (see Debian bug #576821)
• Debian bug #574557 - qpsmtpd - fix virtual deps in init script (patch by Petter Reinholdtsen)

Random points:

• I've exploited quite a bit my (now ex) NM Obey Arthur Liu: 3 of the above squashes come from him. I've been tempted to put Arthur on hold just to have him fix some more RC bugs g (just kidding, of course)
• It has been observed that *cheering up Gregor8 produces beneficial effects on the RC bug count, so why not doing it again?
• Last week I forgot to mention Rhonda's regular stable RC squashing, and in particular the "below 1000" milestone. Cheers!

On 20th of March, at five to midnight, we have released out most straining and time consuming project ever. Its codename is Simon Andr and we are pleased that it was (more or less) a smooth release process with just a minor delay of three days but the best don't release on time but when it is ready. Because everyone loves screenshots, and a few might be viewed on our dedicated Screenshot Page, for completeness this announce contains one: After one week into the release we have to say the feedback and the interest so far is pretty good, the maintenance is requesting its toll, but nothing really unexpected happened so far. We look into a bright future! Thank you for your attention, enjoy the nice spring weather!

Regarding my previous post on source format 3.0, I think it came across that I was blaming lintian entirely which would be unfair.

(As a side-note, a bug in serendipity XMLRPC resulting in all entries having comments disabled has led to a welcome effect of spreading the discussion more widely than a series of comments on my own site could have achieved. I'm happy with this state of affairs, so it you want to comment, either contact me by private email or put your comments on your own blog. I won't be enabling comments any time soon.)

The extended information behind the lintian warning is one thing (I've explained my position on that to Russ privately) - my main objection is to how such a warning was pushed into lintian and the entire use 3.0 or be damned approach that seems to be being adopted.

IMHO, source format 3.0 is not good enough to be the standard dpkg source format for a simple reason: It offers nothing to well maintained packages. Not all packages need NMU's - ever. Not all packages have patches - ever. Native packages and packages with the Debian maintainer upstream gain nothing from 3.0, as far as I can see.

I have 67 source packages - after much very careful consideration, I have found that a handful of those (less than 10) actually benefit from 3.0 and the rest are all unaffected. None of the packages that I will keep on 1.0 have ever had an NMU since I've been maintainer, most are either native or entirely under my sole upstream control. I will decide whether Debian gets a .tar.gz or a .tar.bz2 and although I generally offer both for download where I can, I see no reason to adopt .tar.bz2 as my default for Debian packaging.

Adding a redundant directory and file is obnoxious. I fail to see why debian/source-format would not have been perfectly suitable. Nevertheless, I will do what is necessary to avoid 3.0 until there is a compelling technical reason to adopt it.

The imperative for those in favour of 3.0 is to convince me that there is a reason TO change, not to make it difficult for me NOT to change. I do not need any reason to avoid 3.0 other than I do not have a good enough reason to move from 1.0. Making developers feel like luddites or incompetent merely because the proponents of 3.0 have failed to convince others to move to 3.0 is just insulting. You want me to use 3.0? Explain why I should bother - the current "reasons" on the Wiki page are simply not good enough and any rehash of those will be ignored. Come up with something new or respect my decision and let me get on with more important stuff.