RCBW - week #16 ... and here are christmas (for those who care) RC squashes, by yours truly (for those who care too):

• bug #530527 - ipsec-tools - gcc 4.4 strict-aliasing, patch by peter green
• bug #539010 - opensrs-client - stop using deprecated Perl module MD5, patch by Ansgar Burchardt
• bug #539542 - libnsgif - gcc 4.4 strict-aliasing, patch by peter green
• bug #531715 - gcin - gcc 4.4 missing include, patch by Martin Michlmayr (+ lintian overrides for appropriate use of rpath)
• bug #504873 - im-sdk - gcc 4.4 missing include, patch by Martin Michlmayr (bonus: package orphaning, misc QA, kfreebsd patches applied)
• bug #540681 - beast - cast to volatile pointer, patch by Jakub Wilk
• bug #560499 - beast - gcc 4.4 missing includes

and here are the usual notes:

• most of them come from Luk, which this week provided me with a looong list (and of course I was not able to empty it) ...
• ... that list has probably entered the radar of others: let's thank Christoph Egger, gregor hermann, and David Paleino, which contributed quite a lot of RC-fixing NMUs in the past few days (probably others did too, but these 3 got into my way the most )
• I got annoyed by bug #562518 (zlibg b0rkage) for a while: while my main system got saved by apt-listbugs, my cowbuilder environment was not that lucky
• I've tried following a wise advice to speed up pkg building, but it does not work w/ cowbuilder, which insists in creating hard links and hence fail due to cross-device linking. I need to investigate whether this can be fixed without loosing APT cache sharing with the host system
• "thanks" to im-sdk, I discovered yet another patch management system: dbs: how many others are still out there?
• how dumb is a BTS instance which is not accessible by default w/o registration even for read-only purposes?

Hint/request of the week: please add +pending when you do DELAYED/ NMUs, that way filtering out already taken care of bugs gets easier and refreshing a bug log page in the browser will immediately show the new tag at the top.
(Yes, I agree that nmudiff should offer that when passed --delay, I intend to propose a patch for that, but feel free to beat me at it :-P) In other news, christmas vacations are awesome to catch up with books you planned to finish reading months ago ... Update: the patch for nmudiff I've mentioned has been kindly provided by gregor hermann, thanks!

My parents needed a new printer, and after some research I decided to recommend them an HP OfficeJet Pro 8000. Today I gave it a try, by printing some CD covers for a CD to give away for christmas to some friends.HP failed in a very subtle way: I had printed the covers, cut them, produced the CDs for them. Then I wanted to put the printed covers into the CD cases.Despite the graphics being 12cm x 12cm in size, HP managed to print them in 12cm x 11.4cm. Without any notice (or giving me a choice) it had decided to scale them on the y axis. Which makes them completely unusable, since they don't fit the 12cm height of the CD case now.After some more experiments, I decided to retry without duplex, and voila: 12cm x 12cm.Duplex on HP OfficeJet Pro 8000 is only usable for draft printing, since it will distort your pages!(See also this devidence in the HP forums, of people with the same issue, an attempt to investigate the margin messup happening, a report that the DJ990c driver can print duplex on this printer without messing with the margins, but is slower and offers less print quality. So it seems that this is an HP driver problem. And technically, it must be caused by the driver; at least it should be able to compensate for this!)I also noticed another issue with the print. The bottom right corner of the graphic didn't get enough ink, it looks like the printer stopped printing a bit too early. I don't know if this also happens in non-duplex, since I worked around this by adding a header and footer to the page.Seriously, we should send back the printer. On my first try to use it, I already encountered two bugs. I wonder how many bugs I would see if I'd use it every day?

When being told about the differences between Puppet and Chef by Puppet fans, a few common talking points emerged. They included the terms DSL , declarative , and shell script . Shell script was probably the most entertaining meme, and referred to how, without dependencies, Chef was just like writing shell scripts in Ruby. In actuality, a Chef cookbook appears to be roughly 17 files in 7 different directories. Most of them end in .rb, but there is also a metadata.json to keep the metadata.rb company, and perhaps an .rdoc if you like that sort of thing. I have no idea who writes shell scripts this way. I am also stupefied that people say this is easier than Puppet, because I doubt I would want to perform system administration by writing one of these things. So when I started writing my own thing, I contemplated the dependency issue, and for a few minutes decided to be lazy and leave them out entirely. Once it dawned on me, however, that I was then writing shell scripts in Lua, I became ashamed. If I were going to go that route, why not just set up a git repository with a bunch of shell scripts, and set up cronjobs on each of the clients to do a git pull and run these shell scripts as root? After all, nothing beats shell scripting for shell scripting, not Perl, not Python, not Ruby, and least of all Lua. So I wrote a dependency resolver. It was easier than I had anticipated and I have vague plans to make it smarter than Puppet's. Then I'm justified in sticking to my Lua DSL . Now Steve has a list of requirements that seem to be relatively mild. I think he could easily get away with a VCS-shellscript-cron setup. The VCS pull can be tunneled over ssh or stunnel or anything else which will provide authentication and encryption, so there is no need for a fancy custom server with its own certificate authority. In short, all the tools are there and you just need glue. I will continue to pretend that I'll need more complex logic and power that only Lua can give me, so I'll end up doing VCS-Lua-cron until I change my mind.

It was interesting to see Clint Adams describe love and dissatification with configuration management. At work I've got control of 150(ish) machines which are managed via CFEngine. These machines are exclusively running Debian Lenny. In addition to these hosts we also have several machines running Solaris, OpenBSD, and various Ubuntu releases for different purposes. Unfortunately I made a mistake when I setup the CFEngine infrastructure and when writing all the policies, files, etc, I essentially said "OK CFEngine controlled? Then it is Debian". (This has been slowly changing over time, but not very quickly.) But in short this means that the machines running *BSD, Solaris, and non-Debian distributions haven't been managed as well via CFEngine as the rest, even though technically they could have been. A while back I decided that it was time to deal with this situation. Looking around the various options it seemed Puppet was the way of the future and using that we could rewrite/port our policies and make sure they were both cleanly organised and made no assumptions. So I setup a puppetmaster machine, then I installed the client on a range of client machines (openbsd, debian lenny, ubuntu, solaris) so that I could convince myself my approach was valid, and that the tool itself could do everything I wanted it to do. Unfortunately using puppet soon became painful. It has primitives for doing various things such as maintaining local users, working with cronjobs, and similar. Unfortunately not all primitives work upon all platforms, which kinda makes me think "what's the point?". For example the puppet client running upon FreeBSD will let you add a local user, setup a ~/.ssh/authorized_keys file but will not let you setup a password. (Which means you can add users who can login, but then cannot use sudo. Subpar) At this point I've taken a step back. As I think I've mentioned before I don't actually do too much with CFEngine. Just a few jobs:

• Fetch a file from the master machine and copy into the local filesystem. (Making no changes.)
• Fetch a file from the master machine, move it to the local system after applying a simple edit. (e.g "s/##HOSTNAME##/ hostname /g")
• Install a package.
• Purge a package.
• Setup local user accounts, with ~/.ssh handled properly.
• Apply one-line sed-style edits to files. (e.g. "s/ENABLED=no/ENABLED=yes/" /etc/default/foo)

(i.e. I don't use cron facilities, I add files to cron directories. Similarly I don't use process monitoring, instead I install the monit package and drop /etc/monit/monitrc into place.) There is a pretty big decision to make in the future with the alternatives being:

• Look at Chef.
• Stick with CFEngine but start again with a better layout, with more care and attention to portability things.
• Replace the whole mess with in-house-fu.

If we ignore the handling of local users, and sudo setup, then the tasks that remain are almost trivial. Creating a simple parser for a "toy-language" which can let you define copies, edits, and package operations would be an afternoons work. Then add some openssl key authentication and you've got a cfengine-lite. For the moment I'm punting the decision but I'm 90% certain that the choice is CFEngine vs. Chef vs. In-House-Fu - and that puppet is no longer under consideration. Anyway despite having taken months to arrive at this point I'm going to continue to punt. Instead my plan is to move toward using LDAP for all user management, login stuff, and sudo management. That will be useful in its own right, and it will coincidentally mean that whatever management system we do end up using will have on less task to deal with. (Which can only be a good thing.) ObFilm: Terminator II

It was interesting to see Clint Adams describe love and dissatification with configuration management. At work I've got control of 150(ish) machines which are managed via CFEngine. These machines are exclusively running Debian Lenny. In addition to these hosts we also have several machines running Solaris, OpenBSD, and various Ubuntu releases for different purposes. Unfortunately I made a mistake when I setup the CFEngine infrastructure and when writing all the policies, files, etc, I essentially said "OK CFEngine controlled? Then it is Debian". (This has been slowly changing over time, but not very quickly.) But in short this means that the machines running *BSD, Solaris, and non-Debian distributions haven't been managed as well via CFEngine as the rest, even though technically they could have been. A while back I decided that it was time to deal with this situation. Looking around the various options it seemed Puppet was the way of the future and using that we could rewrite/port our policies and make sure they were both cleanly organised and made no assumptions. So I setup a puppetmaster machine, then I installed the client on a range of client machines (openbsd, debian lenny, ubuntu, solaris) so that I could convince myself my approach was valid, and that the tool itself could do everything I wanted it to do. Unfortunately using puppet soon became painful. It has primitives for doing various things such as maintaining local users, working with cronjobs, and similar. Unfortunately not all primitives work upon all platforms, which kinda makes me think "what's the point?". For example the puppet client running upon FreeBSD will let you add a local user, setup a ~/.ssh/authorized_keys file but will not let you setup a password. (Which means you can add users who can login, but then cannot use sudo. Subpar) At this point I've taken a step back. As I think I've mentioned before I don't actually do too much with CFEngine. Just a few jobs:

• Fetch a file from the master machine and copy into the local filesystem. (Making no changes.)
• Fetch a file from the master machine, move it to the local system after applying a simple edit. (e.g "s/##HOSTNAME##/ hostname /g")
• Install a package.
• Purge a package.
• Setup local user accounts, with ~/.ssh handled properly.
• Apply one-line sed-style edits to files. (e.g. "s/ENABLED=no/ENABLED=yes/" /etc/default/foo)

(i.e. I don't use cron facilities, I add files to cron directories. Similarly I don't use process monitoring, instead I install the monit package and drop /etc/monit/monitrc into place.) There is a pretty big decision to make in the future with the alternatives being:

• Look at Chef.
• Stick with CFEngine but start again with a better layout, with more care and attention to portability things.
• Replace the whole mess with in-house-fu.

If we ignore the handling of local users, and sudo setup, then the tasks that remain are almost trivial. Creating a simple parser for a "toy-language" which can let you define copies, edits, and package operations would be an afternoons work. Then add some openssl key authentication and you've got a cfengine-lite. For the moment I'm punting the decision but I'm 90% certain that the choice is CFEngine vs. Chef vs. In-House-Fu - and that puppet is no longer under consideration. Anyway despite having taken months to arrive at this point I'm going to continue to punt. Instead my plan is to move toward using LDAP for all user management, login stuff, and sudo management. That will be useful in its own right, and it will coincidentally mean that whatever management system we do end up using will have on less task to deal with. (Which can only be a good thing.) ObFilm: Terminator II

I'm a notoriously late adopter of new technologies. Sure, if I think that something is potentially a good idea, I'll go for it, but for the most part, I assume that things are stupid. I refused to use the WWW for many years, thinking it was idiotic. Now I use the WWW. I find microblogging to be inane and narcissistic at best, but I have derived mild amusement from Shaq on Twitter. Microsoft Windows is something I thought would be ridiculously unsuccessful, because it didn't do anything I would find useful. The list goes on and on, and includes something known in the popular vernacular as configuration management . I've been hearing about BladeLogic and Opsware for quite some time, and idly wondering who the incompetent fools are that need something like this. Back in my day we could manage 100 servers with relative ease; no centralized authentication (because it was a running argument about whether NIS sucked more than NIS+ or vice-versa), no cfengine, no prebuilt server images or any of that jazz. If, for some reason, we needed to make the same change to all servers at once, or some subset thereof, we would just script it. So when one of my acquaintances started raving about Puppet, I assumed it was equally pointless. We'll call him Downs. Downs exhibits a pattern of behavior where he will rave about something for a few weeks, sometimes without having even tried it first, and then eventually become disillusioned with it and start ranting with the same fervor with which he had insisted that whatever fad of the week was the greatest thing ever. It came as no surprise to me when he fell out of love with Puppet and started raving about how much better Chef is. In case you're wondering, he still has not tried Chef to this day. Finally someone convinced me of the value of Puppet. I do not think it is the Way and the Light, but I do see a few situations wherein it makes sense to sacrifice efficiency, flexibility, sanity, and system resources to gain a way of building a near-identical machine from scratch. Now, beyond the flaws inherent to a solution like this, Puppet does have some annoying flaws which I find unnecessary, and which Downs ranted about back when I had absolutely no idea what he was talking about. I disregarded his alleged preference for Chef, but I have heard intelligent people extoll the virtues of Chef, and to a lesser extent Bcfg2. So I took a very brief look at each of those, and was pretty much horrified by what I found. If I need something Puppet-like in the very near future, I will probably be choosing Puppet. I have no intention of running Puppet on machines I manage all by myself though. For that eventuality I am NIHing something with what I consider a better design. The current code is published, but it does not do very much, and requires linking with libdpkg.a which does not exist in any package (but Guillem's working on that, I think). I have no idea whether or not I'll have the motivation to finish it all by myself, but it is Free Software. This post is intentionally weak on details, or deets as the kids call them.

I can now announce my return to the land of the internet. Of course, I wasn't entirely without visiting rights. It so happens that one corner of my new living room is just within range of a terribly expensive wireless access point. It was slow, and kept dropping out. But I managed at least one upload over it, and some email... I have quite a lot of catching up to do.

YouTube rz1x5DYwn3U

The WebKit hackfest is now over, and I think it was a very productive week. Thank you very much to all who attended, to Igalia for organizing the hackfest, and hosting us so well, to Collabora for having sponsored the event, and allowed me to spend the week working on it, and to the GNOME foundation for having payed all of my costs!
Xan blogged about day 0, and also a summary of all that was done, so I ll focus on the stuff he forgot to mention ;D. The hackfest, for me, started on day -1 with me not allowing Xan to go sleep before he had reviewed a couple patches of mine to fix DOM context menu handling. It always bothered me that Epiphany failed to open right-click menus in some pages, or let pages handle the right click. Well, this is fixed now, and Zimbra users can now have their right click menus, and WoW players can remove talent points from their calculators =P. It turns out that many of the attendees don t like pages messing with their context menus, though, and they had some good points to back up their positions (like pages making it hard to save images, for instance), so I implemented a way to force openning the custom menu: Ctrl-rightclick. We wanted to use a GtkInfoBar to display questions regarding the form saving - our initial implementation always saved all credentials, but that didn t sound good enough. Xan and I thought it would be very complicated to make this work, because there were assumptions in the code regarding which widget contains which, but it turned out to be quite trivial - making EphyEmbed a descendant of GtkVBox instead of GtkScrolledWindow, fixing a small number of assumptions, and that was it. The passwords are saved in the GNOME Keyring. It s interesting to point out that GNOME Keyring seems to be unhappy with the number of passwords a browser stores - Xan s daemon was hanging, crashing, and spawning a large number of threads. My daemon decided to take up some 300MB of RAM at one point. It s somewhat funny to see how much a browser pushes the limits of our platform. We are hoping this will improve with the new keyring APIs, and the rewrite that is ongoing. It s nice to see my browser form passwords in seahorse, though, and be able to manage them like any other. One more thing worth of notice, although this post is already a bit too big: one of the main concerns people had during the Hackfest was on making build time smaller. Touching a single file in WebCore causes a debug build of 10 minutes on my laptop. Evan Martin and Benjamin Otte made a push at removing unnecessary includes from WebCore, and WebKitGTK+ files, which brough the build time down a bit. They end up inspiring Aroben, from Apple, to go even further into this, and remove many includes from files all over WebKit. Evan was also able to bring linking time down by making it possible to link libwebkit without having to build all the intermediate libraries, which brought build time down to 1 minute, when touching a single file in WebCore. Behdad and I also started looking into breaking WebCore up into lots of shared libraries for Debug builds, since we don t care too much about speed penalties in those. None of these experiments got committed yet, but I am hoping we will be having a better time hacking on WebKitGTK+ in the near future. It was awesome meeting everyone, by the way! See you around =).

I have the time over Christmas off, partly because I needed some distance from work but mostly because the children need looking after while their schools are on break.

Usually switching off from the work mindset is hard for me and I end up "helping" anyway. Not this time...come last Friday at quitting time I was gone. I was apparently in desperate need of this break and spending time with the kids has been great.

It has also been snowing! I used to love the snow when I was a kid and watching the boys build a snowman and have a snowball fight brought back good memories. It somehow has less amusement value when you are older and have to go to work in it and deal with all the problems with transport induces in the UK. Did I mention I was off work? ;-) I had a great time with them...and got a very cold neck.

I have also managed to solve the cat box problem. Turns out it was not the boxes, their placement or type. It seems they wanted three to choose from! They now have three boxes in which to sprawl and they use the original two in the original locations...just as long as they have the option of a third they are happy.

Now I have unwound sufficiently I am looking at tackling some Open source projects of my own which I have been neglecting. I am planning on finishing my whether station recording software and feeding my observations to the weather underground. Possibly doing some more work on Netsurf and maybe even fixing some RC bugs for Debian.

I usally find blog rants useless, but sometimes something is just so annoying one is sufficiently inspired. Today I went with my parents to buy them a Tivo at Harvey Norman, Norwest, Castle Hill, NSW, Australia. I am a big Tivo fan; the interface is good and it "just works". I don't mind paying for (or in this recommending paying for) good products. After selecting the Tivo model, I asked for a HDMI cable. The salesman made a series of questions about what sort of HD TV it was being plugged into; I quickly sensed this as a probe to see what sort of suckers we were, and requested just a "normal" cable. At this point, he insisted on a $130 (you guessed it) Monster cable, and had the audacity to say that we didn't need one of the really expensive cables because our TV wasn't good enough! I openly expressed my concern, but the annoying high-pressure sales pitch had just begun. The amount of, frankly, crap that he spewed about 4-bit this, 10-bit that, legislating of labels, DA signal levels, mythical customers who regretted buying the cheap cables and who knows what else was to the point of being comical if it weren't so insistent and said with such seeming authority. There is only one thing that matters - if the cable has passed the functional requirements for being certified to have the distinctive HDMI logo plastered on it. From the HDMI FAQ:

Q. What testing is required? Prior to mass producing or distributing any Licensed Product or component that claims compliance with the HDMI Specification (or allowing someone else to do such activities), each Adopter must test a representative sample for HDMI compliance. First, the Adopter must self test as specified in the then-current HDMI Compliance Test Specification. The HDMI Compliance Test Specification provides a suite of testing procedures, and establishes certain minimum requirements specifying how each HDMI Adopter should test Licensed Products for conformance to the HDMI Specification.

Now, I can understand that if you buy any old HDMI cable off Ebay for $1, it may be a knock-off that uses the HDMI logo illegally. But there is no way that the certified $50 Philips cable (still very over-priced, but at least not insane, and discounted to $35) performs any differently to some overpriced Monster model certified to exactly the same standard. The thing that annoyed me most was his analogy to buying a tyre. He stated that "if you walked up to a tyre salesman and I said don't want the Pirelli's, just put the cheap-o tires on my Ferrari" I'd be insane, and thus by extension of that logic I was insane for not buying a Monster cable for my great new Tivo. This analogy is completely flawed and really just dishonest. A Ferrari is much more powerful and goes much faster than a standard car. It is plausible it needs a better engineered tyre to perform adequately given the additional stresses it undergoes. A Tivo doesn't put out any more or any less bits than any other HDMI certified equipment, no matter what you do. If the cable is certified as getting all the bits to the other end under whatever environmental conditions specified by the HDMI people, then it's going to work for the 99% of people with normal requirements. Nobody wants to make a significant investment in a piece of audio-visual equipment and feel they are getting something that isn't optimal. Harvey Norman's use of this understandable consumer sentiment to sell ridiculously over-priced cables that do nothing is extremely disappointing. I'm sure the commissions on these things encourage this behaviour, so it is useless expecting the retailer or individual sales assistant to change their policy to reccommend reasonably priced cables. However, it is really Tivo and other manufactuers who get the raw end of this deal; a $130 cable is over 20% of the price the actual Tivo! That is surely affecting people's purchasing decisions. If Tivo and others included a certified HDMI cable with their device, as they do with component cables, and had "Certified HDMI 1.3 cable included" plastered on the box, it would be a harder sell to explain why the manufactuer would bother shipping a certified cable that is supposedly insufficient, and consumers would hopefully avoid the very distasteful high-pressure theatrics I was subjected to today.

I ve been playing with virtualization, and KVM in particular. However, I m running into an interesting problem. Below is how Ubuntu Netbook Remix look inside my KVM (either using virt-viewer, virt-manager or directly KVM to display the VM). Note how the top panel is fine. I m using KVM 88 from experimental (but I had the same problem with KVM 85 from unstable), the cirrus video driver inside the VM, and an up-to-date karmic VM.
Has someone ran into that problem already? If yes, where is it tracked? I m been failing to find the correct search keywords so far.

Ten years ago, on December 21st, 1999, Thomas Lange announced the release of version 1.0 of FAI (Fully Automatic Installation).

FAI is a non-interactive system to install, customize and manage Linux systems and software configurations on computers as well as virtual machines and chroot environments, from small networks to large infrastructures and clusters.

It is a tool for mass unattended Linux installation. You can take one or more virgin systems, turn on the power, and after a few minutes, the systems are installed, and completely configured to your exact needs, without any interaction necessary.

The tool was developed at the University of Cologne, because the author was too lazy to install Debian on 16 hosts manually.FAI now also supports the installation of Ubuntu and RPM-based Linux distributions. It is used worldwide in very different environments; even installations on two zSeries z10 mainframes are reported.

A detailed report in German about the 10 years of the FAI project can be found at http://www.informatik.uni-koeln.de/fai/otherdocs/10jahre.html.

Contributed by: Thomas Lange

Yesterday I was trying to get some of my old keybindings (from awesome 2.x) to work on awesome 3.4 and it was awful the process. With 2.x I worked with awful.spawn and got any bash command I wanted running. Now it changed to awful.util.spawn but if I wanted anything ran on a shell I had to use awful.util.spawn_with_shell but, at least for me, didn t worked. So I got commands like:

scrot ~/tmp/screenshots/$(date +%Y%m%d-%k%M%S).png

That one didn t ran directly. Nor my commands for volume management. So I got a workaround, used only awful.util.spawn calling scripts on my ~/bin path. So if any of you has got issues with this just put your line on a bash script file, make it executable and use a line like:

awful.key( , "Print", function () awful.util.spawn("scriptpath") end),

BTW, don t use ~ nor any thing needs a shell, use full paths to avoid confusion and bad functioning. I used ~/bin/d/anything and didn t worked nor with awful.util.spawn_with_shell. I hope this help anyone with my same issues.

A customer called me a while back. They have a pretty high-end NAS (2U server with external disk enclosure) that they use for most of their needs: both document and other storage for management types, as well as storage for their EDA cluster. People familiar with EDA tools will know that they are pretty disk intensive. They tend to require shitloads of diskspace, preferably at high performance. The problem was that extending the storage space of this high-end NAS device is rather expensive. Supported disks only come at 300G units with prices that are higher than the cheap TB disks available today for the desktop market; and while the price and performance of those disks is worth it for the EDA requirements, the number of people storing documents and similar on the same device is not so high that performance would be an issue. Thus, what they wanted was a cheap solution to augment, rather than replace, their current storage solution, with the focus being on low cost at the possible expense of performance and, since bacula runs well there, reliability. They were quite surprised when I offered them a solution based around a QNAP device; they had expected a price, without hard disks, of about three to four times the price of the QNAP, and therefore were very happy with this suggestion. Unfortunately, the devices produced by this manufacturer that are supported by Lenny, the current Debian stable release, were EOL'd just before we placed the order; however, their replacements will be supported by Squeeze, the next release, and with a bit of help from Martin Michlmayr, we were able to install Lenny with a somewhat more recent kernel. This drove the price up somewhat, both because the newer devices are a few tens of euros more expensive, and because we agreed to pay Martin to prioritize work on the specific device that we'd need, so that we wouldn't have to wait for him to get around to it. As of this Thursday, the device, which had finally arrived after some initial delays, has been installed. Unfortunately, one of the disks that they'd bought was DOA; but they had the foresight to buy five, rather than four, disks, so that was not a major problem. In fact, the only real issues that I ran into were this one arm-specific bug, and the fact that the high-end NAS device is still running etch, which means that rsync --acl won't work. That means I'll have to go back there soon to do an upgrade of the high-end device (which had been planned for a while already); for the arm-specific bug, a workaround is already in place. All in all, a pretty good experience.

Tutorials at the Garching Debian Stammtisch Munich traditionally used to have a lot of Debian Developers, but over the last couple of years quite a few of us who used to be students graduated and moved elsewhere or became very busy with their day jobs. We still meet for having a beer and a chat, but not as much as some years ago. We used to meet about once a month, but in 2009 we only managed to meet four times (however, we organized a Bug Squashing Party in November and had a special meeting as Lenny Release Party in February) As the meetings are really rather informal and not necessarily very Debian related, it is difficult to attract new people this way. So Johannes Wiedersich and I decided to try a more hands-on approach by having a second meeting in Garching, in the student-run bar on the campus of the Technische Universit t M nchen (TUM). The idea was to get more of the local science, mathematics and computer science students (as well as possibly interested faculty members) involved. We tried a first time about a year ago, but after two or three meeting in late 2008 and early 2009, we lost momentum. However, we began organizing the meetings again with the start of the winter term, and had two rather successful meetings so far. For the first meeting, we basically handed out some information on how to get involved locally (the Debian-Munich list, its subscription address, the wiki etc.) and discussed Debian in general and Debconf11 in Munich in particular. About half a dozen people showed up, and two of these attended the Bug Squashing Party later that month, and another one (a faculty member) got very active in Debconf11 organization. Thus, I was quite happy with the outcame of that meeting. Some days ago, we had another meeting, and this time I was doing a live-tutorial on Debian package building. As Johannes was ill, we did not manage to announce or publicize the meeting well in advance, so only three people showed up. Still, I think it went rather OK, and we will be doing another Debian package-building tutorial for the next meeting, and possibly other turorials/workshops afterwards (ideas so far include library maintenance, Debconf, how the Debian community is organized and how to get involved in it). As doing a live-tutorial on one notebook is a bit difficult if you both have to type on it and people should see what happens, we will either use some extra hardware next time, or move to some nearby seminar room with a projector, this will be announced in advance. So if you are on Garching campus or nearby and interested in Debian development (and Debian package-building in particular), come to the next meeting on January 13th! We decided to meet on the second Wednesday of each month, at 18h. Subscribe to the Debian-Munich list to get the invitation or watch out for the flyers on the campus.

As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions.

-- Robert Collins I agree. Robert goes on to talk about the tendancy Debian (and apparently also Ubuntu) have to dislike upstream providing a debian directory. Funny thing is that we also like to say team maintenance is a good idea. An upstream who is doing packaging work is a readymade half of a team; if you write them telling them to rm -rf debian, you are turning away a team member. With a slap in the face. Worse, it's a team member who has demonstrated that they are capable of working in far more complex systems than a debian directory, since they wrote/maintain the software itself. BTW, for those who are skeptical of teams, on the basis that they dilute responsibility: A team consisting of an upstream developer and a distribution maintainer is inherently the more healthy sort of team, where each member has a well-defined area of expertise, but can also venture outside their area when needed. When I packaged FBReader for Debian, upstream already had their own packaging, and I worked with them to fix problems with it and make it something I could be happy maintaining. This was sometimes tricky, since upstream was also maintaining packages for maemo. Sometimes the tools were not ideal. It was still worth it. On the other side of the coin, d-i is an upstream for several distributions. If they told us we needed to rm -rf debian, we'd not have a lot of d-i left. tools I also agree with Robert that most of the trouble comes down to problems with tools. BTW, RPM does not have these problems, and in that world it's typical for upstream to provide a spec file. Much of the problem comes down to the crummyness of dpkg's source format, which cannot rename files, delete files, etc. That the source format directs us to 1970's source management (ie, tarballs and patches), instead of 21st century source management (ie, DVCS), doesn't help either. dpkg's 3.0 quilt source format tries to address the issue by removing any debian directory in upstream's tarball. I am not sure that this is at all the right approach; it makes it harder, not easier to work with upstream as a team. A better approach might be to consider anything that hardcodes the debian directory as having a bug. If upstream can easily package debs using a deb, or maemo, or ubuntu directory, you sidestep any potential conflict while still being able to work with them via a symlink. To put my time where my mouth is: Anytime debhelper prevents working with an upstream who wants to ship a debian directory; that is a bug. I will fix them. (Note that debhelper already provides a --ignore that can be used if upstream has provided a dehelper control file that you can't delete and don't want used.) Previously: Look who's packaging

I've recently gotten myself an Android phone. The Android app market is not as mature as iPhone's App Store, but there is a lot of applications, and plenty of chaff to separate the wheat from. I found most of the apps I use by browsing "top Android apps" lists on the web, so I am putting up a similar list here in case someone finds it useful.

• Everyday apps
  • Astrid Task/Todo List - a great To-Do list app that integrates with Remember The Milk
  • Quick Calendar - an "upcoming events" widget
  • CardioTrainer - nice jogging app, records routes using GPS, integrates with music player
• Language tools
  • Thesaurus Free - a thesaurus
  • Free Dictionary Org - reference dictionary
  • QuickDic German Dictionary - an English-German-English dictionary
• Media content
  • Listen - an app to find audio content online
  • Mother TED - search and view TED talks
  • TuneWiki - music, song lyrics
• Games
  • Lumbricidae - guide a worm using your accelerometer
  • Flying High - plane flying (also accelerometer-based)
  • miniMatcher - memory game
  • Iconic Memory - another memory game
• Cool apps
  • Phonalyzr - pretty phone call (and SMS) stats
  • Shazam - identify a song by recording a short snippet; possibly one of the coolest apps available
  • SnapTell - look up product information by scanning a barcode (or even by snapping a photo!)
  • Backgrounds - background images
  • Google Sky Map - shows constellations
  • Layar Reality Browser 3.0 - a fancy-looking Augmented Reality app
• Music
  • Sonorox - tune composition for everyone (the pentatonic scale is great, isn't it?)
  • Loops! Lite - another music composition app
  • Tuner - gStrings - a guitar tuner
• Miscellaneous
  • Task Manager - a process monitor utility, useful for checking up on app resource usage
  • Currency - a currency converter
  • Sleep Logger - a very simple, but useful app for tracking your sleep habits