We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

• The upgrades done on all systems (e.g. a libc or kernel update)
  
  seperated from
  
• the updates specific to a certain system or system class

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

• Parsing the logfile (obviously)
• Storing each line in a logfile as a DPKG::Log::Entry object that holds informations about the entry type (e.g. action or status update), the package associated (if any), timestamp, verbatim line, line number etc.

• Limiting the number of lines parsed to a time range specified by DateTime objects

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:
dpkg-report

Report for a single host for the last two days:
dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:
dpkg-report --log-file /path/to/logs --merge

This will do the following:

• Report packages which where installed/removed/etc. on all systems seperate from the upgrades only done on the specific systems
• If systems start with a common name and end on a number (e.g. mail1, mail2, mail3 etc.), report packages which where installed on all systems with that common name seperate from the upgrades only done on the specific systems
• For a specific system list only the changes on that particular system and nothing else.

A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)

dpkg-Report for test*:
------------------------
Newly Installed:
blub

dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)

dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

I have been packaging for Debian for a few years now. My first serious package was Wt back in 2007, but I had been backporting for Ubuntu for at least 2 years already, which means I have been doing .deb packaging for about 5 years (!). Last week I decided it was about time stop nagging my sponsors (Vincent Bernat, Thomas Girard and Sune Vuorela) every time I wanted to update the packages I maintain (witty, ace and libmsn), and I finally started the Debian New Maintainer process. The main reason I had not applied for Debian Maintainer yet was it requires some bureaucracy and, well, I d rather spend my time coding or packaging than doing paperwork I sent my Declaration of Intent and soon after, Thomas and Vincent replied and supported my application with very very nice and kind words. Thank you, guys! I m flattered! Had I known I would be buttered up so much, I would have certainly applied a long time ago! But you know what is the best part of this? It shows how open source projects take advantage of all the tools and communications channels we have (IRC, mailing lists, sprints, conferences, etc), and make distributed development work very well: here we have a 900-developers project in which two French guys are praising an Spanish guy they have never, ever met face-to-face (only e-mail, occasional IRC, and the most important of all: code review). Meritocracy at its full extent. Have you ever seen that in a traditional 100,000 workers company with hundreds of developers working in a single project?

The 0.9.2 release of Rcpp is now on CRAN and Debian. This version contains a build fix for the older 10.5.* version of OS X and its g++ 4.2.1 compiler; we now skip one test that upset it. CRAN builds for OS X should resume. We also added simple configuration support for the Intel Compiler; feedback would be welcome on the list. Lastly, documentation in the vignettes was expanded a little. The NEWS entry is below; more detail is in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.2   2011-02-23
    o   The unitTest runit.Module.client.package.R is now skipped on older OS
        X releases as it triggers a bug with g++ 4.2.1 or older; OS X 10.6 is
        fine but as it no longer support ppc we try to accomodate 10.5 too
        Thanks to Simon Urbanek for pinning this down and Baptiste Auguie
        and Ken Williams for additonal testing 
    o   RcppCommon.h now recognises the Intel Compiler thanks to a short
        patch by Alexey Stukalov; this turns off Cxx0x and TR1 features too
    o   Three more setup questions were added to the Rcpp-FAQ vignette
    o   One question about RcppArmadillo was added to the Rcpp-FAQ vignette

Thanks to CRANberries, there is also a diff to the previous release 0.9.1. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

...For the cases where, yes, you actually do want it. For the impatient assuming you're in a clean checkout on the tip of your current branch:

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

you can then double check that everything is as you expect with git diff ref-to-be-merged, which should be empty. The longer story It's noted from time to time that git does not have a -s theirs option to complement the -s ours strategy when merging (or, it did, but it was removed long ago, see below). For those not savvy the idea with git merge -s ours is to pretend as though a merge from some other branch has occurred, though the result remains the current branch's contents, unchanged. This is a neat trick that can be used to show that all changes in some branch have been superceded by the current branch, which can help ease merges further down the line as parallel devlopment continues. However, there is no corresponding -s theirs option, which would conversely say that "everything developed up to here is superceded by this other branch". This feature was discussed and discarded by one of the git authors, who instead advised a developer to throw away the previous work and start on a fresh branch:

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.

In what would probably qualify as "most cases", he's right, but sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided. In debian, for example, it's pretty common for maintainers who use git-buildpackage to build debian packages from git to have two branches: an "upstream" branch and a "debianized" branch. The upstream branch will follow the changes from the upstream project (either by importing tarballs, or by pulling directly from the project's git repo if they also use git), while the debianized branch contains all the packaging related changes as well as any debian-specific changes to the code. In this context, if the upstream project uses git and rebases their history (out of your control), or if they shift development to a different branch, you might want to have a way to merge with their latest changes without rebasing/abandoning your current debian branch. Hence, a "theirs" merge. The author is totally right that the upstream project may be less interested in pulling from such a repository (since they would drag in the entire previous history), and if that's a problem you might need to splinter off the old branch and start a fresh branch instead. But at least for the projects with which I work, I find that it's more likely that pulling is pretty much one way upstream to debian, and that the patches flow back to the upstream project by way of bug trackers, git format-patch sendmail, or quilt patches sitting in the patch-tracker. And if it becomes a problem later you're no worse off, you can still split off a new branch or take some other action. So anyway, I asked Teh Internetz and found a few hits in the right direction, such as this guy at stack overflow, or this guy here. But from an aesthetic point of view I thought their solutions still left some room for improvement--they were both more complicated, involved setting up temporary branches, and I don't know, just weren't pretty on the eyes. So, ending where I started, this is the relatively clean and easy to follow 3 lines I conjured up, which I will give to teh internetz for posterity.

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side). This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates. However, on the debian branch your less interested in the clean upstream development, and instead want to keep a sane history of the debianization work, so on this branch you still do something like a merge -s theirs (though in this case, you probably want to amend the previous version's ./debian dir back in post-merge). So applying the same approach as above with the slight modification, in practice (assuming you're on the clean tip of the debian unstable branch, that'd be):

git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff ref-to-be-merged   git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend

PS In spirit, this is a similar approach to what's done by the XSF team, though I would argue that with what I'm describing both the approach and the resulting history are a bit cleaner and easier to follow. Also, thanks to ron, mrvn, jcristau, and nthykier on #debian-devel for some quick reviewing of this.

You re eager to start contributing to Debian, your first action is to subscribe to some high-profile mailing lists (like debian-devel and debian-project) to get a feel of the community. You read the mails for a few days and then you find out that you could participate to the discussions, it s a simple first step after all. True enough. That said, it s not as easy as it looks like. There are many mistakes that you should avoid:

1. Don t fall in the trap where your mailing list participation is your sole contribution to Debian. If you want people to give credit to your messages, you should already be doing something else for Debian.
2. Don t participate more than once a day to a given thread. There are many people subscribed, you should leave room for other people to express their point of view. You can always follow up one day after and reply to several messages at once if you believe you still have something new to add to the discussion.
3. Don t reply to off-topic threads. Someone asked a simple question and someone else pointed out that his message was off-topic. Don t reply, or if you really need to, do it on the correct list or with a private response.
4. Don t ask questions unless it s useful to bring the discussion forward. Development lists are not here to fill the gaps in your knowledge. We already have debian-mentors for this. Furthermore there s no better way to learn than to find yourself the answers to your questions.
5. Don t believe your opinion is so important. We re all very opinionated and discussions that consist only of contradicting opinions tend to go nowhere. Thus don t give your opinion unless you can back it up with new facts or another experience.
6. Don t participate to all threads. There are surely some topics where you are more knowledgeable than others, participate where you add the most value and leave the others threads to the other experts (and learn by reading them).
7. Don t hide your identity. In Debian we like to know each other. Use your real name and not some anonymous nickname. You need to be able to stand up behind your words, otherwise you re not credible.

I have myself been guilty of several of those when I started I invite you to follow my recommendations to ensure our mailing lists remain pleasant to read and an effective discussion place.

You should follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.

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

One of the reasons I like Scotland is the fun that Scottish people have with language. I'm going to use two examples to illustrate my point:

• "Mind" is often used as "Remember"
• "How" is often used as "why".

The last one is particularly fun when you use questions such as "How no?" - meaning roughly "Why not?". Languages, and idioms, vary wildly in different parts of the world, even when you restrict yourself to English-speaking languages. I'll not even get started on Accents. The UK is tiny compared to many other countries, yet we have a wide array of accents - Australia, by contrast is huge, but I can think of only two accents across the country. (Rationally I expect that there are many accents in different parts of Australia, and I'm merely ignorant.) In conclusion languages are fun, and some places this is more evident than in others. I will most likely contintue to say "The shop is open from 9 while 4" rather than the more typical "From 9 til 4" - I'm allowed to do that, having grown up in Yorkshire!

(PS. PHP still sucks - Even if you post it upon a PHP-powered blog. ;)

ObQuote: "People take you for granted, you know. We gotta make people miss you." - Hancock

A bug-fix release RQuantLib 0.3.6 is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. There are only two changes to two files where an explicit conversion as per Rcpp::as<double> was called for. A Debian archive rebuild had triggered one of those fails to build from source bug reports as the compiler version seems to be more finicky now than when version 0.3.5 was uploaded in November. No other changes were made. Thanks to CRANberries, there is also a diff to the previous release 0.3.5. Full changelog details, examples and more details about this package are at my RQuantLib page.

What Yes, I have not used this kind of outfit for over 20 years. And I hope it will be 20 more years before I do it again. But today, I was seen like this in public. Why? Well, I won't explain the whole background yet again I did it a bit over a month ago in this same space. Much much in short, I never attended university, so after many years of working without any formal validation for my knowledge I followed the CENEVAL Acuerdo 286 procedure to get a "Software Engineering" title and the corresponding c dula profesional. Today I did the last portion of this procedure: Presenting an oral exam, defending the work I developed. Not precisely a thesis, but you can see it as an equivalent. One of the requisites was to go on formal attire Of course, I have some beautiful shirts I am very fond of, but I didn't want to risk it to such a detail, so I asked my friend and almost-neighbour Miguel Barajas to lend me the needed bits of clothing, and presented the exam. Was it easy? No, not by a long shot. Did I pass? Yes! Now, back to work!

git-annex is a recent tool allowing to manage files with git without having theirs contents checked into git. I've been looking at it with some interest in the past few weeks in order to use it to handle my music collection on the various computers I use. My laptop just got a new SSD drive which is quite small and cannot handle the whole collection. By using git-annex, I'm now able to only check out part of my music collection and keeping it synchronized with all my others computers. Using git-annex is pretty trivial once you understand the concepts. I've set up a a git repository in my Music directory, like that:

% git init
Initialized empty Git repository in /home/jd/Music

Then I initialized git annex:

% git annex init "Music on keller"

So now I'm able to import all my date into git annex. git-annex offers several backends to store data. WORM is the default, but is not a good choice for file that could be modified, and music files can be, at least when editing the metadata. Therefore, I chose the slow but more reliable SHA1 backend.

% git annex add --backend=SHA1 .

That can be long, so you should be patient. Then you should commit the fact you annexed files:

% git commit -a -m "Imported my music collection"
[master 82d060f] Imported my music collection

Now, it's done. You can go on another computer and clone the repo:

% git clone ssh://keller/~/Music
% cd Music
% git annex get "Incubus - Light Grenades"

And then let the magic happens. It will retrieve the whole directory for you. Do not forgot to commit the fact that you got those album on that machine! The concept used by git-annex is quite simple. All files are replaced by symlinks pointing to .git-annex/SHA1:filechecksum.log. This file contains lines, whose format is:

retrieval-timestamp is-file-present uuid-of-the-repository

Indicating if the file is present in a repository. This logs file are commited into the repository, whereas the real content is stored in the .git/annex directory and therefore not commited. I recommend to take a look to the walkthrough page to get more idea and what you can and cannot do with git-annex.

Yesterday I had my last day at $company and today is my first day in freedom. I'll write about my future plans in another blog post. Here I just want to express the joy I had yesterday afternoon when I did:

I've started using PHP in 2006 and used it almost exclusively until the end of 2009. I believe I've learned most of what one can learn about PHP in this time. In 2010 I started to work in Java and only started to understand how limited PHP is.
I know that java is far from perfect. So I don't stop there and already started to learn Scala and looking forward to learn other languages too. But Java is for sure a better answer then PHP, regardless what the question was.
There are many reasons, why you should not, never, for no project ever use PHP. I'll only tell you my personal top reasons:

• PHP is neither strictly nor statically typed. I fail to see any advantage in dynamic typing. But there are many advantages in compile time checks, automatic refactoring, call hierarchies and many other goodies that every IDE gives you for java.
• The first time I introspected a running JVM with jconsole and could peek into the inner workings of my application, I knew that PHP is a childish language. The JVM is great, its tool support is great. PHP does not give me nearly as elaborate development tools as the java world.
• PHP5 copied its object orientation syntax from Java (at least it looks like this). PHPUnit is a great tool (thank you SB!), but it's still only a very good copy of JUnit. Why not just use the original?
• PHP is typically choosen because initial development is very cheap. PHP programmers are much cheaper then java developers and you can move faster with PHP. The resulting projects however become a mess of unmaintainable code sooner or later. Nobody wants to work on the code anymore and shops with such PHP code burn one developer after the other to keep the crap running.

I once advocated PHP as a serious plattform and even gave three talks about PHP. I feel ashamed of this now and apologize. Please forgive me. It's not worth arguing about this post. Its just to make me feel less guilty about my foolishness in the past.

My server, which is among other things hosting this weblog, is a dedicated server originally hosted by the German webhoster webperoni. It was a bargain at that time, and still a good price, and I was satisfied with webperoni s performance and reliability. Unfortunately, they were taken over by another web hosting company, best known for their server4you brand. They moved my server to a different data center and continued to run it there. Unfortunately, server4you was less reliable and less flexible than my original hoster: For example, when one sector on the hard drive turned bad, they were not able to put in a new drive in my system, let me mirror the content, and then remove the old drive. In another, even worse, instance, my second IP address, which I bought from webperoni, was given to another customer. When I finally noticed and complained, they refunded me the charges that I paid for the IP. But understandably, I wanted to get away from that hoster. The contract is automatically prolonged for one year if not canceled in time, and I missed the deadline last year. This year, I finally got around to rent a slightly better and slightly more expensive server from Hetzner, which whom I already made good experience. I would have preferred to switch when I am back from India, but server4you would not even let me prolong the contract by just two months only a whole year or nothing. So they got nothing, and I started to work on the move yesterday. At first I set off installing the new system from scratch, setting up all the various services and copying over data and configuration. But quickly, I gave up and moved the system by completely by copying programs, configuration and data from the old server. The new system has its root partition on a LVM share on software RAID, and now uses grub2 to boot. I had a hard time to get it booting, and a hard time to debug the issues without access to the physical console. I finally understood the problem by running kvm -hda /dev/sda -hdb /dev/sdb -curses from the recovery system and observing that the initial ramdisk is having problems finding the root partition. The problem was that I thought addressing partitions via file system labels is the way to go now and manually added root=LABEL=root to the Linux command line in /etc/default/grub. But then the initial ramdisk would not activate the logical volume. If I had just left it to the grub package, which inserted root=/dev/mapper/vg-root, everything would work fine. The new IP address (88.198.48.143) has not propagated throughout the Internet yet. Running the following command for a variety of ports on the old machine (80.86.81.20) makes sure nobody notices:

port=443
iptables -t nat -A POSTROUTING -p tcp --dst 88.198.48.143 --dport $port -j SNAT --to-source 80.86.81.20
iptables -t nat -A PREROUTING -p tcp --dst 80.86.81.20 --dport $port -j DNAT --to-destination 88.198.48.143:$port

The only question remaining is: What to do with the old server for the remaining six weeks? I am considering to erase the system, set up a plain Debian system and run a tor/freenet/whatelse node at full speed.

At the Emdebian ARM sprint, cross-building experiments on a Multi-Arch base are going fairly well. It is looking like the hacks in dpkg-cross may finally be avoidable, possibly before Wheezy gets released. Elsewhere, debhelper has been updated to allow dh_strip and other tools to work directly with the binutils package from the cross-building toolchain and not to need binutils-multiarch any more. dpkg-cross has been updated to only Suggest binutils-multiarch, which makes room for more architectures to be covered by binutils-multiarch (which, therefore, will be getting quite a lot bigger quite soon).

Cross-building in Debian is therefore entering a period of transition and the old ways of dpkg-cross - and the tools it has spawned like apt-cross, xapt, pdebuild-cross and others - will be gradually side-lined and finally rendered obsolete. Like all transitions, there will be breakage, there will be pain, there will be things which don't cross-build now and which have no prospect of being fixed until the transition is deeply entrenched. There are packages which used to cross-build and which will stop cross-building and, again, won't be fixable for months. Sadly, Squeeze released with cross-building breakage too, due to changes within apt during the release freeze. A Lenny chroot is possibly the best place to do cross-building for now.

This is a major transition. It WILL break things. Badly and often.
What's more, just because we decide to implement stuff using one method now does not mean that the same method will even exist in a month or two.

In other words, if you've got a working cross-build chroot or installation currently and you absolutely need it to continue working leave it alone.

Don't go changing real packages to use the changes we're trying out!

If you enjoy fixing stuff, don't mind pain and fancy risking your system as I've been doing (unlinking /etc/, deleting /lib64 on amd64 or forcing package installation such that no shared libraries are accessible any longer) then you are:

1. insane
2. welcome to join the work

Check out the current state of things via the #emdebian channel on oftc.net and the very risky Emdebian multiarch SVN experiments along with the even more risky Emdebian Multiarch Mirror, courtesy of Steve McIntyre and Phil Hands.

The README in SVN is very clear - DON'T INSTALL THESE OUTSIDE A CHROOT and even if you do, don't come crying to me when it breaks your entire system (even when used inside a chroot).

No warranty, no guarantees, no promises, none of this is fit for any purpose whatsoever and we'll say when we finally have something which might actually be useful.

I've been very quiet on here for a few months, and the reason is (of course) because I've been doing other things. No surprise there, I guess! What I've been doing, first of all, is writing aCal, an Android CalDAV client with a lot of help from Chris Noldus. It's probably fair to say that Chris did most of the heavy lifting while I learned Java, did most of the UI & graphic design, and the low-level CalDAV synchronisation and geeky calendaring code. This is now available in the Android market for NZD$2.00 to help us fund further development and in a few days (or a couple of weeks) I'll get the source code up somewhere public (probably Gitorious) and it will be licensed GPLv3... When I get a moment - although refer to title :-) Of course on top of that I'd already committed to a second year of handling the sponsorship job for Linux.Conf.AU, so a fair amount of January was taken up with preparing for, and attending LCA in Brisbane where I took a lot of photos. LCA was, as always, a blast, and all credit to the fantastic team over in Brisbane who really came together when it seemed it was all going to fall apart after the flooding. This seems to be six long months of disasters around this part of the world, although until Tuesday I guess we thought we'd escaped the worst of it in New Zealand. After LCA I snuck home for a few days before flying off in the other direction, to UC Berkeley, for CalConnect XX where I managed to get in some great testing of the new Android CalDAV client, some excellent standards discussions, more photos and (even) a few days sightseeing. I've been home for a week from that now - just barely long enough to hug the kids, really - and today I am in the air once more, off to CeBIT in Hannover where I have been lucky to be sponsored a free booth in the Open Source Lounge by Linux New Media AG. My original travel sponsor slipped through the cracks, but I was fortunate that InternetNZ agreed to help fund me instead. If you're coming to CeBIT please do stop by the Morphoss table in the Open Source Lounge (Hall 2, F40) for a chat about DAViCal and Android - and anything else you want to talk about! I'll be there all week :-) And if I have some quiet time in that week (yeah, right!) I'll be trying to push out a new DAViCal release, which is overdue really, since the last one was two months ago.

I ve recently got a new Xperia X10 Android phone for my with with Virgin mobile, it s generally been working OK although I am having some issues [1], I ll write another blog post soon about other problems I ve discovered with the phone and how I ve solved some of the previous ones.I upgraded my wife s phone first because I can t be without Nagios SMS messages if things don t work. So now that things are generally working I want to get myself an Xperia through Virgin (and have my wife s phone get the Nagios SMS in the mean-time). But since last Friday the entire Virgin sales infrastructure has apparently been down. It started with just declining my attempts to purchase a new phone on a separate account, but when I decided to add a second phone to my wife s account the web site told me that they are upgrading their CRM system and it should be fixed on the 22nd of Feb (yesterday). The web site is now saying that I should check back in 2 hours for an update , it s been saying that for a couple of days now.So for most of a week potential Virgin customers have been turned away. It could be that Virgin stores are processing sales on paper, but they offer some significant discounts for web sales the plan I want is a $39 per month plan and I ll get 3 months free for buying on the web. I m not about to visit a store and lose $117! I m sure that many people are losing confidence in Virgin and taking their business elsewhere. I have only just installed the 3G Watchdog free Android app that monitors bandwidth use and automatically turns off 3G when the quota is reached. For the first few days of using the phone which were more data intensive than usual I had no monitoring and no way of using the Virgin web site to discover how much was used. If Virgin bill me extra for data use I ll complain and demand that they alter the bill.This is even worse for pre-paid customers who can t add credit to their account while this happens!Virgin state that they are upgrading the hardware, operating system and database our platform uses to ensure that we can service our Members even better for years to come [2]. I wonder how people get themselves into such a mess. I guess they didn t have a decent test environment to allow testing the upgrade process before doing it on the live data, I can understand a routine small upgrade going wrong and corrupting data in a way that takes some time to resolve. But when everything is upgraded then everything should be tested, and tested before going live! One thing that Virgin could do to regain some credibility is to publish what went wrong and what they learned from it. I would be much more happy to trust my personal data and my business critical phone to a company that learns from it s mistakes and publishes plans on how they do better than one that just does PR.According to Whirlpool they did the same thing on the 25th of January, so they have had two outages of their billing/CRM system in two months! [3]. The Whirlpool thread has discussion about last month s down-time and this month s down-time.On the up-side, Whirlpool user Kevin JD is a Virgin representative who advised customers to send email to telesales@virginmobile.com.au with a contact phone number if they have any issues. It s good to see a company engaging with it s customers.Update: An hour after emailing the URL to this post to Virgin I got a call from a service representative. It wasn t a very productive call as I already knew that their servers are down and they can t do anything. But it s good to know that they are very enthusiastic about making things better. One useful thing that I learned is that my wife s service is probably on a pro-rated bandwidth quota. As she got the phone in the middle of the month we can only do 100M of data transfer not 200M before the end of the month, by my rough calculations I ve downloaded well over 50M of data (maybe as much as 100M) from the Android marketplace. So it might be necessary to negotiate about the bill as soon as their CRM system works.

• [1] http://etbe.coker.com.au/2011/02/18/xperia-x10i-first-experience/
• [2] http://www.virginmobile.com.au/upgrade
• [3] http://forums.whirlpool.net.au/forum-replies.cfm?t=1626553

The interview at Munich seemed to go well. Well, at least, I had fun. We'll see how that turns out.

For now, I'm off again for another job interview, this time to Palo Alto. This will be my first time to the West Coast, so I have postponed the return flight for two weeks to familiarize myself with the proverbial area. If anyone's from around the San Francisco Bay Area, I would be very happy to meet over lunch/dinner/beer!

Another week is over and it's time to look again at state of translations for phpMyAdmin 3.4. Compared to last week, there one new translation at 100% this week, thanks to Dutch translators. We now have nine translations at 100%:

• Czech
• English (United Kingdom)
• Dutch
• French
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are three which were close last week, but are still not at 100%:

• Greek
• Chinese (China)
• Catalan

Was your language not listed? You can help it being better!

Filed under: English Phpmyadmin 0 comments Flattr this!

After almost six years from the original ITP bug #304570, we finally have Code::Blocks in Debian. Enjoy it, and please report any bug you might find. Also, this is a complex package, so if anyone wants to step up as co-maintainer, or maybe make a "Debian Code::Blocks Team", I'm all for it!

Okay, I finally decided it's about time to make Debian package out of German-Czech dictionary for which I'm providing builds for StarDict. Daily snapshots are (as usual) available in my Debian repository and the monthly builds will be uploaded to Debian (once it passes NEW queue). The dictionary currently lists only few words, but I hope it will improve in near future.

Filed under: Debian English Stardict 0 comments Flattr this!

Short version: Dear FSF, thanks for your appreciation of Debian Squeeze achievements in getting rid of non-free firmware blobs. We still disagree on the overall freeness assessment of Debian, but I'm positive that steps like this one can further future collaboration, in the interest of both projects. Long version follows.

---

Historically, the relationships among Debian and the FSF have gone through mixed fortune (and that's quite an euphemism). On the one hand, Debian is committed to 100% Free Software, is an open project explicitly inspired by "the spirit of GNU", has been sponsored by FSF in its infancy, and properly calls itself "GNU/Linux" (or even "GNU/kFreeBSD"). On the other hand, Debian is the project who considers the GNU FDL license to be only conditionally free and which is not considered to be an entirely Free system according to FSF.
So much for the history corner. As a long time member of the Debian Project, as well as an FSF(E) fellow, I've always felt a bit sad about this state of affairs. Not because the two projects should have aligned goals; they clearly focus on different aspects of the quest for a Free (Software) world. Not even because they should agree on how to build a Free distribution: history has shown that FSF technical positions do not always get along with Debian's more "pragmatic" style, as embodied by point 5 of the Social Contract. Rather, my sadness is rooted in the belief that not getting along have encouraged duplication of efforts which could have been easily avoided (e.g. multiple distributions concurrently freeing up kernels). Furthermore, I'm more and more convinced that Debian nowadays enjoys a rather privileged position among Free Software vendors. Indeed, even though GNU/Linux distributions have reached a popularity we didn't dare to imagine 15 years ago or so, most distributions are under the direct or indirect control of commercial vendors. Those commercial vendors play a very important role in the promotion of Free Software. For instance, they are structured in ways that enable them to seal OEM deals with hardware manufacturers to sell computers with GNU/Linux pre-installed. Commercial vendors, by their own nature, are also in general better at marketing than non-commercial vendors. On the flip side however, commercial vendors are not yet relevant enough to drive proprietary drivers out of the market and, as a consequence, cannot yet afford not to support hardware which need such proprietary bits to work. Among mainstream GNU/Linux distributions[1] Debian is one of the very few vendors if not the only one that is both very relevant and, thanks to its independence, can afford taking Free Software's side: no commercial urgency can force Debian to negotiate on that. That is quite an asset to be used in the promotion of Free Software, especially to a public that is interested in and willing to understand what Free Software really is about. Such an "aware" public is on the rise as of lately, together with the general awareness increase of risks entailed by living a digital life, when that life is not under our control (think, as an example, at how often the "Facebook privacy debate" has hit mainstream medias in the last year). The "aware" public is the natural target of both Debian and the FSF. Dividing it would not serve well the cause of Free Software. With all that in mind, last August I took the chance of being on the "right" side of the Atlantic Ocean for DebConf10, to discuss possible venues of collaboration among Debian and the FSF. I sat down and discussed at length with John Sullivan, who I happen to know for his Debian involvement, in his capacities of FSF representative and operations manager. We discussed various topics, with the intention of bringing them up to the respective communities[2]. Then, inevitably, we ended up talking about the overall freeness of Debian and his exclusion from FSF listing of Free systems. (FSF is of course entitled to such judgements, pretty much as Debian is entitled to its own judgements on FSF licenses. Nevertheless those judgements contribute to dividing our public and might lead to wasteful duplication of efforts, where Free Software could better be served by collaboration.) The main ground for exclusion from that list used to be the compromises Debian has made in the past about non-free firmware blobs. But, as I pointed out back in August, those compromises would have been gone starting with Squeeze, making that argument moot. Today 6 months later I'm delighted to cheer at FSF's decision to publicly recognize the achievements Debian has delivered with Squeeze.
Thanks! It's a nice gesture that I've very much appreciated. I'm confident steps like this one will help future collaboration if, on both sides, we will be able to spot actual venues for collaboration. Needlessly to say, I still disagree with the overall FSF assessment of Debian non-freeness. Apparently, it still stands on the basis that Debian also provides a repository of nonfree software [ ] [which] is not part of the Debian system. [ ] but users would be hard-pressed to make a distinction and that people can readily learn about software available through it by browsing Debian's online package database. I respect the principle of non advertising non-free software and I even agree that it is a good principle. But unfortunately it's also a very blurry principle on which, in my opinion, Debian actually scores very well. No non-free software is offered to users by Debian; it's just for users that really want to have non-free software (or need to, in order to run a Free OS on their computers), that Debian tries to stay out of their way. For the "aware" public discussed above, I think it's much better to draw the line where software freedom ends and use that line to explain what does crossing it entails, than locking them up pretending non-free software do not exist. But fair enough: for the time being, I guess, we will need to agree to disagree on this one. Getting a little bit closer in the occasion of the Squeeze release is still an important step forward. It's up to each of us now to seek out initiatives which attract the interest of both projects and that can benefit from synergies.

---

[1] Sorry, I've no decent definition of "mainstream distribution" to offer, besides folklore and well-established distribution review sites. (Heck, I don't even have a decent definition of "well-established distribution review site" to offer!).
[2] which hasn't happened yet, due to the proverbial amount of available spare time.