I had cause to try and get a core dump from a segfaulting process at work the other day, and I wanted to figure out if fiddling with /etc/security/limits.conf was going to do the trick (I didn't) or if I had to modify the initscript to include a ulimit -c unlimited call. Of course, on a modern system (>= 2.6.24), one would just take a look at /proc/PID/limits and get on with life, but unfortunately the system in question was running 2.6.18, so more fiddling around was required. I'd found something once before that told me how to do it with GDB, but all I could find this time around was a rather over-complicated Knol article, which made a bunch of assumptions (well mainly that the binary in question wasn't stripped). So with some help from the Knol article, I muddled through it. Disclaimer: I don't profess to be an expert on system internals like this, so if this eats your first-born, don't come crying to me. Firstly, you need to know that it's the getrlimit(2) system call that you want to be using, and then you need to figure out the number for the resource limit you want to retrieve. The man page for getrlimit(), tells you it's defined in /usr/include/sys/resource.h, but I've found that the actual useful bits end up being in /usr/include/bits/resource.h I wanted the resource limit for the maximum core dump size, which is RLIMIT_CORE and has a value of 4. Next, you need to know that the getrlimit() system call takes an integer and a pointer to an rlimit structure as arguments. We've just figured out the value for the integer, but we're also going to need to pass a pointer as the second parameter. A pointer to enough memory to hold an rlimit structure. Fortunately, the rlimit structure is pretty simple:

struct rlimit  
    rlim_t rlim_cur;  /* Soft limit */
    rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
 ;

After a bit of grepping around in /usr/include, I determined that an rlim_t is essentially an unsigned long int, so we need to allocate a pointer big enough to hold two of them. Note that if we had an unstripped binary, we could have saved a lot of faffing around by just going

print sizeof(struct rlimit)

in GDB (assuming that the binary has the getrlimit symbol in it) The sure-fire way of figuring out how much memory we need for this pointer is to go

print sizeof(unsigned long int)

in GDB, and then double that (since we want two of them). On my system an unsigned long int is four bytes, so I'm going to want to allocate enough memory for 8 bytes. Now it's time to attach GDB to the offending process and see what the resource limit currently is. (gdb -p PID)

(gdb) print malloc(8)
$1 = 152186904
(gdb) print getrlimit(4, $1)
$2 = 0
(gdb) x/2xw $1
0x9123018:	0x00000000	0x7fffffff
(gdb) quit

So in this particular case, we've retrieved the soft and hard limits of the RLIMIT_CORE resource limit, and you can see that the soft limit is zero, and the hard limit is unlimited. Note that the getrlimit() function returns an integer as its return code, which is what the $2 = 0 is above. Now it's just a case of altering the the resource limits via the preferred mechanism, restarting the process and then repeating this GDB examination of the process to check they were changed successfully. Circumstances where this can all fall down would appear to be ones where the getrlimit symbol isn't present in the binary, or the binary is compiled as a position-independent executable. I'd think that in the latter case, the system is probably modern enough to be running a kernel that supports directly examining the resource limits via the /proc filesystem.

So I got my hands on that new machine, somewhere, somehow, and I had to make myself comfortable on it. The biggest difference in that machine and the ones I used before is the RAID controller, an Adaptec 5405, instead of the 3ware ones I used to have before. That means getting used to new tools, messages and all these things which I ll try to document here.Step 1: does vendor deliver?Well, yes, mostly. There is (mainline) kernel support for the controller, Squeeze s kernel will boot up just fine and I just throw my junk into /dev/sda and it will handle the whole raidy thingy itself. But what is when I want to check the health of the disks, to add a spare or modify the caching? Ask the mighty vendor and it will answer Yes, you can! .So I downloaded that asm_debian_x86_x64_v6_50_18570.tgz, unpacked and faced two debs, one i368 and one amd64. Yes, you could have saved half of the bandwidth if someone would have asked for the arch before, but who cares for some additional 60MiB today? So let s see what it does. Oh no, wait, there is a README ASM_IUG_for_Debian_and_Ubuntu.txt:

1. Make sure to be in root level access.
2. Install the ASM storman .deb package. For example, if the package is storman_6.50-18570_i386.deb,
   then install it using the following command dpkg -i storman_6.50-18570_i386.deb
3. Adaptec Storage Manager will get installed at /usr/StorMan
4. Add the line /usr/StorMan to /etc/ld.so.conf. Then run "ldconfig". This is needed for the arcconf
   utility to find the path of the libstdc++.so.5 library

Well, 1 is obvious, so is 2.
For 3: hum, /usr/StorMan? Ever heard of FHS? Don t think so.
For 4: WTF?! I prefer to get libstdc++5 from my local Debian mirror instead.But at least they provide a .deb, right? Uhm, no, it s an RPM converted via alien :( And don t dare to look at preinst, postinst and postrm (it extracts an own copy of Sun JRE 1.6u16, chmods around wildly on install and does rm -rf something on uninstall, did I see that some days ago on the webs?). Let s get rid of that package as soon as possible, I decided, and just keep arcconf (which will be described later), esp because StorMan itself seems to include some call-home functionality which I d like not to have:

cp -a /usr/StorMan/arcconf /usr/local/sbin/
apt-get remove --purge storman

Step 2: does community deliver?You can, by the way, get (better) packages at http://hwraid.le-vert.net/wiki/DebianPackages from Adam C cile (Le_Vert). I didn t test those much, but I currently use the arcconf package from there, which seems to be exactly what I need: proper dependencies and just the arcconf binary, no Java sh*t.Step 3: monitor the controllerAs this post is about monitoring, not ranting, let s continue. As mentioned before, I only have arcconf installed, which is just a cli to do stuff with the controller. If I understood the docs right, the actual StorMan is able to send notification mails when a disk dies or the controller gets eaten by aliens, but as I don t have StorMan, I have to do things myself.Adam has a aacraid-status package in his repository, which includes some minimalistic shell-daemon to monitor the output of arcconf. It didn t perfectly fit my needs (and had some hickups with my disks which refuse to report a vendor, whyever), so I decided to write something myself (slightly based on what Adam has done in aacraid-status, though).The result is on GitHub: https://github.com/evgeni/aacraidAs you can see the code contains (at the time of writing) exactly ZERO comments and there is no README either, but it s actually quite usable already.

• aacraid.py is the main magic inspired by Adam s aacraid-status, basically just parsing arcconf output
• aacraid-status prints all useful info about all controllers, arrays and disks (the output is pretty much like Adam s)
• aacraidd is a small daemon which will monitor all controllers every (per default) 5 minutes and mail you in case of status-change

I am now running aacraidd and get happy mails when something breaks :) [running = running from /etc/rc.local, no init script yet :)]Step 4: monitor the disks via smartmontoolsThere is one little problem I have with arcconf: it s closed source and does magic to the controller.With the old 3ware controller I was able to monitor the disks with smartmontools/smartd using something like this:

/dev/twa0 -d 3ware,0 -a -s L/../../2/01 -m root
/dev/twa0 -d 3ware,1 -a -s L/../../2/03

This is possible with Adaptect controllers too (not through /dev/twaX obviously). You have to have the sg module loaded, which will result in /dev/sg[012] on my machine, with sg0 being the controller itself and sg1/sg2 the both disks attached to it. Having sg loaded, one can now use smartd with:

/dev/sg1 -d sat -a -s L/../../7/01 -m root
/dev/sg2 -d sat -a -s L/../../7/02 -m root

(-d sat is the important option here!)Thanks to Thomas Krenn Wiki: Smartmontools mit Adaptec RAID Controller for the basic info and ostlogd.spenneberg.net: Adaptec-Raid-Controller S.M.A.R.T.-Healthstatus monitoren for the pointer to the sg module!Step 5: relaxYupp, 4 steps are enough, go relax until the next disk dies (you will be doing something REALLY important that moment according to Murphy).

0 comment(s) this blog is flattr enabled

Come to the Portland Debian SOCIAL SCENE. There will be beer and flannel for all. Join us as we hack on software to promote the supremity of Cascadia! Note: neither beer nor flannel guaranteed

John Atherton sent me a link to cyberunions discussing open-source and worker co-ops. In general, it s a very good show and worth a listen by anyone from the union movement, in my opinion. It s available in Ogg as well as MP3, which I think is also a plus point. There were a couple of points where I was ranting at the radio, though The first was the choice to try Skype alternatives. Leaving aside the danger of playing the alternatives game, I can understand why they chose that (the change of corporate control to Microsoft has been in the headlines recently and the phones affect them but not their listeners or readers), but open internet phones are a bit fiddly because they try to move quite a lot of data (audio) in real-time and a lot of domestic network devices don t behave correctly with the protocols that they use to do it. I agree with their conclusion that the problem is probably networking, but I wonder why they didn t log in to their routers, look at any debugging output and try to find the setting to change? Or try switching on debugging in the software and see what s wrong, or send it to someone who can help? Instead, it seemed like Linphone and Ekiga got blamed for not doing Skype-style router-busting without asking. They don t mention whether they tried switching on the STUN option mentioned in the Linphone FAQ and I don t see a email on linphone-users asking for support but I don t read every mail on that list. Am I being unfair, expecting them to seek support? Maybe but I m not sure. If you got the software from a store, what would you do? Would you throw it away and tell people that the stupid thing doesn t work? Moreover, would you use your podcast to say it doesn t work because users need to be clever enough for that obscure tool? That s a great way to scare people off unnecessarily. Wouldn t you usually think you might be overlooking some detail and ask for support, from its maker or the place where you got it? I think you d ask. I d probably ask, even though I m available for hire to fix FOSS problems and it s not the proudest feeling when I have a script-reading call-centre worker solve my mistake. Of course, with most from-store software, you ve paid an artificially-inflated box price, but the bigger cost is your time and that s the same for downloaded free and open source software, so why give it less of a chance to work? I also think they had easier options, like switching more of their website over to free and open source software, like getting rid of the rubbish comment system which doesn t work if you don t let it run javascript on your browser. I ve had a bit of discussion with them since the show and it seems my first suggestion may no longer work (typical!), so we ll see how that goes. Back to the show: the next segment did a good job of linking FOSS to the co-operative movement. I really think they should call it Free and Open Source Software and not just open source because I feel the freedom should be important to the labour movement. Also, calling the whole thing open source seems like calling all of the political left Revolutionary Socialism : inaccurate at best. I don t often express this objection these days (I ve bigger targets to work on), but it s important when trying to inform new audiences, else they only see part of our rainbow, a less radical part. Pretty interesting to suggest Orbea bikes as Mondragon s most famous brand. I d pick Eroski or Caja Laboral. What about you? Then it moved on to a pretty good description of UK co-ops, mentioning co-ops that I m a member of (the Co-operative Group) or buy from (John Lewis and Suma). I was surprised that it seemed to stop short and didn t mention any of the co-ops that work with free software, or with any software in fact. Of course, I d love software.coop to be mentioned, but there are other interesting and very different ones like BristolWireless.net and OSAlliance.com. Globally, many of the worker tech co-ops are linked through the tech-coop mailing list. This was the second part where I was shouting at the speakers. After all, Debian is a great voluntary project making a fantastic GNU/Linux distribution, but it is not a worker co-op by a long way and I suspect some of my fellow developers would be horrified to hear that suggested. Why not mention some actual tech worker co-ops? Finally, before the listener feedback, suggestions of tools which union activists could use. There was some minor confusion about exactly which version or name was really FOSS and a surprising claim about openoffice into LibreOffice (I thought Oracle were still screwing that up with Apache s help but I may have missed some news), but it was a good list of door-opening suggestions. I hope some activists will take them up. It seems there s an earlier show about open social networks, which is a topic I ll look at after I finish my series of posts about mailing lists. So, please let me know if you have comments on this show, that show, open social networks or mailing lists which you think I might find interesting, or if there s anything above you d like me to expand upon (or correct often, correct ).

I've been getting strange failures on some architectures for xdotool. xdotool is a library and a command-line tool to allow you to inject events into an existing X11 session. I'm trying to understand (or even to reproduce) these errors so i can fix them. The upstream project ships an extensive test suite; this test suite is failing on three architectures: ia64, armel, and mipsel; it passes fine on the other architectures (the hurd-i386 failure is unrelated, and i know how to fix it). The suite is failing on some "typing" tests -- some symbols "typed" are getting dropped on the failing architectures -- but it is not failing in a repeatable fashion. You can see two attempted armel builds failing with different outputs: The first failure shows [ and occasionally < failing under a us,se keymap (that is, after the test-suite's invocation of setxkbmap -option grp:switch,grp:shifts_toggle us,se):

Running test_typing.rb
Setting up keymap on new server as us
Loaded suite test_typing
Started
...........F..
Finished in 19.554214 seconds.
  1) Failure:
test_us_se_symbol_typing(XdotoolTypingTests)
    [test_typing.rb:58:in  _test_typing'
     test_typing.rb:78:in  test_us_se_symbol_typing']:
<" 12345678990-=~ !@\#$%^&*()_+[] ;:\",./<>?:\",./<>?"> expected but was
<" 12345678990-=~ !@\#$%^&*()_+] ;:\",./>?:\",./<>?">.
14 tests, 14 assertions, 1 failures, 0 errors

The second failure, on the same buildd, a day later, shows no failures under us,se, but several failures under other keymaps:

Running test_typing.rb
Setting up keymap on new server as us
Loaded suite test_typing
Started
..F.F.F.......
Finished in 16.784192 seconds.
  1) Failure:
test_de_symbol_typing(XdotoolTypingTests)
    [test_typing.rb:58:in  _test_typing'
     test_typing.rb:118:in  test_de_symbol_typing']:
<" 12345678990-=~ !@\#$%^&*()_+[] ;:\",./<>?:\",./<>?"> expected but was
<" 12345678990-=~ !@\#$%^&*()_+] ;:\",./<>?:\",./<>?">.
  2) Failure:
test_se_symbol_typing(XdotoolTypingTests)
    [test_typing.rb:58:in  _test_typing'
     test_typing.rb:108:in  test_se_symbol_typing']:
<" 12345678990-=~ !@\#$%^&*()_+[] ;:\",./<>?:\",./<>?"> expected but was
<" 12345678990-=~ !@\#$%^&*()_+[] ;:\",./<>?:\",./<>?">.
  3) Failure:
test_se_us_symbol_typing(XdotoolTypingTests)
    [test_typing.rb:58:in  _test_typing'
     test_typing.rb:88:in  test_se_us_symbol_typing']:
<" 12345678990-=~ !@\#$%^&*()_+[] ;:\",./<>?:\",./<>?"> expected but was
<" 12345678990-=~ !@\#$%^&*()_+ ;:\",./>?:\",./<>?">.
14 tests, 14 assertions, 3 failures, 0 errors

I've tried to reproduce on a cowbuilder instance on my own armel machine; I could not reproduce the problem -- the test suites pass for me. I've asked for help on the various buildd lists, and from upstream; no one resolutions have been proposed yet. I'd be grateful for any suggestions or hints of things i might want to look for. It would be a win if i could just reproduce the errors. Of course, one approach would be to disable the test suite as part of the build process, but it has already helped catch a number of other issues with the upstream source. It would be a shame to lose those benefits. Any thoughts?

This is a kernel module I cooked in a couple of days. The idea is to expose a v4l device that gets its data from user space.

I had 2 use cases in mind:
1) Educational purpose for myself (I'm really a kernel noob).
2) Streaming movies over skype, google talk, ... etc.

The idea could be good or completely rubbish but hey ? Learning can only be done with stupid ideas!

The code is highly unstable. It shouldn't oops the kernel but I'm not responsible. I've been developing and testing it inside qemu.

Clone it from the git repository via:

Here are a few missing bits off the top of my head:

* I'm not following the kernel coding style yet ;-)
* I'm sure my locking, unlocking and concurrency handling is flawed.
* The code is a bit fragile.
* It'd be nice to implement mmap support for the character device. This should eliminate data copies.
* Perhaps expose the character device all the time and generate "fake" frames when streaming starts ? Problem now is one has to be very fast in feeding data to the module otherwise select() on the v4l device will timeout.
* Many more...

If someone finds this idea useful, please drop me a line.
Comments, use cases, ideas and tips are really welcomed!

If I see a lot of interest, I might try to push it to the kernel tree one day ;-)

Update: Seems vloopback already exists and renders my code useless. I might still do something with it as my idea seems a bit simpler but whatever.

Update 2: There's also v4l2loopback and its fork. read more

I uploaded a new upstream version of the ttf-oldstandard font. The new version is a real 2.2 while the former was numbered 2.02 by upstream but got accidentally numbered 2.2 by us, packagers.. The occasion was good and I renamed the source package to follow the "yes-yes-yes-soon-to-be-published" fonts packaging policy for naming. The new package is "fonts-oldstandard". A new upstream version of samba was released and I packaged it just after the last 3.5.8 package entered testing. Samba is now 3.5.9 in unstable. I should work on backporting (for backport.debian.org) what's entered in testing, by the way. I sent l10n NMU proposals for unattended-upgrades, memtest86+, cacti. I also NMUed memtest86 (still in DELAYED).

After my post about the vector screenshots two days ago stirred quite some interest, I was hard-pressed to push the code out in proper form. So here you are: You can get release tarballs which can be installed with the usual configure && make && sudo make install. You can also get the code via git from the gitorious project page. Freshmeat and ohloh registration will follow soon. I don t think though that I need more infrastructure, e.g. a mailing list would be overkill, unless the project becomes much larger than I expect at the moment. After all, I do prefer small projects.
Over the version that you saw in the screencast two days ago (which almost broke my server, as I included the video via the <video> tag, and every reader of my blog entry automatically started downloading the 2MB file), I have added support for SVG, PostScript and (hear hear) PNG, made the button much more visible and improved minor usability things. Since Saturday, the work was covered in ycombinator s hacker news and on golem.de. If the interest stays high and I get positive feedback from users of the above code, I ll also upload it to Debian. I would really like to have this as a stand-alone program that can take screenshots of any running gtk-3 application, but I m not sure if this is possible in a clean fashion. Can I somehow hook into a running glib application and call object methods there, maybe similar to how gdb would do it? Alternatively, I could install the module system wide, so that it is loaded into every application, and then somehow triggered (e.g. using a signalling mechanism based on X window s property). Ideas and patches welcome!

The upstream and debian packages for psmisc version 22.14 were released tonight. This version has a lot of bugfixes. I ve also taken some time to clean up some of the minor compile warnings I used to get which were mainly variables set but not used. Two bugs that I ll concentrate on getting fixed for the next version are all about the command line. The first is that the fuser -s flag changes the return code for items found. It should be consistent so it doesnt matter if fuser displays values or not, 0 means found something and 1 means didn t find it. I can see why in the code it might be different, because the code follows different paths with the s option, but not exactly where the problem is. The second bug is the -M flag for fuser only works if it is before the mount points so -M -m /foo works but -m /foo -M does not. Unlike the -s problem, I can see where it is failing. Currently fuser scans the options one by one. If it finds a -m option, it checks at that point if the -M option is set. The solution is to store all potential targets and only after exhausting the entire command line do we add the potential targets to our real targets. It means scanning the command line, or a subset of it, twice but the performance penalty is tiny. Finally, I released there was a rather neat Makefile command make distcheck . This target makes a tar.g archive, extracts it, builds then cleans. It is a very good program for trapping things like a file exists in your local directory but is not included in the tar.gz (lists.h was missing until I ran this). For some make distcheck is something they re known for years, but if you have an autotools package you develop, have a look at it. With all the talk about testing and test driven releases, I was going to put some test cases in. The problem is there doesn t seem to be an easy way to do testing. I might have to just hack up some scripts but surely there is a better way. That would trap, for example that fuser -s returns 1 but fuser returns 0. I looked at check, but it doesn t work for single-file programs like psmisc is mainly made of.

This is a frequently asked question: What package manager shall I use? . And my answer is the one that suits your needs . In my case, I even use different package managers depending on what I m trying to do. APT vs dpkg, which one is the package manager? In the Debian world, we re usually thinking of APT-based software when we re referring to a package manager . But in truth, the real package manager is dpkg. It s the low-level tool that takes a .deb file and extracts its content on the disk, or that takes the name of a package to remove the associated files, etc. APT is better known because it s the part of the packaging infrastructure that matters to the user. APT makes collection of software available to the user and does the dirty work of downloading all the required packages and installing them by calling dpkg in the correct order to respect the dependencies. But APT is not a simple program, it s a library and several different APT frontends have been developed on top of that library. The most widely known is apt-get since it s the oldest one, and it s provided by APT itself. Graphical APT front-ends update-manager is a simple frontend useful to install security updates and other trivial daily upgrades (if you re using testing or sid). It s the one that you get when you click in the desktop notification that tells you that updates are available. In cases, where the upgrade is too complicated for update-manager, it will suggest to run synaptic which is full featured package manager. You can browse the list on installed/available packages in numerous ways, you can mark packages for installation/upgrade/removal/purge and then run in one go all the recorded actions. software-center aims to be an easy to use application installer, it will hide most of the packaging details and will only present installed/available applications (as defined by a .desktop file). It s very user friendly and has been developed by Ubuntu. Of the graphical front-ends, I use mainly synaptic and only when I m reviewing what I have installed to trim the system down. Console-based GUI APT front-ends In this category, I ll cite only aptitude. Run without parameter, it will start a powerful console-based GUI. Much like synaptic, you can have multiple views of the installed/available packages and mark packages for installation/upgrade/removal/purge before executing everything at once. Command-line based package managers and APT front-ends This is where the well known apt-get fits, but there are several other alternatives: aptitude, cupt, wajig. Wajig and cupt are special cases as they don t use libapt: the former wraps several tools including apt-get, and the latter is a (partial) APT reimplementation (versions 1.x were in Perl, 2.x are now is C++). You re welcome to try them out and find out which one you prefer, but I have never felt the need to use something else than apt-get and aptitude. apt-get or aptitude? First I want to make it clear that you can use both and mix them without problems. It used to be annoying when apt-get did not track which packages were automatically installed while aptitude did, but now that both packages share this list, there s no reason to avoid switching back and forth. I would recommend apt-get for the big upgrades (i.e. dist-upgrade from one stable to the next) because it will always find quickly a relatively good solution while aptitude can find several convoluted solutions (or none) and it s difficult to decide which one should be used. On the opposite for regular upgrades in unstable (or testing), I would recommend aptitude safe-upgrade . It does a better job than apt-get at keeping on hold packages which are temporarily broken due to some not yet finished changes while still installing new packages when required. With aptitude it s also possible to tweak dynamically the suggested operations while apt-get doesn t allow this. And aptitude s command line is probably more consistent: with apt-get you have to switch between apt-get and apt-cache depending on the operation that you want to do, aptitude on the other hand does everything by itself. Take some time to read their respective documentation and to try them.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

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

Well, every once in a while we re forced to do something that isn t particularly interesting or pleasant. Last week it happened again: I had to import a few pretty big PSTs (most 2Gig, one 10Gig, with about 100.000 emails) into our dovecot IMAP. Doing this with Outlook itself was out of the question: it took way too long, even on the local network (many hours for a 1G file) and was prone to hanging and crashes, which were obviously a pain to debug and start over.
Thunderbird was unfortunately not much better, since at least in our tests it didn t import the read status of the emails (they were all marked as unread) and also wasn t particularly good at handling folders with strange names, containing . , / or some more obscure characters. We had used it before for smaller files, where manually dealing with the problems was acceptable, but this time it required something a bit more elaborate, if we were to keep our sanity. Enter libpst. It includes the handy readpst utility which dumps all emails in usable formats in a directory tree, one directory per folder. Unfortunately the Debian version is somewhat outdated and doesn t support the newer Outlook formats, so I did some packaging and even a little bit of patching. It seems Thunderbird also uses this library, which would explain why it didn t handle the Read-Status (haven t confirmed this though; just read it somewhere). The last step was this not-so-little script, which uses the dumped directories from readpst and imports them in IMAP. It would have probably been a bit more elegant to use libpst directly, but I unfortunately didn t have the time to mess around with that. I did have to mess around a lot with encodings though, ergo the unholy chaos with unicode()s and str.encode()s thrown around like rice at a wedding (I could never really wrap my head around charset problems; the subject boggles my mind to this very day). Another useful automation is using the mappings file, which looks something like to automatically import in the right destinations, in case you have a standardized structure.

Sometimes there s nothing quite so heartwarming as hearing a 4-year-old that doesn t think anybody is listening. When Jacob is all alone in his room, sometimes he will sing. Maybe it s a song he knows, or fragments of a song he knows. Or maybe it s something he just made up on the fly. It might be about trains, cats, letters, or who knows what. Maybe it will crack him up and he ll keep singing and then laugh. Or maybe it will stop in 30 seconds and he ll go on to something else. Brief and out of tune though it may be, it is still one of the most beautiful sounds I know and I love to hear it. Jacob loves to have other people sing, too. Sometimes I will make up songs while we drive: We are driving, we are driving, we are driving down the road; we are driving down the old country road and we re making some dust, yes a lot of dust Or Jacob likes me to sing the songs in the Winnie the Pooh book he has (the original, pre-Disney version, which has the words for the songs but not a tune, so I make up a little bit different one each time). Very occasionally he will sing with me, but if he does, he doesn t want anybody to comment about it. I sing with the Kansas Mennonite Men s Chorus. We re a group of about 300 singers (all men, though not all Kansan and not all Mennonite) that sing for charity. We ve raised over $600,000 for charity so far. I still remember the first time I went to a KMMC practice 3 years ago. It was my first year singing, and the first practice of the season. We started singing the first song, and wow what a powerful moment. Even at its imperfect first practice state, hearing 300 people sing quietly is a powerful sound and when they get to the top of their lungs, it s indescribable. No CD can ever quite do that justice. Jacob and Oliver come to KMMC concerts sometimes, but this year they took a special interest. Oliver pointed to, hm, perhaps 300 men and said dad for each one. (He was quite far away and probably couldn t pick me out specifically.) Jacob, for the first time, sat quietly engrossed in the concert until we got to Dry Bones (a song involving surprise and lots of homemade instruments) which made him laugh out loud. Then he would hide under his seat from the applause. Last week, KMMC went on tour. This was my first choir tour, and Terah came along while the boys spent time with grandparents in Kansas. We sang in Bloomington, IL, and then in Goshen, IN at the fairly new Sauder Concert Hall. That hall is a few years old, and has been reviewed as once of the best concert halls in the world acoustically. It seats 1100 people and was perfect for this. The 85 or so singers from KMMC that went on tour joined the Indiana and Ohio Men s Choruses to make a combined group of about 200 singers. And what an experience that was. I learned later this was the first event to completely pack Sauder Concert Hall. We ended the concert singing the Mennonite Anthem a souped-up version of the doxology. (You can see a video of a different group singing it to get an idea of what it was). This is often joked about as being part of Mennonite DNA. You can gather a random group of Mennonites and ask to hear 606 (its number in, well, an old hymnbook that we don t use anymore) and you can probably get a fairly well-sounding rendition, from memory, a cappella, complete with 4-part harmony, at the drop of the hat. Mennonite youth have been known to sing it in train stations, airports, soccer stadiums, and with kazoos. At Goshen, we had 200 men on stage, plus a brass band, plus 1100 people in the audience facing us. They were, of course, invited to sing along. (That s one of the rules of 606: you can t exclude anybody because even if you tried, they d still sing, because how can you resist?) So I was up there on stage, singing a song I love, and hearing the 1100 people in the audience sing it to me. I could glance out over the front rows and saw the smiles on so many faces as they sang, and what a moving moment that was. The excitement and thrill of it all hit me so much that I could barely finish the song. The numbers aren t all in yet, but I m guessing that we raised over $15,000 for charity last weekend (the choir members paid their own expenses in advance, so 100% of the money raised goes to international relief efforts.) A 4-year-old singing alone in his room is really heartwarming. I have to say that 1300 people singing a song that touches each one of them is a pretty close second.

Half a year ago, I experimented with gtk+ and cairo to extract a PDF screenshot out of a progam, i.e. a screenshot of the window that is not a table of colored dots as a regular PNG file would be, but rather a vector graphic that scales perfectly and has selectable text. The main use that I see is documentation: A scalable screenshots looks much better in print, and even in an online-PDF-file, having the full-text-search also find the text in the images is useful. My experiments back then were successful in a proof-of-concept way, but they were very ugly hacks. With the new version 3 of gtk+, though, things become much easier, as only one cairo context is used, instead of each widget creating its own context to draw on. By now, the first gtk-3 applications have reached Debian unstable, so I thought it would be time to re-do the experiment. And the result is very pleasing: The pdf screenshot program comes as a gtk module that you can load by setting an environment variable before launching a gtk-3 program. The application will run as usual, but there is an additional PDF screenshot button. If you click it, you get a Save File dialog (with a nice, live-updated preview of the screenshot, as an additional gimmick) that lets you save a PDF file. Its as easy as that. You can check out the resulting PDF file of gucharmap and a screencast of me creating that file, including copy n pasting from the resulting document. PS: I would offer the video as well on YouTube, but it seems it does not accept Ogg Theora videos. I hope all of you can make use of the above links. Update: By popular demand, I also created a SVG version. It even looks better because the embedded pixmaps have a higher resolution probably gtk is confused by the resolution of the PDF cairo surface. The code is almost trivially the same. I guess I could add other formats (PNG, PS) as well. Now I just have to find out how to tame GtkFileChooser to offer this feature better.

Half a year ago, I experimented with gtk+ and cairo to extract a PDF screenshot out of a progam, i.e. a screenshot of the window that is not a table of colored dots as a regular PNG file would be, but rather a vector graphic that scales perfectly and has selectable text. The main use that I see is documentation: A scalable screenshots looks much better in print, and even in an online-PDF-file, having the full-text-search also find the text in the images is useful. My experiments back then were successful in a proof-of-concept way, but they were very ugly hacks. With the new version 3 of gtk+, though, things become much easier, as only one cairo context is used, instead of each widget creating its own context to draw on. By now, the first gtk-3 applications have reached Debian unstable, so I thought it would be time to re-do the experiment. And the result is very pleasing: The pdf screenshot program comes as a gtk module that you can load by setting an environment variable before launching a gtk-3 program. The application will run as usual, but there is an additional PDF screenshot button. If you click it, you get a Save File dialog (with a nice, live-updated preview of the screenshot, as an additional gimmick) that lets you save a PDF file. Its as easy as that. You can check out the resulting PDF file of gucharmap and a screencast of me creating that file, including copy n pasting from the resulting document. PS: I would offer the video as well on YouTube, but it seems it does not accept Ogg Theora videos. I hope all of you can make use of the above links.

My internship is now finished, this means that I will be able to work on my GSoC project a lot more than the previous weeks. I hope to make some good progress in the next days.

This last 2 weeks, I was still studying how Jigsaw works. Even if there is no progress on the Jigsaw packaging I have done some packages that will help later.

I ve spend a lot of time trying to package JT Harness and JTReg.
I ve successfully built JT Harness using CDBS but I ve finally rewritten the package using only debhelper and javahelper. Javahelper was really useful to build JAR files, move them to the right directory, put the Javadoc in the right place as well as the examples. The Debian directory of JT Harness can be found on the Java team SVN.

svn co svn+ssh://$ SVN_USER @svn.debian.org/svn/pkg-java/trunk/libjtharness-java

The source package of jtharness build 2 binary packages: libjtharness-java and libjtharness-java-doc. You can see that by looking at the control file in the debian directory. There are some interesting files in this package, let s take a look at them.

First of all, some of the source files needed to be patched for the package to build. So to accomplish this, there is a couple of patches in debian/patches :

• dependencies.diff, used to locate JAR files in /usr/share/java , and,
• rxtx.diff, done by Tom Marble used to change some imports from javax.comm to gnu.io .

To generate these patches, I ve used the edit-patch command which is a really awesome tool. This command uses a temporary shell where we can edit files we want to patch. When the job is done, CTRL + D terminates the temporary shell and the patch is generated.

There are 4 interesting files which are used to build the binary packages and put the files in the right directories. These files are:

• rules,
• libjtharness-java-doc.install,
• libjtharness-java.jlibs, and,
• libjtharness-java-doc.javadoc.

Of course rules is the most important one. This file tells us how packages are built. A good thing is that rules is quite simple in the jtharness case.

#!/usr/bin/make -f
JAVA_HOME = /usr/lib/jvm/default-java

override_dh_auto_build:
ant -f build/build.xml

%:
dh $@ --with javahelper

We just tell where Java is and to use javahelper ( with javahelper). Overriding dh_auto_build is interesting because since the JT Harness uses Ant as build system we need to give to Ant where the build.xml file is. By default Ant is searching it in the current directory but in jtharness the file is in the build directory. Since the Ant build file is correctly written, the build generates JAR files, Javadoc and examples code. And libjtharness-java* files are here to put the generated things in the right places.
The job of libjtharness-java.jlibs is to tell where to find the JAR libraries. In this case, the intesresting JAR files were javatest.jar and jt-junit.jar . So in the .jlibs file we just give where those files are after being built.
The job of libjtharness-java-doc.javadoc is to tell where the Javadoc is and where to put it. So there is only one line that says the generated Javadoc is in jar-build/javadoc and put it in /usr/share/doc/libjtharness-java/api .
And finally, libjtharness-java-doc.install is used to move the examples. The syntax is same as libjtharness-java-doc.javadoc .

The JT Harness package can be found in Sid now thanks to Sylvestre Ledru who uploaded it for me. So the ITP bug that I created is now closed.

Building the package for jtreg is quite similar. In fact, it probably easier but I m still facing a problem. jtharness is just a library, jtreg does have main classes and generate some binaries. The difficulty here is to generate the man pages for the 2 generated binaries: jtdiff and jtreg. These 2 files are shell scripts which just use jtreg.jar with the correct parameters.

I tried several tools to generate the man pages of each script. Sadly, I can t find a way that does not causes any problems.
My first choice was to use help2man. This tool looked like to be perfect for the job. But I couldn t find how to launch the scripts correctly. The scripts needs jtreg.jar but they also need javatest.jar from the libjtharness-java package. The classpath cannot be set correctly due how the scripts are written. So to use help2man I ll probably have to patch and completely rewrite jtdiff.sh and jtreg.sh in the sources.
My second choice was to use txt2man. During the build of jtreg there is a usage.txt file which is generated and which can be used as a man page. txt2man can take this text file and output a man page based on the text. I thought it was working but when building the package, lintian threw some warnings about syntax errors in the man pages.

W: jtreg: manpage-has-bad-whatis-entry usr/share/man/man1/jtdiff.1.gz
W: jtreg: manpage-has-errors-from-man usr/share/man/man1/jtdiff.1.gz 292: warning [p 4, 3.3i]: cannot adjust line

Finally, few days ago I decided to try rst2man. This tool looks cool and easy to use. But the text that I have to convert into a man page is not a reStructured text so it cannot without patching the usage.txt file for example. I was going to do it but there is no such file in the sources of jtreg. Actually this file is generated during the build but the text had to come from somewhere. And it was from two properties files in the source code.
I m still looking for a good solution to generate the man pages. If someone has any idea just let me know

The debian packaging of jtreg is not in the Java team SVN yet because of the man pages problem. I opened an ITP bug so people know that someone is working on jtreg.

My goal for the next two weeks is to finish the jtreg package, understand how jpkg (which is supposed to create Debian packages) works in Jigsaw and write more examples using the modular JVM.

Things aren t exactly going as smoothly as expected. Here are some explanations. First collateral damage: non-free fglrx and nvidia drivers. We have to admit we didn t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that s the move we call adding multiarch support ). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages. Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded. Second collateral damage: xserver-xorg-core in testing. The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post. That s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:

1. The server only has libgl1-mesa-dri in Recommends, so there s no hard dependency here.
2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.

But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path! Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages. To get fixed packages, two things were needed:

1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.

While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner. (As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we ll make sure we update the Breaks in the new mesa to make sure that it can t happen. Since it s not as urgent as getting the server in testing fixed, it s only queued for mesa 7.10.3-3 for now.)

I'm writing a blog entry instead of just replying to myself on a mailing list, since this subject might be interesting to a largish portion of the community. Most people assume things just magically work out by themselves and then after a release wonder why it wasn't so.

So, I raised a question on ubuntu-devel-discuss mailing list about whether usb-modeswitch should be included in the default Ubuntu 10.04 LTS installation instead of it only being in the universe repository. Reason was simply that firstly, I've read some general wonderings from the community about why it isn't already so. Secondly, without it my 3G modem (Huawei E1552) was first not functional, but right after installing usb-modeswitch package Network Manager worked smoothly with it.

Since I didn't get much discussion going on besides some statements that it doesn't work for everybody and even has caused extra problems for some others (in 9.10), I asked for a small round of comments on the subject on IRC. The channels are logged so I believe I can quote those a bit.

Colin Watson said among else:

"surely we just want the kernel to DTRT [do the right thing] by default ... this is the upstream trend ... it already DTRT for quite a few devices"
"I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel"
"I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work ... I'm just not very convinced it's a real properly supportable option"
"but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)"

Later on Paul Sladen continued a bit, among else:

"usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile"
"grep -hr MessageContent usb_modeswitch.d/ sort -n uniq -c sort -rn shows the level of duplication in the configuration files"
"...I do like that it is done in userspace though, as so easy to disable if you wanted something else".

Meanwhile I also IM:d a bit with Antti Kaijanm ki from whom I probably originally coined the idea of following whether usb-modeswitch is integrated into Ubuntu or not. He mainly said that he doubts the feasibility of updating kernel's USB storage quirks in a stable release, compared to having stable release upgrades about the usb-modeswitch-data udev rules. He also proposed discussing maintainability and usability by distros with the Debian maintainer and upstream, although it sounds like Colin might have had some talks already.

So there we are now. Apparently at this point it is hoped that as many quirks as possible are inserted in the kernel, see for example drivers/usb/storage/unusual_devs.h in the kernel. But if you have concerns about if 10.04 LTS will be kept up-to-date regarding 3G modems and want to somehow participate in bringing usb-modeswitch into Ubuntu default installation or simply discuss how to handle the kernel SRUs properly, it's time to stand up and do something.

Should there perhaps be a process with which the usb-modeswitch developers would get the information they are gathering more easily to the upstream kernel _and_ (older) distribution kernels? Is this simply a case of being easier to address an issue with a "hackish" approach, or is the usb-modeswitch actually the right way to go?

Note that I'm no expert in this area, I simply become interested in various subject from time to time :)

-Timo, going to figure out a kernel quirk for his 3G modem

Since Matt is going to be busy the next few weeks moving and traveling, he arranged for Stefano Zacchiroli to fill in for him temporarily as my mentor. I must say, I am quite lucky to have the chance to have both Matt and Stefano as mentors this summer. Yesterday, I had my first call with Stefano. I started by filling him in on the current status of the project. We discussed how the dashboard is going to be based on tasks rather than bug . He reminded me that we want to make sure all useful information makes its way back to the BTS (ideally in an automated or) in a fast and easy way. Most of the information that will be stored in the dashboard probably won t be that useful to the package maintainers. However, there will be a column for DEX members to add notes about tasks. This column could potentially contain some useful information. That is one reason that the dashboard will parse this column for bug numbers and then display extended information about the bug. Hopefully, this will encourage DEX members to send information to the BTS when relevant. Having the bug numbers will also allow us to automate sending information from the DEX dashboard to the BTS if we choose to. I also spent some time this week working on a script to generate some graphs. These graphs will allow us to track the number of remaining tasks in a project vs. time. Stefano mentioned possibly borrowing some code from the Ubuntu burndown charts, but right now, I think the Ubuntu charts might be a bit more complicated than what we need. We can always decide to borrow some features/code down the road if necessary. It is also just about time for me to prepare my second formal report for the Summer of Code. I will use that to showcase the current status of the code and make it available for people to test and review.

It was very much a team effort. My friend Brandon, who is an excellent photographer, came over and took some photos. Then my friend Sara, who is a bit of a Wikipedia contributor/edit/expert, showed me how to upload the photo to the Wikimedia Commons, and then it was just a case of gluing it all together by making the edit on the Wikipedia page. Then it was almost immediately deleted. It turns out that apparently the Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic license (better known as CC BY-NC-SA 2.0) is somehow incompatible with Wikipedia & friends (I haven't figured out the exact ins and outs of why yet). I had to get Brandon to re-license the photo I used as just CC BY-SA 2.0 (basically ditching the non-commercial restriction). Then it magically reappeared (after some help from Sara with the response). Crikey, this Wikipedia contributing is tricky stuff. At least when Speck's owners get back to pick her up, I can tell them their gecko is famous.