Having monitoring for dualstack connectivity in place helps a lot. Unfortunately in most cases we are running also services we want to offer dualstacked. In the past we just monitored in those cases IPv4 only or created a separate check for the same service on IPv6. This is a bit messy and I was looking for something to check services via IPv4 and IPv6. Digging my most boring search engine doesn t help much here. So I was talking with some people more involved into the core Icinga/Nagios stuff. Seems there is actually the best solution to use check_multi. As we have the command definition for check_multi_icinga already in place, I created a check_smtp_dualstack.cmd for monitoring a dualstacked SMTP service

command[ IPv4 ] = check_smtp -4 -H $HOSTADDRESS$
command[ IPv6 ] = check_smtp -6 -H $HOSTADDRESS6$
state [ CRITICAL ] = COUNT(CRITICAL) > 1
state [ WARNING ] = COUNT(WARNING) > 0 COUNT(CRITICAL) > 0
state [ UNKNOWN ] = COUNT(UNKNOWN) > 1 A simple SMTP service definition does the trick (don t forget address6 in host definition)

define service
use generic-service ; Name of service template to use
host_name localhost
service_description SMTP
check_command check_multi_icinga! check_smtp_dualstack.cmd !'-r 1+2+4+8
Okay .. that looks nice, but only at the first view. Imagining what we are actually running as service checks, it seems we just need for every unique service check a new cmd-file for check_multi as I didn t found a way to generalize the whole stuff yet. Does anybody know a way to pass commands for check_multi via service definitions? Something like:

define service
[...]
check_command check_multi_icinga! check_general_dualstack.cmd !'check_smtp -p 666 ! -r 1+2+4+8
[...]

FedEx has had some issues in my area. There for awhile, they kept returning packages as undeliverable, saying the address was bad. It wasn t. Just because their GPS can t find it or their driver doesn t know it doesn t mean it doesn t exist. A map, a real map, would have done it. I had this kind of conversation with them once. Me: So you re returning my package to the sender. FedEx: Yes sir, the address was wrong. Me: No, it wasn t. [ we confirm we're talking about the same address. ] FedEx: Our driver says it doesn t exist. Me: I ve lived here for [x] years. I do know my address. FedEx: Maybe it s just new. Me: Someone has lived at this spot since the 1890s. FedEx: Hmm. I don t know then. Me: How about I give you directions? FedEx: Well, OK, I guess I could send directions. But they probably won t see them for three days. Me: Where will my package be by then? FedEx: Hard to say. Me: Do you people have cell phones maybe? FedEx: No. Me: Well, OK then Lately we have been noticing that the driver throws the package from the truck without stopping. We find them all over the yard. Unless it s big, in which case he puts it on the porch, puts a completely useless sticker on the door saying We delivered your package to right here! , and doesn t ring the doorbell. And panics due to the muddy road. The FedEx driver once told Terah, I almost got stuck on that muddy road! What s the good one? Terah: Well, which one did you take? [ he describes ] Terah: [ serious ] That IS the good road. FedEx: [ turning pale ] Oh my. I don t know if I can make it back to the highway. Terah: Well, I suppose I could get the boys in the car and drive you into town FedEx: [ embarrassed and more pale ] Uhm that s OK uhm I think A *month* later, we got another FedEx package. The driver called me at work, saying, I just don t know how I m going to get down those roads. Can I deliver the package to you here? (10 miles away). I said yes, and managed to suppress a significant snicker at his obvious relief. FedEx drivers seem to come and go. The UPS driver, on the other hand, knows the names of our boys, our cat, and puts anything small behind the storm door so it won t blow away if we re not home. And he gets a great big laugh when I tell him that the FedEx drivers are afraid of our roads. Haha, he thinks THAT S mud? Obviously he never drives in Butler County.

I've just switched https://l10n.cihar.com/ to Weblate as I think it's stable enough to replace Pootle installation there. This change immediately affects translation of all projects which were done there - phpMyAdmin, Gammu, Wammu, GePeS or Ukolovnik. In addition Weblate itself is also being translated there. Your old usernames and passwords should be valid (in case you've activated the account and used it in last year), but you might want to adjust your profile as the settings were intentionally not imported (many users had corrupted name in Pootle and hope this will let them fix it). Let's see how many bugs will this switch reveal, but I expect it will work quite smoothly.

Filed under: English Gammu Phpmyadmin Weblate Website 1 comments Flattr this!

I followed Gregor s evolution within Debian because I used to be somewhat active in the Perl team. His case is exemplar because it shows that you don t need to be an IT professional to join Debian and to make a difference. His QA page is impressive with hundreds of packages maintained and hundreds of non-maintainer uploads too. While he started out slowly, I remember meeting him at Debconf 7 in Edinburgh and after that he really got more implicated. Again a case of someone joining for technical reasons but getting more involved and staying there for social reasons! Let s jump into the interview and learn more about him. Raphael: Who are you? Gregor: I m 41 years old, and I live in Innsbruck, Austria, in a shared apartment with a friend of mine. In my day job, I m working at the regional addiction prevention agency, so I m one of the few Debian guys who s not an IT student or professional. I started maintaining packages in 2006, and I am a DD since April 2008. Raphael: How did you start contributing to Debian? Gregor: After having used Debian on servers for some years, I finally switched to it on the desktop after some procrastinating. Soon afterwards I wanted to know more about the making-of , started to join mailing lists, filed bugs, and tried to learn packaging. Luckily I quickly found a permanent sponsor Tony Mancill, and we re still co-maintaining each others packages. And when I packaged my first Perl modules, Gunnar Wolf invited me to join the Debian Perl Group, an offer I accepted a few days later. And I m still there Later, the NM process, although it involved some waiting times, was also a good learning experience due to my AM Wouter Verhelst. (And in the meantime the organization of the NM process has vastly improved, from what I hear.) So my starting point for joining Debian was my curiosity but what really helped me to find my way into the project was the support of the people who invited and helped me. Raphael: What s your biggest achievement within Debian or Ubuntu? Gregor: I m not sure I can name a single big achievement but I guess I can say that my contributions to the Debian Perl Group have helped to make and keep the team a success story. Raphael: The pkg-perl team seems to work very well. As an active member, can you explain us how it is organized? How do you explain its success? In particular it seems to be a great entry point for new contributors. Gregor: The team is huge, both in numbers of members and packages (over 2200). Since last DebConf we manage our source packages in git, we have 2 mailing lists and an IRC channel, and we manage to keep an overview by using PET, the Package Entropy Tracker. It s true that we get new members on a regular basis; we try to invite people (like it happened to me 6 years ago ) but there are also quite a few new contributors who find our docs and introduce themselves on the mailing list. Maybe someone should conduct a study and ask them what motivated them to join. We hand out group membership/commit access quickly, and we try to mentor new contributors actively during their early times in the group. Some of them leave for other projects after some time, but many also stay and become DDs later. I m not sure what the reasons for the group s success are, maybe a combination of:

• a culture in the group (and also in the upstream Perl community) that s based on fun, cooperation, and respect;
• the fact that packaging Perl modules is most of the time quite easy;
• a great set of tools, and also (hopefully) useful documentation;
• a bunch of relaxed people who are open to newcomers and try to help each other.

For everyone interested in joining the Debian Perl Group, our Welcome page on the wiki is a good starting point. Raphael: What are your plans for Debian Wheezy? Gregor: Nothing overly exciting. What I should do is getting a newer JabRef into Debian (which involves packaging some new Java libraries any takers?). A solution for libdatetime-timezone-perl (which ships timezone data converted to Perl modules and tends to get outdated when the timezone data change) would be nice; let s see if #660404 leads to some results And some Perl packages will also need a bit of work for the hardening build flags release goal (cf. #657853). Raphael: What s the biggest problem of Debian? Gregor: Inertia. While I really like the fact that Debian is a volunteer project, and that every contributor works when and on what they decide to work on, I get the feeling that Debian could do better in moving forward, innovating, taking decisions. I also think that more uniformity in managing source packages would make things easier; it s quite amazing to see how many source formats, packaging helpers, patch systems, RCSs etc. are used all over the archive. I m not advocating for mono-cultures, and I consider this diversity a strength in general, but having to find out first how this particular package works when preparing a bug fix can be annoying. On the bright side, I think that the myth Debian and its mailing lists are mostly about flames can be seen as dispelled in the meantime. Sure, sometimes the tone could be a bit more civil, but in general most of the interactions I ve seen in the last years were friendly and helpful. IMO, the Debian Project consists of mostly nice and cooperative people, and that s what makes it fun for me. Raphael: You re one of the most dedicated participants to RCBW (Release Critical Bugs of the Week), an initiative to fix RC bugs every week. How much time do you spend on it? What would you advise to people who are considering to join the movement? Gregor: I got into the habit of fixing RC bugs after having been invited to my first Bug Squashing Party in Munich some years ago. During this weekend I saw that fixing RC bugs can be fun, is often not that difficult, and gives a warm fuzzy feeling I can definitely recommend attending a BSP if one happens to be organized near you. After tasting blood at this first BSP I tried to continue looking at RC bugs, and I guess I spend something around half an hour per day on it. I usually blog about it once a week, in order to motivate others to join in. And joining is easy: just take a look at the tips people like Zack, Vorlon, or me have written. You don t have to be a DD to help, many of my NMUs are based on patches that others kindly prepare and send to the BTS kudos! Another nice aspect is that the RC bug list contains problems from different fields: general packaging problems, language-specific issues, policy violations, etc. So there s something for everybody, and you don t have to be an expert in all fields to fix a specific bug. What s rewarding about fixing RC bugs is not only the feeling of accomplishment and the knowledge about having helped the next release I also received quite a few Thank you mails from maintainers who were busy at that time and appreciated the help. Raphael: Do you have wishes for Debian Wheezy? Gregor: Well, there s not so much left of the Wheezy release cycle if we manage to freeze in June Some quick thoughts for Wheezy and Wheezy+1:

• Obviously, getting multi-arch and the hardening build flags as far as possible would be good.
• What I like is the idea of the time-based freeze, and I hope it will work out in June. And then I hope that the freeze will be shorter this time than during the last 2 releases.
• Unless I m missing something, the CUT discussions have more or less died down; IMO that s a pity because there are users who run testing and would like to avoid the several month long freeze. Maybe someone can come up with new ideas for Wheezy+1
• Too late for broad adoption in Wheezy but still: What constantly annoys me is the handling of conffiles during upgrades (when I want to keep changed values but at the same time want to add new variables). Config::Model seems to be the best idea so far for configuration upgrades but it s not yet widely adopted.

Raphael: Is there someone in Debian that you admire for their contributions? Gregor: There are many people in Debian I admire, too many to name them all. The first one that comes to my mind is Russ Allbery who not only does great work from lintian to Debian policy but who also sets a great example of communicating in a perfectly polite and respectful way even in heated discussions.

---

Thank you to Gregor for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

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

I'd been curious about Jonathan Lethem ever since Cory Doctorow blogged a riveting review of 'Chronic City' on boingboing, but it was this short fictionalisation of Phil K Dick's early writing life that really made me curious to sample more of his work. It was then that I discovered that virtually no (physical) bookshop anywhere in my vicinity, first or second hand, had a single book by him in stock. Of course I could have ordered some books on Amazon immediately, but I've been trying to ween myself off the urge to purchase and own every book I want to read. I was beginning to wonder whether anyone in the UK had heard of Lethem when I found two books in the Durham branch of Waterstones. The city library near where I work has a small number on their records, but most of them are on loan (and mega-overdue), with the exception of one book, a short story collection called 'Men and Cartoons', which I duly borrowed. The six-ish stories within are very varied, to say the least: from realist social observations, to satirical looks at near-historical periods of time, to melencholic observations about odd relationships, to straight up science fiction. There is a feint thread of comic books in common across a few of them. They were quick and fun to read. Without being able to point at why or where, I felt that they were very well written, and I've got a taste for something more substantial ("Gun, with Occasional Music" just dropped through my letter box).

One of the Debian Edu developers, Wolfgang Schweer, just created a screen cast documenting how to create a lot of new users in LDAP on Debian Edu Squeeze. The video is embedded here in quarter size, and also available from vimeo and download as a Ogg Theora file. Check it out below. <video controls="controls" height="184" id="gosa-mass-user-create-movie" preload="preload" width="256"> <source src="http://ftp.skolelinux.org/skolelinux/press/screencasts/2012-02-29-debian_edu_mass_create_user_accounts.ogv" type="video/ogg; codecs="theora, vorbis""> Download video as Ogg. </video>

Packt Publishing has offered phpMyAdmin to sponsor some coding contest with books. The contest is already running since Monday and we have first winner, but still, your chances are pretty high. So in case you are interested in having Mastering phpMyAdmin 3.4 for Effective MySQL Management, go ahead and check out the contest rules.

Filed under: English Phpmyadmin 0 comments Flattr this!

I recently got to rebuild an Android NDK with a fresh toolchain again, and hit an interesting problem. I actually had hit it before, but only this time I fully analyzed what s going on. [As a side note, if you build such a NDK, don't use mpfr 3.1.0, as there is a bug in the libtool it ships] Linking an application or a library pulls many things, that aren t part of the code being built. One of these many things is the libgcc static library. Part of libgcc consists in an implementation of the platform ABI. On Android systems, this means the ARM EABI. GCC, when compiling some instructions, will generate ABI calls. For example, integer divisions may call __aeabi_idiv. Consider the following minimized real world scenario:

$ echo "int foo(int a) return 42 % a; " > foo.c
$ arm-linux-androideabi-gcc -o libfoo.so -shared foo.c -mandroid

GCC will emit a call to __aeabi_idivmod for the % operation. With GCC 4.6.3, this function is in _divsi3.o under libgcc.a. That function itself calls __aeabi_idiv0, which lives in _dvmd_lnx.o under libgcc.a. When statically linking, ld will thus include foo.o, _divsi3.o and _dvmd_lnx.o, meaning it will include all functions from these object files. That is, foo, __divsi3, __aeabi_idiv, __aeabi_idivmod, __aeabi_idiv0 and __aeabi_ldiv0. And more than being included, these functions are exported, because symbol visibility in libgcc.a is default. So while we expect exporting foo from our library, we re actually exporting much more, including functions that just happened to be near the ones that our code (indirectly) uses. Now, let s say we want to build another library, using that foo function from libfoo:

$ cat > bar.c <<EOF
extern int foo(int a);
long long bar(long long a) return foo(a) % a;
EOF
$ arm-linux-androideabi-gcc -o libbar.so -shared bar.c -mandroid

(The code above has absolutely no meaning, it just triggers the same function calls as what I was getting in the actual real world case) When statically linking the above code, GCC will generate a call to __aeabi_ldivmod, which calls __aeabi_ldiv0, and many other things, directly or indirectly. When linking as above, nothing particularly nasty is going to happen. However, linking as above is actually wrong: the resulting library has an undefined reference to the foo symbol, and doesn t depend on libfoo. At runtime, if libfoo wasn t already loaded somehow, loading libbar would fail. The proper way to link is the following:

$ arm-linux-androideabi-gcc -o libbar.so -shared bar.c -mandroid -L. -lfoo

A feature of ELF static linking is that when it resolves undefined symbols, the linker will choose to use the first occurrence of a symbol it finds in the various objects and libraries given on its command line. So with the command line above, for each __aeabi_* symbol, it will first look in libfoo if there isn t one. And while __aeabi_ldivmod is not in libfoo, __aeabi_ldiv0 is (see above). So instead of including the code for __aeabi_ldiv0 from libgcc.a, it will call the copy from libfoo. This wouldn t be so much of a problem if __aeabi_ldiv0 wasn t a weak symbol. Enters faulty.lib. In the real world case, libfoo is loaded by the system dynamic linker, and libbar by faulty.lib. When resolving symbols for libbar, faulty.lib has to resolve libfoo symbols with the system linker, using dlsym(). On Android, dlsym() returns NULL for weak (defined) symbols, so faulty.lib can t resolve __aeabi_ldiv0. The real world case wasn t a problem with GCC 4.4.3 from the vanilla Android NDK because in that GCC version, __aeabi_ldivmod doesn t call __aeabi_ldiv0. This wouldn t happen if shared libraries wouldn t expose random platform ABI specific bits depending on what they use and depending on other symbols that happen to be in the same object files. A similar issue happened a little while ago on Debian powerpc because a shared library was exporting ABI specific bits. Even worse, the toolchain was assuming the symbols would come from libgcc.a and generated wrong relocations for these symbols. Update: Interestingly, the __aeabi_* symbols are hidden, in libgcc.a as provided on the Debian armel port.

What is it? Last month I started what I am calling the LUV Hardware Library. It s a briefcase full of computer parts that are free to LUV members which I plan to bring to all LUV meetings [1]. The issue is that there is a lot of hardware which has no great value to people and is often excess to requirements but which is still somewhat expensive or difficult to obtain and thus transferring it from the people who don t need it to people who do provides a significant benefit to the recipient but no real cost to the donor. Currently my briefcase has a range of different types of DIMM, some PCI cards, some assorted cables, a laptop SATA disk, and a bunch of other random things. Most of the stuff has been in my spare parts pile for a year or two, but some of it has been donated by other people. What we Need The next thing we need is more packaging, anti-static bags for RAM and PCI cards, sealable bags for screws, and some way of storing motherboard batteries. In terms of hardware that can be donated one thing that would be really useful is SATA disks. I m sure that there are lots of people who have upgraded the storage of their computer and kept the old drive with no real chance of using it. But there are lots of people who need such disks, for example I ve been giving away a bunch of P4 systems which lack disks and are not cabled for IDE disks a supply of SATA disks would make them a lot more usable. Also any other random electronic stuff is of interest, including non-Linux things such as mobile phones (but only if not network locked). If you have something that s big or heavy to donate then contact me via email first. Other Options Computerbank does great work in rebuilding old PCs and selling them cheaply to worthy people [2], but most of the spare hardware I get is below the minimum specs that they will accept. I m not planning to compete with Computerbank in any way, I just want to provide a useful service to LUV members who want to upgrade their PC for free. I encourage other people to do the same at other LUG meetings!

• [1] http://luv.asn.au/
• [2] http://www.computerbank.org.au/

Related posts:

1. Donating old Hardware On a recent visit to my local e-waste disposal place...
2. Giving Away Hardware For the last few years I have been actively seeking...
3. Shelf-life of Hardware Recently I ve been having some problems with hardware dying. Having...

I roll my eyes a little when I think that Unhappy Birthday is the document I have written that has been read by the most people. The page -- basically a website encouraging people to rat on their friends for copyright violation for singing Happy Birthday in public -- has received millions of page views and has generated tons of its own media (including a rather memorable interview of CBC's WireTap). At the bottom of the page I am listed, by name and email, as the "copyrighteous spokesman" for the initiative. And since the page has been online, I have received hate mail about it. Constantly. Since the email only goes to me, I thought it might be fun to share some of these publicly. All these messages are quoted verbatim but I have not included the senders' names. Be warned: the language is often salty. This email is years old now but it is probably still my favorite:

Atrocity and strife run rampant in this world. Babies are abandoned in dumpsters. Teachers molest students. Impoverished Indonesians make sneakers for pennies while the spoiled jackhole in the 30-second commercial makes millions for sinking a three-pointer and smirking at the camera. Forms of religion are interpreted as to compel people to strap explosives to their chest and board buses full of innocents. Boss Tweeds embezzle and get severance pay while John Q. Workingman gets put out on the street when the corporation goes belly up. Out of all these indignities and countless others I haven't the time to mention, why do you make it your personal crusade to assist in the flagrant persecution of family restaurants for partaking in the time-honored tradition of singing "Happy Birthday"? God forbid these foul brigands bend copyright law in order to bring a smile to somebody's face. Food for thought...without the accompanying song.

Many others strike a defiant, if less poetic, tone:

Good luck! There are millions of us who refuse to accept the ridiculous "copyright" on Happy Birthday. If Time Warner were an ethical company rather than a greedy megacorp they would do something truly special and release it into the public domain. There are some things in this world more important than money.

Quite a few people notice that my last name is Hill and suspect that I must be related to the Hill sisters who originally penned the song. I'm not, to my knowledge, although since Time Warner bought the rights, it's not clear it would matter:

I am writing to just let you know how disappointed I am that a large corporation and others (like the HILL family) are making $2 million plus for a song that was created over 100 years ago with noone knowing who created the lyrics! None of us at our place of employment could believe this and we certainly won't encourage people to send money to ASCAP. It is a shame that ASCAP license fees aren't used to pay more to up-and-coming artists who I'm sure need this money alot more than Time Warner. We all plan to sing Happy Birthday MORE now in public places and if anyone asks if it is copyrighted we will say "of course not". Maybe this way the song will not die out completely as more and more other "birthday" songs are being sung. It would also be nice if your website cited whose opinion is writing the piece and your obvious conflict of interest.

Or another:

Is it a coincidence that your last name is the same as the last name of the authors of the song "Happy Birthday?" You seem to have a personal monetary motive for your work with the "grassroots project" you call Unhappy Birthday, and if you do not, your concern is misplaced all the same. Whom do you imagine your campaign serves? And do you realize whom it harms? I do not question the illegality of performing the copyrighted song publicly. And you are correct that most of the public is not even aware that the song is under copyright. I think the harm done to Time Warner and its associates by such public performances is far outweighed by the joy created when the much-loved happy tune is shared. I urge you to ask yourself why you think the immortal Hill sisters wrote the song in the first place. It was not to put more money Time Warner's pocket. It was, I would argue, for the sake of the song itself and the happiness it brings when performed (publicly or otherwise). Please consider siding with the children and the artists; let the lawsuits alone.

Some people suspect the site may be satire, but include insults and and attacks just in case it isn't:

I'm trying to figure out if your Unhappy Birthday site is meant to be in jest. If so Rofl, and congrats on a hilarious site. If you're actually serious, then fuck you Nazi cunts and your corporate butt buddies. Thank you for your time.

Or these two alternatives (each were separate emails):

If this is a joke then it's rather funny. However if this website is serious then you're a fucking idiot. Get a life!!!! if it is a form of protest, then THANK YOU! if it is not, then screw you all!

One memorable piece of mail was from someone who knew of me from my activities in the free software and free culture communities and had a hard time reconciling my work there with the high protectionist website:

I was quiet surprised to see your name and email address at the bottom of the home page of the site Unhappy Birthday. The site claims that you are their spokesman. Is this correct? I do not understand... You have all this Open Source/ Free Software background and then this site that defends one of the most controversial copyright issues??? Do you really mean this? Do you want to help Time Warner?

I've also received probably half a dozen mails that offer some sort of support! For example, this person liked the website -- and even wanted to buy one of our t-shirts -- but objected to our logo:

I was going to buy one of your products from your Unhappy Birthday Shop at CafePress but there's a problem. I hate emblems that uses human skulls in them. Being a member of ASCAP I really do support your cause but I can't buy a product that I would never wear.

And many people are simply confused asking something like this one:

So I saw the unhappy birthday site and I'm just a little confused. Is this a joke or a serious thing?

I usually reply and explain that I have tried to ensure that the site describes the legal situation around Happy Birthday honestly and correctly. That said, the vast majority of messages I receive are unequivocal. Like this email that I received last week addressed to "you anti-free speech fascists":

         __
        /  \
            
            
            
 __  __      __
/  \/  \    /  \
                \
                  
                 /
                 \
                  /
\                /
                 
                 

Half an hour later, the author followed up with a English version of the same message, set to the tune of happy birthday. You might think that getting insulted and flipped off by confused people on the Internet might get me down. It doesn't! I made Unhappy Birthday because I thought that the fact that something as important to our culture as Happy Birthday could be owned was outrageous. Every piece of hate mail means that somebody else -- almost always somebody who isn't a "copyfighter" or a free culture geek -- is now upset about the current state of copyright too. Sure, Unhappy Birthday makes me a tiny bit sad about people's ability to recognize satire. But it makes me really happy about people's ability to get very annoyed at what they think is the outrageous control of our culture through copyright. When more people are as mad as the the people I've quoted above, we will be able to change copyright into something less outrageous to all of us.

At May First/People Link we have been using KVM for several years now and recently I have been running KVM instances on my local laptop. I'm pleased to see all the work that has gone into libvirt, which seems like a robust and full-featured suite of tools for managing many virtualization technologies, including KVM. However, we don't use it at May First/People Link for a number of reasons. The most pressing is that it runs all virtual guests as the same user, but also because it offers far more features than we need (such as graphical access to virtual server, which we don't need since none of our guest servers run X). On May First/People Link hosts, we are using a relatively simple set of bash scripts (accessible via git at git://lair.fifthhorseman.net/~dkg/kvm-manager). These scripts re-use many tools we are already familiar with to build and launch kvm guests. Each guests runs as a dedicated non-provileged user, with a console available using screen, and the kvm process is managed using runit. Since our admins are familiar with these tools already, the learning curve involved is much less steep. Despite the relative simplicity of kvm-manager, it was still more complicated and involved than I wanted on my laptop. Additionally, I wanted to fully understand every piece of the puzzle and separating out user privileges wasn't important to me. So - I wrote the following bash script to launch virtual servers. It assumes you are using logical volume manager. Some editing required if you want to re-use it.

#!/bin/bash
# manage a virtual server
# add /etc/udev/rules.d/92-kvm.rules with the following line (change "jamie" 
# to the group you are running as and vg_animal0 to the name of your volume 
# group):
# ACTION=="change", SUBSYSTEM=="block", ATTR dm/name =="vg_animal0-*_root", GROUP="jamie"
#
# install a new server by:
# * create logical volume with the name: servername_root
# * $0 servername start /usr/local/share/ISOs/default.iso
bridge=virbr0
user=jamie
base=/home/jamie
server="$1"
vg=vg_animal0
# modify server memory here
mem=768
command="$2"
[ -z "$command" ] && command=start
die ()  
  printf "$1\n"
  exit 1
 
cdarg=
if [ -n "$3" ]; then
  [ ! -f "$3" ] && die "Third argument should be path to cd iso. Can't find that path."
  cdarg="-cdrom $3"
fi
function start()  
  lvname="$ vg -$ server _root"
  # trigger udev to ensure we have proper ownership of the block device
  sudo udevadm trigger --subsystem-match=block --attr-match=dm/name="$lvname"
  lv="/dev/mapper/$lvname"
  [ ! -e "$lv" ] && die "Can't find $lv"
  sudo modprobe -v tun   die "Failed to modprobe tun module"
  # create network device if it doesn't already exist
  ip tuntap   grep "$tap"   sudo ip tuntap add dev "$tap" mode tap user "$user"   die "Failed to create device $tap"
  # bring up device if it's not already up
  ip link   grep " $tap "   sudo ip link set "$tap" up   die "Failed to set $tap to up"
  # add the device to the bridge so it get use the upstream network connections
  /sbin/brctl show   grep "$tap"   sudo brctl addif "$bridge" "$tap"   die "Failed to add tap to bridge"
  # launch kvm in a screen session
  screen -S "$server" kvm -drive "file=$lv,if=virtio,id=hda,format=raw" -m "$mem" -device "virtio-net-pci,vlan=1,id=net0,mac=$mac,bus=pci.0" -net "tap,ifname=$tap,script=no,downscript=no,vlan=1,name=hostnet0" $cdarg -nographic   die "Failed to start kvm" 
 
function cleanup()  
  read -p "Please shutdown the host first then hit any key to continue..."
  sudo brctl delif "$bridge" "$tap"
  sudo ip link set "$tap" down
  sudo ip tuntap del mode tap dev "$tap"
 
# generate reproducible mac address
mac="$(printf "02:%s" "$(printf "%s\0%s" "$(hostname)" "$ server "   sha256sum   sed 's/\(..\)/\1:/g'   cut -f1-5 -d:)" )"
tap="$ server 0"
case "$command" in
  start)
    start
    ;;
  cleanup)
    cleanup
    ;;
  *)
    die "Please pass start or cleanup as first argument"
esac

git-annex has special remotes that allow large files checked into git to be stored in arbitrary places, that are not proper git remotes. One key use of the special remotes is to store files in The Cloud. Until now the flagship special remote used Amazon S3, although a few other things like Archive.org, rsync.net, and Tahoe-Laffs can be made to work too. One of my goals is to add as many cloud storage options to git-annex as possible. Box.com came to my attention because they currently have a promotion that provides 50 gigabytes of free "lifetime" service. Which is a nice amount of cloud storage to have for free. I decided that I didn't want to spend more than 4 hours of my time to make git-annex use it though. (I probably have spent a week on the S3 support by contrast.) So, this is a case study in quickly adding support for one cloud storage provider to git-annex.

• First, I had to sign up to box.com. Their promotion requires an android phone be used to get the 50 gigabytres. This wasted about an hour getting my unused phone dusted off etc. This also includes time spent researching ways to access box.com's storage, including reading their API documentation. I found it has a WebDAV interface.
• Sadly, there is not yet a native WebDAV library for haskell. This is a shame, because it would make the implementation better. But, I'm confident someone will eventually write one. My experience with haskell libraries for other web APIs (S3, GitHub) is that it's an excellent language to write them in, the code tends to be very simple, concise and clear. But I can't do it in 4 hours. So for now, the workaround is to use a WebDAV mounting tool. I picked davfs2 as it was the first one I got to work with box.com's slightly broken WebDAV. 2 hours spent now.
• With box.com mounted, I was neary done; git-annex's directory special remote can use the mount point. But there was a catch: box.com only allows up to 100 mb large files. I spent 1 hour or so adding support to the directory special remote for chunking files into a user-specified size.
  This was a fairly complex problem -- the existing code had a ByteString that when accessed lazily read the whole large file (from disk or from gpg, depending), and just called writeFile on it.
  I needed to still consume it lazily to avoid reading the whole file into memory, but write out chunks. This gets a bit into haskell's ByteString internals, but they're very well suited to this kind of thing, and so after 15 minutes familiarizing myself with the data structures, it was actually fairly easy to write the code. patch
• I spent my last hour testing and tuning the box.com special remote. Using davfs2 as a quick fix caused some technical debt that I had to make up for. In particular, the chunked filename retrieval code had to make sure not to open every chunk at once, because that makes davfs2 try to cache them all, instead of streaming one at a time. patch
• Not counted toward my 4 hour limit is the ... er ... 4 hours I spent last night adding a progress bar to the directory special remote. A progress display while transferring the files makes using box.com as a special remote much nicer, but also makes using my phone's SD card as a special remote much nicer! This is why I'm a poor consultant -- when faced with something generic and generally useful like this, I have difficulty billing for it.

The end result is that there are detailed instructions for using box.com as a special remote. And it seems to work quite well now. I just set up my production box.com special remote. All content written to it is gpg encrypted, and various of my computers have access to it, each using their own gpg key to decrypt the files uploaded by the others. (git-annex's encryption feature makes this work really well!) So..
There is a DropBox API for haskell. But as I'm not a customer, the 2 gb free account hardly makes it worth my while to make git-annex use it. Would someone like to fund my time to add a dropbox special remote to git-annex?

I've recently acquired an UMTS USB stick, a ZTE MF190 (USB ID 19d2:0117/19d2:2000, after and before mode switch, the second ID can be seen while the stick offers its data partition for Windows driver installation). Naturally I wanted to use the stick with Debian. Normally that is no problem at all (as long as you've usb-modeswitch, modemmanager, ppp and a kernel configured with CONFIG_USB_SERIAL, the driver for your device, most likely CONFIG_USB_SERIAL_OPTION in this case, and CONFIG_PPP installed; in short a Debian standard kernel plus network-manager with its recommended packages does the trick). So why write about this at all? Simple: if you have KDE SC 4.7 installed (from experimental), then you need to recompile networkmanagement, the source package building the Plasma widget for controlling the NetworkManager under KDE, as there have been incompatible changes (see e.g KDE bug #282453 for one related bug), which cause a crash after PIN entry. To do that, just follow the few easy steps below:

1. Download the networkmanagement source package: dget -d http://cdn.debian.net/debian/pool/main/n/networkmanagement/networkmanagement_0.9.0-1.dsc (please note, that the version available in Debian might have changed, check the latest version on the PTS page).
2. Build the source package. (Make sure you build in an experimental chroot, otherwise you end up with the same binary.)
3. Install the binary package(s) you just built (most likely plasma-widget-networkmanagement and maybe the debug package).
4. Restart your KDE session.

I'm working on porting FreeGLUT for Android, and FreeGLUT is switching to CMake. I'm more familiar with the GNU Autotools myself, and I'm used to cross-compile with a simple:

./configure --host=arm-linux-androideabi

Can we do that with CMake? Well, it's not well-documented, but yes :) Let's see how to do that for Android (smartphones) and MinGW (.exe for windows).

---

The principle is:

• write a "toolchain" CMake script that defines the cross-compiler,
• mention you're using a "GNU" compiler (a.k.a. GCC) so CMake automatically looks for prefixed cross-compilers tools such as arm-linux-androideabi-cpp or arm-linux-androideabi-ld.
• pass the toolchain script to CMake using the predefined CMAKE_TOOLCHAIN_FILE variable.
• REMOVE all the CMake-generated files when you change anything, CMake does not rebuild its cache when the toolchain script or PATH is modified, this creates misleading errors. Hence, building in a subdirectory is crucial.

Here's a simple toolchain script:

SET(CMAKE_SYSTEM_NAME Linux)  # Tell CMake we're cross-compiling
include(CMakeForceCompiler)
# Prefix detection only works with compiler id "GNU"
# CMake will look for prefixed g++, cpp, ld, etc. automatically
CMAKE_FORCE_C_COMPILER(arm-linux-androideabi-gcc GNU)
SET(ANDROID TRUE)

Note: SET(ANDROID TRUE) is not mandatory for CMake, it's just used to detect an Android build in the particular case of FreeGLUT development. Here's how to invoke it:

PATH=/usr/src/ndk-standalone-9/bin:$PATH
cd /usr/src/freeglut-3.0.0/
mkdir cross-android/ && cd cross-android/
cmake \
  -D CMAKE_TOOLCHAIN_FILE=../android_toolchain.cmake \
  -D CMAKE_INSTALL_PREFIX=/freeglut \
  ..
make -j4
make install DESTDIR=$(pwd)

---

Now here's a slightly more complex toolchain for MinGW. The main issue with MinGW is that there are at least 4 possible prefixes depending on which version and which distro you're using. So I ask the user to specify it with GNU_HOST:

SET(CMAKE_SYSTEM_NAME Windows)
include(CMakeForceCompiler)
IF("$ GNU_HOST " STREQUAL "")
    SET(GNU_HOST i586-mingw32msvc)
ENDIF()
# Prefix detection only works with compiler id "GNU"
CMAKE_FORCE_C_COMPILER($ GNU_HOST -gcc GNU)
# CMake doesn't automatically look for prefixed 'windres', do it manually:
SET(CMAKE_RC_COMPILER $ GNU_HOST -windres)

I wanted to print an error when GNU_HOST is not specified, but the toolchain script is loaded multiple times, and the command-line variables are not always set (CMake is not super-clean in that regard). So I defined a default, that works. Sample invocation:

  apt-get install mingw-w64
  mkdir cross-woe/ && cd cross-woe/
  cmake \
    -D GNU_HOST=x86_64-w64-mingw32 \
    -D CMAKE_TOOLCHAIN_FILE=../mingw_cross_toolchain.cmake \
    -D CMAKE_INSTALL_PREFIX=/freeglut \
    ..
  make -j4
  make install DESTDIR=$(pwd)

---

I used this technique to cross-compile my projects, or other projects that use CMake. mingw-cross-env uses this technique (abeilt with explicit definition of all compiler tools) to provide pre-built windows libraries without altering the existing CMake scripts. Do you people have tips or a better technique to cross-compile with CMake?

This follows up on a previous post, and tries to summarize the corrections and suggestions I received. First, a reminder: yes, I'm really looking for a filesystem, not a storage system. Even if I only consider the music files use case, there are just too many things that want to access the files, and there's no way I'm going to port these things to use the storage system's API instead of plain old file access. Examples? The Rhythmbox player. The XMMS2 player. The mt-daapd/forked-daapd DAAP server. My script to backup or restore metadata (tags). Ex-Falso, to do mass edits on these tags. abcde, to add new files when I buy a new CD. Any kind of shell one-liners I currently do without thinking because find, xargs, cp, ln, and so on all operate on files. I understand that providing filesystem semantics on top of a storage system is hard, but that doesn't change my requirements, and saying otherwise is patronising. So, on to the meat of the matter. Apparently my understanding of Tahoe-LAFS was mostly correct. It seems that multiple introducers are on their way to become a reality, which would mean the one remaining central point would go away. Most of my other complaints seem to be on their way to be resolved, too, except that it's still targeted as a storage system, and the FUSE/sshfs layer on top still has its drawbacks (quoting from the wiki, Before uploading a file to a Tahoe filesystem, the whole file has to be available , mutable parts of a filesystem should only be accessed via a single sshfs mount [...] data loss may result for concurrently accessed files if this restriction is not followed and so on). From what I read, the position is that nobody publicly uses Tahoe's filesystem integration, therefore there's no need to fix its shortcomings; my understanding is that nobody uses it precisely because of its shortcomings. Ceph: apparently does repair/rebalance automatically contrary to what I thought. However, two persons told me that it's really expecting all nodes on the same LAN, and geographically distributed setups aren't really targeted. XtreemFS: I don't think I got any comments on my evaluation, so I'll assume it still stands. git-annex: storage system, not a filesystem. Yes, the files can be made available in the filesystem, but if I need to manually retrieve them before accessing them, this doesn't work. GlusterFS: I'd like to read more docs on how it works, but I haven't been able to find them. Apart from the installation manuals, the only documentation I found was a very short Concepts page, which described some of the concepts but didn't give me the big picture on how the who thing works. (I'm turning a blind eye on the Red Had advertisements and the requiremets that everything be installed on RH machines; the hardware requirements are also quite out of line with what I want to do.) HekaFS (aka CloudFS): I found even fewer docs about this one than about GlusterFS, and apparently HekaFS is on its way to being merged into GlusterFS anyway. PlasmaFS: I didn't know about this one previously, but the one email I got about it was mainly full of this won't work and this won't work either . I didn't feel inclined to read further docs after that. In summary, I guess the replies I got didn't cause me to change my mind too much. Tahoe-LAFS still seems to be, if not the best solution, then at least the least bad . Hopefully the drawbacks will be fixed soonish; the main sticking point (at least from my point of view) still seems to be the lack of focus on proper filesystem integration. I'll try setting it all up at some point; I may report further if I end up finding interesting things. Thanks to all who responded!

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.

* In case of you ve noticed, this blog has new URL: http://0x1f1f.wordpress.com, reading from Planet Debian doesn t harm your feed reader (if any readers left ). * On Debian front, I m mostly helping Debian-IN-Workers team to finish ttf->fonts naming transition and moving rest of packages to Git. Vasudev and Muneeb has done most of these work, well done! Rest of my time with Debian goes to usual updates of packages and in reading debian-devel during weekends. It is still fun, yeah. * And, illumian is born. * On personal side, life is great as usual. It looks that couple of dentist visit is coming soon. I also started jogging/running regularly since couple of months. In case you re interested, I m on dailymile too.

Recently, I have been working on a side project for Debian. The goal was to rebuild of the Debian archive (the distribution) with clang, a new C/C++ compiler. clang is now ready to build software for production (either for C, C++ or Objective-C). This compiler is providing many more warnings and interesting errors than the gcc suite while not carrying the same legacy as gcc.
This rebuild has several goals. The first one is to prove (or not) that clang is a viable alternative. Second, building a software with different compilers improves the overall quality of code by providing different checks and alerts. The result are detailed and explained here:
http://clang.debian.net/ Conclusions
When I had the idea to rebuild Debian with a new compiler, I was expecting many issues and bugs caused by clang but I have been surprised to notice that most of the issues are either difference in C standard supported, difference of interpretation or corner cases.
My personal opinion is that clang is now stable and good enough to rebuild most of the packages in the Debian archive, even if many of them will need minor tweaks to compile properly.
In the next few years, coupled with better static analysis tools, clang might replace gcc/g++ as the C/C++ compiler used by default in Linux and BSD distributions.
The clang developers are progressing very fast: 14.5% of the packages were failing with version 2.9 against 8.8% with version 3.0.
Several major steps in the clang adoptions have been made like chromium/chrome being built by default with clang, Xcode providing clang by default, FreeBSD working on the gcc -> clang switch, etc.
However, on the Debian point of view, one of the important step would be to make sure that clang manages all the Debian architecture/kernel (11 official, 6 unofficial)

I'm seeking advice on budgeting. Historically, I've been crap at managing money. Things have improved in recent years. My main tool is Martin Lewis' Money Saving Expert budget planner. It's simply a spreadsheet, into which you feed your income and outgoings. You can supply each line item as either a daily, monthly or annual income or expense. The sheet works out both a monthly and an annual total for each and the difference (be it positive or negative). The monthly summary is a useful benchmark against which you can compare your monthly bank statements, but it's not sufficient. Consider a one-off annual expense, such as a holiday payment. On the budget planner, the expense will be divided up into monthly chunks and deducted from your monthly income. However, the expense won't be on your bank statements, unless you've made a special arrangement to pay out a monthly sum to another account, such as savings account, for every annual expense. Therefore you can't just compare the planner's monthly summary against your bank statement summary and hope the two match. I really need to see what my monthly outgoings should total to, rather than what all my outgoings are, presented monthly, in order to meaningfully compare the two. How should I handle this? Should I do as I suggested there and total up my annual one-offs, divide by twelve and make a monthly payment for that sum to a savings account? I'd still want to be able to quickly look at my main statement and judge the overall figure as either 'good' or 'bad'. Perhaps I should feed my various statements into one place, perhaps a finance tool, in which case, which one? How do you manage your finances?