Quick post. In light of recent Nokia+Microsoft-MeeGo news, I have gone to learn more about Android in a hurry. And here is the first result MorzeSMS. Basically it is a tiny app that will play a morze code when you receive an SMS message. The morze code is the phone number of the sender in cut number morze form (to be shorter). The idea is that first of all morze is a cool sound and second is that each sender gets a unique sound that you can learn to identify over time so that you know who sent you a message as soon as you hear the beep. This is very early beta there is no UI, no configuration. You can download it here. Leave bug reports in the comments of this blog post. It does not disable the stock SMS-received sound.

I've decided to try to get rid of some more Debian packages. The main reason being that I don't use MPD anymore so following packages are for sale:

• mpdris
• mpdscribble
• python-mpd
• sonata

I will continue to upload new versions (should there be any) until somebody steps up, but that's pretty much all I can do. PS: And there is still gpointing-device-settings for sale as well.

Filed under: Debian English 2 comments Flattr this!

We just learned about the Nokia and Microsoft strategic partnership today and many people are concerned. I think the agreement is worrying for Qt, but even more worrying for Nokia. I foresee an exodus of current developers and Nokia mobile device users. Many Windows developers will come. Hopefully? I really wonder who is actually benefited by this strategic partnership. Nokia already had many mobile devices with Symbian, one with Maemo (and there could have been many more with Maemo, but for some unknown reason there weren t) and Meego could have been adopted already (but again, for some reason, Nokia had not). On the other hand, Microsoft had an operating system but no users. Virtually nobody wanted Windows 7. It was either Android or your own solution (MeeGo, WebOS, Bada, etc). In my opinion, the next move we will see is Microsoft buying Nokia to be able to compete one-to-one with Apple and Google. I think it will not take too longer, probably they are just waiting for Nokia stock to fall a bit more. So what should have been the change of direction Nokia should have done a few years ago? In my opinion, when Nokia acquired TrollTech, they should have released at least 10 devices with Qtopia. Immediately. And dump Maemo. In parallel, they could have added more and more Maemo features to Qtopia. By doing that, they would have had a good mobile operating system and applications in no time. There was even an X11 compatibility layer for Qtopia back then. I did not understand why Nokia adopted Qt and went on with Maemo and Meego based on Gtk+, and tried to keep as much backwards compatibility (regarding to source compatibility, development methodology,e tc) with devices which barely had users (N770, N800 and N810). I think noone understood that move. From my point of view, that was a waste of time, money and effort, which ultimately led to Nokia s demise. PS: Yes, I still am a KDE on Windows developer and part of the Debian Qt-KDE team

Yesterday night I arrived in Pune for the GNUnify conference where I m a speaker. I should speak more often at such conferences, they really pamper the speakers: I was picked up with a car from the train station, brought to a posh restaurant where other speakers were already dining and afterwards accommodated in the guest house of the Symbiosis University, which means a spacious room with my own bathroom (with running hot water) and best of all: Internet connectivity after midnight! Tonight I was alone, the next night I ll be sharing it with another speaker.
Today we had breakfast at the conference venue and the first talks started. I attended a talk about Openmoko, but nothing new to me so far. I was happy to see Debian listed as one of the Distributions for the FreeRunner, given that I once co-initiated that port. Nevertheless it could not bring me to try using the FreeRunner again, reliability is just not good enough. I asked for the next best (in terms of freedom and geek-compatibility) phone, but there is no obvious good answer. The n700 seems to be a dead end, given that Nokia might ditch Meego. The Geeksphone sounds like a good candidate, but is out of stock. My Haskell talk will start in 30 minutes. I hope I ll reach my audience and haskell-cafe will see more Indian names soon... The talks are recorded. I guess I should have dressed better.

After Debian Squeeze was released last weekend, development will speed up again.
Today I uploaded a new postfwd package which ships also the postfwd2 script, a prefork server version.
I also started to orphan packages I m not using anymore or having dead upstream. The first candidate was policyd-weight, fortunately Chris Butler took the package over.
I m happy to be the first uploader into squeeze-backports with . icinga.

Sponsoring a package means uploading a package for someone else (usually a new contributor starting out as package maintainer). This is an activity reserved to Debian Developer who are supposed to be knowledgeable about packaging. This article tries to document the process to ensure the sponsor is doing a reasonably good job according to Debian s standards. Sponsoring a package in the Debian archive is not a trivial matter. It means that you verified the packaging and that it is of the level of quality that Debian strives to have. Let s have a look to what you can and should do when you re sponsoring a package. Sponsoring the initial upload Sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Building the package and testing the software is definitely not enough! You should open every file in the debian directory and look out for potential problems. Here s a checklist that you can use to perform the audit:

• Verify that the upstream tarball provided is the same that has been distributed by the upstream author (when the sources are repackaged for Debian, generate the modified tarball yourself).
• Run lintian. It will catch many common problems. Be sure to verify that any lintian overrides setup by the maintainer is fully justified.
• Run licensecheck and verify that debian/copyright seems correct and complete. Look for license problems (like files with All rights reserved headers, or with a non-DFSG compliant license).
• Build the package with pbuilder (or any similar tool) to ensure that the build-dependencies are complete.
• Proofread debian/control: does it follow the best practices? are the dependencies complete?
• Proofread debian/rules: does it follow the best practices? do you see some possible improvements?
• Proofread the maintainer scripts (preinst, postinst, prerm, postrm, config): will the preinst/postrm work when the dependencies are not installed? are all the scripts idempotent (i.e. can you run them multiple times without consequences)?
• Review any change to upstream files (either in .diff.gz, or in debian/patches/ or directly embedded in the debian tarball for binary files). Are they justified? Are they properly documented (with DEP-3 for patches)?
• For every file, ask yourself why the file is there and whether it s the right way to achieve the desired result. Is the maintainer following the best packaging practices described by the Developers Reference?
• Build and install the packages, try the software. Ensure you can remove and purge the packages. Maybe test the packages with piuparts.

If the audit did not reveal any problem, you can upload the package. But remember that even if you re not the maintainer, the sponsor is still responsible of what he uploaded to Debian. That s why you re encouraged to keep up with the package through the Package Tracking System. Sponsoring an update of an existing package You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a more deeper look just in case the initial reviewer was sloppy. To be able to analyze the difference you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget). Read the new changelog entry, it should tell you what to expect during the review. The main tool you will use is debdiff, you can run it with two source packages (.dsc files), or two binary packages, or two .changes files (it will then compare all the binary packages listed in the .changes). If you compare the source packages (excluding upstream files in the case of a new upstream version, for example by filtering the output of debdiff with filterdiff -i '*/debian/*'), you must understand all the changes you see and they should be properly documented in the Debian changelog. If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (like some files dropped by mistake, missing dependencies, etc.). You might want to check out the Package Tracking System to verify if the maintainer has not missed something important. Maybe there are translations updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the NMU in his package. Maybe there s a release critical bug that he has left unhandled and that s blocking migration to testing. Whatever. If you find something that she could have done (better), it s time to tell her so that she can improve for next time. And so that she has a better understanding of her responsibilities. If you have found no problem, upload the new version. Otherwise ask the maintainer to provide you a fixed version.

---

This article will be repurposed to enhance the Debian Developers Reference, hopefully leading to a fix for the wishlist bug #453313. Click here and help me fix more of those. You re also welcome to suggest improvements in the comments. Are there other checks that you re always doing? Do you have some handy tip to make it easier to review a package?

7 comments Liked this article? Click here. My blog is Flattr-enabled.

LWN Coverage of Eben Moglen's FOSDEM keynote. A very thoughtful article on freedom and how to get there. While we can, technically, build these free systems that Eben Moglen talks about, history has shown that we won't. People don't care until it's too late until the police is on their doorstep with an arrest warrant (if the regime cares about such details at all.) So it's up to the small minority of people who actually cares and is prepared to pay the price (in money or in being isolated by not being on Facebook or whatever) to create systems that are both Free and also appealing to the uneducated masses. People will move to Free systems only when they're much cheaper and also offer more value as perceived by them, in terms of features, or coolness or whatever. Bling. We're almost there in terms of software (Firefox managed to get noticeable market share, and people at least talk about OpenOffice / LibreOffice.) We're nowhere close in terms of networks and content, though. Wikipedia and Openstreetmap are the rare exceptions, but there's not much in terms of social networking, searching, messaging, collaboration platforms etc.: all firmly in corporate hands. I'm not sure that Moglen's Freedom Box idea will succeed either: so far, I can't see the must have element for people who don't care about these things that might change the game.

The conference LCA 2011 had an anti-harassment policy [1] which was violated by a keynote speech. The speaker and the conference organisers apologised, but of course the matter didn t end there.Discussion continued on the lca-chat list (for conference delegates) [2], on the Linux-aus list (for members of Linux Australia the parent body of the LCA conference) [3], and in some blog posts.There is also some discussion on an LWN article that is linked from an ITWire article [4].I think that the policy was reasonable and from all the descriptions it seems to have worked reasonably well. With such things there are always possibilities to tweak things, so probably there will be future policies which are better in some ways, but it seemed to do the job. The way that the LCA organisers handled the situation was appropriate. In the discussion there were some comments with logical failures that I think need further analysis, I ll summarise them one per paragraph with the heading being a para-phrase of the claim.Is it Offensive?A particularly relevant blog post is Skud s post about avoiding the use of the word offense [5]. In the various discussions about the speech in question most of the people who disapprove of the erotic images don t use the word offense , this is presumably due in part to the influence of Skud s post. This hasn t stopped people claiming that the debate is about whether the images are offensive, I m not sure if this is a deliberate straw-man attack or just cluelessness.The anti-harassment policy does use the word offensive in two places, I think that this was a mistake but it doesn t detract from the overall meaning of the document.Is it Harassment?There was some discussion about whether the actions in question were harassment. Wordnet s definition of harassment includes the act of tormenting by continued persistent attacks and criticism . It seems unlikely that any of the people in the audience who objected to the erotic content in the lecture slides had never seen unwanted erotic material before. So I think that it s worth considering this incident as just another entry in a list of similar incidents that some of the delegates have experienced, and thus as a continuation of persistent attacks IE harassment. Melissa McEwan s post about the variety of harassment that she has received from men is worth reading in this regard [6].I think that a reasonable analogy here is the school bullying campaigns that were experienced by many members of the Linux community when they were younger. School bullying in most cases is not about a small number of extreme incidents, but about a large number of small incidents each of which when considered independently can be rationalised as something that isn t significant (excusing such incidents independently is what allows bullying to be rife in most schools). In many cases of high school bullying the victim is blamed for supposedly over-reacting after a reaction is compared to some small incident at the end of a long harassment campaign, some of the criticism of the Geek Feminists seems to echo this pattern.It seems to me that some of the more dismissive comments which demonstrated a lack of regard for the experiences of other people can reasonably be considered as harassment too (which is also something that Melissa McEwan mentions). Note that I am specifically not advocating that the discussion be shut down, merely that the people who claim that it s only the (supposed) opinion of the majority that matters are part of the problem. However the fact that the apology for the talk received applause from the majority of the audience seems to indicate that the majority is in fact in favor of the anti-harassment policy.Derald Wing Sue, Ph.D. and David P. Rivera (a doctoral candidate in counseling psychology) have written a couple of interesting short articles about this for Psychology Today. Bullying and Microaggressions describes bullying as more than physical violence and also discusses adult bullies [7]. The Power to Define Reality describes the way that the experiences of people who lack power can have the reality of their experiences denied [8] this one really relates to some of the discussions about harassment.But it s Legal!It has been claimed that the legal system works well in Australia and that Australian law should be the only necessary guide to content. A trivial counter-case that was noted in the discussion is the fact that pure sales presentations are not accepted at LCA and such presentations are certainly legal! There is a good precedent for prohibiting things that are legal as part of the conference speaker agreement.More generally the legal system changes slowly and still infringes on what many people in our community regard as basic human rights. There is no reason why an Australian conference should have as it s standards the bare minimum that is required by Australian law.It was pointed out that workplace social norms translate well between cultures, they are usually more stringent than Australian law requires and Australian workplace law is a lot more stringent than the laws relating to conferences and other public events. It seems to me that a presentation which would result in a visit from HR if given at the office shouldn t be regarded as suitable for a conference such as LCA.But there is a Balance of Men and Women in Erotic Pictures!The complaints are not about a lack of balance in the erotic material, but it s presence there at all. Defending the slides on the basis that there was a supposed balance of male and female misses the point that most people just want no erotic material in presentations at conferences.Also it seems to me that if there are pictures which aren t offensive then the way to demonstrate this would be to publish them and say look, they aren t offensive . If it takes 600 words in a blog post to justify the use of some images then that alone seems to be evidence that the images were poorly chosen.But the talk was EffectiveSome of the people who have commented on this issue mentioned that they couldn t remember what was said when the images in question were displayed. When images from the talk are remembered and the main content of the talk isn t that seems to be a failure of the talk.When a major sponsor of the conference complains and requests that the talk video never be published that also seems like a major failure of the talk.I think that the effective talks are ones that educate people and inspire them to do something positive and useful. A talk that inspires a discussion about whether the speaker deserves censure doesn t seem effective.There are claims that there is no way the talk could have made the point as well if it wasn t for the images in question. But I can t believe that someone who is capable enough to get awarded a keynote speaking position at a conference such as LCA is incapable of finding other images to make the same point.But Similar Images are on MTVWhen people want MTV content they can watch MTV.Why Can t we just try Educating Men?It was claimed that education works in dealing with such issues in corporate environments and sporting clubs. My observation of the corporate environment is that such training must be extremely rare in Australia, the Netherlands, and probably the UK due to the fact that none of my employers have done it. I have heard first-hand reports of diversity training from people who work in the US. I expect that the fact that people who fail diversity training in a corporate environment get a meeting with HR is a major factor in it s effectiveness.The long email discussions and blog comment threads when these incidents happen could theoretically be used as training. But when you have some men using multiple mailing lists and dozens of posts arguing without appearing to learn it seems clear that they are not about to learn anything no matter what education is offered. It seems to me that you could broadly divide the free software community into two groups, those who want to learn how to do things better (but who are unlikely to make gross errors anyway), and those who won t learn.Besides, having a keynote speaker at a major conference apologise should be educational.But Clueless Nerds Hit on GirlsI don t know why every discussion about the treatment of women ends up getting a mention of this supposed issue.But Women Could make False AccusationsIn any classification system you have to make some sort of balance between false-positives and false-negatives. If the aim is to get zero false-positives then the incidence of false-negatives will increase. So if the aim was to never ever have a false accusation brought against a man for sexual harassment then the vast majority of real harassment cases would result in no action at all.I don t think it s reasonable to expect that most women who are mistreated should suffer in silence just to reduce the possibility that men might be falsely accused.The Rape Statistics cited in the discussion may be InaccurateThere is no possible way of interpreting rape statistics to make it not be a serious problem, now matter how you analyse the available information it happens far too often and has a significant impact on the victim. Also the suggested reinterpretation of the statistics didn t contradict the claim that it is likely that there are multiple rape victims attending LCA. So interpreting the statistics in a different way to get different numbers doesn t change anything. Trying to diminish the significance of rape generally doesn t support any other arguments that you might make.There are things that you can just discuss for the heck of it and things which should be discussed with care (if at all) to avoid needlessly hurting people. In these sorts of discussions the right thing to do is to avoid debating the numbers as much as possible.I think that the numbers produced by RAINN [9] are as good as we can get.But I am very supportive of women in our communityIf you spend all your time arguing with women and don t listen to what they have to say then you really aren t supporting them.ConclusionAfter publishing this post I ll email the URL to a few of the men who helped inspire it, I will explain how disappointed I am and how I expect better from them. I encourage others to do the same.Also when such discussions happen I encourage men to vote in favor of the positions advocated by women. Writing a message that addresses points in the debate can be difficult and if the debate is rapid then you may find that every point that you might make has been made by someone else. But in that case just posting to agree with the women can really mean a lot.

• [1] http://lca2011.linux.org.au/about/harassment
• [2] http://lists.followtheflow.org/pipermail/chat/2011-January/001722.html
• [3] http://lists.linux.org.au/pipermail/linux-aus/2011-January/018431.html
• [4] http://www.itwire.com/opinion-and-analysis/open-sauce/44803-linux-australia-members-abused-over-pesce-keynote?start=1
• [5] http://infotrope.net/2009/08/05/action-and-reaction-on-avoiding-offense/
• [6] http://shakespearessister.blogspot.com/2009/08/terrible-bargain-we-have-regretfully.html
• [7] http://www.psychologytoday.com/blog/microaggressions-in-everyday-life/201101/bullying-microaggressions
• [8] http://www.psychologytoday.com/blog/microaggressions-in-everyday-life/201010/the-power-define-reality
• [9] http://www.rainn.org/

Now that maintain several dozens of packages in Debian, I think twice before uploading a new one. Does it have a future, a public ? Some of the packages I prepare are available on git.debian.org, and are listed in Debian Med's tasks pages. It would not take me long to finish most of them, but that does not take into account the time others will spend on it. They will make our archive bigger and our quality tests longer to execute. Somebody will translate their description. Somebody else will perhaps write a security patch someday, or a patch to make the package compilable with a new version of GCC. All in all, each package has a footprint in Debian's ecosystem. That footprint starts early, as soon as the package is sent to the NEW queue. For instance, I kept by mistake some old content in the copyright file of clustalw, that was recently freed and has to go through the NEW queue to be transferred from the non-free to the main area of our archive. That costed a small of exchange of emails, that could have been avoided. Our packages should be perfect, but that is difficult to achieve alone. For that reason, I proposed two years ago a package review system, that functions like a chain reaction. The principle is simple. After uploading to the NEW queue, download two neighbor packages and check their copyright file. The errors found can be corrected by their maintainer before the the FTP team inspects it, which save their time. For instance, after uploading tabix, I found an error in mediathekview, that was corrected. That compensates for my mistake with clustalw. If each person receiving a package review does a review of two other packages, that will create a chain reaction that will clean the queue from the simplest mistakes, leaving only the really problematic cases. As Torsten noted recently, the NEW queue is getting long. So how about trying to help ?

The backports team is proud to announce the next generation of backports:
squeeze-backports. From now on all contributors will be able to upload
backports of packages available in wheezy (testing) to squeeze-backports.
Additionally the previously announced lenny-backports-sloppy is now officially
open for uploads.

To ensure the basic principle that a system consisting of lenny plus
lenny-backports can be upgraded to squeeze proper, the handling of the
lenny-backports branch has changed. From now on uploads to lenny-backports
need manual approval from a backports team member similar to the handling of
the proposed-updates queue within the regular archive. Feel free to upload
packages here, especially security updates to previously backported versions,
but please ensure the versions are lower than those in stable /
stable-security.

If you feel the need of newer versions for lenny than which are available in
squeeze, please do upload them to lenny-backports-sloppy. The rules for this
suite are practically the same as for squeeze-backports: Do base your uploads
on packages available in testing (wheezy) and build them in the appropriate
environment.

Please remember when using lenny-backports-sloppy you can't easily upgrade to a
plain squeeze. This suite is specificly meant to contain newer versions than
squeeze. While the aim is to only carry packages that will also be provided in
squeeze-backports for upgrade possibilities, we can't guarantee that, so be
careful.

User visible change to squeeze-backports

As the apt maintainers had been so kind to introduce a new archive wide option
in squeeze, the usage of backports.debian.org is easier than ever before: In
the past you had to explicitly configure pinning for the backports repository
to enjoy the full feature set including upgrades to new versions of packages
you had installed from there. As this is cumbersome, errorprone and a nuisance
this new setting got introduced. With this feature backports get handled in a
way that updates for packages installed from squeeze-backports will happen out
of the box.

And last but definitely not least, let us send a big "thank you" to all
contributors that backports.debian.org enjoys to have - you made it possible to
serve more than 1400 binary packages through 837 source backports since
lenny-backports got kicked into life. Keep up the good work.

Thank you very much!

Here comes the forth Debian XSF News issue! I usually try to keep the items sorted chronologically (but grouped by topic when possible), so if you re wondering about the current status of X in unstable, make sure you read the last entry.

• I prepared a reference documentation about dependency handling between the X server and the drivers. It describes both upstream and Debian sides, and documents the mechanisms to get the dependencies right. If you maintain an input or a video driver for X, you really should have a look into it.
• I also announced the changes on debian-boot@ since the Graphical Installer is also concerned.
• Since there are some drivers which aren t maintained by the X Strike Force, I mailed almost all maintainers (plus the ones I missed) to keep them posted. Further coordination will go through a mail alias (which means a little less overhead than running a mailing list; mail me if you want to be added).
• I prepared a great clean-up of the drivers, and published a status report 3 days later.
• In order to keep track of people working on X packages these days, I started pinging the Uploaders of X packages. Thanks again, folks!
• On the driver side, I moved the xserver-xorg-video-dove driver to the attic (where we move repositories of unmaintained packages), since it was only ever uploaded to Ubuntu, and not really maintained upstream. I also moved 7 drivers there, and requested their removal through RM bugs (each bug contains a link to the git repository in the attic in case someone wants to revive a driver): xserver-xorg-input-citron, xserver-xorg-input-evtouch, xserver-xorg-input-fpit, xserver-xorg-input-hyperpen, xserver-xorg-video-nv, xserver-xorg-video-radeonhd, xserver-xorg-video-v4l.
• Julien Cristau also requested the removal of xprint and xprint-utils. He also orphaned xresprobe since it s of no use as far as X is concerned, but still seems to be of some interest to DebianEdu folks.
• I requested an update of debian-x@ s description. We haven t been doing any Debian XFree86 packaging in a while.
• I requested help from GNU/kFreeBSD and GNU/Hurd folks, and got replies from Petr Salinger and Dave Airlie. Now mesa builds again on kfreebsd-amd64 (and kfreebsd-i386 once the remaining glitch is fixed).
• In the same mesa upload, I enabled the r600 Gallium driver, and cherry-picked a commit to fix the crash at X s start-up with r300 and UMS.
• I merged the xsf-docs.git repository (source for XSF documentation at http://pkg-xorg.alioth.debian.org/) into the xorg.git one, and moved the former to the attic. Starting with xorg/xserver-xorg 1:7.6+2, XSF documentation is shipped in the xserver-xorg package, in the /usr/share/doc/xorg directory, in HTML, PDF, and TXT formats.
• I also added a bug control file (as documented in reportbug s README.developers) to xorg, telling reportbug to also report information related to the xserver-xorg package. This means we get xserver-xorg-core s version, along with the drivers. I also made xorg depend on xserver-xorg with the same version, to make sure that upgrading xorg means upgrading xserver-xorg as well (and xserver-xorg-core ultimately, since xserver-xorg pulls a given version of the server).
• Julien also uploaded a few libraries and mesa-demos (new source package for mesa-utils) to unstable. I also uploaded the latest pixman to unstable.
• A few hours before squeeze got released, I prepared the big move of the X server from experimental to unstable. For the record that meant uploading libdrm, libxfont, and mesa as prerequisites. I then pushed the locally-built packages in a local archive to use from my sbuild chroot, to get xorg-server built. Subsequently, I built 45 drivers against it. The xorg metapackage was also prepared. All in all, that meant 200MB worth of Debian packages (including 130MB for mesa alone ), which sat on ravel.debian.org until the squeeze release announcement. Unfortunately, lintian s #612137 triggered an automated rejection of all drivers. Options seemed to be: adding build dependency noise to debian/control for all drivers; or adding lintian-overrides noise to all drivers; or waiting for some reaction from lintian s maintainers or from ftpmasters. I picked the last option for now, since I m very reluctant to do extra and pointless work on 45 packages to get them accepted when the reason for the rejection is buggy. Hopefully this will be sorted out soon, and I ll be able to upload the same packages again. If one feels the urge of installing X11R7.6, picking drivers from experimental will do the job.

As we're slowly heading towards phpMyAdmin 3.4, it is good time to look at current translations state. There are few which are already at 100%, so they are in best possible shape:

• Czech
• English (United Kingdom)
• French
• Slovenian
• Turkish

Some languages really miss just few messages, so they will hopefully get to 100% soon:

• Swedish
• Greek
• Chinese (China)
• Catalan

And there is huge progress in Russian, which will at this pace get to 100% this week. Was your language not listed? You can help it being better!

Filed under: English Phpmyadmin 0 comments Flattr this!

So Debian squeeze has finally been released and it is time to look toward to what we might work on or want to happen for the next release, codenamed Debian wheezy. An informal discussion on IRC mentioned libburnia libraries and apps, finishing DEP5, objnam, wayland, multiarch, Matthew Palmer plans to work on netcfg, ifupdown and the KDE team plan to remove Qt3/KDE3. I personally plan to work on catching up with my packages, the removal of defoma, boosting the Debian games team, improving collaboration with derivatives, changes to the Debian wiki, reviewing more packages mentioned on debian-mentors and more. I am really excited to see the cross-distro collaboration of Enrico Zini and others in bringing application management to Linux distributions, the multiarch work by Steve Langasek and others and hopefully optimistic about the recent discussions of automated post-install testing. I probably will not work on almost all of these but I would like to see multiarch, cross compiliation, widespread systemd integration, netconf revival, porting to phones/tablets, OEM mode and media for d-i, partitioning improvments for d-i, widespread automated post-install testing, expansion of daca, deployment of debexpo, widespread adoption of PET, automated removal of bad packages, better pro-active security measures, building all packages on buildds, migration away from Debian-specific stuff in favour of cross-distro solutions, addition of new UI experiences (like MeeGo, Android, Unity, QtMoko), addition of new APIs for portability (like Android, Khronos, MacOS/iOS stuff), more interesting/weird ports, merging derivatives into Debian, better integration of Debian Pure Blends, removing non-free packages where free alternatives exist, ex-developers and MIA folks returning to Debian, expansion of the backports repository, fixes for lots of bugs and probably other things I forgot. What are you going to work on? What do you wish you could work on? What work are you hoping others will do? What work are you excited about that others are doing?

mythbustering a Debian release This is no news anymore, but in case you don't know yet: Debian 6.0 "Squeeze" has been released the past week-end. If you haven't yet downloaded Squeeze, stop reading this blog post right here and jump to: to choose your ISO; or check the release notes for upgrade instructions from Debian 5.0 "Lenny". Done?
Cool!
I hope you are now enjoying Squeeze as much as I've enjoyed being part of its development cycle which:

• has lasted 24 months from the Lenny release
• has been worked on by a volunteer Project of about 900 members and thousands of other volunteer contributors
• has closed 150'000 bugs
• has increased user freedom by delivering a Free Linux kernel
• has added 2 non-Linux ports (kfreefbsd 32/64 bits) to the already large family of Debian ports
• will continue the tradition of archive-wide long term security support (lasting about 3-3.5 years given current Debian release cadence)
• maintains, stubbornly, the tradition of a rock-solid Debian-quality system, made of packages which have been "tortured" by testing utils like piuparts, edos-debcheck, and frequent archive rebuilds (after all, what is Free Software for if you cannot recompile your programs?)
• has added 10'000 new (binary) packages
• has provided official backport service
• ... etc, you got the idea

I'm still shaked by the events, given the release happened in a sort of split context: the teams working on the final phases of the release (release team, ftp-masters, webmasters, cd, DSA, etc.) were "at home" hacking frantically on it, while many EU-based Debian people (including yours truly) were at FOSDEM representing Debian to the community with booth, talks, and answering the recurrent question so, have you released yet? . At FOSDEM, I've been personally submerged by congratulation messages that are not really for me, but rather for the Debian community at large. So: congratulations folks! People out there be them Debian users, users of some derivative, or Free Software enthusiasts in general seem to really love what we have achieved with Squeeze! The people that need to be thanked for this result are way too many, so I won't try to name names. Nonetheless, I've a few personal kudos to deliver to:

• The release team for the fantastic coordination and communication job over the past few months. They have also contributed to mythbustering #1: Debian cannot fix a release date (a bit) in advance.
• All the people who have worked on fixing RC bugs by sending patches, reviewing and testing them, preparing NMUs, etc. I'll never give up my belief that releasing is a shared responsibility and that we cannot scale without realizing that and changing our culture accordingly. All this people have contributed to move towards mythbustering #2: NMUs are bad.
• The publicity team which with release live blogging via @debian, blog posts, and press releases have contributed to mythbustering #3: Debian isn't able to communicate about the "cool" stuff they are doing.
• The webmaster team which has done an incredible job at mythbustering #4: Debian web presence sucks.

I'm overwhelmed by happiness about all that and I'll cherish it forever as a souvenir of what a community of volunteers, driven by common ideals, can achieve. Now let's party and then roll up our sleeves for Wheezy, which is already open for development.

---

PS I've talked again at FOSDEM about the relevance of Debian in the Free Software ecosystem. I've the impression the message is getting through: check out the very nice article Why Debian matters more than ever by Zonker.

The last weeks before a Debian release are usually boring with respect to working on new stuff since unstable is pretty much closed to development. Now that the release is finished, this fun is back \o/ I have been in an upload frenzy since yesterday night and I have updated some packages in unstable: KOffice[1] and KOffice-l10n 2.3.1, yakuake, rsibreak and tintin++. Another of my packages, kid3, got magically updated itself in unstable before I had time to look at it, the magic of having active co-maintainers. [1] Thanks for the gentle push to update this, Pino :) I also emailed one of my upstream maintainers to ask him about the KDE 4 version of his application and he will likely make a release soon. One of the goals for wheezy is remove completely KDE 3 and Qt 3. If you are maintaining a KDE 3 or Qt 3 based application, we are about to start annoying you about this! See http://wiki.debian.org/kdelibs4c2aRemoval and http://wiki.debian.org/qt3-x11-freeRemoval The last 2 weeks before the release I had some fun watching how the Squeeze release countdown banner I published at http://news.debian.net spread to a lot of websites, personal blogs, community sites, forums to news portals.
The traffic has been increasing little by little through the 2 weeks the banner has been online and currently is still moderately high, since people keeps retweeting the news item about the Debian release. While writing these lines, the banner has been served 449575 times to a total of 244975 unique IP addresses!

This is my first blog post on my new tarent blog which I am using as a replacement for blogspot. We had 451 new source packages in the NEW queue tonight. It is nice to know that Debian is the largest free software distribution but it will take some time until we (the ftp team) have processed all those new packages as we need the check every single package. I wanted to work on dak (the Debian archive kit) again after we have released Squeeze but I ll give NEW processing a higher priority. My next plan for dak is generating the contents files in dak directly instead of using apt-ftparchive. Contents generation is the slowest part of apt-ftparchive and having the package contents in dak s database is quite useful.

I m glad that 5 years after the facts, people are still not getting them straight. The Firefox logo was not under a free copyright license. Therefore, Debian was using the Firefox name with the earth logo (without the fox), which was and still is under a free copyright license. Then Mozilla didn t want the Firefox name associated to an icon that is not the Firefox icon, for trademark reasons. Fair enough. Although at the time Debian had concerns with the trademark policy, there was no point arguing over it, since Debian was not going to use the logo under a non-free copyright license anyway. Now, it happens that the logo has turned to a free copyright license. Request for a trademark license was filed a few weeks after we found out about the good news, and we are still waiting for an agreement draft from Mozilla to hopefully go forward. It is still not certain that this will actually lead to Debian shipping something called Firefox some day, but things are progressing, even if at a rather slow pace, and I have good hope (discussions are promising). By the way, thank you for the nice words, Daniel.

The Ubuntu website states that we aim to make Ubuntu a wonderful place to participate . We developed the Ubuntu Code of Conduct to set a standard for participants to accept each other in the spirit of cooperation, and have improved it over time to state these principles more clearly. It is implicit in our philosophy that these and other Ubuntu values should hold equally true for everyone. I would like to propose that we upgrade this to an explicit statement on behalf of the project. I have spoken with many people who were interested in joining a free software project, but were put off because they felt unwelcome. I know various people who participate in Ubuntu today, but sometimes face difficult social obstacles in order to do so. Going forward, I would like for us, as members of the Ubuntu community, to make the extra effort to accept all kinds of people. This may sound simple, but it can be very difficult to put into practice. People often don t even notice they ve gotten it wrong, until the offended party points it out to them. We need tools and guidance to make this a reality. To that end, I would like to propose a diversity statement for Ubuntu. This draft has already received support from a majority of the Community Council, but I d like to take it a step further. Because I want this to be a commitment that we can all stand behind, I m also calling for support from the community as a whole. Please give this issue your consideration, and let me know in the comments if you can get on board with an official statement like this. The more support we have, the more real this commitment can be. Here s the text. Many thanks to Mary Gardiner, Valerie Aurora and Benjamin Mako Hill for their review and input.

The Ubuntu project welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining. Although we may not be able to satisfy everyone, we will always work to treat everyone well. Standards for behavior in the Ubuntu community are detailed in the Code of Conduct and Leadership Code of Conduct. We expect participants in our community to meet these standards in all their interactions and to help others to do so as well. Whenever any participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong. Although this list cannot be exhaustive, we explicitly honor diversity in age, culture, ethnicity, genotype, gender identity or expression, language, national origin, neurotype, phenotype, political beliefs, profession, race, religion, sexual orientation, socio-economic status, subculture, and technical ability. Some of the ideas and wording for this statement were based on diversity statements from the Python community and Dreamwidth Studios (CC-BY-SA 3.0).

FOSDEM ended yesterday and here I am sitting at Charleroi Airport (also known as Brussels South , quite a misleading name given that it s 80 Km from Brussels). I have already passed all controls, check-in and everything. While I wait for boarding, I am watching the shameful spectacle of airport personnel (let me reiterate that: airport personnel, not Ryanair s) enforcing RyanAir s 10 Kg cabin baggage limit. According to RyanAir, they want to minimize the weight the plane carries to use less fuel. So far, so good. Here is what I have seen: people who do not carry any baggage (very few, they have probably checked it in because it exceeded size or weight), people who are below the 10 Kg limit and people who are way over it (and have been told to check luggage in). I am OK with those cases. There is still a fourth case: people who are slightly over 10 Kg. I ve seen a woman whose bag was 10.15 Kg to be told to pay 20 EUR to check her bag, or go back to the RyanAir desk to check-in the bag. She opened her bag, took a scarf, put it on and now the bag matched the weight limit. Yes, RyanAir is charging 20 EUR/Kg for hand baggage from 10 Kg on. What a rip-off. A couple of East-European girls were about 1 Kg in excess each. They put a couple of extra jumpers on and now baggage was under 10 Kg. Many people were about 1 Kg in excess. When they were told their suitcase better got lighter or pay 20 to 40 EUR. Most of them just took something (camera, food, slippers, whatever) and put in the pockets of their coats. Fortunately, RyanAir is not charging for body and clothes weight (yet?). In all those cases the plane will end up transporting the same weight and RyanAir won t get one more dime, so why RyanAir? Why are you such a shameful company? Why are you enforcing ludicrous and pointless policies? Don t you know after passing the control everybody just put everything back into the suitcase? Of course you do. So after watching this ridiculous spectacle go on for a while, I had a devious idea: let s organize a fat people conference and fly them all over to and from using RyanAir. Further, all of them should carry exactly 10 Kg hand baggage.