Do you use the debian dspam packages, specifically with one of the database backends? Recently upgraded the packages? Does noone email you anymore? You might be bitten by a bug, or perhaps undocumented misfeature, that bit me this morning. No emails were coming in and yet the mailserver logs said they were coming in, but a closer look at the logs showed this: Aug 15 09:08:17 elmo dspam[24896]: dlopen() failed: /usr/lib/dspam/libpgsql_drv.so: /usr/lib/dspam/libpgsql_drv.so: cannot open shared object file: No such file or directory What happened here? A quick look at the installed packages said the pgsql backend was still installed but this file was not being found. The latest version of libdspam7-drv-pgsql now has multiarch support which means /usr/lib/dspam no longer exists and the driver is found in /usr/lib/x86_64-linux-gnu/dspam. The problem happens because the configuration file specifies the directory and that has now changed. The fix is as simple, update /etc/dspam/dspam.conf with the new path.

Every year I worry that DebConf might not be as good as I hope, or not as good as previous years. Well, I've yet to be let down! The road trip down to Banja Luka was good fun, even if it took a little longer than planned. We ended up travelling down through Germany on the same Friday as much of the country finished work/school for their summer vacation, so there was a lot of traffic. Meh, we got there in the end. I made my usual mistake of planning some things to hack on during the DebConf week; by now I should know better... :-) I made a start on one small project, but then got so distracted by so many talks and side meetings with people that it's still waiting. As always, my own personal TODO list picked up huge amounts of extra stuff from those discussions. Catching up with, and socialising with, Debian friends from all over the world was also fun as always! Lots of highlights of the week for me, both for technical and social reasons:

• Multi-arch is finally with us! Great talk from Steve Langasek, and a very useful meeting afterwards to unpick what work is still needed. Quite a bit, it seems... :-)
• Useful meetings with Otavio to discuss future changes to how debian-installer is going to work, and how the debian-cd and debian-installer teams can work together better on that.
• Catching up with Martin to work out what's needed to get pancutanfinally integrated with our regular CD builds.
• Talking with Jimmy about where to go next for regular debian-live builds on our core CD build machine.
• The ARM BoF, where things have moved on from "why should I care about ARM?" to "when will you have armhf ready for going in the archive?". W00t!
• Doing our own day trip in the cars from the UK. We got to meet some very friendly and helpful local people, plus we found some incredible roads to drive on. Even if not all of them were technically roads yet... :-)
• Playing poker in a real casino for the first time, along with a bunch of friends. Nice atmosphere, and very good fun.

Banja Luka was a lovely place to visit, and a great host city for DebConf. Looking forwards to Managua now!

The new release switches to GDBus and adds an application icon. Together with the recently released Modem Manager 0.5 it's now able to fetch the balance information via USSD on Huawei and ZTE modems as well. This blog is flattr enabled.

Dear lazyweb, In a couple of weeks I'm likely to be going cycle touring around the North East of England. This will involve first taking a train from Nottingham. While looking at train options just now, I was reminded of a little survey that I wanted to conduct. Taking bicycles on trains in the UK can be a hit-or-miss experience. The UK's train routes are operated by a variety of train operating companies who each have different policies on taking bicycles on their trains. Some require a reservation, some do not. Some do not even allow reservations at all. There's no official database of these policies. It is up to you to check all of the companies' websites individually. As far as I can tell it is impossible to make a cycle reservation online. If you don't make a reservation, chances are that you'll be OK, but there are no guarantees you won't find yourself stranded in Bolton when none of your connections will take you. The number of spaces reserved for cycles is extermely limited. Two seems to be the most common number that a train can officially carry (you may be able to stash it in the vestibule). Even given this, it is usual to find that the cycle spaces are taken up by prams, luggage and other crap when you actually board the train, so the effective number may actually be 0. However, it is thankfully not uncommon to find staff and other passengers who are more than willing to go out of their way to help you if they see you are trying to take a bicycle onto a train. Anyway, I'm interested in how this situation is in other non-UK countries. Better or worse? A lot of countries certainly have a more cycle-friendly culture I'd like to know how this kind of thing works there so that I can write a Strongly Worded Letter about how we Should Be Doing Better. (Image by onohiroki, CC-by-nd.)

Painless they say, automatically they say. This is what the NetworkManager manual page describes the daemon. I d like to say annoying and intrusive and I know there are a lot of people out there that feel the same. The program is used to set-up network connections and provides a system tray thingy for Gnome and for simple set-ups its great. Sure, I got NetworkManager running on my laptop and we re all friends over there. It just works, it just works for my local network, wireless network and even 3G and VPNs work just like they should. This is the environment where it was designed for and it shows. What about on the server where I login using gdm? We ve had nothing but a world of pain there. It used to be bad enough when it fiddled with /etc/resolv.conf meaning DNS stopped working everytime i logged out. Every stop playing around with my settings and leave me alone option fails to do just that. It got so bad I had to use chattr to make the file immutable; so if you are tearing your hair out, then chattr +i /etc/resolv.conf is your friend. The latest version of NetworkManager takes this insanity to a new level. Now not content with messing around with my resolver files, it reconfigures my statically assigned IP address to a dynamic DNS one AND removes it when I logout. No doubt if it let it, it would muck around with resolver files too. Again, by default on a laptop this is fine. The problem is the would you leave me alone options fail to work, or mean stupid things happen like pidgin doesnt think there is a network so never logs in. So I resorted to reading more about this intrusive program and was there a way of stopping it doing what it was doing. The directory /etc/NetworkManager/system-connections looked promising as they were connections available at boot time and across all users. But then there is the funky format and wow, nothing saying what you might need versus what if you have missing makes the thing fail. What s not obvious is that if you edit your network connections and then select available to all users then your settings go into that system-connections directory and that for the moment appears to be working. It means I have my network settings configured in two places which means all sorts of fun if I change them and forget about the other. This isn t an ideal situation and network manager should start to behave properly and read the ifupdown stuff and use it but not muck around with settings if it is told to. There are options that imply they do this but they don t work. Despite the title, I don t think peace has broken out between me and Network Manager but rather an uneasy truce; I m sure that program is just sitting there thinking of what other settings it could play with when my back is turned.

Related articles

• Network connections on Ubuntu (flatchat.wordpress.com)

These days I briefly discussed with a fellow Debian developer about how to maintain upstream patches in Debian packages with Git, what brought me to rethink a little about my current practices. What I usually do is pretty much like point 4 in Raphael's post "4 tips to maintain a 3.0 (quilt) Debian source package in a VCS": I make commits in the Debian packaging branch, or in a separate branch that is merged into the Debian packaging branch. Then I add the single-debian-patch option to debian/source/options so that a single Debian patch is generated, and include a patch header that points people interested in the individual changes to the public Git repository where they were originally done. My reasoning for doing so was the following: most upstream developers will hardly care enough to come check the patches applied against their source in Debian, so it's not so important to have a clean source package with separated and explained patches. But then there is the people who will actually care about the patches: other distribution developers. Not imposing a specific VCS on them to review the patches applied in Debian is a nice thing to do. Then I wrote a script called git-export-debian-patches (download, manpage), which was partly inspired by David Bremner's script. It exports all commits in the Debian packaging branch that do not touch files under debian/ and were not applied upstream to debian/patches. The script also creates an appropriate debian/patches/series files. The script is even smart enough to detect patches that were later reverted in the Debian branch and exclude them (and the commit that reverted them) from the patch list. The advantage I see over gbp-pq is that I don't need to rebase (and thus lose history) to have a clean set of patches. The advantage over the gitpkg quilt-patches-deb-export-hook hook is that I don't need to explicitly say which ranges I want: every change that is merged in master, was not applied upstream and was not reverted gets listed as a patch. To be honest I don't have any experience with either gbp-pq or gitpkg and these advantages were based on what I read, so please leave a (nice ;-)) comment if I said something stupid. I am looking forward to receive feedback about the tool, specially about potential corner cases in which it would break. For now I have tested it in a package with simple changes agains upstream source, and it seems fine.

OK, this one is meant for Planet Debian...

One of many, many changes in the latest lintian is vendor profiles and, thanks to a heads-up by Niels Thykier, Emdebian will have working profile support in the next upload of emdebian-grip. (The only reason it's not already in Debian is my own fault for not uploading when I thought I had the time to upload.)

$ lintian --profile emdebian-grip drivel_3.0.2-1em1_amd64.deb 

$ lintian --profile debian drivel_3.0.2-1em1_amd64.deb 

E: drivel: debian-changelog-file-missing

E: drivel: copyright-file-compressed

W: drivel: copyright-without-copyright-notice

E: drivel: description-contains-invalid-control-statement

W: drivel: binary-without-manpage usr/bin/drivel

So the em1 version implements Emdebian Policy for Emdebian Grip. Clean for Emdebian Grip, just as the Debian package is clean prior to the changes.

I expect this to dramatically improve the processing of Emdebian packages, both for Grip and for the cross-built flavour, Crush, once that actually starts up.

Thanks to the lintian team for this support. Now if there was some way of backporting this version of lintian to Squeeze, I could also use this at work to suppress really annoying lintian warnings about non-standard suite names. (The whole point of using a non-standard suite name is to keep our stuff separate from the normal Debian/Emdebian stuff for licensing reasons etc.) Update: of course, I didn't check the PTS for lintian before writing that, so hence didn't notice that the backport already exists! Thanks again to Niels for the prompt. I've now got another package to create for work. Update2: Thanks to Joerg Jaspert for the tip that all lintian versions get backported directly from unstable as an exception on ~bpo. The work package is ready, so this is going to make things a lot easier when building stuff on stable.

In other news, the same version of emdebian-grip will include support for integrating Emdebian Grip into Debian itself. This too will use vendor-specific support, this time an internal vendor name which just needs to work on the "buildd".

(It's not quite a buildd, Emdebian Grip doesn't build anything, it's all post-processing. It's just that the processing of Debian packages for Emdebian Grip will look a bit like having a second buildd working on the packages uploaded by the existing buildd. The process itself is still developing...)

Multistrap runtime message translations need updating but the manpages aren't being done this time around. More changes are likely before those get done.Current runtime translation status:

language        translated     fuzzy     untranslated

-----------------------------------------------------

  da               103           4             4

  fr                54          17            40

  pt                54          17            40

  vi                54          17            40

http://lists.debian.org/debian-i18n/2011/08/msg00105.html
Check with the relevant debian-i18n team for your language, this is just a prompter in case people miss the mailing list post.Update: Hmm, that went to the wrong blog. It got tagged i18n but was meant for the i18n blog. Ah well, doesn't hurt for Planet Debian to see what is going on elsewhere....

For a number of years, I've been making myself metapackages that pull favorite packages and pre-configure the desktop environment to use my favorite global default settings. This currently means configuring the gconf keys for the GTK theme, icon theme and background image for GDM. Until now, I implemented this by calling gconftool-2 directly in postinst as user gdm but Lintian recently started warning me that the correct way to do this would be by calling gconf-schemas or update-gconf-defaults instead. I was thus wondering, would anyone have any sample code that accomplishes this? To further complicate things, GNOME 3 has transitioned from gconf to dconf, which suggests that a slightly different method needs to be used to perform the same. Would anyone have any sample code to implement this? Thanks in advance to anyone who can help me with this!

[...]
FAIL: integrityhuge
==================================
7 of 9 tests failed
Please report to wouter@debian.org
==================================

Obviously, this new code is somewhat broken. Hack hack, debug debug, oh, oops, there's still an nbd-server running, so bind fails, which is why the test suite fails. Maybe that's just it? ... yes, if I kill that other nbd-server, this test suite seems to work. Looks like I'm a better coder than I thought!

[...]
FAIL: integrityhuge
==================================
6 of 9 tests failed
Please report to wouter@debian.org
==================================

... except I'm not, I'm just very good (or very bad, depening on your point of view) in picking test suites to debug. Hrmpf.

The Border Gateway Protocol is what network operators use to exchange the various routes forming the Internet. It's a pretty critical piece of infrastructure. Most providers are probably using proprietary solutions using dedicated hardware, but free software on comodity hardware can also be an option for some networks. In Debian, we already have Quagga and Bird that both implement BGP on top of Linux for quite a while. Back in time, FOSDEM feb. 2006, Ging is being demonstrated. Immediately my mind races with something like: waow, we could port OpenBGPD on that! OpenBGPD is another BGP routing daemon. This new effort was started in 2003 by Henning Brauer for OpenBSD. To sum up its goal, it was meant to be secure, reliable, lean, easy to configure, fast and memory efficient. This is quite the opposite of Quagga codebase, which is inherited from an older project, Zebra which was mostly documented in Japanese. Another issue I have seen hapenning with Quagga on Linux is that its blocking implementation and the time that the kernel needs to insert/remove routes made the daemon unresponsive enough to created cascading failures. The IPv4 Internet is nowdays made of more than 350 000 prefixes, so when a network peer fails, the router needs to process those changes while continuing to answer other peers. Otherwise, they will kill the session meaning yet another 350 000 prefixes to process on both sides. And again when the session is restored. Leading to more downtime, flaps, and failures. OpenBGPD was ported to FreeBSD. The port is maintained by Hiroki Sato. Starting with this port and using libbsd made the creation of a package for Debian GNU/kFreeBSD pretty doable while at DebCamp11. It probably still has some pretty rough edges and the manpage needs to be reviewed (and some unsupported features trimmed, maybe), but the package should be usable. So OpenBGPD is now in Debian, and it could be one of the killer features of a port that some describe as a toy OS. Unfortunately I did not yet have access to proper network equipment to test the package on real production scenario (with 2 or 3 full BGP views). If you have a lab (or feel adventurous) and have access to such gears, please have a try!

Getting older^W wiser, and definitely fatter than yesterday [ Photo of the cake is missing, have I already told you I became fatter? ]

Via #241343:

* Package name    : apt-gentoo
  Version         : 0.0.1
* URL             : http://www-jcsu.jesus.cam.ac.uk/~mma29/apt-gentoo/
* License         : GPL version 2 or above
  Description     : enhanced package installation
 apt-gentoo enhances the Debian package installation experience to make
 it fully competitive with newly-popular source-based distributions.
 As packages are installed, apt-gentoo automatically downloads their
 build logs from the buildd network. The logs are then slowly scrolled
 past on the user's terminal to simulate building the software on the
 local machine.
 [..]

So, something like: Package/source and example installation transcript.

This is my first week back after two weeks off (I aim for three complete weeks off a year). Even if I had reached InboxZero (and ToDoZero and so on ), there was two weeks of requests, reports and rubbish piled on top of what was already scheduled. I wasn t even completely offline this time and was forwarding urgent incoming messages to other members of our co-op, but the backlog is still significant. How you deal with this? Basically, I arrive back and I feel like I m already behind. The good feeling of being up-to-date seems like a distant memory. The clear day I allocated to dealt with things that arrived seemed inadequate. Was that just bad luck because a lot of stuff came in, or is there a rule-of-thumb for how much catch-up time to allocate? 3 Lessons Learned From 6 Days Off The Grid Social Butterfly Guy offers a view on how to prioritise things, but it still looks like catch-up takes hours. Can you see any ways to make it more efficient but still please clients, collaborators and co-op members?

Welcome Planet Debian viewers If things are working right, Planet Debian will now be getting my blog posts tagged Debian. The main reason I had not done this before is not much on my blog relates to Debian, and it tends to be much less technical than most of the blogs there. Viewers from there might want to check out my recent post on debconf11 and may check out the rest of my blog archives, where I'm trying to get rid of my house and move in to a motorhome.

About 24 hours ago I rebooted the system that runs the secondary DNS for my zone and a few other zones. I d upgraded a few things and the system had been running for almost 200 days without a reboot so it was time for it. Unfortunately it didn t come back up. Even more unfortunately the other DNS server for my zone is ns.sws.net.au which is also the only other server for the sws.net.au zone. Normally this will work because the servers for the net.au zone have a glue record containing the server IP address. So when asked for the NS records for the sws.net.au domain the reply will include the IP address of ns.sws.net.au. The unfortunate part was that the IP address was the old IP address from before the sws.net.au servers changed to a new IP address range, I wonder whether this was due to the recovery process after the Distribute IT hack [1], as forgetting to change a glue record is not something that I or the other guy who runs that network would forget. But it is possible that we both stuffed up. The DNS secondary was an IBM P3-1GHz desktop system with two IDE disks in a RAID-1 array. It s been quite reliable, it s been running in the same hardware configuration for about four years now with only one disk replacement. It turned out that the cooling fan in the front of the case had seized up due to a lot of dirt and the BIOS wouldn t let the system boot in that state. Also one of the disks was reporting serious SMART problems and needed to be replaced poor cooling tends to cause disk errors. It seems that Compaq systems are good at informing the user of SMART problems, two different Compaq desktop systems (one from before the HP buyout and one from after) made very forceful recommendations that I replace the disk, it s a pity that the BIOS doesn t allow a normal boot process after the warning as following the recommendation to backup the data is difficult when the system won t boot. I have a temporary server running now, but my plan is to install a P3-866 system and use a 5400rpm disk to replace the 7200rpm that s currently in the second position in the RAID array. I ve done some tests on power use and an old P3 system uses a lot less than most new systems [2]. Power use directly maps to heat dissipation and a full size desktop system with big fans that dissipates less than 50W is more likely to survive a poorly cooled room in summer. Laptops dissipate less heat but as their vents are smaller (thus less effective at the best of times and more likely to get blocked) this doesn t provide a great benefit. Also my past experience of laptops as servers is that they don t want to boot up when the lid is closed and getting RAID-1 and multiple ethernet ports on a laptop is difficult. Finally I am going to create a third DNS server for the sws.net.au domain. While it is more pain to run extra servers, for some zones it s just worth it.

• [1] http://www.zdnet.com.au/distributeit-data-unrecoverable-post-hack-339317149.htm
• [2] http://doc.coker.com.au/environment/computer-power-use/

As our GSoC students are approaching quite well, we've already numerous features included in current master, which are worth mentioning. You can try all bellow mentioned features on our demo server. Grid editing provides really simple way of editing data, by simply clicking on it while browsing table. Just try it on some table. Performance suggestions are part of completely reworked server status and can give you valuable information how to tune your server. You can see it on demo server. Another nice addition to server status page is live monitor, which charts basic server information in real time. Again, try it on demo server (you need to press start for now, this will probably go away soon). Other big, thought not that fancy change is complete support for routines. This includes stored procedures/functions, triggers and events. For example see routines in sakilla database. Of course there is much more to mention, like improving of AJAX in lot of places, GIS support. On the other side, we've also recently decided to remove support for Microsoft Excel import and export as used PHPExcel library seems to suffer some licensing issues, which prevented phpMyAdmin from being included in Fedora. You can still use CSV or OpenDocument formats though.

Filed under: English Phpmyadmin 0 comments Flattr this!

DebConf11 ended nearly two weeks ago After all the discussions that happened there, I really feel that some of those topics could benefit from more coverage. Planet Debian looks like a good candidate, so we'll see how it goes. To sum it up: Hi there!

DebConf11 ended nearly two weeks ago After all the discussions that happened there, I really feel that some of those topics could benefit from more coverage. Planet Debian looks like a good candidate, so we'll see how it goes. To sum it up: Hi there!

I like so much the git feature branch workflow, that in the early days of development on Python with Mercurial I created some named branches; well, that is something you should not do.

In Mercurial, the changeset contains the branch name, so you cannot develop on a separated (named) branch and then merge on default and hope that branch goes away, because it will stay.

What do I do now? Python Mercurial repository is quite big (around 200Megs) so I wanted to avoid to re-check it out. Thanks to the help of the folks on #mercurial (on freenode IRC network) I found my solution: strip the branch!

Please note that strip is dangerous. Use it only as last resort, and mind you can lose data with it. That said, it's a very powerful tool :) My main aim was to remove completely those named branches, leave no traces, and lose the changes I made on them. Another important aspect is that I didn't merged those branches on default.

So, how to get rid of a named branch:

$ hg strip "branch($ BRANCHNAME )"

and re-iterate for all the branches you have, that's it. Now, to be completely sure they were removed and no spurious changes are in the repository, you can:

$ hg pull -u
$ hg outgoing

and if it says "no changes found" you're sure that those branches are really gone.