Since some ages we are deploying IPv6 in our network and also for some selected services. Some days ago we discovered, that anybody has enabled accidentally a router advertisement daemon in a network where this shouldn t happen. As result of this, IPv6 enabled systems got (additional) IPv6 adresses and some services where using this new learned addresses as source address when sending out replies. Maybe this doesn t sound so harmful on the first view. But some services rely on a correct source address when getting a reply for a request (for example dns resolver library). To be aware of the issue, that a service maybe available via IPv4 but not via IPv6 or vica versa, a dualstacked monitoring needs to be in place for dualstacked services. Looking into the issue, I stumbled upon Michael Friedrichs HowTo about Dualstacked monitoring with Icinga. Luckily we have the full software stack in place on Squeeze (with squeeze-backport). As icinga and nagios-plugins was in installed already, I just needed to fetch check_multi.

aptitude install -t squeeze-backports nagios-plugin-check-multi Now a new check command is needed, I created the following:

define command
command_name check_multi_icinga
command_line /usr/lib/nagios/plugins/check_multi \
-f /etc/check_multi/$ARG1$ $ARG2$ $ARG3$ $ARG4$ \
-s objects_cache=/var/cache/icinga/objects.cache \
-s status_dat=/var/cache/icinga/status.dat \
-s HOSTADDRESS=$HOSTADDRESS$ -s HOSTADDRESS6=$HOSTADDRESS6$
For monitoring connectivity I created check_host_alive_dualstack.cmd

command[ IPv4 ] = check_ping -4 -H $HOSTADDRESS$ -w 5000.0,100% -c 5000.0,100% -p 5
command[ IPv6 ] = check_ping -6 -H $HOSTADDRESS6$ -w 5000.0,100% -c 5000.0,100% -p 5
state [ CRITICAL ] = COUNT(CRITICAL) > 1
state [ WARNING ] = COUNT(WARNING) > 0 COUNT(CRITICAL) > 0
state [ UNKNOWN ] = COUNT(UNKNOWN) > 1 Now we just need to replace the check-host-alive command and add a value for address6 on the host as the following

define host
use generic-host ; Name of host template to use
host_name localhost
alias localhost
address 127.0.0.1
address6 ::1
check_command check_multi_icinga! check_host_alive_dualstack.cmd !'-r 1+2+4+8
Reloading icinga should you show something like this:
Now we have general connectivity of our dualstacked systems monitored.

After about week of (not so heavy) development, I can announce availability of Weblate - web based translation tool with tight Git integration. The project was started because I was not happy with existing solutions (see my blog post) as all of them was missing some features I find useful. I started with quite simple definition:

Minimalistic web based translation with direct commit to git on each translation made. There is no plan in heavy conflict resolution as these should be primarily handled on git side.

Also the project started with defined list of features:

• Easy web based translation
• Propagation of translations across sub-projects (for different branches)
• Tight git integration
• Usage of Django's admin interface
• Upload and automatic merging of po files
• Links to source files for context

Pretty much all of that is completed right now, however there will be definitely some issues which will need fixing. All important information about the project are available on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Please give it some testing as I plan to deploy it on http://l10n.cihar.com/ pretty soon.

Filed under: Django English Weblate 5 comments Flattr this!

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (384.14 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg and multiarch The month started with a decision of the technical committee which allowed me to proceed with an upload of a multiarch dpkg even if Guillem had not yet finished his review (and related changes). Given this decision, Guillem made the experimental upload himself. I announced the availability of this test version and invited people to test it. This lead to new discussions on debian-devel. We learned in those discussions that Guillem changed his mind about the possibility of sharing (identical) files between multiple Multi-Arch: same packages, and that he dropped that feature. But if this point of the multiarch design had been reverted, it would mean that we had to update again all library packages which had already been updated for multi-arch. The discussions mostly stalled at this point with a final note of Guillem explaining that there was a tension between convenience and doing the right things every time that we discuss far-reaching changes. After a few weeks (and a helpful summary from Russ Allbery), Guillem said that he remained unconvinced but that he put back the feature. He also announced that he s close to having completed the work and that he would push the remaining parts of the multiarch branch to master this week (with the 1.16.2 upload planned next week). That s it for the summary. Obviously I participated in the discussions but I didn t do much besides this I have a mandate to upload a multiarch dpkg to sid but I did not want to make use of it while those discussions remained pretty unconclusive. Also Guillem made it pretty clear that the multiarch implementation was buggy , not right and not finished and that he had reworked code fixing at least some of the issues since he never shared that work in progress, I also had no way to help even just by reviewing what he s doing. We also got a few multiarch bug reports, but I couldn t care to get them fixed since Guillem clearly held a lock on the codebase having done many private changes it s not quite like this that I expect to collaborate on a free software project but life is full of surprises! I ll be relieved once this story is over. In the mean time, I have added one new thing on my TODO list since I made a proposal to handle bin-nmu changelogs and it s something that could also fix #440094. Misc dpkg stuff After a discussion with Guillem, we agreed that copyright notices should only appear in the sources and not in manual pages or --version output, both of which are translated and cause useless work to translators when updated. Guillem already had some code to do it for --version strings, and I took care of the changes for the manual pages. I merged some minor documentation updates, fixed a bug with a missing manpage. Later I discovered that some recent changes lead to the loss of all the translated manual pages. I suggested an improvement to dh_installman to fix this (and even prepared a patch). In the end, Guillem opted for another way of installing translated manual pages. Triggered by a discussion on debian-devel, I added a new entry to my TODO list: implementing dpkg-maintscript-helper rm_conffile_if_owner to deal with the case where a conffile is taken over by another package which might (or might not) be installed. Misc packaging At the start of the month, I packaged quilt 0.51. The number of Debian specific patches is slowly getting down. With version 0.51, we dropped 5 patches and introduced a new one. Later in the month I submitted 4 supplementary patches upstream which have been accepted for version 0.60. This new version (just released, I will package it soon) is an important milestone since it s the first version without any C code (Debian had this for a long time but we were carrying an intrusive patch for this). Upstream developer Jean Delvare worked on this and based his work on our patch, but he went further to make it much more efficient. Besides quilt, I also uploaded dh-linktree 0.2 (minor doc update), sql-ledger 2.8.36 (new upstream version), logidee-tools 1.2.12 (minor fixes) and publican 2.8-2 (to fix release critical bug #660795). Debian Consultants The Debian Project Leader is working on federating Debian Companies. As the owner of Freexian SARL, I was highly interested in it since Freexian contributes to Debian, offers support for Debian and has a strategic interest in Debian . There s only one problem, you need to have at least 2 Debian developers on staff but I have no employees (it s me only). I tried to argue that I have already worked with multiple Debian developers (as contractors) when projects were too big for me alone (or when I did not have enough time). Alas this argument was not accepted. Instead, and since our fearless leader is never afraid to propose compromises, he suggested me (and MJ Ray who argued something similar than me) to try to bring life to the Debian Consultants list which (in his mind) would be more appropriate for one-man companies like mine. I accepted to help animate the list, and on his side, he s going to promote both the Debian Companies and the Debian Consultants lists. In any case, the list has seen some traffic lately and you re encouraged to join if you re a freelancer offering services around Debian. The most promising thing is that James Bromberger offered to implement a real database of consultants instead of the current static page. Book update We made quite some progress this month. There s only one chapter left to translate. I thus decided to start with proofreading. I made a call for volunteers and I submitted one (different) chapter to 5 proofreaders. The liberation campaign made a nice leap forwards thanks to good coverage on barrapunto.com. We have reached 80% while we were only at 72% at the start of the month (thanks to the 113 new supporters!). There s thus less than 5000 EUR to raise before the book gets published under a free license. Looking at the progression in the past months, this is unlikely to be completed on time for the release of the book in April. It would be nice though so please share the news around you. Speaking of the book s release, I m slowly preparing it. Translating docbook files is not enough, I must be able to generate HTML, ePub and PDF versions of the book. I m using Publican for most formats, but for the PDF version Publican is moving away of fop and the replacement (webkit-based) is far from being satisfactory to generate a book ready for print. So I plan to use dblatex and get Publican to support dblatex as a backend. I have hired Beno t Guillon, the upstream author of dblatex, to fix some annoying bugs and to improve it to suit my needs for the book (some results are already in the upstream CVS repository). I m also working with a professional book designer to get a nice design. I have also started to look for a Python Django developer to build the website that I will use to commercialize the book. The website will have a larger goal than just this though ( helping to fund free software developers ) but in free software it s always good to start with your own case. Hopefully everything will be ready in April. I m working hard to meet that deadline (you might have noticed that my blog has been relatively quiet in the last month ). Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

For some time, we use Pootle as online translation tool for phpMyAdmin. It is indeed great tool, but somehow we seem to be hitting more and more issues with it and I feel it really won't fit nicely once we will want to support translations on two divergent branches. Also it's code base is not something easy to understand so that I would be able to fix bugs myself without major effort. So this is when I started to look for alternatives. Unfortunately there is nothing I could find what would work in way I want. I've looked at Transifex, Translatewiki, Crowdin and others whose names I've forgotten and I still haven't found what I'm looking for. The key feature I want from such system is full integration with git. This means that whatever is changed should be committed to local git branch and merging translations back should be as easy as merging remote branch. I've hacked such thing into Pootle (in quite dirty way), so this is basically workflow we have right now and I'm pretty much happy with that. Another thing (which seems to be existing in some tools) is support for simultaneous translation of more branches - if same string exists in more branches, it should be translated in all of them. And last but not least, it should support import of po files allowing users offline translation. Thinking about this I'm starting to thing that it should be pretty easy to implement something what I want using existing pieces of software without major effort. I'll probably start to play with Django, translate-tookit and GitPython to see if I can come up with something working reasonably well in few days... PS: Anybody working on updated GitPython packages for Debian, looks like I will need them soon :-).

Filed under: English Phpmyadmin Weblate 10 comments Flattr this!

Also this year the Debian Project is running a booth at Chemnitzer Linux-Tage. Unfortunately this year we are lacking a bit manpower compared to the last years. Actually we have 6 persons at our wiki without knowing how much time everybody will be present at the booth. It would be really cool, if we can prevent us from having a D j vu.
So if you want to visit one of the best community focused OpenSource events in germany and can invest some time helping to run our booth, have a look into the report from last year and the organization wiki. If you feel you want to be part of this enjoyable event, please get in touch with me. As the registration for the booth is closing on 28th February, don t wait too long! ;)

These articles cover my way to DebConf 11 through Hrvatska and Bosna i Hercegovina. After telling my initial plans to go by train (mostly) and bus (where it couldn't be avoided) on IRC, I was warned that public transport is quite bad and unreliable. Also, as I live in M nchen, of course this part of Europe was always known as "near" and "could be visited any time" (which means "one never gets to it"; and I can still remember the time when it was Yugoslavia - there are and always were many people living here from that part of Europe; in fact, it's nearer than some parts of Germany). I plan to publish more parts of my way within the next days. Already at home I also learned that most trains in Hrvatska (and all in Bosna i Hercegovina) are not part of the usual train information system, so it was a bit more advanced to find out the appropriate connections. And in both countries there are only a few trains running, so one shouldn't miss a train ("few" means e.g. two per day and direction - but one at most unappropriate times, so really only one suiteable). The first day saw me boarding the Suburban train (S-Bahn) at my usual station, changing platforms and trains at M nchen Ost station and then I was sitting in a train to Zagreb. Nothing strange there, except that the coach I had an seat reserved in was missing. I learned later on that it happens more often that the coach from Serbia is not there because it's technically too unfit to send it to Germany -- and usually, there will be more coaches added in Ljubljana. Border checks were uneventfull but at the slovenijan border my passport was stamped (not sure why, didn't happen on the way back).
Train in sterreich After arriving in Zagreb and dropping off my luggage in the hotel, I first got some Kunas and then bought my ticket to Split for the next day (as a direct ticket from M nchen to Split was not available). After having done that, I took a brief tour through Zagreb until it became dark, with visiting some of the tourist places.
Zagreb

Intro RAID sucks, and so do all other Free alternatives in the Linux world. Having been in exactly the same situation several times in the past, I have been following Russell Coker's posts regarding data integrity with interest. FWIW, the correct answer to "BTRFS (sic) and Xen" is: subvolumes. Now that Fedora has, once again, decided to postpone their switch to Btrfs as default file system, I decided to write up my own take on this topic. Any and all my considerations are made under the assumption that important data is backed up while semi-important data is at least living on two different machines. Beware, this is a long post, but I do like to think it's well worth reading. RAID Disk failures Let's recap the current situation for "traditional" file systems like xfs, ext 2..4 , etc. In case you need to freshen up on the technical details go here.

• Single disks: Fine for many use cases like Laptops, Desktops, etc, they are what most of us are using for most storage needs.
• RAID 0:If you are using that, you are most likely doing it wrong. Barring increasing caches for SSD-based volumes on machines which you simply take out of your cluster if there is any kind of problem, I don't know of not a sigle valid use case. Other than to get rid of data, that is.
• RAID 1: The default for small servers and important machines which don't need a lot of disk space.
• RAID 5: OK for personal storage servers, avoid once disks become larger than 500GB-1TB, depending on personal preference. To write data, you need to calculate new checksums and thus read all data from all corresponding slices, impacting write performance significantly.
• RAID 6: The RAID 10 people will disagree, but I like this RAID level best. While your write performance will definitely take a hit, you can mitigate this by decreasing your volume sizes. The extra cost in ways of power, disks, controllers, and rack space are a price we gladly pay for the ability to lose two disks and still retain all data.
• RAID 10: Great write performance until the day when two disks in the same RAID position die right after each other and your company's main mail storage dies. Yes, this has happenend to me and it sucks.
• RAID 2,3,4,50,60,foo: Mostly irrelevant in the real world; disregard.

Silent corruption All the RAID levels with redundancy are fine and dandy if you lose a whole disk and put in a new one. Of course, that does not help you the tiniest bit once you get read errors. Controllers which manage RAID 1 or 10 may or may not compare the data while it's being read and may or may not tell you about discrepancies. They can then toss a coin and give you either result. There is no way to determine which is correct. RAID 2, 3, 4, 5, and 6 could, in theory, verify the data as it's being read, but that would limit your read rate to that of a single disk so no one does that. We actually had a massive web presence fail over night, once. No one knew what the cause was as there hadn't been any kind of access logged. As that particular deployment is done directly from a VCS, we simply ran a diff and found one change. We traced the failure down to a syntax error; a one character change made everything fail. Looking at the ASCII table, it was clear that one single bit had flipped. This sucked. A lot. Mitigation So you end up scrubbing your RAID sets on a weekly basis, recovering from silent corruption with the help of your RAID 6's two parity stripes. And even though you schedule the scrubbings with the least priority, you still take a performance hit when randomly seeking a lot. ZFS Some smart people at Sun set out to fix these problems and more, and fix it they did. The "Z" in ZFS is meant to imply that this is the last file system you will ever need and if not for its license, this might have worked. Of course, "last" and "forever" mean "not now" and "10 years" respectively, in computer terms. The limits within ZFS have been chosen so that the entropy needed to create a disk able to max out a ZFS volume would, literally, require our oceans to boil. Let's just say that you won't encounter these limits any time soon. While that is a nice thing to know, it does not say anything about data integrity. There are several mechanisms ensuring data integrity built in ZFS, the most fundamental being extensive checksumming. Checksums are vastly superior to live comparisions which RAID would have to perform as it does not need to sacrifice any significant i/o reading checksum data. With HDD access, you are i/o-bound, and not CPU-bound, anyway, so performing the checksum calculations is laughably cheap when factoring in the added safety. Everything, be data, metadata, inodes, you name it, is checksummed. Every read operation must go through the checksumming functions, ensuring that all data which reaches your user space is correct. If ZFS can't verify the checksum, it will not deliver any data at all, ensuring noticeable, as opposed to silent, corruption. So how does ZFS recover when the checksum does not match the data? copies= 1..3 The easy way is to store several copies of your data within your volume. Mount a ZFS volume or subvolume with copies=2 or 3 and all data that is being written from then on will be copied twice or three times. Trivial in principle, but powerful when built into a file system. RAIDz 1..3 This is where things start to get interesting. RAIDz1, 2, and 3 will allow you to lose 1, 2, or 3 disks respectively while still retaining your data; at the obvious expense of the storage capacity of as many disks. Basically, RAIDz2 is ZFS' variant of RAID 6, but it's so much better than mere RAID 6. Moo! RAIDz will not assign fixed slices and fill them up like RAID does. It will look at the current write speeds and use appropriate slice sizes dynamically. As a direct result, data which has been written at roughly the same time will always be near other data written at the same time. This is very nice for functionality like snapshots, writeable subvolumes and other things and is called COW, ZFS' variant of super cow powers. This also enables ZFS to write data, read it back and verify the checksum and only then point to the new data. Atomic commits done right. Keep rollin' As ZFS has to keep track of what data is still in use in which volumes and subvolumes anyway, it knows which regions are free to be reclaimed. Instead of filling up random places, ZFS will roll over your disks, overwriting unused data on the fly. This bears repeating: Contrary to RAID 5 and 6, ZFS will never need to read old data in order to write new data. Write performance galore and anyone still stuck on RAID 10 can finally enjoy the increased data security. Btrfs To be completely honest, I do not know Btrfs as well as I know ZFS. If I get anything wrong, correct me. If I offend anyone with my outsider's interpretation, that is not my intention. Btrfs has been initiated by Oracle way before it ever even thought about buying Sun or history might have run a different course, for worse or a lot worse. The closing of Java, Solaris, ZFS, Hudson, OpenOffice (since then "gifted" aka thrown away), and others makes me think the latter. As there are few technological developments which caused me as much stress, overtime and pain as OCFS2, I am naturally wary of file systems sponsored by Oracle and their data focus integrity/availability. The fact that there's still no way to fsck a Btrfs volume could be birthing pain or yet another facet of Oracle's stance on this topic, I honestly don't know. Either way, it's a good idea to be wary for now. I can't say too much on Btrfs' technical underpinnings, but I know it uses COW and that it has its own variant of RAID. Toss in snapshots (writeable?), subvolumes and integrated block device management, and you have the building blocks of a decent file system. Still, Btrfs is not ready for prime time. Btrfs has been "one or two years in the future" for a few years now so I will not be holding my breath. And once the first distributions are starting to use Btrfs by default, people will lose data. A year or three after that, I will feel comfortable to use it myself and in production. Commercial solutions You can either hand a lot of money to proprietary vendors who will not tell you a thing about how things work internally (and no way to fix things directly) or you can buy solutions that employ ZFS in the back-end. I prefer my storage hardware to be relatively dumb while keeping the intelligent bits where I can see and poke them so this is not really part of these considerations. So what can you do? Test your disks before deploying them Easy, but vitally important:

disk=/dev/foo
smartctl -a $disk
smartctl -t long $disk
badblocks -swo $vendor_$model_$serial_$timestamp.badblocks.swo $disk
smartctl -a $disk

If you are lazy, get a copy of disktest, a tool I wrote to do exactly this. It should wait for the long self-test to finish, can not read out all vendor names, and does not have a way to document who ran the test, but it's a start. Patches and feedback are, obviously, welcome. And yes, I will package this soonish. Using your disks This list is surprisingly short. You can use

• distinct disks
• RAID as per above
• ZFS-FUSE
• Debian/kFreeBSD
• Nexenta

And that's it. At work, I prefer small RAID 6 volume sets. It sucks, but there is nothing better. For personal use, I have a machine with a FUSE-based RAIDz2 mounted with copies=2. Three disks can fail and my data is still secure. While this setup is slow as molasses due to FUSE, speed is not a consideration for me here; data safety is. A migration to Debian/kFreeBSD in the medium term is still likely. If you have things to add or disagree with me, I would love to hear from you. Update: Jan Christian Kaessens pointed out that, contrary to my experience, zfsonlinux did not bring down his sytem in flames. As zfsonlinux is a kernel module, potential performance is a lot better. Also, it supports ZFS Pool Version 28 as opposed to FUSE-ZFS' 23. While the really nice features are in v 29 and 30 (which are closed thanks to Oracle) v 28 still has some nice changes.

I ve been working on enum again recently and got completely stuck in getopt_long() return values. I don t want to bore you with details, so let me cut to the chase: I needed a way to look into what getopt_long() is actually doing. Now, there are a few ways to figure out the doings of a function. If it s your own code, you could just go ahead and add a few printf()s to see if your variables fill up as intended. Then you could use gdb to walk through your running code. But what if you want to do so in functions outside the scope of your own code? In my case: getopt, i.e. libc? Obviously, you can download the library, add your printf() stuff, compile and install it, and see it all happening. But libc isn t exactly small, fast-compiling, and you really don t want to mess it up and have it installed on your system. So how about just taking what you actually care for and push it in? This is nothing experimental or particularly hacky . I just don t want to forget about it and maybe someone can make use of it. So here we go Download your libc sources to a new directory and copy the files you need. Try something like

mkdir -p /tmp/getopt/mygetopt
cd /tmp/getopt
apt-get source eglibc
cp eglibc-*/posix/getopt* mygetopt/
cd mygetopt

Now write up a primitive Makefile:

all: libmygetopt.so
libmygetopt.so: getopt.c getopt1.c getopt_int.h getopt.h
	gcc -shared -Wl,-soname,libmygetopt.so.1 -fPIC -o libmygetopt.so.1.0.0 getopt1.c getopt.c
	ln -s libmygetopt.so.1.0.0 libmygetopt.so.1
	ln -s libmygetopt.so.1 libmygetopt.so
clean:
	$(RM) libmygetopt*

In order for this to actually work, I fiddled around with a few #ifdef s in getopt.c. But that s something you ll probably find out yourselves. You should at least be able to compile it ( make it). Now put a printf statement somewhere in the function you want to inspect. Recompile the lib and then go back to your actual program. Running the program ist easy.

src/enum -p1 1 3
1.0
2.0
3.0

Surprisingly, running it using your own getopt version is just as easy. Just push your library in:

LD_PRELOAD=libmygetopt.so LD_LIBRARY_PATH=/tmp/getopt/mygetopt:$LD_LIBRARY_PATH src/enum -p1 1 3
Yo, Ulrich, my getopt version is waaaay cooler than yours!
Yo, Ulrich, my getopt version is waaaay cooler than yours!
1.0
2.0
3.0

If you re disappointed now, that s your own fault. I said it in the beginning, this is nothing special. It s not my idea. It s something that developers all use all the time or something like that. In case you didn t know about it, good for you. Otherwise, sorry for reading my memory dump.

Sociological Images has an interesting article about the attempts to apply the word Camping to OWS and framing the issues [1]. Lester Macgurdy wrote an insightful article about the snake , a new technique for OWS protesters to beat riot police [2]. Ron Barassi suggests that Australia Day be celebrated on the 27th of May to commemorate the day in 1967 when the Australian constitution was amended to not be racist [3]. The current Australia Day is often referred to as Invasion Day . IMHO Ron deserves another Best and Fairest award. Stefon Harris gave an entertaining TED talk about improv Jazz music titled There Are No Mistakes on the Bandstand [4]. It seems that his concepts can apply to some extent to many collaborative projects. John Robb wrote an interesting article about the future of drone (UAV) warfare [5]. He suggests that having one person control each drone is a temporary thing and that the future is to have a cloud of cheap autonomous drones taking strategic control from one person. His comparison of Starcraft players to future drone fighters is interesting. The OWS movement is branching out into other related areas, OccupyYourHomes.org is one of the latest ones [6]. When banks try to forclose on homes without good cause the OWS people are protesting. Cory Doctorow wrote an important article for The Guardian about corporations using the Youtube ContentID system to pirate works that other people have uploaded [7]. Matt Taibbi s description of Goldman Sachs as a great vampire squid wrapped around the face of humanity, relentlessly jamming its blood funnel into anything that smells like money will never die [8]. It has spawned many other creative descriptions of the evil and greed of Goldman Sachs and even Lloyd Blankfein of Goldman Sachs describes his company as having burned down the Reichstag, shot the Archduke Ferdinand and fired on Fort Sumter he was trying to use satire, but I don t think that Goldman Sachs people would act differently to Fritz Thyssen. Keith Packard wrote an interesting article about the Calypso CalDAV system which he uses with Android [9]. He makes lots of good points about how to improve calendaring and contacts on Android, unfortunately I lack time to fiddle with such things at the moment so I ll stick with Google in spite of the risks. Asheesh Laroia wrote a great article about the problems with short (32bit) GPG keys [10]. It seems that creating keys with matching ID numbers isn t particularly difficult and that GPG doesn t handle them as well as we would like giving the possibility of at best annoying DoS attacks and at worse security problems due to using the wrong key. Sociological Images has an interesting article about when game show audiences are trustworthy [11]. It seems that French people don t want an undeserving person to win so they will intentionally advocate the wrong answer if the contestant should know it. Paul Wayper gave a great lecture titled SE Linux for Everyone [12]. He covers the basics of SE Linux in a user-friendly way and explains some simple solutions to common problems which don t involve compromising system security. Paul Tassi wrote an insightful article for Forbes about piracy [13]. His conclusion is that the media companies should make it cheaper and easier to be a customer and not spend insane amounts of money on low quality products. The Reid Report has an interesting article about Ron Paul s racism [14]. Ron Paul is generally well regarded outside the US because he wants the US government to stop meddling in the affairs of other countries, but while he s less bad than other US politicians in terms of foreign policy that doesn t make him a good person. Anonymous hacked some mailboxes belonging to a neo-Nazi group and found links to Ron Paul [15]. I ve always been suspicious of the way Ron Paul wanted to avoid anti-racism legislation on supposed Libertarian principles. The Reid Report has an interesting summary of Ron Paul news plus some criticism of Glenn Greenwald and others who associate with him [16].

• [1] http://thesocietypages.org/socimages/2011/12/06/on-camping-and-the-framing-of-occupy-movement-strategies/
• [2] http://www.portlandoccupier.org/2011/12/15/occupy-portland-outsmarts-police-creating-blueprint-for-other-occupations/
• [3] http://tinyurl.com/6mr95hu
• [4] http://www.ted.com/talks/stefon_harris_there_are_no_mistakes_on_the_bandstand.html
• [5] http://globalguerrillas.typepad.com/globalguerrillas/2011/12/drone-bonjwas.html
• [6] http://occupyourhomes.org/
• [7] http://www.guardian.co.uk/technology/2011/dec/12/pirates-of-youtube-cory-doctorow
• [8] http://dealbook.nytimes.com/2011/12/13/the-long-life-of-the-vampire-squid-metaphor/
• [9] http://keithp.com/blogs/calypso/
• [10] http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html
• [11] http://thesocietypages.org/socimages/2011/12/26/are-game-show-audiences-trustworthy/
• [12] http://www.youtube.com/watch?v=ZThVfm3JXdM
• [13] http://www.forbes.com/sites/insertcoin/2012/02/03/you-will-never-kill-piracy-and-piracy-will-never-kill-you/
• [14] http://blog.reidreport.com/2011/12/the-real-bottom-line-on-the-paul-newsletters-race-baiting-for-power-and-profit/
• [15] http://www.care2.com/causes/anonymous-hacks-neo-nazis-finds-ron-paul.html
• [16] http://blog.reidreport.com/2011/12/should-glenn-greenwald-have-to-own-the-ron-paul-blue-plate-special/

Related posts:

1. Links February 2011 Australia s Department of Finance has mandated that the MS-Office document...
2. Links January 2012 Cops in Tennessee routinely steal cash from citizens [1]. They...
3. Links February 2009 Michael Anissimov writes about the theft of computers from the...

Fresh from the oven, monthly report of what I've been working on as DPL during January 2012.

---

Dear Developers,
here is another monthly report of what happened in DPL-land, this time for January 2012. There's quite a bit to report about --- including an insane amount of legal-ish stuff --- so please bear with me. Or not. Legal stuff

• Webmaster heroes have decided to tackle the long standing issues of copyright and licensing of the Debian website. I've accepted to help them out in reaching consensus with license choice and I'm happy to report that we've managed to pick a DFSG-free license (BSD-ish) for future contributions. Webmasters will soon contact contributors to re-license old contributions (or get rid of them), so hopefully will have a DFSG-free website RSN. Many thanks go to David Pr vot for successfully tackling such a can of worms.
• I've sought a second legal advice on the constraints that trademarks (might) impose on the work-flow of a distro like Debian. Luckily, it is coherent with one I've sought in the past so I'm now in condition to wrap up the "trademark vs DFSG" thread on -project with the missing legal information. Hopefully, I'll find time to do that sometime next week.
• I've restarted discussions with the Debian France association so that they can become a Debian Trusted Organization (as per Constitution 9.3). Members of the board of the association seem to be interested and I'm positive it could happen fairly soon. The importance of this is that we could use a back-up association in Europe to hold Debian assets, to complement the services that FFIS are already offering us.
• Thanks to the contributions of Benjamin Mako Hill and SPI lawyers, I've now what I consider a final draft of a trademark policy for Debian trademarks. Before proposing it to you, I'm waiting for some feedback from another umbrella organization for Free Software projects, that is working on a trademark policy for all their associated projects. As many Free Software projects are seeking trademark protection these days, I see benefits in having uniform (and sane!) policies. I hope to be able to gather the feedback I still miss this week-end at FOSDEM, and let you know shortly after that. Once this is done, we'll also be able to (finally!) relicense all kinds of Debian logos under a DFSG-free license. On this front, I've also updated http://www.debian.org/trademark with the information needed to contact us about trademark usage; hopefully it'll reduce the burden of answering to such inquiries.
• With the help of Kenshi Muto, Fumitoshi Ukai, Ishikawa Mutsumi, Shuzo Hatta, and Yasuhiro Araki we've started the process to move the Debian trademark in Japan from individuals (who are present or past members of the Debian JP association) to SPI. That would help dealing with these matters, as well as ensure that important Debian assets are held by Debian Trusted Organizations.
• I remind you that we've an ongoing complaint with the current registrant of debian.eu, domain that we believe Debian should legitimately own. Lawyers at SPI has now formally contacted the current owner and hopefully we'll be able to solve the issue amicably in the next months.
• Some of the past legal advice I sought for PPA came handy in a discussion on the legal risks of running a service like mentors.debian.net, hopefully addressing part of the issues in turning that into mentors.debian.org
• Patent policy for the Debian archive is now ready as well and I also have a patch for the website ready to be merged. I'm just waiting for the final blessing from SPI (lawyers) to go ahead and publish it.

Most of the above wouldn't have been possible without the precious help of folks at SFLC working for SPI and Debian. Be sure to thank SFLC for what they're doing for us and many other Free Software projects. Coordination Nobody stepped up to coordinate the artwork collection for Wheezy I've mentioned last month, so I've tried to do a little bit of that myself. The -publicity team is now preparing the call for artwork and hopefully we'll send it out RSN. In case you want to help, there is still a lot of room for that; just show up on the debian-desktop mailing list. Sprints A Debian Med sprint has happened in January, and Andreas Tille has provided a nice and detailed report about it. Some more sprints are forthcoming this spring, how about yours? Money

• We got from SPI a prepaid and rechargeable credit card that we can use for expenses or other kind of guarantees. Many thanks to Michael Schulteiss, SPI treasurer, for his help with that. Using it, we've redeemed 10k$ of credits offered to us by Amazon, that (thanks to ongoing work by Lucas Nussbaum) we're going to use to make our QA rebuilds independent from the underlying computing infrastructure.
• Thanks to the help of Luca Capello, we advanced quite a bit on forming the Debian Event Box kit that should make it easier to set up Debian booth at FOSS events. We bought the machine for it (for about ~755 CHF) and the box to contain it will soon be on its way as well. If you're at FOSDEM, tend to the Debian booth to check it out (and possibly help out with the technical setup).
• We've got quite a bit of donations during the December holidays. I've took the chance to thank donors, discuss what we do with donations and the status of publishing periodic Debian budgets.
• Pinged by Yves-Alexis Perez, I've now properly documented the fact that DDs are welcome to apply for hardware sponsoring, in case the hardware can be used to help/improve their Debian work. As suggested by Yves-Alexis, you can also advocate other DDs for hw sponsoring.
• Given hardware invariably age and that we can afford it, I've prodded DSA to prepare a general hardware replacement plan for our machines. Planning will go on this week-end and FOSDEM (thanks to Martin Zobel-Helas and Faidon Liambotis for their presence here) and I hope to have an approved machine replacement plan well before the end of the current DPL term (although I'm usually optimist...).

Important stuff going on Other important stuff has been going on in various area of the project in January. I'd like to point your attention to a couple of things:

• People active on debian-mentors have proposed an improved work-flow to deal with sponsoring/mentoring requests, based on the usage of a new pseudo package "sponsorship-requests". Thanks to Ansgar Burchardt, Jakub Wilk, Arno T ll, and Gregor Herrmann for working on this.
• Raphael Hertzog has kickstarted work on DEP-2, as a way to rationalize the flow of package-related information that (co-)maintainers get. Discussion about the idea are ongoing on the debian-qa mailing list.

Miscellanea

• Work has further progressed in reaching out to companies with an interest in giving support for, and contributing to Debian. Thanks to Alexander Wirt the technical work is now done and some sort of governance policy has been decided. Further step for me is to announce it properly hoping to reach out to as many interested companies as possible. I hope to finalize that in the next month. (If you're working for such a company and you happen to read this, feel free to reach out to me already.)
• I've completed an old todo item setting up and documenting titanpad.debian.net, service that has been requested for collaborative work during various kinds of online events. Help is welcome to help administering the service (see doc).
• SPI has clarified the role of project representatives and, as a consequence of that, I (as DPL) no longer receive SPI board discussions addressed to board@spi. That is good not only for the sanity of my inbox, but also because it puts all projects affiliated to SPI at the same level of communication within SPI. Thanks to Robert Brockway for his work on this.

In the unlikely case you've read thus far, thanks for your attention! Happy Debian hacking.

---

PS as usual, the boring day-to-day activity log is available at master:/srv/leader/news/bits-from-the-DPL.*

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (213.68 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg The biggest change I made is a small patch that brings to an end years and years of recurring discussions about the build-arch and build-indep targets of debian/rules (see #229357). Last year the technical committee took this issue in its hands (see #629385) but it failed to take any resolution. Fortunately thanks to this we got some concrete numbers on the colateral damages inflicted on the archive for each possible approach. In the end, Guillem and I managed to agree on the way forward. The remaining of what I did as dpkg maintainer has not much to do with coding. I reviewed the work of Gianluca Ciccarelli on dpkg-maintscript-helper who is trying to provide helper functions to handle migration between directories and symlinks. I also reviewed a 2000-lines patch from Patrick Schoenfeld who s trying to provide a perl API to parse dpkg log files and extract meaningful data out of them. I updated the dpkg-architecture manual page to document the Makefile snippet /usr/share/dpkg/architecture.mk and to drop information that s no longer releveant nowadays. I reviewed a huge patch prepared by Russ Alberry to update the Debian policy and document the usage of symbols files for libraries. As the author of dpkg-gensymbols, I was keen to see it properly documented at the policy level. I brought up for discussion a detail that was annoying me for quite some time: some copyright notices were embedded in translatable strings and updating them resulted in useless work for translators. In the end we decided to drop those notices and to keep them only at the source level. I updated my multiarch branch on top of Guillem s branch several times, all the fixes that were in my branch have been integrated (often in a modified form). Unfortunately even if the code works quite well, Guillem doesn t want to release anything to Debian until he has finished to review everything and many people are annoyed by the unreasonable delay that it imposes. Cyril Brulebois tried to release a snapshot of the current multiarch branch to experimental but Guillem has been prompt to revert this upload. I m somewhat at a loss in this situation. I offered my help to Guillem multiple times but he keeps doing his work in private, he doesn t share many details of his review except some comments in commit logs or when it affects the public interface. I complained once more of this sad situation. Debian Package Maintenance Hub That s the codename I use for a new infrastructure that I would like to develop to replace the Package Tracking System and the DDPO and several other services. I started to draft a Debian Enhancement Proposal (DEP), see DEP-2, and requested some comments within the QA team. For now, it looks like that nobody had major objections on the driving idea behind this project. Those who commented were rather enthusiastic. I will continue to improve this DEP within the QA team and at some point I will bring the discussion to a larger audience like debian-devel@lists.debian.org. Package Tracking System Even if I started to design its replacement, the PTS will still be used for quite some time so I implemented two new features that I deemed important: displaying a TODO notice when there is (at least) one open bug related to a release goal, displaying a notice when the package is involved in an ongoing or upcoming transition. Misc packaging tasks I created and uploaded the dh-linktree package which is a debhelper addon to create symlink trees (useful to replace embedded copies of PHP/JavaScript libraries by symlinks to packaged copies of those files). I packaged quilt 0.50. I helped the upstream authors to merge a Debian patch that had been forwarded by Martin Quinson (a quilt s co-maintainer). I packaged a security release of WordPress (3.3.1) and a new upstream release of feed2omb and gnome-shell-timer. I prepared a new Debian release of python-django with a patch cherry-picked from the upstream SVN repository to fix the RC bug #655666. Book update We re again making decent progress in the translation of the Debian Administrator s Handbook, about 12 chapters are already translated. The liberation campaign is also (slowly) going forward. We re at 72% now (thanks to 63 new supporters!) while we were only at 67% at the start of January. Thanks See you next month for a new summary of my activities.

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

When you read this, GNOME Shell 3.2 will (hopefully!) have finally transitioned to Debian s testing suite. Planet GNOME readers might think Debian now has outdated versions of software even in their development versions, or the distribution s development marches at glacial pace. Wheezy GNOME users will finally have a Shell that matches the rest of their GNOME components, something that works with the Shell extensions website and much less problems and limitations compared to 3.0.2. The reality is that GNOME 3.2 s packaging was quite ready back when it was released in late September, but a number of not-so-desirable situations held GNOME Shell from transitioning to testing until today, four months later. So, what happened? TL;DR: transitioning from GNOME 2 GNOME 3 is not so easy if you want to keep testing in a sane state, and when you need to deal with dozens of indirectly related packages, for more than 10 architectures but it shouldn t take nearly a full year, either Let s go back to the last months of 2010. Debian squeeze is in very deep freeze, and the release team and many Debian developers are focusing on squashing as many release critical bugs as they can, in order to make Debian 6.0 the great release it ended up being. The GNOME project has recently delayed the big launch of GNOME 3.0 again, until March 2011; Debian has already settled on GNOME 2.28 for its release, although it will end up cherry-picking many updates from the 2.30 release modules. With most of the stabilization work being done, many Debian GNOME team members were at that time working on packaging very early versions of what would end up being GNOME 3.0 technology: GTK+3.0, GNOME Shell, Mutter and some brave users even tried to use it via the experimental archive. On February 6th, Debian 6.0 was released, and soon after, on April 6th, GNOME made a huge step forward with the much anticipated release of GNOME 3.0. At that time, Debian developers were busy breaking unstable as much as they could, as it s tradition on the weeks following a major release, and the Debian GNOME team was able to start moving some GNOME 3.0 libraries (those which were parallel-installable with their GTK+2.0 versions) to unstable. However, moving the bulk of GNOME 3.0 to unstable wasn t so easy. When you start doing that, you need to be sure you re ready to have all affected packages in a transitionable state as soon as possible, to minimise the chances of blocking transitions of unrelated packages via the dependencies they pick up with rebuilds. All the packages involved in a transition need to be ready to go in the same testing run , for all supported architectures. When you re dealing with dozens of GNOME source packages at the same time, many of which introduce new libraries, or worse, introduce incompatible APIs that affect many more unrelated packages, things get hairy, and you need a plan. So, Joss outlined what a sane approach to this monster transition could look like. The amount of work to do was what we call fun on #debian-gnome. In a nutshell, we had to deal with quite a few transitions, starting with having a newer version of libnotify in unstable, and a pre-requisite for that was making sure all the packages using libnotify1 were ready to use the source-incompatible libnotify4, and this meant preparing patches and NMUs for many of our packages, as well as many others not under our control. Before starting a controlled transition like this one, we had to get an ACK from the release team, who was busy enough handling other huge transitions like Perl 5.12, so by the time we got our own slot, we were well into Summer. With libnotify done in August, it was time to get our hands dirty with more exciting stuff, like getting Nautilus in testing. This meant bumping a soname and requiring all packages providing Nautilus extensions to migrate to GTK+3.0, or drop the extension entirely, as you can t mix GTK+2.0 and GTK+3.0 symbols in the same process. However, in GNOME 3.0, automounting code had moved from Nautilus to gnome-settings-daemon, so in order to not break filesystem automounting in testing for an unreasonable amount of time, both Nautilus and g-s-d needed to go in at the same time. The fun thing is that g-s-d dragged glib2.0, gvfs, gnome-control-center, gdm3, gnome-media, gnome-session and gnome-panel into the equation, so this transition needed extra planning and a lot more work than initially expected: migrating all nautilus extensions, plus ensuring all Panel applets had migrated to GTK+3.0 and the new libpanel-applet-4 interface. In short, this was the monster transition we were trying to avoid. By the time all this mess was sorted out, GNOME 3.2 had been released, and for what users said, it was a lot better than 3.0. We still had no more than a few bits and pieces of 3.0 in testing, and we were working hard to get 3.0 in wheezy. With all the excitement around 3.2, at times it was difficult to explain outsiders why we were beating a dead 3.0 horse Going back to our huge transition, it was just a matter of time before all the packages would be built and be ready to enter, on the same run, in testing. A few weeks later, in early November and after several rounds of mass-bug-filings, fixing unrelated FTBFS, many NMUs, package removal requests and dealing with any possible problem that could block our transition, everything seemed to be set, and our release team magicians had everything in place for the big magic to happen. However, our first clash with the rest of Debian happened a few hours before our victory, in the form of an unannounced ruby-gnome2 upload which resetted the count for everyone. It was fun to see the release team trying all sorts of black magic in an attempt to mitigate the damage. Fortunately, after a few tries they managed to fool britney (the script that handles package transitions from unstable to testing) somehow, and the hardest part of the job was done with just one day of delay. At last, the core of GNOME 3 was in testing, and testing users found soon after. The rest of the week saw a cascade of hate posts against GNOME 3 in Planet Debian, and personally I didn t find that especially motivating to keep on working on the rest of GNOME bits. With experimental clear of GNOME 3.0 stuff, we finally were able to focus on packaging whatever GNOME 3.2 components were not already done, and preparing for what should be a plain simple transition of GNOME 3.0 to 3.2. After our share of wait for a transition slot, as Perl 5.14, ICU and OpenSSL were in the line before us, and after dealing with a minor tracker 0.12 transition, we were ready for our next episode: evolution-data-server. At first sight, we thought this would be a lot easier, but it still got a bit hairy due to evo-data-server massive soname bumps. We were given our slot just before Christmas, after a few weeks of wait for others to finish their migration rounds, and most of the pack entered wheezy a few days before the new year. No rejoicing, though, as GNOME Shell 3.2 didn t make it. First, we discovered it was FTBFS on kFreeBSD architectures, as NetworkManager had been promoted from optional to required, for apparently no good reason, leaving the BSD world in the cold, including our exotic GNU/kFreeBSD architectures. Now, let s clarify that I m a supporter of the Debian kFreeBSD architectures and was really happy to see it accepted as a technology preview in squeeze. However, as you know, GNOME Shell currently requires hardware acceleration to run, a requirement hardly met in kFreeBSD, unless you re using a DRI1 X driver. We seriously doubted anyone had ever ran a GNOME 3 session on kfreebsd-*. However, if it didn t build, it was a blocker bug for GNOME Shell. We considered creating different meta-packages for kFreeBSD architectures, to conclude it d be a mess, so our awesome Michael Biebl ended up cooking up a patch that restored the ability to build the Shell without NetworkManager support. With this out of our way, we just needed to upload Michael s fix and watch the buildds do their part of the job. Or maybe not? Enter Iceweasel 9. In parallel, and with incredible bad timing, Iceweasel 9.0 was uploaded to Debian the very same day it was released by Mozilla. Again, it greeted us with a nasty surprise: yet another mozjs API change, which made gjs FTBFS, which meant our kFreeBSD fixes would be unusable until someone who knew Gjs internals well enough bit the bullet and worked around the new API changes. Again, Michael Biebl tried to be our saviour, but unfortunately wasn t able to fix all the problems, so we tried to focus on plan B. Mozilla had released a fork of the mozjs that is included in Firefox, so that embedders would have a bit less of a hard time with these recurrent API changes. This was based on Firefox 4, and was already being packaged by Ubuntu. Gjs would build using this older version just fine, so we just needed to get it in Debian as soon as possible. We just needed to find a sucke^Wvolunteer that would be inclined to maintain the beast. Only after a few weeks we managed to get Chris Coulson, the Ubuntu packager, to maintain the package directly through the Debian archive via package syncs. However, his package had only been auto-compiled in the three Ubuntu architectures, that is amd64, armel and i386. It s late January 2012, and we ve been fighting this war for 10 months. After getting some help from Michael to get the new package in shape for Debian standards, we were excited to sponsor it for Chris. Duh, after a few days in the NEW fridge, it was rejected by the ftp-masters. The license statement was missing quite a few details, so I went ahead and sacrificed a few hours of my copious free time to get this sorted out. A few days later, mozjs was accepted, but the result was horrible. It was very red. mozjs didn t build on half of our targets. Mike Hommey was quick to file a bug and point us to the most obvious fuckups. As he had dealt with this in the past as the Iceweasel maintainer, all of these issues were fixed and patches were ready to be applied verbatim or with minimal changes to our sources. With mozjs finally built successfully (although with severe problems on ia64), we were finally able to rebuild Gjs against it, upload GNOME Shell with our kFreeBSD fixes and wait until today for this mess to be over. Whew. I can t say I ve enjoyed all the stages of this ride. Some bumps on the road were clearly there to test our patience, but it has helped me get back in touch with non-leaf GNOME packaging, which was all I was doing for a while due to being super-busy lately with studies. It also reminds me of the privilege of working side by side with some awesome people, not only Joss, Michael, Sjoerd, Laurent or Gustavo, to name just a few Debian GNOME team members, but also the receptive release team members like Julien or Cyril, and NEW-processing record-breaking ftp-master Luca. Without them, we might be trying to figure out the Nautilus transition since last Summer. We really hope GNOME 3.4 will be a piece of cake compared to this. ;)

Can t believe its almost 7 years since my first sponsored upload of Dibbler to Debian archive. I did it cause upstream promised to maintain it and fix any bugs submitted by Debian users. Unfortunately after 3-4 years he stopped to do it. Well since I was the sponsor of it, then I should feel responsible for these packages after him. It s quite hard to do it, cause I m not using these packages at all Anyway, I finally found some time and reviewed them. It wasn t easy cause in the meantime whole build process totally changed. To whom it may concern: Dibbler is an IPv6 DHCP client, relay and server. I ve just uploaded the newest upstream version. Changelog follows: dibbler (0.8.1-1) unstable; urgency=low * ACK previous NMUes thanks!
* New upstream version (Closes: #629685)
uses correct example adsress pool in examples (Closes: #544323)
corrects scope of stateless in manpage (Closes: #615165)
* Fix pending l10n issues. Debconf translations:
Danish courtesy of Joe Hansen (Closes: #597767)
Dutch courtesy of Jeroen Schot (Closes: #632628)
* Fixes handling of children processes using resolvconf (Closes: #627317)
* Doesn t conflict with other resolver configuration daemons (Closes: #627786)
* Correctly handles multiselect values from debconf (Closes: #629681)
* Debianized almost from scratch, uses new source format.
* New Standards-Version (no changes needed). Bartosz Fenski <fenio> Fri, 27 Jan 2012 14:37:13 +0100 Yep, it fixes 8 bugs, and brings the newest upstream version with huge number of new features to Debian. Enjoy!

I've started uploading snapshots of git-buildpackage to experimental recently. Here's a short list of what changed over the version in wheezy and sid:

• git-buildpackage now has a --git-pristine-tar-commit option that commits a tarball right back to the pristine-tar branch if it's not already there. This makes tracking upstream git and dfsg-clean source handling easier.
• git-buildpackage's --git-upstream-tree now accepts a tree directly without the need to use --git-upstream-branch.
• git-buildpackage's --git-export now parses the exported changelog instead of the working copy. This way we automatically pick up the correct tarballs, branches, etc. reducing the number of options needed.
• Jan apek added a --git-postexport hook to allow to mangle the source after exporting it.
• gbp-pull and gbp-fetch now support shallow clones thanks to Markus Lehtonen.
• gbp-pull got a speed up by skipping the checkout for fast-forward. This makes updating large source trees less time consuming.
• git-import-orig and git-import-dsc can now import into bare repositories.
• Russ Allbery updated git-pbuilder to 1.27.
• gbp-pq should be easier to use thanks to the --force and --switch options. It also handles patches without descriptions more robustly.
• The test coverage of the internal test suite increased quiet a bit. We're now generating coverage information during the build in build/cover.
• We're now generating apidocs which also serves as usage examples.

This blog is flattr enabled.

And now a slightly longer than usual rant: The problem with the o2 network disclosing mobile browsers phone numbers that I repeated 2 days ago (and it appeared on our co-op website) snowballed yesterday to the point that it was on the short bulletins from ITN, BBC, IRN and probably many more. And then o2 fixed it. Good! The reply claims that it s only since 10th January which is rather at odds with other claims that it has been happening since at least March 2010 in some situations. I started buying from o2 in December. I was using Three, but their network where I stay in Norfolk isn t reliable and you can t just buy a device in a shop for The Phone Co-op. The dongle from o2 is a recent Huawei USB device that just worked in debian and was fairly easy for me to get working in Ubuntu. There s space in it for a memory card, so maybe I could boot from it but that s an idea for later. The o2 deal is OK but not great, and the included wifi is nowhere near as good as it looked: when it says it includes BT Openzone that doesn t include any of the BT Openzone-H hotspots that are much more common. You re only allowed to register one device for wifi, so no using your phone, tablet and laptop at different times! I can t believe it s legal to advertise that as unlimited wifi , but o2 is still a better offer than access to BT Openzone-H hotspots at 39/month (yes, that s the price for wifi-only ). Ultimately, I think the problem is that there s a rubbish choice of mobile (wifi or 3G) internet access providers in the UK. It s a completely and utterly failed market, so you need to use Virtual Private Networks and similar tricks to protect yourself from the dysfunctional networks. My VPN meant my mobile number was safe: how about yours? As luck would have it, I had already proposed a resolution about protecting customer privacy to The Phone Co-op (affiliate link) for our AGM on Saturday 4 February (if you re a member, let me know). We were trying to find a compromise wording and I don t think this little o2 scandal has hurt my proposal at all! At least the phone co-op s mobile service is based on Orange s network, which wasn t affected. How does your network perform? There s an Internet Service Provider evilness test which might tell you.

Cops in Tennessee routinely steal cash from citizens [1]. They are ordered to do so and in some cases their salary is paid from the cash that they take. So they have a good reason to imagine that any large sum of money is drug money and take it. David Frum wrote an insightful article for NY Mag about the problems with the US Republican Party [2]. TreeHugger.com has an interesting article about eco-friendly features on some modern cruise ships [3]. Dan Walsh describes how to get the RSA SecureID PAM module working on a SE Linux system [4]. It s interesting that RSA was telling everyone to turn off SE Linux and shipping a program that was falsely marked as needing an executable stack and which uses netstat instead of /dev/urandom for entropy. Really the only way RSA could do worse could be to fall victim to an Advanced Persistent Attack :-# The Long Now has an interesting summary of a presentation about archive.org [5]. I never realised the range of things that archive.org stores, I will have to explore that if I find some spare time! Jonah Lehrer wrote a detailed and informative article about the way that American high school students receive head injuries playing football[6]. He suggests that it might eventually be the end of the game as we know it. Fran ois Marier wrote an informative article about optimising PNG files [7], optipng is apparently the best option at the moment but it doesn t do everything you might want. Helen Keeble wrote an interesting review of Twilight [8]. The most noteworthy thing about it IMHO is that she tries to understand teenage girls who like the books and movies. Trying to understand young people is quite rare. Jon Masters wrote a critique of the concept of citizen journalism and described how he has two subscriptions to the NYT as a way of donating to support quality journalism [9]. The only comment on his post indicates a desire for biased news (such as Fox) which shows the reason why most US media is failing at journalism. Luis von Ahn gave an interesting TED talk about crowd-sourced translation [10]. He starts by describing CAPTCHAs and the way that his company ReCAPTCHA provides the CAPTCHA service while also using people s time to digitise books. Then he describes his online translation service and language education system DuoLingo which allows people to learn a second language for free while translating text between languages [11]. One of the benefits of this is that people don t have to pay to learn a new language and thus poor people can learn other languages great for people in developing countries that want to learn first-world languages! DuoLingo is in a beta phase at the moment but they are taking some volunteers. Cory Doctorow wrote an insightful article for the Publishers Weekly titles Copyrights vs Human Rights [12] which is primarily about SOPA. Naomi Wolf wrote an insightful article for The Guardian about the Occupy movement, among other things the highest levels of the US government are using the DHS as part of the crackdown [13]. Naomi s claim is that the right-wing and government attacks on the Occupy movement are due to the fact that they want to reform the political process and prevent corruption. John Bohannon gave an interesting and entertaining TED talk about using dance as part of a presentation [14]. He gave an example of using dancerts to illustrate some concepts related to physics and then spoke about the waste of PowerPoint. Joe Sabia gave an amusing and inspiring TED talk about the technology of storytelling [15]. He gave the presentation with live actions on his iPad to match his words, a difficult task to perform successfully. Thomas Koch wrote an informative post about some of the issues related to binary distribution of software [16]. I think the problem is evenm worse than Thomas describes.

• [1] http://www.youtube.com/watch?v=Xg4ArbQpsIU
• [2] http://nymag.com/print/?/news/politics/conservatives-david-frum-2011-11/
• [3] http://www.treehugger.com/natural-sciences/7-ocean-friendly-eco-cruises-hitting-the-high-seas.html
• [4] http://danwalsh.livejournal.com/48571.html
• [5] http://longnow.org/seminars/02011/nov/30/universal-access-all-knowledge/
• [6] http://www.grantland.com/story/_/id/7443714/jonah-lehrer-concussions-adolescents-future-football
• [7] http://feeding.cloud.geek.nz/2011/12/optimising-png-files.html
• [8] http://www.helenkeeble.com/2011/08/08/repost-what-i-thought-about-twilight
• [9] http://www.jonmasters.org/blog/2011/11/30/on-citizen-journalism/
• [10] http://www.ted.com/talks/luis_von_ahn_massive_scale_online_collaboration.html
• [11] http://duolingo.com/
• [12] http://www.publishersweekly.com/pw/print/20111205/49728-cory-doctorow-copyrights-vs-human-rights.html
• [13] http://www.guardian.co.uk/commentisfree/cifamerica/2011/nov/25/shocking-truth-about-crackdown-occupy
• [14] http://www.ted.com/talks/john_bohannon_dance_vs_powerpoint_a_modest_proposal.html
• [15] http://www.ted.com/talks/joe_sabia_the_technology_of_storytelling.html
• [16] http://www.koch.ro/blog/index.php?/archives/153-On-distributing-binaries.html

Related posts:

1. Links January 2011 Halla Tomasdottir gave an interesting TED talk about her financial...
2. Links January 2010 Magnus Larsson gave an interesting TED talk about using bacteria...
3. Links January 2009 Jennifer 8 Lee gave an interesting TED talk about the...

Since my last SE Linux in Debian status report [1] there have been some significant changes. Policy Last year I reported that the policy wasn t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released. Kernel Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though. As the kernel silently ignores command line parameters that it doesn t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won t work with SE Linux. As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven t needed to be changed for 6 years! SE Linux isn t a new thing, it s been in production for a long time. Audit While the audit daemon isn t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future. Libraries There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I m sure that I will notice soon enough if they don t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing. Play Machine I am now preparing a new SE Linux Play Machine running Debian/Unstable. I wore my Play Machine shirt at LCA so I ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

• [1] http://etbe.coker.com.au/2011/10/31/selinux-status-2011-10/

Related posts:

1. Status of SE Linux in Debian LCA 2009 This morning I gave a talk at the Security mini-conf...
2. SE Linux in Debian I have now got a Debian Xen domU running the...
3. Debian SE Linux Status At the moment I ve got more time to work on...


The following is a makefile fragment I seem to start each of my appengine projects with.

GAEPATH = $(HOME)/bin/google_appengine
PORT=8081

PYLINTS = $(wildcard *.py */*.py */*/*.py)
PYLINTFILES = $(patsubst %.py,.%.lint,$(notdir $(PYLINTS)))
PYLINT = $(join $(dir $(PYLINTS)),$(PYLINTFILES))

PYTHONPATH=$(GAEPATH):$(GAEPATH)/lib/yaml/lib:$(GAEPATH)/lib/webob:$(GAEPATH)/lib/django_0_96:.

APP=new-app

run:
$(GAEPATH)/dev_appserver.py ./ --port=$(PORT) --datastore_path=/tmp/$(APP).dev_appserver.datastore


.%.lint: %.py
@PYTHONPATH=$(PYTHONPATH) pychecker --only --no-miximport $?
@touch $@


lint: $(PYLINT)


Adam sent a new call for testing for the next point release of Debian Squeeze. Please test the packages in squeeze-proposed-updates on some machines running squeeze if possible, so that we don't screw up your production machines with bad updates in a week. The point release is scheduled for January 28th, i.e. next Saturday. Don't forget to copy the debian-release mailing list when you encounter regressions. Thanks for your efforts.

If you want to receive these notices by mail, please subscribe to the debian-stable-announce mailing list.

Last year I shared my Debian related goals for 2011 . I tend to put more goals than what I can reasonably complete alone and this year was no exception. Let s have a look.

1. Translate my Debian book into English: PARTLY DONE
   It took more time than expected to prepare and to run the fundraising campaign but it has been successful and the translation is happening right now.
2. Finish multiarch support in dpkg: DONE BUT NOT ENTIRELY MERGED YET
   Yes, multiarch support was already in the pipe last year in January. I completed the development between January and April (it was sponsored by Linaro) and since then it has mostly been waiting on Guillem to review it, tweak it, and integrate it.
3. Make deb files use XZ compression by default: TRIED BUT ABANDONED
   After discussing the issue with Colin Watson and Joey Hess during debconf, I came to the conclusion that it was not really desirable at this point. The objections were that debian-installer was not ready for it and that it adds a new dependency on xz for debootstrap to work on non-Debian systems. I believe that the debian-installer side is no longer a problem since unxz is built in busybox-udeb (since version 1:1.19.3-2). For the other side, there s not much to do except ensuring that xz is portable to all the other OS we care about. DAK has been updated too (see #556407).
4. Be more reactive to review/merge dpkg patches: PARTLY DONE
   I don t think we had any patch that received zero input. We still have a backlog of patches, and the situation is far from ideal but the situation improved.
5. Implement the rolling distribution proposed as part of the CUT project and try to improve the release process: NOT DONE
   We had a BoF during debconf, we discussed it at length on debian-devel, but in the end we did nothing out of it. Except Josselin Mouette who wrote a proof of concept for his idea. For me testing is already what people are expecting from a rolling distribution. It s just a matter of documenting how to effectively use testing, and of some marketing by defining rolling as alias to testing.
6. Work more regularly on the developers-reference: PARTLY DONE
   I did contribute some new material to the document but not as much as I could have hoped. On the other hand, I have been rather reactive to ensure that sane patches got merged. We need more people writing new parts and updating the existing content.
7. Write a 10-lesson course called Smart Package Management : NOT DONE
8. Create an information product (most likely an ebook or an online training) and sell it on my blog: NOT DONE
   This was supposed to happen after the translation of the Debian Administrator s Handbook. Since the translation is not yet over, I did not start to work on this yet.
9. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products: NOT REACHED
   My target was rather aggressive with 700 each month, and given that I did not manage to complete any information product, I m already very pleased to have achieved a mean amount of 204 of donations each month (min: 91 , max: 364 ). It s more than two times better than in 2010. Thank you! Note that those figures do not take into account the revenues of the fundraising of the Debian Administrator s Handbook since they will be used for its translation.

That makes quite a lot of red (for things that I did not achieve) on the other hand I completed projects that I did not foresee and did not plan. For instance improving dpkg-buildflags and then merging Kees Cook work on hardened build flags was an important step for Debian. This was waiting for so long already

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