See you in Banja Luka! As mentioned previously, there's a gang of us heading over by car from the UK, which should be great fun. 9 countries in 2 days on the trip down, and an extra one on the way back, just because.

By the way: For DebConf attendees from Germany (or passing through Germany) might be interesting, that you can currently book the night train from Munich to Zagreb with a special price (called Spar Night or something like that); quite cheap: It's cheaper for Meike and me in a double cabin of that train, than to fly for one of us. As far as I know it is a limited offer, to book fast while you can! Apparently you can't book that train via the web interface, but you can buy it in their offices and via phone. Oh, an it seems that the train on the 22nd of July there and on the 31st back might become a Debian train. Seems there are already five of us taking that one ;) Update: Fixed a typo: DebConf is taking place in July, not in June.

Let's see ...

• Got the application for leave filed and accepted at work
• Registered my talks
• Booked the trip
• Got a working plan for (my day at) DebCamp
• Wrote my abstracts

... I guess I am going to DebConf :D

I ve been busy tonight spamming mailing lists and otherwise getting the word out: the LSB workgroup is preparing to update the FHS. This update has been a long time in coming; FHS 2.3 (the current version) was released back in 2004. Since then, a lot has happened, and it s starting to look like the FHS is holding things back due to the lack of updates. For the longest time, the FHS was cared for by its original editors: Dan Quinlan, Rusty Russell, and Chris Yeoh. We should all be grateful that they created a useful and well-written standard one that has been resilient enough to remain useful for six years without changes. Even though it s time to move on, we should not forget that we are building on a strong foundation they laid for us. So, you may be asking: how can I help? Glad you asked!

• First of all, get the word out! If you know people who might be interested (developers for Linux distributions, standards people, etc.), point them to this post or to the LSB announcement linked earlier.
• We have set up the usual open-source project infrastructure: a bug tracker, version control (using Bazaar), a mailing list, and a wiki (of sorts; it s actually a page on the LSB wiki). Come and join in! Subscribe to the mailing list, post comments on the wiki, check out the source and submit patches.
• The bug tracker deserves special mention. We hosted it for the old FHS project, and so we re continuing to use it. In particular, we ll be doing triage on the old bugs there, as well as any new bugs filed. So go ahead and file bugs, or add comments to old bugs; we ll be taking those into account for the new update. If you file new bugs, please file them against the FHS product.

We re tentatively shooting for a goal of releasing FHS 3.0 before July, though that s not written in stone. But we don t want to wait much longer than we ve already had to.

No, not programming whilst inebriated. Although the effects of the Ballmer Peak are well known. I mean using wsgi and Apache together with Django. But, perhaps, I should explain my (current) layout of projects. I now use:

 /path/to/project/
                 .git
                 .gitignore
                 project_name/
                             urls.py
                             settings.py
                             production_settings.py
                             [...]
                 apache/
                       project_name.conf
                       django.wsgi
                 env/
                    [...]
                 sitestatic/
                 requirements.txt
                 fabfile.py

This allows me to have revision control of things meta to the project and of the project itself. This setup is relatively new, I've only been using it in about 4 projects now. Which meant that my wsgi file had to be slightly modified. This took me a lot longer than I expected to get going. But if you decide to use a layout similar to mine, this might help.

import os
import sys
import site
## Assumptions:
# Assume that the Django project and the environment are at the same level.
# i.e.
# /home/
#      /<project root>/                                     <- *
#                     /<project name>/                      <- *
#                                    /apache/
#                                           django.wsgi
#                                    production_settings
#                     /env/
#                         /lib/
#                             /pythonX.Y/
#                                       /site-packages/     <- *
#                     /sitestatic
#
# Directories marked with '<- *' need to be imported for everything to work
PROJECT_NAME = "control"
PYVER = "%d.%d" % (sys.version_info[0], sys.version_info[1])
APACHE_DIR = os.path.abspath(os.path.dirname(__file__))
PROJECT_ROOT = os.path.abspath(os.path.join(APACHE_DIR, ".."))
site_packages = os.path.join(PROJECT_ROOT, 'env/lib/python%s/site-packages' % PYVER)
site.addsitedir(os.path.abspath(site_packages))
sys.path.insert(0, os.path.join(PROJECT_ROOT, PROJECT_NAME))
sys.path.insert(0, PROJECT_ROOT)
# import from down here to pull in possible virtualenv django install
os.environ['DJANGO_SETTINGS_MODULE'] = 'production_settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

One slight tweak I have also done is to rename the django.wsgi file, to be the environment file. e.g. devel.wsgi. That means the only hardcoded thing in the wsgi file is the PROJECT_NAME. Apply this patch on top of the file above:

--- apache/django.wsgi  2011-05-06 00:38:57.266316530 +0100
+++ apache/devel.wsgi   2011-05-05 14:23:33.708685680 +0100
@@ -24,14 +24,15 @@
 PYVER = "%d.%d" % (sys.version_info[0], sys.version_info[1])
 APACHE_DIR = os.path.abspath(os.path.dirname(__file__))
 PROJECT_ROOT = os.path.abspath(os.path.join(APACHE_DIR, ".."))
+ENVIRON_TYPE = os.path.basename(__file__).rstrip('.wsgi')
-site_packages = os.path.join(os.path.dirname(PROJECT_ROOT), 'env/lib/python%s/site-packages' % PYVER)
+site_packages = os.path.join(PROJECT_ROOT, 'env/lib/python%s/site-packages' % PYVER)
 site.addsitedir(os.path.abspath(site_packages))
 sys.path.insert(0, os.path.join(PROJECT_ROOT, PROJECT_NAME))
 sys.path.insert(0, PROJECT_ROOT)
 # import from down here to pull in possible virtualenv django install
-os.environ['DJANGO_SETTINGS_MODULE'] = 'production_settings'
+os.environ['DJANGO_SETTINGS_MODULE'] = '%s_settings' % ENVIRON_TYPE
 import django.core.handlers.wsgi
 application = django.core.handlers.wsgi.WSGIHandler()

If you have any suggestions for improvements, or thoughts on how to remove the PROJECT_NAME, let me know!

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.

I ve just uploaded to sourceforge the third and hopefully last RC for jffnms network management system version 0.9.0 The reason for the delay was easter as well as I wanted to test the engines for a long while to make sure I was not getting any orphan children or items. Previous versions had processes that never died or if they died the parent didn t realise and didn t handle the item, permanently making the item out for work . PHP5 has much better job and process handling and the new version takes advantage of this handling. It s run well on my on test setup for a week or two. You can find the RC code or just the older releases at https://sourceforge.net/projects/jffnms/files/

As previously announced, I ve been working on a Debian packaging tutorial. It is composed of about 60 slides providing a throughout overview of Debian packaging. It now reached the point where I consider it ready for use, and I am looking forward to reviews and comments.
The document is split into 4 different PDFs:

• the tutorial itself
• a practical session about modifying the grep package
• a practical session about packaging the gnujump game from scratch
• a practical session about packaging a Java library

And of course, it can be found on git.debian.org:
git clone git://git.debian.org/~lucas/packaging-tutorial.git

A few hours ago I performed my first source-only upload, and that wasn t to a well-known Debian derivative. :) Thanks to Peter Hutterer for the initial idea I could handle that release, and to Alan Coopersmith for the handholding session.

Mostly everything in life boils down to the same troublesome issue: people are reading different things into what they read, and interpret them regularly in a way it wasn't meant to. It seems that in certain areas a culture of interpreting things in a bad way instead of good or asking how they were actually meant has established the rules of (not) working together but rather against each other and around each other. At times I would like to account it to language barriers, or cultural differences, but it happens with people from all areas so that reasoning would be too easy. Even artists manage to do that, and in that certain area it creates something extremely creative and thoughtful. This blog entry thus contains three songs and six videos: Two different interpretations of the same lyrics. Maybe this is able to stir some thinking process whether the interpretation that one found for a given situation might be biased or even just looking from the wrong angle.

• Imagine (John Lennon vs. A Perfect Circle): It gives me the shivers when thinking about what a different tune and might turn the same lyrics into. The various videos going with this interpretation make me even cry, and since the official video might be blocked in your country I linked one of the private made ones.
• Mad World (Tears For Fears vs. Gary Jules): You might not have known the original (Tears For Fears is well known for other songs actually) but only the cover, which was in the soundtrack of Donnie Darko.
• Drive (R.E.M. vs. R.E.M.): You read correctly: a band covering itself is rare but it happens. And yes, when I heard the live version back in the years it was a quite enlightening situation.

Enjoy! One thing I'd like to mention, and that is two cross references to former blog entries. For the first song, James Iha played as guitarist in The Smashing Pumpkins before he joined A Perfect Circle. The second cross reference is with respect to my former blog entry about the Wise Guys: They did also cover Mad World, in the Gary Jules' interpretation but of course in a capella.

/music permanent link Comments: 6 Flattr this

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.

It s a bit quiet on this blog recently because I m busy with lots of non-software tasks, including:

1. I am standing for election to the UK Worker Co-operative Council. Thank you to software.coop for the nomination and help. Voters can ask me questions on the uk.coop site.
2. I was renominated to Kewstoke Parish Council and even though there s no contest (just enough candidates to fill the council), I ve another 16 pages of legally-required forms to complete to take up office. I hate bureaucracy and I think it deters a lot of good people from helping their villages.
3. I m contemplating standing in the co-operative group area committee elections again.

So, I m far from idle. I m still developing software for clients of our co-op but not finding time to write about it just now. Maybe this would be more interesting to readers: I ve moved my wifi antenna out of the metal box it s been in for a while. Now it covers a half-decent area, I m looking at installing CoovaAP to offer some free public access wifi while trying to limit the risk of illegal activity. Would you do it? Do you run a public wifi point? What should I watch out for?

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!

I'm using gitosis to manage my Git repositories on the public server. That server was recently upgraded to Squeeze and I didn't create a new repository on that server so far but today I wanted to and got:

ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly

A search yielded some results with people messing up their keys or forgetting to create the configuration file entry or something similar. None of this was my problem. As it turned out, the post-update hook for the admin repository has been moved from /usr/share/python-support/gitosis/gitosis-0.2-py2.5.egg/gitosis/templates/admin/hooks/post-update to /usr/share/pyshared/gitosis/templates/admin/hooks/post-update, but the symlink hasn't been updated on upgrade. After running a simple

ln -sf /usr/share/pyshared/gitosis/templates/admin/hooks/post-update post-update

in the hook directory of the admin repository everything worked again.

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.