And after a long and boring week and a half of ordered Development Platform uploads, today the first few Desktop packages have started to hit unstable. I expect that the entire 2.14 release will be ready for your apt-get'ing in just a few days more. Of course, that doesn't include Ekiga, as their dependencies seem to be in a debian-legal trap... The most exciting bit of this round of uploads is the participation of at least 3 new Debian GNOME maintainers, including... new people looking after the evolution packages!

Via reddit (which kicks the crap out of slashdot and digg): What I've Learned From Failure.

The link above is a long, but fascinating piece. I've had to become a lot more interested in how to manage software projects since taking on Xorg maintainance, and the same lessons seem to scale up well to how Debian as a whole manages itself. This article talks about some of the major problems that I've seen myself deal with, and the experiences of this guy echo my own over the past year very strongly. Here's a few examples:

"Getting away from weak teams, another source of failure is the omnipresent threat of "chickens." A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team."

I like this and I've noticed it in the XSF and in Debian as a whole. People are free to work on what they want how they want, and this tends to work out well for us. But we also have no structure in which people must actually commit to what they do. As such, there's no accountability. This frees Debian developers from the preassure of having to work on something they don't enjoy, but it also creates abandoned packages, ignored bugs, and frustrated release schedules. In the past I've described a need for a stick in addition to a carrot for Debian developers, and the sentiment here echoes that idea. I've spoken with Manoj about his conception of personal responsibility in Debian, and I think it may truly be the bedrock on which Debian needs to rest. I still don't have a good mechanism for this yet though.

"Another sign of a weak team is poor development hygiene. There are dozens of development practices that seem trivial to the inexperienced outsider or to the manager focusing on "big wins." Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews)."

This is a something I myself have had a problem with over the past year. Branden was extremely good about keeping the XSF svn repo and the BTS up to date and well managed. I've done just about the opposite over the past year, and it's bitten me a few times. This however, was a conscious decision on my part, knowing that I was so far behind upstream that it was going to be hard to effectively manage the BTS without a recent codebase deployed to our users. So I focused on packaging instead, and luckily that road is nearly finished. Also fortunately, everyone else in the XSF managed the BTS for me, most notably (in alphabetical order by last name) Julien Cristau, Michel D nzer, Eugene Konev, and David Martinez Moreno, and they've managed to keep it relatively tidy. I'm going to spend some serious effort over the coming months to clean out the BTS so it's more manageable both for users and developers again. Luckly our SVN repo is in good shape still, so for the most part we're doing pretty well here. Debian as a whole also seems to be doing better at this, with lots of public svn repos springing up on alioth.

"It's mandatory to fail early. You need to know you're in trouble right away. That's essential when taking over an existing project or starting something new. You have to find out how you're doing within weeks. Not quarters, not months. The longer you wait, the more inertia the failure will have."

We're getting better at this, and I've sort of made it my mantra for this release cycle. Get things in to experimental as fast as possible, and then when I've fixed the majority of the bugs that show up there, put it in unstable as fast as possible. It worked out well for all the releases I've done so far and I'm going to keep doing it. Michel is really pushing me to keep CVS (or git as of Real Soon Now) snapshots from upstream in experimental, and I really like this idea and plan to follow through with it for this reason. This also echoes some of aj's ideas about speeding up development pace. Hopefully he'll implement them whether or not he becomes DPL, because I think they're going to be important for Debian as a whole.

"Dates are sacred."

We learned this during the sarge release cycle.

"The net result is that I've tried to find the happy medium where I generate weekly management reports on projects. A management report is something that is used to actually make a decision. Everything else is garbage. I've learned that when I haven't had management reports for a project, failure has resulted."

This is an interesting idea. It sort of echoes how I try and provide status updates on my blog, as well as the "Bits from" emails, but perhaps something more like this would be useful. I may try and play with this idea in the near future.

There's a lot more in there, but this entry already got way too long. Hopefully there's some food for thought in there for everyone who's interested in how Debian is run. The Debian development model has carried us very far, but I can't shake the feeling that we need to make some critical changes for it to continue. This will require a certain degree of boldness, but in order to fix the problems with the project I think we just need to clench our teeth and go for it. With that, I'll leave you with one last line from the above: "And if you decide to make changes, have the courage to go 100% with your gut. I've failed more than once when I watered down my convictions in order to appease dissenters. The only thing worse than evangelizing change and failing is looking back and realized you might have succeeded if you'd held firm on your convictions."

Aircrack, one my favourite wifi tools, was quite dead for a while. Bad enough, but after I switched to the madwifi-ng driver recently I discovered that I can't do injection anymore, which is quite bad. I searched for a workaround and found aircrack-ng, a fork of aircrack, which has been made recently. There weren't much changes to the aircrack codebase yet, but at least everything works well with madwifi-ng now. Now, as aircrack seems to be moving again I mplemented some changes I always wanted to have, such as attack names (documentation patch) instead of attack numbers I could never remember and tried to get them submitted to upstream. What I normally do that situation is to check out the latest development version from the projects version control system, prepare a patch against it and send it to the development mailing-list afterwards. That's hardly possible with aircrack-ng. Not only that one or two persons are having a master copy of the code instead of using a nice, public accessibly version control system, but also the total lack of mailing-lists or any other possibility to coordinate development besides an IRC channel and a wiki, which is only partially editable, makes contributing quite hard. After announcing some of my patches on IRC several times one of the upstream developers finally took a look at it and said he applied it so it'll be released in the near future. I'm happy about that, but the deficits in the development process still exist. Therefor I offered to sponsor hosting, including mailing-lists, a version control system, a bug-tracking system and whatnot. It was thankfully declined as they already seem to have a hosting plan. Great! Unfortunately they don't have the money for that currently, but they at least have plan. Hooray for aircrack-ng.. Debian packages for the latest release already exist and should be upload in the next days, btw.

The coldfire development kit of which I made mention in a somewhat recent -devel-announce post has arrived about a week ago. Mine was the last one to arrive; the other four have already arrived. It took a while, because mine apparently got lost in shipping, so they had to ship me a second one. That, and the fact that I said I'd ask around in my neighbourhood whether it'd been delivered at the wrong address (but then eventually forgot to tell the Freescale folks that I had done so and that, no, it wasn't) meant it took a bit over two months to arrive here. But it finally has. Whee! The box contains a number of things I do not and will not likely ever need (the CodeWarrior Development Studio, for example, or power cables for other places of the world, like the US, the UK, and Japan), but, well—that's not important. It also contains some things that are interesting, such as a serial cable—even if I already have a few of those. The box contents also smells funny. Oh well. In the mean time, however, I've come across a bit of a problem: I can't seem to boot the thing. Well—I can, except it seems to be mangling the serial output it's sending for some reason. I can see that some output is being sent to the serial console, but it's not readable. And I can also see that it doesn't find it's root file system—I'm doing NFS root currently, and there's no network activity. Not sure what the problem is, though. Update: someone suggested that it is the baud rate. Yes, obviously it's something like that; however, I did try every baud rate between 9600 and 115200, but none of them worked. Besides, I have my command line say "console=ttyS0,19200n8", and it's still not working. I suspect a driver problem at this point...

The coldfire development kit of which I made mention in a somewhat recent -devel-announce post has arrived about a week ago. Mine was the last one to arrive; the other four have already arrived. It took a while, because mine apparently got lost in shipping, so they had to ship me a second one. That, and the fact that I said I'd ask around in my neighbourhood whether it'd been delivered at the wrong address (but then eventually forgot to tell the Freescale folks that I had done so and that, no, it wasn't) meant it took a bit over two months to arrive here. But it finally has. Whee! The box contains a number of things I do not and will not likely ever need (the CodeWarrior Development Studio, for example, or power cables for other places of the world, like the US, the UK, and Japan), but, well—that's not important. It also contains some things that are interesting, such as a serial cable—even if I already have a few of those. The box contents also smells funny. Oh well. In the mean, however, I've come across a bit of a problem: I can't seem to boot the thing. Well—I can, except it seems to be mangling the serial output it's sending for some reason. I can see that some output is being sent to the serial console, but it's not readable. And I can also see that it doesn't find it's root file system—I'm doing NFS root currently, and there's no network activity. Not sure what the problem is, though. Update: someone suggested that it is the baud rate. Yes, obviously it's something like that; however, I did try every baud rate between 9600 and 115200, but none of them worked. Besides, I have my command line say "console=ttyS0,19200n8", and it's still not working. I suspect a driver problem at this point...

Hi! This is Comas, the conference management system we all know and love! Perhaps you remember me from /www.consol.org.mx/">/www.consol.org.mx/">CONSOL 2004 and 2005, Debconf 5 and 6, CICOL, Seminario Globalizaci n, Conocimiento y Desarrollo or other such great conferences! Well, it is a pleasure for me to announce I am moving.
That's right - My developers have felt too constrained by CVS to keep being merry and productive, and decided to move away from it and to Subversion. If you are tracking my development history, you should have noticed a new file in my base CVS directory, called DONT_USE_THIS_REPOSITORY_ANYMORE. I will reproduce it here following Gunnar's wishes, and hoping it is useful to you.

PLEASE DON'T USE THIS REPOSITORY ANYMORE! Just in the meantime, while we migrate our current installations to point to the correct server, while our users take note, and while the kind GBorg admins lock down this project: PLEASE DON'T USE THIS REPOSITORY. WE HAVE MOVED. The Comas project will no longer be hosted at GBorg - We are moving to Debian's Alioth.
Comas' webpage (although it is still ugly :) ) is still the same as always. The repository will no longer be handled through CVS - We switched to Subversion. Don't worry, the usage is basically the same. You can use anonymous access to get the Subversion tree. If you want to participate in the project, register at Alioth and ask us for commit access. You can also use the very nice SVN Web interface, which allows you to look at each of the files, view the changes, and even subscribe to the Comas RSS feeds! Development goes on. Stay tuned! Greetings, - Gunnar Wolf

Of course, as in any migration, there is still a lot of things to do. Mail the other contributors and interested people notifying them of the move. Migrate (and check the validity of) any tickets we have in the old site. Point all the places where there is Comas-related information to the new repository. Close the existing project page at GBorg. Sanely re-structure the repository in a more standard and functional way (and hope it does not break current installations ;-) ). Rework the documentation that has been neglected in the last months. Rework the bits of logic that never smelt very good but -as a dead rat- now positively stink. Fixe the things that will eventually stink as well... Anyway, I'm sure this will speed up my growth!
I am very excited on which way my dear authors will continue to push me - I know I'm quite a lousy program for many things, and I know there is a lot for me to learn until I am a military-grade conference management system - But my many parents have written me with deep love, and I understand they had to write hastily parts of my code. I understand their mistakes, but I hope they make them go away soon.

My name is Jurij and I’m a Pine user. I’ve been using it forever and got remarkably used to it. If previously there was no good reason to switch to anything else, lately two things where bugging me a bit: lack of PGP/MIME support, and lack of Mail-Followup-To handling. If the latter problem is not such a big deal, the former was seriously annoying me sometimes, because even if you save the PGP/MIME message in a file, checking the signature is sowewhat non-trivial. So, on Saturday I’ve decided that time has come to switch to mutt. Again. And failed. Again. It’s just so different that using it is painful, in spite of all the flexibility and configurability. So instead I’ve spent the better part of Sunday writing a PGP/MIME signature checker, which can be used from within Pine. The resulting script pgpmime.py just reads a PGP/MIME message from standard input and checks the signature (more features are planned in the future). From Pine one can just pipe the raw PGP/MIME signed message to it using the (pipe) command.

The Latin American Infest finally ended yesterday. In Caracas, it was a week of hard work with people of the Science and Technology Department and the IT Office (government offices) but the event in Caracas ended succesfully. It was a world-class event featuring renowned keynote speakers who spoke about Web Development using Frameworks (featuring TurboGears, Rails and Catalyst) and software development paradigms migration from privative platforms to GNU/Linux (Gambas and Mono). Other talks included basic security in Debian GNU/Linux and a speak about electronic signature security by an officer of the Venezuelan Government CA. We had a speak about Clusters, hosted by a female member of the Venezuelan Free Software Community and Debian User, and a speak about Free Software in the Venezuelan Education, by a 16-year-old Venezuelan GNU/Linux user and a willing Debian Maintainer. Of course, the Installation Festival took place in the Knowledge Square, in the Auditorium Building Lobby, with the extraordinary support of the Venezuelan Free Software Users Community. Debian GNU/Linux Sarge netinst and CD1 was distributed (several hundreds) as well as Knoppix and Ubuntu Hoary. Ernesto Hern ndez-Novich (maintainer) and me wore Debian T-Shirts on Saturday, and he made a great speech about the Project, named “Debian is inexorable“. We had demonstrations of Linux on a Mac Mini, using XGl and presenting several applications, as well as Debian running Enlightenment on an old Presario 1246 laptop. I would like to thank all the speakers and the attendees for making of FLISOL Caracas a great event. More information about FLISOL Caracas is in my blog and the homepage (spanish). Pics are here.

Dave Winer: “You can view the 60-percent-Vista-rewrite story as something of a software development IQ test. Anyone who believes that it’s conceivable is someone who hasn’t got the most basic clue about how software development works.”

Living with mricon I get exposed to the way the other half lives. One thing I've noticed is that the RPM tools automatically build extra -debuginfo packages that contain the debugging symbols for the binaries in the package, which gdb can use. I thought too myself "That's cool, why doesn't Debian do that?" Of course, after some research it's actually very easy to accomplish the same thing in a DEB. First step is just to add a dbg package to your debian/control file like so:

Package: giblib1-dbg
Architecture: any
Section: libdevel
Priority: extra
Depends: giblib1 (= $ Source-Version )
Description: debugging symbols for giblib1
 giblib is a library of handy stuff. Contains an imlib2 wrapper to avoid the
 context stuff, doubly-linked lists and font styles.
 .
 This package contains the debugging symbols for giblib1.

Then change your call to dh_strip in your debian/rules files so it looks like this:

dh_strip --dbg-package=giblib1-dbg

If you use cdbs then just add the line:

DEB_DH_STRIP_ARGS := --dbg-package=giblib1-dbg

These cause dh_strip to place the debugging symbols under /usr/lib/debug in the named package. Make sure you have debhelper compatibility level set to 5, as the semantics for the --dbg-package switch in 4 and earlier were different and weird. So add a -dbg package to your library or binary today!

Horms, why not use gworldclock? Martin, I think you are after tra. Andrew, you do realise that you could do that with yum – which has been in Debian for a while now. You'd have probably heard about it earlier if Mako could be bothered to get Atom 1.0 support working on Planet Debian. Rodney, Nokia phones generally use Netfront as their default. If you want to use Opera you have to specify it. I'd be highly skepticle of KHTML being used anywhere memory footprint mattered. It looks like it might be WebCore (dervied from KHTML) instead. But that is only on very recent phones (first half of 2006). Oh, and that is likely to be Yahoo merchant crawler. Yahoo probably thinks you are a corporate whore or something ;-). Finally is it just me or does it strike anyone else as odd that the Mozilla Corporation, with all of its' money, is not able to get a crack group of hackers together so that Firefox 2.0 can render ACID2? At least two of the competitors can already so, what's the go, Joe? (or in this case Mitchell).

Andrew Pollock reports that there is (finally) an rpmstrap. Finally, indeed. I have set up RedHat chroots in the past, by manually downloading some file, manually filtering out the list of packages that are relevant for my architecture, manually downloading them, and manually running rpm --root, or whatever they use to set the root directory; but it wasn't pretty. Being able to say here's a directory, there's a mirror, I want this, go do it for me would be...great.

I love reading about the new packages in Debian Weekly News. It's one of the regular bits of it I always look forward to. This week, I was very pleased to read about rpmstrap being packaged. Finally, I can create a RedHat chroot to muck around in to test RPM building, without having to resort to running an entire RedHat box (or messing around with virtualising one).

Over the past week or so, I've decided to get around to listening to some of the "amateur" (in the same way that Open Source software is "amateur") podcasts that I've collected in the past couple of months (primarily so I can either archive them, or delete them and free up a bit of HDD space). As a great fan of radio, I've been pretty disappointed at the quality of the podcasts I've listened to. While I hadn't expected the BBC world service, there are a number of quite common mistakes I've noticed across several of the podcasts I've listened to. In the spirit of kaizen, I've noted down the really bad things that I've noticed, in the hope that someone who does a podcast, or is considering doing a podcast, might keep these simple mistakes in the back of their mind and avoid them. No podcast I've listened to so far has exhibited all of these symptoms (there's no way I would have gotten to the end of that hypothetical nightmare audio file) but most have exhibited at least one of these flaws. For a better general idea of how a good podcast might sound, listen to professional radio for a bit -- a lot of good shows are podcast themselves these days -- and get an idea of what a good show looks like. I'm also prepared to go further than just bitching about podcasts. If you do a podcast, and would like my (unprofessional but oh-so-opinionated) assessment of your podcast, please e-mail me at mpalmer@hezmatt.org with a link to your podcast, and I'll try to give it a listen and honest critique.

• Ad-libbing is a sometimes thing. I think I'm quite good at it (I gave my wedding thankyou speech unscripted and unrehearsed, and survived, so I can't be that bad) but I'd never consider doing a podcast without a script. In a podcast, all you have are your words, so if you're searching for words, or mangling them, it all falls apart. The downside to scripting is that you can end up reading your script in a monotone, without any life at all. I think practice with your script can probably improve that, but see the last point below.
• Waffle sucks. I'd say that scripting can help here, but if your script is full of waffle too, then you're SOL. Brutal editing is the only cure. The worst part here is that, since most people silently read faster than they speak, what looks fine on paper turns into something amazingly long and boring when read.
• Avoid meta-podcasts -- that is, don't talk about your podcast in your podcast. Something like "we're always looking for new content, see for more info" is bearable, but when 8 minutes of a 30 minute podcast is taken up with talking about the podcast wiki, mailing list, forum, ouija board, and so on, know that you're killing your audience.
• You do actually need content. Things that somebody out there is going to care about. A regular podcast is a brutal thing to commit to, and sticking to it must be hard at the best of times, but if you've got nothing interesting to say, don't record it, just have a short or missing show. We all know what filler sounds like -- you're not fooling anyone.
• Uhm is your mortal enemy. Not so much the occasional quick 'uhh' in the middle of a sentence, but I've heard "Uhmmmmmmm"s that went for at least 5 seconds. If you're that stumped for something to say, you need more scripting or editing.
• "Funny" voicing can be really distracting. Having a bit of life in your voice is great, but going completely off the charts only works for Robin Williams (and even then it's not a surefire hit).
• Whilst talking faster than a chipmunk on speed isn't a great way to run a podcast, you can easily fall into the trap of going too far the other way, and... talking... like... your... jaw... is... stuck... in... chilled... molasses...
• Why in the name of $DEITY are you reading out a long command line in a podcast? Sure, without the help of something like Annodex it's tricky to do commands and links the way you're supposed to (as text, dammit), but please do try. If your podcast is example-heavy, either consider dropping the podcast angle, or at the very least, provide an annotated transcript or "companion guide".
• You are allowed to do multiple takes of your podcast. Really. Read in small sections, and then stitch it together. Listen and retake a bunch of times until it sounds reasonable. (Aside: my one appearance in a podcast to date was about 15 minutes of recorded audio, before final editing. It took me about 7 hours to do -- admittedly, that included learning how to drive Audacity and do my editing, but I'd say I had at least 2 hours of mic time in there.)
• Some people just weren't cut out for "radio". You may be unable to stop your voice sounding like Lurch, or you get the giggles, or just can't think of interesting things to say "on air" -- whatever the problem is, you may just have to accept that you're better behind a keyboard than a mic. There's nothing wrong with that, but please be self-aware enough to realise it. No podcast I've yet listened to has been "kill it, now!" bad, but since I've only been listening to personal recommendations, I figure I'm mostly listening to the better class of podcast out there, and there's plenty of "give it up, please" podcasts out there.

Via Guilded Lilies (Grown Women Playing Games):

One of the things I find interesting in the development of computer games is the selective application of the increased realism that has been made possible by improvements in game engine technology. [...] What I find to be ironic is that there has been an industry-wide movement toward more realism through the function of, for example, physics AI in computer game design, without there necessarily being a concurrent application of that ideal to the creation of certain female body parts. This point has generated the response that games are not about realism, but rather fantasy, and thus do not have an obligation to represent women realistically

Josh, Martin F. Krafft and Wouter talked about how to explain Debian with a few sentences. You mustn't feel awkward about explaining that, instead you should be prepared. If it helps you, think you are selling a product, not showing how "nerdy" you are. You are doing great stuff, you can earn your living with it quite well and you like it. That is perfect, so be proud about it. You need to have what is called an "elevator pitch". That is a short preso you could give while going up a few floors with an elevator on your way to a meeting, back, at a conference, at a party... That format seems most appropriate to me, and there are good guides on how to do elevator speeches. Rehearsing makes sense, too. You'll however likely want some variants, depending on the audience. My first stab at writing such a speech:

Debian is a Linux-based operating system [software for computers] made by volunteers, of which I am one. It is in fact one of the most widely used operating systems worldwide, and usually picked because of its reliability and security, while being entirely customizable to fit your needs. And it's development community really makes the difference, there are so many bright people there, doing amazing new software.

(notice: I extend the development community to floss, beyond just the official DDs, because thats the way it is. There is nothing wroing with bragging about e.g. what the Gnome people do, because you can use it with Debian, too.) and optionally, depending on the audience:

There are also variants suiteable for novice users, such as schools. You can run it on laptops and desktop computer as well as on mainframes or embedded devices. You can do everything with it.

or:

The city of munich is just switching to it for their computers. This saves the city a lot of money, while becoming independant from Microsoft.

or:

Our computer science department has almost only Linux on its computers. And many other universities do the same. Can you think how cool it is to have millions around the world use your software?

and of course:

That is so cool, I can do stuff I really like to do, meet really cool and bright people and earn my living doing so. That's heaven on earth.

[Update: someone might consider the use of "guys" to be sexistic. Well, of course there are very cool grrrls there, too. I've replaced it with "people" now, so I don't neet to explain grrrls next. ;-)]

I would really wish that I could travel around the world and do evangelization about i18n just like Jordi, Daffyd and Michael have been able to do. Of course, this is a known difference between a development model where people are paid to work on development and a completely volunteer development model. However, I really hope that all the good things that will be done to better support Asian languages in Ubuntu will end up in Debian really soon. After all, much of the initial work has been done in Debian itself by the wonderful Japanese/Chinese/Korean developers, or by the "debian-in" project lead by Jaldhar H. Vyas for Indic languages support. Don't take me wrong: I don't have any griefs towards Ubuntu when it comes at i18n. This is an area where the collaboration is already quite good and I hope it will become better if we manage to converge towards common tools (just free up the bloody Rosetta, Mark!). This is one of the goals I personnally set for the i18n session in Extremadura. Our goals here are common: we want more and more pleaces in the world to be able to use the Best Operating System ever and we will paint it red. (another way to say this: "we want the world and we want it NOW") For this, we just have to cooperate.