Yay! As others have started posting in Planet Debian, I'll do my part: Yesterday I finished booking our flights, so if everything goes as planned, Reg and me will be arriving to Zagreb (Croatia) at 21:30, Monday July 18, to take part of the 12th Debian development conference, DebConf11, in Banja Luka, Bosnia & Herzegovina! Of course, reiterating this will never hurt: Do you want to support a global-scale, well-recognized, community-based Free Software project development? Be a sponsor for DebConf11!" Want some more DebConf11 banners and posters?

liw recently wrote about test-driven development:

This all sounds like a lot of bureaucratic nonsense, but what I get out of this is this: once all tests pass, I have a strong confidence that the software works. As soon as I've added all the features I want to have for a release, I can push a button to push it out

To my mind, this is only one of the benefits. He doesn't describe another major benefit, which is the confidence with which you can take on re-factoring in projects with well-developed test infrastructure. If your project has no test infrastructure at all, and you make a deep and/or potentially invasive change, you might well produce something that is heinously broken for users who have a different pattern of using the tool than you do. But if you have a well-developed, reasonable test suite with fairly wide coverage, you can make a deep or invasive change, and be confident that -- if the tests all pass -- the stuff you release isn't going to be too horrific. And if you do break something with a change which the test suite didn't cover, that's an indication that the test suite is lacking. Hopefully, you can factor out a problem report into its own test, so that future changes will ensure that the behavior doesn't regress too. The upshot of more-confident re-factoring is that your development can be much bolder, you can roll out new features more quickly, and you can spend less time agonizing about whether you've got the various abstraction layers exactly right the first time through. These are all good things (though i do think the agony of abstraction perfectionism is well-warranted in some contexts, like API definitions, and wouldn't want test-driven development to make people give up on that necessary task). when testing can't cover everything Some things are just hard to test well. for example, if you have 20 different boolean options to a command-line tool, you can't realistically test them in all combinations and permutations; that would be over a million tests. User experience is also notoriously difficult to test, as are tools that rely heavily on network interaction, which can be flakey and unpredictable. other downsides Test suites themselves require maintenance, as the components they rely on can change over time. More than once, i've had a test suite failure that was really a failure of the test infrastructure, not the code itself. But in those same projects, that's usually followed or preceded by a test suite failure that picks out a particularly nasty or subtle bug in the tested code that might have persisted for quite a while unnoticed. So the test suite does in some sense create more work all around. more and better testing is good for Debian Even when we know that coverage isn't perfect, and even with its additional overhead, well-integrated tests (at the unit level and more generally) are worth the tradeoffs. It's worth doing because of the robustness and guarantees that we can give each other with regularly-tested code. It's a more stable foundation which surprisingly also gives us more flexibility going forward. This is good for free software in general. It also helps us find our bugs before our users do, so it's better for our users. So more and better testing directly supports the two main priorities outlined in the Debian Social Contract.

We re in that in-between place where there is plenty of IPv4 out there, but sometimes you either need or want to get to IPv6 addresses. With the IPv4 address allocations out of ARIN now empty there is going to be an increased need of NAT either between the address families or within it. This is a quick overview of the different sorts of systems that do this address translations. 6tunnel The best way to describe this is port forwarding across the address families. You can have a IPv4 port on your local device that when you connect to it forwards the connection via IPv6 to a remote device, perhaps on a different port. You can also do it the other way, so connecting to a local IPv6 port will connect to a remote IPv4 port. Of course remote could be another port on the same computer. Squid You could replace squid with any other sort of proxy server that can work as a reverse proxy and understands IPv6. From the deployments I ve heard of, this arrangement where the IPv4 only webservers are front-ended with a dual stack IPv4/IPv6 squid (or other) reverse proxy server or set of servers. It is a real simple way of getting your webserver onto IPv6, if you cannot do it in the webserver itself. The usual advantages and disadvantages of using a reverse proxy apply here. The better long-term solution is to have the servers just run IPv6 natively, but this is a reasonable stop-gap. That s a brief overview of the various packages out there that can help with address translation to either get your servers understanding IPv6 or a client to get to an IPv6 server. Ideally these are only temporary measures but as some methods people use to write programs (the latest I ve seen has weird hard-coded 4 byte offset tree-table with 256 long list inside good luck fixing that!) they may be temporary for some time. Tayga This program implements NAT64 which is a 1:1 address translation. It can work both ways so IPv6 clients can connect to IPv4 servers and vice-versa. You would normally use this for your own hosts, rather than for connecting to the internet as you need to specify prefixes. It works like the old style static nat ranges in IPv4 where 1.1.1.10-100 would map to 2.2.2.10-100 tnat64 Now this package is a little back-to-front to the others in that it takes an existing IPv4 only application and makes it able to connect, at least at the socket level, to a IPv6 server. It works by preloading a library which overloads the socket functions like socket() and connect() so it can attempt to find IPv6 servers. totd This is a small DNS proxy which can be used to translate IPv4 A records to IPv6 AAAA records. You often use it with translation technologies like Tayga.

Related articles

• A Sandbox to Test IPv6 Courtesy of OpenDNS (readwriteweb.com)
• With no (or few) more IPv4 addresses, where s the IPv6 traffic? (arstechnica.com)
• What works, and what doesn t work, with IPv6 (zdnet.com)
• IPv6 Addressing (blogs.cisco.com)
• It s official: Asia s just run out of IPv4 Addresses (zdnet.com)

Steve Kemp recently announced his resignation from Debian. That left a few of his packages without a maintainer, one of them was Chronicle. As a Debian Developer using Chronicle, I've adopted this package. The upstream development will still be mostly done by Steve. The packaging is done in a Git repository. The 4.6-1 upload consists of a new upstream version and some housekeeping stuff on the packaging side (like switching to a minimal debian/rules, fixing some Lintian warnings and complying with the latest version of the Debian Policy). I'd like to take this opportunity and thank Steve for all his work for Debian. Hopefully he'll be back to Debian in the future.

One important aspect of the mancoosi project is to build a model of the installation process in order to simulate packages upgrades before committing the changes on the machine. This work described here and here (and in upcoming publications) relays on the availability installation plan of the meta-installer (the exact order in which packages will be installed, configured and removed ) to run a simulation of maintainers scripts and check for potential problems accordingly to the model. Thanks to the help of Julian Andres Klode upstream and maintainer of the python-apt bindings it is now possible to extract the installation plan from apt-get without resorting to debug printout or other hacks. A forthcoming integration with mpm (Mancoosi-Package-Manager, our testbed meta-installer) will give us the possibility to hook the model checker to the meta-installer and to run it before every upgrade. The two important changes in the python-apt bindings that will make this possible are the new bindings to the class OrderList and the sub-classing of the class package manager. PackageManager . Regarding the latter, this is a small example (thanks again Julien !) that you can use to get the installation plan as computed by apt-get. In theory, this will also allow to experiment with different back-ends (like rpm - blah ! :) ) easily without the need to hack the c++ code. And this is the result on my machine :

It's time to report again progress on phpMyAdmin translations. I will make it shorter this time :-). There has been great progress in translation progress. Japanese translation is near completing (only 55 messages are missing right now) thanks to Yuichiro who did tremendous work there. There is also ongoing effort for Sinhala translation lead by Madhura Jayaratne. Nevertheless the number of complete translations is still 14 (see my previous post for complete list). Besides translating phpMyAdmin itself, there was lot of work on translating documentation, so we now have complete documentation translated to Spanish and very good progress on Chinese one. As the final release of 3.4.0 is really close, anybody is welcome to translate missing bits. Any Norwegian, Polish or Finnish readers of this blog? I'm sure you can still make your translation complete! (Others are welcome as well of course.)

Filed under: English Phpmyadmin 0 comments Flattr this!

Since this has been a major request from users for a long time, I can only cool with the idea of seeing the Debian project support a rolling release. However I m not pleased with the proposed ideas, since they don t actually include any serious plan to make this happen. Sorry guys, but a big GR that says We want a pony rolling release to happen doesn t achieve anything. Let me elaborate. First of all, discussions have focused a lot on what to do when we re in a freeze phase. Numerous cool ideas have been proposed, including PPAs (which again, won t happen until someone implements them). This is all good, but this is only the tip of the iceberg. Above all, before wondering what can happen in a freeze that lasts 20% of the time, let s wonder what can happen for the 80% remaining time. Once you have something that works in the regular development phase, you can tune it to make it happen, even if in a less optimal way, when the distribution is frozen. So let s not put the cart before the horse. There are three options if you want to make a rolling release happen.

1. Make unstable usable. to make it happen, you have to prevent the disasters that rarely but unavoidably happen here. You don t want to make all rolling systems unusable because someone broke grub or uploaded a new version of udev that doesn t work with the kernel.
2. Make testing usable. This sounds easy since RC-buggy packages are already prevented from migrating, but actually it is not. A large number of RC bugs are discovered at the time of testing migration, when some packages migrate and others don t. Worst of all, they require several days to be fixed, and it is very often that they require several months, when one of the packages gets entangled in a transition.
3. Create a new suite for rolling usage.

The proponents of the CUT project obviously believe in option 2. Unfortunately, I haven t seen many things that could make it happen. A possible way to fix the situation would be to run large-scale regression testing on several upgrade paths. I don t know if there are volunteers for this, but that won t be me. That would also imply to make a lot of important bugs RC, since they could have a major effect on usability, but the release team will not be keen to make it happen. Because of the testing situation, when someone asks me for a rolling release, I point her to unstable with apt-listbugs. As of today, this is the closest thing we have to a rolling release, so we should probably examine more deeply option 1. Is it that complicated to write a tool to prevent upgrades to broken packages? A 2-day delay in mirror propagation and a simple list of broken packages/versions (like the #debian-devel topic, would be enough. Add an overlay archive, that works like experimental, and you can now handle freezes smoothly. Wait isn t that aptosid? We would probably gain a lot of insight from the people who invented this, instead of trying to reinvent the wheel. Finally, option 3 could open new horizons. There s a risk that it might drive users away from the testing and unstable suites, and this makes us wonder how we could have proper testing for our packages. Still, build a process that would (and that s really only an example) freeze unstable every month, give people 10 days to fix the most blatant issues, add a way to make security updates flow in from unstable, and you have a really nice rolling distribution. So overall, it only requires people to make things happen. You want option 2 to happen? Instead of working on GR drafts, start working with maintainers and release managers on ways to avoid breakage in testing. You want option 3 to happen? Start it as a new .debian.net service and see how it works. Personally, I d be in favor of offering aptosid developers to become DDs and offer their solution as a Debian service. It would bring in new people rather than driving away existing developers from working on our releases.

This is my monthly summary of my Debian related activities. If you re among the people who support my work, then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. GNOME 3 packaging Right after the GNOME 3 release, I was eager to try it out so I helped the pkg-gnome team to update some of the packages. I did some uploads of totem, totem-pl-parser, gvfs, mutter, gnome-shell, gnome-screensaver. I also kept people informed via my blog and prepared a pinning file for adventurous users who wanted to try it out from experimental (like me). One month later, I m still using GNOME 3. There are rough edges still, but not so many. And I m starting to get used to it. Debian Rolling planning Debian Rolling is a project on my TODO list for quite some time. I decided it was time to do something about it and started a series of articles to help clarify my ideas while getting some early feedback. My goal was to prepare a somewhat polished proposal before posting it to a Debian mailing list. But as usual with Murphy s law, my plan did not work out as expected. Almost immediately after my first post the discussion started on debian-devel:
At this point it s a discussion thread of several hundreds of messages (there are several screens of messages like the one above). Many of the sub-threads have been interesting, but the general discussions mixed too many different things so that there s no clear outcome yet. Lucas Nussbaum tried to make a summary. Obviously I must adjust my plan, there s lots of feedback to process. I accepted to drive a DEP together with Sean Finney to help structure the part of the discussion that focuses on allowing development to continue during freezes. But I m also eager to fix the marketing problem of testing and have the project recognize that testing is a product in itself and that end-users should be encouraged to use it. Package Tracking System maintenance The Package Tracking System is an important tool for Debian developers, and it has been broken by some change on the Bug Tracking System. I worked around it quite quickly so that few people noticed the problem but Cron kept reminding me that I had to properly fix it. I ended up doing it last week-end. While working on the PTS, I took the opportunity to merge a patch from Jan Dittberner to enhance the news RSS feed that the PTS provides. And I also integrated information from backports.debian.org (thanks to Mehdi Dogguy for reminding me #549115). Multiarch update Not much new this month. I fixed two bugs in the multiarch dpkg branch thanks to bug reports from Ubuntu users (LP 767634, LP 756381). I m still waiting on Guillem Jover finishing his review of the multiarch branch. I m pinging him from time to time but it looks like multi-arch is no longer in his short term priority list. I ve been running this code for more than 2 months and it works fine. I want to see it merged. I m ready to update my code should anything need to be changed to please Guillem. But without any feedback we re in a deadlock. Misc dpkg work While fixing a bug in update-alternatives (found in one of the valid reports on launchpad), I noticed that there was room for improvements in the error messages output by update-alternatives. I changed them to reuse the same strings that were already used in other parts of dpkg. The result is that there are a few strings less to translate (always a nice thing for the poor translators who have to deal with the thousands of strings that dpkg contains). I also tried to fix some of the most cryptic error messages in dpkg (see #621763) but that work is stalled at the request of Guillem. Book update We (me and Roland Mas) are almost done with the update of our French book for Debian Squeeze. It will hit the shelves in July or September. I m starting to prepare the fundraising campaign to make an English translation of it. We ll use ulule.com for this. On my blog I have been pleased to interview Meike Reichle, it s the first women that I have interviewed in the series but it s certainly not the last one. I also interviewed Adam D. Barratt, one of our tireless release managers. Thanks Many thanks to the people who gave me 180.35 in March and 235.37 in April. That represents 1.5 and 2 days of work for those months. See you next month for a new summary of my activities.

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

I mourn the loss of thousands of precious lives, but I will not rejoice in the death of one, not even an enemy. Returning hate for hate multiplies hate, adding deeper darkness to a night already devoid of stars. Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. anonymous (often attributed to Martin Luther King, Jr.)

Seen many times today.

I look forward to Ubuntu s semiannual release day, because it s the completion of 6ish months of work by Ubuntu (and by extension Debian) developers.I also loathe it, because every single time we get people saying This Ubuntu release is the worst release ever! .Ubuntu releases are always rocky around release time, because the first time Ubuntu gets widespread testing is on or after release day.We ship software to 12 Million Ubuntu Users with only 150 MOTUs who work directly on the platform. That s a little less than 1 developer with upload rights to the archive for every 60,000 users.¹ Compared to Debian, which (at last estimate in 2010) had 1.5 million uniques on security.debian.org, yet has around 1000 Debian Developers.Debian has a strong testing culture; someone once estimated that around of Debian users are running unstable or testing. In Ubuntu, we don t have good metrics on how many people are using the development release that I m aware of (pointers welcome), but I d guess that it s a very very small percentage. A common thread in bug reports, if we get a response at all, goes on as follows:

Triager:² Is this a problem in $devel?

User: I ll let you know when it hits final

Triager: It s too late then. Then we ll want you to test in the next release. We have to fix it BEFORE its final

User: Ok, I ll test at beta.

Triager: That s 2 weeks before release, which will be too late. Please test ASAP if you want us to have time to fix it Of course, there are really important bugs with hardware support which keep on cropping up. But if they re just getting reported on or around release day, there are limits to what can be done about them this cycle.We need to make it easier for people to run early development versions, and encourage more people to use them (as long as they re willing to deal with breakage). I m not sure whether unstable/testing is appropriate for Ubuntu, and I m fairly confident that we don t want to move to a rolling release (currently being discussed in Debian, summary). But we badly need more developers, and equally importantly, more testers to try it out earlier in the release process.To users: please, please try out the development versions. Download a LiveCD and run a smoketest, or check if bugs you reported are in fact fixed in the later versions. And do it early and often.

1. This number, like all other usage data, is dated, and probably wasn t even accurate when it was first calculated
2. Developer, bugcontrol member, etc. Somebody who is not experiencing the problem but wants to help.

• Go to the Debian Mozilla Team page.
• Select the Debian version you are running, Iceweasel and the version, 5.0 .
• Follow the instructions.
• Profit.

Only amd64 and i386 packages are available. Note that there is another Iceweasel version available there: aurora . Currently, this is the same as 5.0 , but whenever Firefox 5.0 will reach the beta stage, aurora will be 6.0a2. Please feel free to use aurora if you want to keep using these pre-beta builds.

There seem to be lot of momentum in discussions about making Debian testing more attractive to users on debian-devel mailing list (see Lucas's summary for summary of the lengthy discussion). One of the raised points there is that Debian misses equivalent of Ubuntu's PPA or openSUSE build service. As Debian is usually about do-ocracy, it will be there once it will be implemented, but I still don't think it is always useful to have such thing. The problem with both (but this is especially the case for openSUSE build service) is that you need to add dozens of home: projects with questionable quality of the software. This usually leads to horrible mess, especially in case of incompatible libraries with different build options (anybody using wxWidgets?). It can definitely lower barrier for people to create packages for the distro, but is it really good to lower barrier that much? I'd really prefer new things to be uploaded to Debian itself without need to use any external repositories, it would ensure at least some level of quality and compatibility with other packages.

Filed under: Debian English Suse 5 comments Flattr this!

Here is my attempt at a summary of the rolling discussion currently happening on debian-devel@. It might not be complete, it s probably a bit biased, but I hope that it s still better than nothing. It was also posted on debian-devel@. If you are involved in Debian development, please discuss it on debian-devel@, rather than in the comments of this blog. If you want to provide feedback about the Debian rolling idea, use this Doodle poll and/or the comments of this blog.
Update : Someone had the good idea to vandalize the poll, and remove all the votes from people in favor of rolling. Before the vadalism (log), the results were:
37 votes: I am a Debian user, I use testing or unstable, and I would like rolling to happen.
6 votes: I am a Debian user, I use testing or unstable, and I DON T want rolling to happen.
17 votes: I am a Debian user, I use stable, and I would like rolling to happen.
3 votes: I am a Debian user, I use stable, and I DON T want rolling to happen.
7 votes: I am NOT a Debian user, but I would probably use it if rolling happened.
1 vote: I am NOT a Debian user, and I don t care about rolling. Motivations There s some user demand for rolling releases. For evidence, one can look at the usage of Debian testing or unstable which clearly goes further than the Debian development community. Or at the quickly growing market share of ArchLinux. Or at the interest in LinuxMint and Aptosid. Or at the DPL s report of his interactions with the press. Debian s only official product is its stable releases. While it s a clearly great and useful product, many users and developers don t recognize themselves in it: it contains software that is too old for their needs. The success of Ubuntu is related to this problem: Ubuntu proposes a different compromise between stability and up-to-date-ness. While concurrencing Ubuntu with more frequent stable releases (released every 6-months, for example) doesn t look like the right thing to do, Debian is in a perfect position to provide a rolling release with marginal additional work, since Debian already has testing (and unstable) to build on. The rolling discussion investigates how we could endorse the concept of a rolling release, provided as a product in addition to stable releases. This rolling release would be based on the current testing branch. Benefits for Debian:

• Attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (free software developers and contributors), thus interesting to work with (able to submit good-quality bug reports, etc). Some of them could also become Debian contributors. And even if they don t, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers].
• Give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Debian is often identified by upstream developers as the platform with releases from two years ago. I would love to see Debian in a position to contribute more to improviing the quality of the Free Software world.
• Get back some attention that is currently taken away from Debian by derivatives. This is important to carry our political or technical messages, which are not necessarily carried out by our derivatives.

Current proposed plan for rolling (Disclaimer: this is mostly my view. It is shared by others, but some details might not be) rolling is mostly about (external) communication. It is not expected to change our development processes fundamentally.
It would be a statement by the project (through a GR, for example). A very preliminary draft was proposed by Raphael Hertzog:

Title: Debian endorses usage of testing by end-users, and renames it to rolling The Debian project recognizes that the Debian testing distribution initially created to make it easier to prepare and test the next stable release has become a useful product of its own. It satisfies the needs of users who are looking for the latest stable versions of software and who can cope (or even appreciate) a system that s constantly evolving. The Debian project decides to endorse this usage and will strive to provide a good experience to users of testing . To better communicate this policy change to our users, testing will be renamed rolling .

Yes, it s mostly PR bullshit , and I don t expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What would change is more attention from developers to what happens in testing/rolling, which is a good thing since a better testing/rolling makes it easier to create stable releases from it. Open questions Most of the discussion is about the influence of the introduction of rolling on Debian development processes, and in particular, on the painful process resulting in stable releases. Many fear that, with rolling , it will be harder to get stable releases out. The root question is: if we do rolling, what do we do during freezes? Several options have been mentioned in the thread:

1. We could decide not to do anything special: just freeze rolling for ~6 months, as we used to freeze testing. That might bore people who like the constant flux of new upstream releases, but if we decide that it s the only way to ensure high-quality stable releases, so be it.
2. We could decide to fork a frozen branch when we freeze, and continue to manage rolling using migrations from unstable.
3. We could mix both solutions: freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork frozen off rolling, and unfreeze rolling.

Two kinds of objections have been raised:

• Those against the rolling concept:
  • It s only about PR, Debian isn t about PR. Answer: PR does matter sometimes, especially if we want to attract users.
  • There s usually no installer for it, other than installing the latest stable release and dist-upgrading, which doesn t always work. Answer: True; but it sounds like an acceptable problem. And if upgrades from the latest stable fail, it s an RC bug, so we would like to know. And if we do get d-i betas, it s a great way to get user testing for them.
  • It will split the developers base between supporting rolling and supporting stable releases (which also need to be supported after they have been released). Answer: already the case today.
  • Testing is not targeted at end users, but is a tool for the release team to create stable releases. It needs to stay that way. Answer: really, can t we do both?
  • Renaming testing to rolling will require changes in many parts of Debian infrastructure. Answer: some problems can be mitigated by keeping a testing symlink. The remaining impact needs to be evaluated.
• Those against the two development branches during freezes problem:
  • It splits the users and developers base between two branches (less users means less bug reports ; less developers means less bug fixing). Answer: true.
  • It requires the use of two different entry points for packages (unstable for packages targeted at rolling, frozen-proposed-updates for packages targeted at frozen). Answer: true.
  • All in all, huge overhead for the release team. Answer: true.
  • Overhead for developers, who need to support two targets. Answer: true.
  • Just after a stable release, we would start the next release from rolling, instead of stable. So we would start from a less clean base. Answer: true.
  • It s even worse if you consider staged freezes (freezing base packages earlier than the rest of the distribution, for example). Answer: true; but is it really a problem if some base packages are frozen in rolling for a few months?

Other things that were discussed:

• possible changes to processes around testing to make it more usable (reduce the set of architectures required for migration to testing ; allow/encourage usage of t-p-u to rebuild unstable packages that are ready to transition except for the fact that they are entangled in a transition ; have different level of RC bugs: there are RC bugs that are acceptable in rolling that are not acceptable in stable)
• PPAs for Debian
• Developer activity during freeze (developer temporarily stopping to work on Debian during freezes)
• Let s improve our packaging process or reduce the duration of our freezes before introducing rolling. Answer: but then, shouldn t we also stop doing stable releases for a while? ;)
• Setting up an official rolling instance . Answer: that can t work. detailed answer
• Using unstable instead of testing as the basis for rolling. Answer: there seems to be more demand for something similar to testing, than for something similar to unstable.

Tentative personal conclusion I have the impression that advertising testing as a rolling release usable by end-users is generally considered a good thing.
The renaming of testing to rolling is not as consensual, but most opponents have a whatever ; if you want position. How we deal with freezes is the hard point in this discussion. I m personnally in favor of the freeze rolling for 3 months, then fork frozen and unfreeze rolling plan, though it has some problems too (it is not clear whether the required manpower really decreases at the end of freezes). Where do we go from there? After another round of discussion, we might postpone the how to deal with freezes question to later, and proceed with a GR to measure the support for the testing for end-users + s/testing/rolling/ proposal.

The above sign was prominently displayed at a fair that was recently run by the Banyule Council. We have had some discussions in the Linux community about what policies should be used in regard to photography at events, it seems that this is a precedent for being able to opt-out of public photography.

Will I succeed maintaining a weekly log of what I'm doing in Debian? We'll see. At least, let's try. D-I work: After spending most of the end of week 16 uploading D-I components, I completed this during this week. I hunted down the remaining arch:all, arch:i386 and arch:amd64 packages that need an upload because of l10n changes. The main point was bringing published D-I work inline with the work of translators. That was mostly meant to publicly have an image with Uyghur activated (which I blogged about separately). Finally, I ended up doing some changes to the fonts-ukij-uyghur package in order to use the right font to display the language in D-I, as well as improving the readability by increasing the font size just as we're already doing for Arabic and Persian. Samba packaging: I got release managers approval to upload a new release to stable-proposed-updates. It fixes several important bugs in samba 3.5.6, often affecting Win7 clients. I'm always happy to see that we can do that even when issues are ot security or "release critical" issues. I also integrated the newly-published samba 3.6.0-pre3 in the package maintenance SVN. However, we're still having problems with symbols disappearing from libwbclient, that prevent me to upload 3.6.0pre3 in experimental. Steve Langasek's help here will be welcome. Pytrainer and "gant" packaging: I setup a mailing list for the pkg-running maintenance team so that we can move the few packages some of us maintain (pytrainer and garmin-forerunner-tools as of now, and soon "garmin-ant-downloader", the helper tool for 405 watches). I also began looking at pytrainer bugs and forwarding some of them upstream. I also began packaging "gant" (had to rename it as we already have a gant package, totally unrelated). I just got a notice from Klaus Ethgen about improvements he did to the software. We'll try to figure out what to do as this software doesn't really have a clear upstream and published versions. l10n work: a few packages introduced debconf templates and I launched reviews of English for them (while mumbling about uncoordinated work, of course..;-)). I also reviewed about one hundred package description translations in French DDTP (something I recently began to commit to do even though it means onlinen work for me, which I'm not used to). No l10n NMUs this week but a few maintainer uploads after I (gently) kicked their ass..:-)

I really don't know how I ended up spending this entire evening listening to Bhutanese music. But I did well. I particularly enjoyed Rang Sem Kar Ga Mikar and Gayser Jang Lu Jonpi Gang, which I both found on YouTube. The former reminded be the pleasure and (apparent) simplicity of Bhutanese dances, which I had the privilege to share with guests in Thimphu a few years ago. The latter gives a great idea of the peacefulness of that place of the world (I recommend scenery views some of which probably taken at Dochula Pass). And that language is so beautiful even when one doesn't understand a word. Maybe some readers of this blog will become listeners of Bhutanese music for some time after reading this. I just can wish this. And, doh, I really can't wait until I go back there. I will, one day or another. "Ku Zu Zang Po La" to those who made me discover that place.

I will never forget.

Last week, I announced the activation of Uyghur language in Debian Installer. For once, I even went further: I rebuilt all D-I packages that include localization (at least for i386/amd64 architectures) and uploaded them. As a consequence, D-I daily builds now allow previewing how an install done in Uyghur can be like. For this, please go to the Debian Installer development page, download the netboot ISO image (not netinst) and launch D-I with "suite=unstable" passed as argument when booting the ISO image. You should end up with something like this, this or this. There are a few glitches, still: for instance, as the font we chose has no Bold variant, the screens "titles" do not use an Uyghur font but an Arabic or Persian one. As a consequence, glyphs ar enot properly joined together. I'm investigating this issue with Uyghur translators and we're trying to choose an appropriate font among the gazillion that have been created by UKIJ. Please notice that Uyghur looks like Arabic but, according to those who can read Arabic, is really different from Arabic (or Persian). I hope that this great work by Gheyret Tohti, Abduqadir Abliz and other people working on this will give ideas to other so-called "minorities", here or there in the world, who want to be able to install Debian in their language. There is still a lot of work to do, such as having end-user software localization for Uyghur and, then, a uyghur-desktop task, but this is at least the first language that gets added for wheezy. In case you would be wondering, the current count of activated languages in D-I is 71.

It s Autism Awareness Month April is Autism Awareness month, there are lots of articles about Autism, most of them are at best misleading if not wrong. The most common error seems to be describing non-verbal Autistic children and then claiming that Autistic people comprise about 1% of the population. The number of non-verbal Autistic children is a lot less than 1% of the population, and at least 1/3 of the people on the Autism Spectrum have good verbal skills and often talk more than average. To be precise, they are describing the symptoms of people who would be diagnosed with Severity 3 according to the American Psychiatric Association s Diagnostic and Statistical Manual (the DSM) as applying to all people who are on the Autism Spectrum even though of the currently diagnosed people probably about 1/3 might be classified as Severity 2 and 1/3 as Severity 1. It seems that severity 1 Autism is going to be the replacement for Asperger Syndrome in the new DSM-5. The problem with misleading information in regard to what comprises Autism is that parents really don t want to have a child who s abnormal and search for evidence to make their wishes come true. At the extreme there are parents who can convince themselves that a 4yo non-verbal child isn t on the Autism Spectrum. When people are given the impression that Autism is only about non-verbal children then they will probably think that a 6yo who can give a half-hour lecture on a topic of interest (regardless of whether the audience is interested) isn t on the Autism Spectrum. There is also a similar issue with undiagnosed adults, I would have probably got assessed at least a decade earlier if I had learned more about Autism instead of believing some of the stories. In a quick Google search for Autism Awareness Month I haven t found any clear and accurate information on what Autism is or what should be done about it, so it seems to me that the awareness project has largely been a failure. The Autism page on Wikipedia [1] and the page for Asperger Syndrome [2] are good places to start reading. By merely pointing to those two Wikipedia pages I ve made this post a lot more useful than every article I ve seen in the mainstream media. To find some useful and insightful posts about Autism awareness you have to add some search terms such as neurodiversity, which turns up posts such as a post by Leah Jane about Autism Acceptance [3]. It seems that the Autism Awareness articles that are most useful at informing people will only be found by people who are already aware of some of the issues. Most People Who Read this are Geeks The majority of the readers for my blog come from aggregators that cater to fairly geeky people. Geek culture is largely Aspie culture. So I think that most people who read my blog have a good general knowledge of what people who might be diagnosed with Asperger Syndrome or High Functioning Autism are like they just think that such people are merely a bit more geeky than is typical for the Free Software community. So it s not as if all Autistic people are hidden away somewhere because they can t live independently. Many of us work in the computer industry and in academia. Probably the majority of people who have a university degree related to science or engineering have had a professor who was on the Autism Spectrum, probably most people who have any significant experience in the computer industry have had colleagues who are on the Spectrum. After having become used to the geek culture I initially found it difficult to believe that I could be on the Autism Spectrum because I knew heaps of people in the Free Software community who are at least as geeky as me but apparently weren t on the Autism Spectrum. I now think that the majority of people who are as geeky as me would get diagnosed with Asperger Syndrome (or High Functioning Autism under DSM-5) if they were assessed. Adult Diagnosis If you are wondering whether you might be on the Autism Spectrum then it s worth reading the pages linked from the DSM 5 draft process have the full diagnostic criteria (both for DSM-4 and DSM-5) [4]. Also Glenn Rowe has a web page with tests designed by Professor Simon Baron-Cohen [5] and Leif Ekblad has a project to do long-term analysis of changes to personality test scores which starts with a quick Aspie quiz [6] (and also has lots of links to other relevant sites). If you think that you might be on the Autism Spectrum (which means Asperger Syndrome in the case of most people who read my blog) then I recommend that you get assessed if possible. As assessment by a psychologist isn t cheap there is the option of self-diagnosis in which case Chaotic Idealism s post about self-diagnosis is worth reading [7].

• [1] http://en.wikipedia.org/wiki/Autism
• [2] http://en.wikipedia.org/wiki/Asperger_syndrome
• [3] http://www.shiftjournal.com/2011/04/15/autism-acceptance-for-autism-awareness-month/
• [4] http://www.dsm5.org/ProposedRevisions/Pages/proposedrevision.aspx?rid=97
• [5] http://glennrowe.net/BaronCohen.aspx
• [6] http://www.rdos.net/eng/Aspie-quiz.php
• [7] http://chaoticidealism.livejournal.com/70133.html