Jacob really enjoys his pajamas. By this point, he can mostly get himself ready for bed. He still wants help brushing his teeth but that s about it. His favorite pajamas are his rocket ship pajamas , which also cover his feet and have a white pad underneath the feet. That s his favorite part. They have rockets all over them, and he sometimes will run out of a room and inform me with delight, I m all rocket ships! Oliver has really started to form up words. We can pick out words like lettuce, truck, book, look, and dad John . He also has a way of saying there it is , most particularly when looking at trains. Jacob still loves trains. In church, he will take his markers, connect them end to end, and have a marker train that will keep him entertained for quite a long while. He will slide it back and forth on the pew, and eventually it will slide in a tunnel (behind my back). This actually started with hymnbook trains get a few books in a row, and it s a train. Anything can be a train to Jacob. Driving down the road, we might see what he calls tree trains, which are just trees in a row. Last Sunday, the Kansas Mennonite Men s Chorus had its first concert of the season. I sing with this group, which has nearly 300 men in it. It s a lot of fun to be a part of that group, and the music is wonderful. Jacob and Oliver were there on Sunday, and both started to take more of an interest in the music that before. Jacob particularly loved the song Dry Bones, which had a number of odd percussion instruments in it. He was laughing at spots, and wanted to hear me sing it for the next several days. He even wanted Terah to read the program from the concert to him before his nap one day. Oliver enjoyed it too, and kept saying dad John (his word for me) whenever there was a soloist. I didn t sing a solo, but apparently to 1-year-old eyes, 300 guys all dressed alike all look like dad. Jacob and I recently have been reading Winnie the Pooh stories at his bedtime. Not the Disney books, but the original A. A. Milne stories. We read a few pages every night, and have made it to page 214 by now. Jacob loves it. And he s becoming increasingly interested in reading things. Sometimes we ve been unsure if he s reading something or just had it memorized. Last night, I got out the book, and we were on a page he had never seen or heard before. He pointed to a word, and said, It says Roo there! And indeed it did. Then he added, It says said Roo. . Yep. And then he read me the whole sentence:

I love jumping, said Roo.

I believe that s the first time I ve been certain Jacob has read me an entire sentence without having memorized any of it beforehand. And he won t be old enough to start Kindergarten for another year and a half. We then read the story, and when I came to the sentence Jacob had read to me, he interrupted, saying, No, dad, I will read that one! And he did.

This year we had very little snow again. Although winter started (too) early (first snow on October 16th) we topped out at little over 50cm in Au (in December). In a normal winter we should have 1m at least temporarily, and 2m is not a rare. Temperatures were high, too. I was usually wearing a layer less than normally. All this had me riding in Dam ls most of time, Diedamskopf only saw me in December, since they have little artificial snow, and natural one was missing. Summer temperatures (20 C) at start of April cut the season very short. My last snow day was on April 3rd. On the upside I did not hurt myself this year (knock, knock) and the weather was good often. Here is the balance sheet:

	2005/06	2006/07	2007/08	2008/09	2009/10	2010/11
number of (partial) days	25	17	29	37	30	30
Dam ls	10	10	5	10	16	23
Diedamskopf	15	4	24	23	13	4
Warth/Schr cken	0	3	0	4	1	3
total meters of altitude	124634	74096	219936	226774	202089	203918
highscore	10247m	8321m	12108m	11272m	11888m	10976m
# of runs	309	189	503	551	462	449

MeeGo Summit FI is now nearing completion, with several keynotes and other presentations, Meegathon 24h contest just coming to an end and a lot of interesting discussions had. See full program for details. Yesterday was a hugely energetic day, but today the lack of sleep starts to kick in a bit at least for me.

Some highlights via photos:



Keynote venue was a movie theater




MeeGo status update by Valtteri Halla / Intel - talking among else about tablets, IVI, and the 20 person team at Nokia doing MeeGo(.com) for N900 phone





Mikko Terho / Nokia - "Internet for the next billion => Qt good candidate", "code wins politics and standards"




Carsten Munk / Nomovok - "Hacking your existence: the importance of open-ended devices in the MeeGo world"




In addition to MeeGo tablet demonstrations a Wayland compositor was demoed by a Nomovok employee.



One of the many Qt / QML related talks was held by Tapani Mikola / Nokia



Evening party




Day 2 started with a few more presentations and Finhack event launching in the Protomo room as well

Still remaining for the day are Meegathon demonstrations (well actually I'm right now already following those while finishing this - cool demos!) , Meegathon awards, a panel discussion on "MeeGo, Nokia, Finns - finished? Can MeeGo be important in Finland without being inside Nokia's core?", BoF sessions and finally Intel AppUp Application Lab including some MeeGo table give-outs.

Thanks to organizers, many of whom were volunteers. The event has been running completely smoothly, coming not as a big surprise after the hugely successful last summer's Akademy 2010 also held in Tampere.

Theres an ongoing thread on the Debian mailing lists about making network-manager installed by default on new Debian installations. I won't say much about the thread. Its just a prototype example for Debian project discussions: Discuss everything to death and if its dead discuss a little more. And - very important - always restate the same arguments as often as you can. Or if its not your own argument you restate, restate the arguments of others. Ending with 100 times stated the same argument. Even if its already disproved.

I don't have a strong opinion about the topic in itself. However there is something I find kinda funny. A statement brought up by the people who strongly oppose network-manager as a default.
A statetement I've heard so often that I can't count it anymore.

The last time I've tried network-manager it sucked.

It often comes in different masquerades, like:

• network-manager is crap.
• network-manager is totally unusable
• network-manager does not even manage to keep the network connection during upgrades

When did you test network-manager the last time?

A long time ago. Must have been around Etch.

Update: I reported the deluge issues and added a new problem about the lack of click on tapping on the touchpad.

---

I know that installation reports and upgrade reports need to be submitted to the BTS, but I just want to point out some issues for people that might hit the same issue on upgrade from lenny to squeeze.

But before that I must say I like the new Debian site(s) look.

Issue number one: When upgrading from lenny's deluge to squeeze's deluge, the new version of the app is quite different from the prevoious version. Here are some things to take into account:

• when starting for the first time the new version it will take ages to check (and probably recalculate some checksums); make sure you don't mind the I/O activity when you start it; a torrent will not be available until this check is done
  
• the new version relies on a client-server model which is disabled if you use the "classic mode" (Edit->Preferences->Interface)
• some features available in the old version are not available in the new version (e.g.: graph for traffic and embedded search function)
• some features are availbale as modules, but there are just a few modules
• when starting the graphical interface in the new mode, don't use the "Start daemon" button, use the "Connect" button. If you start the daemon via the "Start daemon" button the "Connect" button will become "Disconnect" although the client is NOT connected. Using the "Connect" button directly solves the problem.
• There is an ugly side panel (on the left side) which, IMHO has no real function or use, except filtering in the view the active downloads or similar things
• when choosing the place to save a torrent and trying to set that place as the default location, deluge will not remember that setting
• closing now (with the daemon option) the app will close just the client, but the server/daemon will remain in the background, unless is explicitly closed (there is a dedicated menu entry)
  

Issue number 2: I seem to experience some weird glyph/graphic area reshuffling in GNOME (maybe X?) after recovering from hibernate. With a total (according to my current sloppy counting) 5 resumes, things get back to normal, but I suspect the next hibernate-resume cycle will restart the glyph reshuffling cycle.

By glyph/graphic area reshuffling I mean alterations of the shapes of the glyphs (and some areas on the background picture) in such a manner that it seems that within a set of 8/16/N (?) lines are shifted/rotated sideways with some undefined and different ammount each, but in a reproducible manner ("b" will always be doodled in the same way, no matter if is in the word "be" or if is in the word "absurd".

I'll try to provide some picture in the bug report, once I report this issue in BTS.

Update: I reported this in Debian's BTS and upstream (with screenshots, too). I am not convinced the problem is in the kernel since I tried an old kernel and saw the same issue. I suspect X is at fault.

Issue number 3: This is more like a convenience issue. In the past I was using "hibernate" with uswsusp which I understand is now broken beyond repair and replaced by pm-utils. The thing I miss in the hibernate process now is the ability to abort the hibernation process as it was possible in lenny's uswsusp by pressing the backspace key during the storing of the state on disk phase.


Issue number 4: The upgrade process was quite tedious because once I tried upgrading aptitude, python2.6 was pulled in and almost all apps ended up needing upgrading due to the chaining of necessary package upgrades.


Issue number 5: For some weird reason pulseaudio was initially installed making playback of any audio impossible (the apps wanting to emit noises would just freeze but they were TERM-inatable) and later I've seen a default null audio sink was defined for me. Killing pulseaudio and removing the ~/.pulse directory fixed the issue (but I should probably see why pulseaudio didn't work properly in the first place because I suspect the problem will reappear at the next restart - I usually use hibernate).

Issue number 6: Tapping the touchpad no longer results in a click. Maybe some packages got removed? And, no, it is the same when I remove the external mouse, so it is not because of some smart behaviour of that sort.

Otherwise I am quite satisfied with the result of the upgrade. A huge "thank you" to all people involved in the development of squeeze.

Most probably haven't noticed yet but I finished the Mono 2.10.1 debian packaging effort of the past 3 months and uploaded it to Debian/Experimental. With Mono 2.10 I had to make the biggest changes in Mono packaging since the big Mono 2.0 upload. The runtime no longer supports the 1.0 and 2.0 runtime profile, instead it now supports the 2.0 and 4.0 runtime profile. This meant I had to drop all libmono*1.0-cil packages and add libmono*4.0-cil packages. This sounds like a lot of s/1.0/4.0/ work but it actually wasn't. Mono 2.10 ships a lot of new libraries over 2.6 and I had again to decide where they should go. "Where should this $library go?" I have been playing this game for the past 7 years maintaining Mono and I finally gave up on it... What, where, when, why? I could give now a 2 hours talk of the issues behind the current packaging approach (keeping the number of library packages low) but instead I will do something else. Please, just take a look at this picture for a second: If your browser crashed, your eyes hurt or your brain simply melted, I think you have got the idea. The Big Split The cure? cli-common-dev! This is a package that contains 2 extremely important debhelper packaging tools for packaging Mono/CLI related packages called dh_makeclilibs and dh_clideps. If you don't know these, they do exact the same thing as dh_makeshlibs and dh_shlibdeps do. dh_makeclilibs generates library dependency tracking information and dh_clideps consumes that information to automatically generate the package dependencies for you. So each library of the 4.0 runtime profile has now it's own package, simple as that, the rest does cli-common-dev for me and you. "Hey, that Mono packaging bastard is polluting the Debian archive because of his laziness!" No, I am not. This packaging change not only has the advantage of simplifying the packaging and with that bringing new Mono versions faster to you but also reduces the typical install size for applications as they will only pull in the really used libraries of Mono instead of groups of them. I don't have any numbers handy right now as none of the applications are built against Mono 2.10 (yet), but when the transition starts we will get numbers. New Features There is also a new SGen flavor of Mono available called mono-runtime-sgen which is no longer using the conservative non-generational Boehm's garbage collector but SGen which is a simple generational garbage collector with promising advantages. And here some more Mono 2.8/2.10 news from /usr/share/doc/mono-runtime/NEWS.Debian.gz:

• SGen Precise Stack Scanning
• Enhanced SIMD with new methods for Vector data type conversions and swapping elements in vectors
• ASP.NET MVC 3.0 (not included, only supported)
• The C# Interactive Shell can now be used as shebang: #!/usr/bin/csharp
• .NET 4.0 runtime
• C# 4.0 compiler
• ASP.NET 4.0
• Managed Extensibility Framework (MEF)
• System.Data.Services.Client (OData)
• glib was replaced with eglib
• Removed .NET 1.1 runtime

Architecture Regressions With the initial upload of Mono 2.10.1 to Debian/Experimental the architecture world broke apart and it regressed on all Mono architectures except for i386 and amd64 There is a reason it's called experimental isn't there? In mono 2.10.1-3 I could solve all regressions except for kfreebsd-* and armel. Jo Shields fixed the remaining regressions and the world started to look good again in mono 2.10.1-4! He also took care of mono-basic, mod-mono and xsp, but mod-mono and xsp are still waiting for the translation call deadline to pass by so they can also be uploaded to Debian/Experimental. Planned Transition As mentioned above, there will be a Mono 2.10 transition needed when the packages hit Debian/Unstable. There is no ETA yet on this when it will happen as I have to coordinate this with debian-release first. But as things are not showtime ready in experimental anyhow, this will not happen too soonish. The Mono 2.10 transition plan will be covered in a following post. GIVMENOWPLX OMG, all this rumbling about Mono 2.10 and I still haven't said a word on how to obtain it, sorry about this, just do this and I will shut up now:

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get install -t experimental mono-complete

(this is the easiest way of getting only mono 2.10.1 from experimental)

It seems that Project Harmony has finally taken itself public. From the website:

Project Harmony is a community-centered group focused on contributor agreements for free and open source software (FOSS).

In reality, this seems to be a closed group that in no way represents the community in general and mainly acts in the interest of various corporations. Their goal is to create a bunch of templates for contracts to make participating in free software projects even more complicated than it already is. Look, we have a bunch of copyright licenses. They're not always easy to understand, and there's enough details and corner cases and interactions with the real world to make your head hurt. My head as well. (They're still easier, and more standardized, than contracts for proprietary software.) Contributing to a free software project is easy enough, in most cases. You make a patch, and if the project accepts it, yay. Your patch will be licensed the same way as all the other code. These Harmony agreements aim at making you give up your copyright to someone else, usually a corporate sponsor of the project. That's a bad thing. If the corporation owns the copyright, or you give them a license to do anything they wish with the project, they can do all sorts of evil things with it. For example, they can release it under a non-free license, or enter into complicated patent agreement with someone else that will require you to pay protection money later on, or something else. There is no end to the evil corporations invent, when given the chance. If, however, you refuse to give the corporation any ownership, or special powers, then their ability to do evil lessens, or at least you aren't helping them do that. It might be possible to use the Harmony agreements, as they are currently written, in ways that do not directly allow evil. However, why bother? By sticking to well-known, court-tested free software free software licenses, there is no need for the Harmony licenses. You get to keep the corporations honest, without having to read piles more legalese. Another way of looking at this: here's a bunch of corporations that want you to start using complicated legal documents for their benefit. Ask yourself, in what scenario is this going to be a good idea for you? Just say no to copyright assignments.

I'm participating in the MeeGo Summit FI that starts tomorrow, and I'm already in Tampere now, as you can see. The summit is at an interesting time, given that there is a huge amount of stuff happening around MeeGo while at the same time Nokia is balancing on what do both in the far future and what to do to ship the MeeGo device they've already promised. The summit is fully and overly booked for >300 attendees. There is also Finhack free software event happening alongside on Saturday at the same venue.


The company I work for, Nomovok's CEO illustrated the MeeGo situation extraordinarily well a little less than two months ago. I think it's one of the best insights you can get from anywhere in public at the moment. Now things are starting to really heat up. Of course the Big thing is the MeeGo Conference in San Francisco in the end of May, but it takes nothing away from this being the major event both in the country formerly known as NokiaLandia, and also globally given the amount of MeeGo related talent here. Nomovok is teasing people with the SteelRat - a launchpad for MeeGo tablet creation and an UX, based on latest MeeGo Core - a beta of which will be available now in Tampere and first version in San Fransisco. Meanwhile we and others are investing in also the MeeGo IVI and MeeGo TV platforms, not forgetting about the handset industry that is more visible to many tech savvy consumers.


At the same time there is a lot of exciting stuff going on in the Ubuntu project (Ubuntu 11.04 upcoming, I'm already using it and reporting bugs), together with Linaro and other ARM players. As a founder of Ubuntu Finland I'm always eager to see if I can work there also on work time, not only on free time. And regarding ARM, Nomovok is the key player in having ARM on MeeGo as well.

Then on the completely other end of spectrum, I'm eagerly waiting for the GTA04 project to have my Neo FreeRunner(s) bumped up to modern specs. At the end of the day I'm still using over 2,5 year old phone myself, since I want to run the software that is both free and completely selected (and if I want, done) by me. With GTA04, I could choose between MeeGo armv7hl port, Debian armhf port or Ubuntu as the base distribution to use my software.

It seems I'll be at the Lua workshop at Fabelier/tmplab on April 28th 2011, where I'll try to present and talk about Lua, how to use it, and why you should probably not use it. ;-)

We're heading to release candidates for phpMyAdmin 3.4.0 (probably once GSoC application/evaluation rush period is over), so the translators have less time to make the translations better. There is no new complete translation, so we still have 14 translations at 100%:

• Catalan
• Chinese (China)
• Czech
• Dutch
• English (United Kingdom)
• French
• German
• Greek
• Italian
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are still lot of translations which would need some love, for example:

• Finnish
• Norvegian
• Polish

Recently two of our prospective GSoC students started to contribute to translations, so there is great progress in Sinhala and Hindi translations. Looking forward to have these completed soon :-). You can also help make translation to your language better! If your language is missing just let me know (either in comments or by email).

Filed under: English Phpmyadmin 0 comments Flattr this!

A maintenance release 0.2.3 of RProtoBuf is now on CRAN. RProtoBuf provides GNU R bindings for the Google Protobuf data encoding library used and released by Google. The NEWS file entry follows below:

0.2.3   2011-04-12
   o    Protect UINT64 and INT64 with '#ifdef RCPP_HAS_LONG_LONG' which
        itself is valid with either g++ <= 4.4, or newer versions if the 
        -std=c++0x is used
    o   The documentation Makefile now uses the $R_HOME environment variable
    o   The documentation Makefile no longer calls clean in the all target

And courtesy of CRANberries, here is the diff to the previous release 0.2.2:

Diff between RProtoBuf versions 0.2.2 dated 2011-01-12 and 0.2.3 dated 2011-04-13
 RProtoBuf-0.2.2/RProtoBuf/inst/doc/RProtoBuf-quickref.Rnw                      only
 RProtoBuf-0.2.3/RProtoBuf/ChangeLog                                               23 
 RProtoBuf-0.2.3/RProtoBuf/DESCRIPTION                                              8 
 RProtoBuf-0.2.3/RProtoBuf/R/with.R                                                12 
 RProtoBuf-0.2.3/RProtoBuf/cleanup                                                  3 
 RProtoBuf-0.2.3/RProtoBuf/inst/NEWS                                               10 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/Makefile                                       42 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf-quickref.pdf                      binary
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf-unitTests.pdf                     binary
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf.pdf                                1267 +++++-----
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/unitTests-results/RProtoBuf-unitTests.html     20 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/unitTests-results/RProtoBuf-unitTests.txt      14 
 RProtoBuf-0.2.3/RProtoBuf/src/extractors.cpp                                      44 
 RProtoBuf-0.2.3/RProtoBuf/src/mutators.cpp                                        55 
 RProtoBuf-0.2.3/RProtoBuf/src/wrapper_FieldDescriptor.cpp                         24 
 15 files changed, 819 insertions(+), 703 deletions(-)

As always, there is more information at the RProtoBuf page which has a draft package vignette, a 'quick' overview vignette and a unit test summary vignette. Questions, comments etc should go to the rprotobuf mailing list off the RProtoBuf page at R-Forge.

R 2.13.0 will be released tomorrow. It contains a new package by R Core member Luke Tierney: compiler. What a simple and straightforward name, and something that Luke has been working on for several years. The NEWS file says

    o Package compiler is now provided as a standard package.  See
      ?compiler::compile for information on how to use the compiler.
      This package implements a byte code compiler for R: by default
      the compiler is not used in this release.  See the 'R
      Installation and Administration Manual' for how to compile the
      base and recommended packages.

so the compiler is not yet used for R's own base and recommended packages. While working on my slides for the upcoming Rcpp workshop preceding R/Finance 2011, I thought of a nice test example to illustrate the compiler. Last summer and fall, Radford Neal had sent a very nice, long and detailed list of possible patches for R performance improvements to the development list. Some patches were integrated and some more discussion ensued. One strand was on the difference in parsing between normal parens and curly braces. In isolation, these seem too large, but (as I recall) this is due some things 'deep down' in the parser. However, some folks really harped on this topic. And it just doesn't die as a post from last week demonstrated once more. Last year, Christian Robert had whittled it down to a set of functions, and I made a somewhat sarcastic post argueing that I'd rather use Rcpp to get 80-fold speed increase than spend my time argueing over ten percent changes in code that could be made faster so easily. So let us now examine what the compiler package can do for us. The starting point is the same as last year: five variants of computing 1/(1+x) for a scalar x inside an explicit for loop. Real code would never do it this way as vectorisation comes to the rescue. But for (Christian's) argument's sake, it is useful to highlight differences in the parser. We once again use the nice rbenchmark package to run, time and summarise alternatives:

> ## cf http://dirk.eddelbuettel.com/blog/2010/09/07#straight_curly_or_compiled
> f <- function(n, x=1) for (i in 1:n) x=1/(1+x)
> g <- function(n, x=1) for (i in 1:n) x=(1/(1+x))
> h <- function(n, x=1) for (i in 1:n) x=(1+x)^(-1)
> j <- function(n, x=1) for (i in 1:n) x= 1/ 1+x 
> k <- function(n, x=1) for (i in 1:n) x=1/ 1+x 
> ## now load some tools
> library(rbenchmark)
> ## now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
     test replications elapsed relative
5 k(N, 1)           10   9.764  1.00000
1 f(N, 1)           10   9.998  1.02397
4 j(N, 1)           10  11.019  1.12853
2 g(N, 1)           10  11.822  1.21077
3 h(N, 1)           10  14.560  1.49119

This replicates Christian's result. We find that function k() is the fastest using curlies, and that explicit exponentiation in function h() is the slowest with a relative penalty of 49%, or an absolute difference of almost five seconds between the 9.7 for the winner and 14.6 for the worst variant. On the other hand, function f(), the normal way of writing things, does pretty well. So what happens when we throw the compiler into the mix? Let's first create compiled variants using the new cmpfun() function and then try again:

> ## R 2.13.0 brings this toy
> library(compiler)
> lf <- cmpfun(f)
> lg <- cmpfun(g)
> lh <- cmpfun(h)
> lj <- cmpfun(j)
> lk <- cmpfun(k)
> # now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
9  lj(N, 1)           10   2.971  1.00000
10 lk(N, 1)           10   2.980  1.00303
6  lf(N, 1)           10   2.998  1.00909
7  lg(N, 1)           10   3.007  1.01212
8  lh(N, 1)           10   4.024  1.35443
1   f(N, 1)           10   9.479  3.19051
5   k(N, 1)           10   9.526  3.20633
4   j(N, 1)           10  10.775  3.62673
2   g(N, 1)           10  11.299  3.80310
3   h(N, 1)           10  14.049  4.72871

Now things have gotten interesting and substantially faster, for very little cost. Usage is straightforward: take your function and compile it, and reap more than a threefold speed gain. Not bad at all. Also of note, the difference between the different expressions essentially vanishes. The explicit exponentiation is still the loser, but there may be an additional explicit function call involved. So we do see the new compiler as a potentially very useful addition. I am sure more folks will jump on this and run more tests to find clearer corner cases. To finish, we have to of course once more go back to Rcpp for some <emph>real</emph> gains, and some comparison between compiled and byte code compiled code.

> ## now with Rcpp and C++
> library(inline)
> ## and define our version in C++
> src <- 'int n = as<int>(ns);
+         double x = as<double>(xs);
+         for (int i=0; i<n; i++) x=1/(1+x);
+         return wrap(x); '
> l <- cxxfunction(signature(ns="integer",
+                            xs="numeric"),
+                  body=src, plugin="Rcpp")
> ## now run the benchmark again
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           l(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
6   l(N, 1)           10   0.120   1.0000
11 lk(N, 1)           10   2.961  24.6750
7  lf(N, 1)           10   3.128  26.0667
8  lg(N, 1)           10   3.140  26.1667
10 lj(N, 1)           10   3.161  26.3417
9  lh(N, 1)           10   4.212  35.1000
5   k(N, 1)           10   9.500  79.1667
1   f(N, 1)           10   9.621  80.1750
4   j(N, 1)           10  10.868  90.5667
2   g(N, 1)           10  11.409  95.0750
3   h(N, 1)           10  14.077 117.3083

Rcpp still shoots the lights out by a factor of 80 (or even almost 120 to the worst manual implementation) relative to interpreted code. Relative to the compiled byte code, the speed difference is about 25-fold. Now, these are of course entirely unrealistic code examples that are in no way, shape or form representative of real R work. Effective speed gains will be smaller for both the (pretty exciting new) compiler package and also for our C++ integration package Rcpp. Before I close, two more public service announcements. First, if you use Ubuntu see this post by Michael on r-sig-debian announcing his implementation of a suggestion of mine: we now have R alpha/beta/rc builds via his Launchpad PPA. Last Friday, I had the current R-rc snapshot of R 2.13.0 on my Ubuntu box only about six hours after I (as Debian maintainer for R) uploaded the underlying new R-rc package build to Debian unstable. This will be nice for testing of upcoming releases. Second, as I mentioned, the Rcpp workshop on April 28 preceding R/Finance 2011 on April 29 and 30 still has a few slots available, as has the conference itself.

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now. I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there s lots of work left. Instead Roland Mas gently answered me Sooner if you help . First steps as a GNOME packager This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org. Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance. Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version usually 2.91 in experimental, but some are still at 2.30). Packages updated and problems encountered (You can skip this section if you re not into GNOME packaging) So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment. Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log. Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem. In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus. Help is still welcome There s still lots of work to do, you re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don t know). Installation of GNOME 3 from Debian experimental You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you re ready to invest some time in understanding the remaining problems. It s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues). To help you out with this, here s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500
Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it s better than nothing. I hope you find this useful. I m enjoying my shiny new GNOME 3 desktop and it s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

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

This is the tenth Debian XSF News issue. It is basically meant to be a follow-up to DXN#9.

1. I completed the addition of the Sinhala language, and also dealt with big changes on the xkb-data (a.k.a. xkeyboard-config) side, as explained by Sergey Udaltsov. Protocol:
   • [KiBi] x11proto-core: the upload to experimental was a bit overcautious, so upload again unstable.
   Data:
   • [KiBi] xkb-data 2.1: been in experimental for a while, changes were announced to debian-boot@ unstable.
   • [KiBi] xkb-data 2.2.1: new upstream release, which breaks older libx11-6; also announced to debian-boot@ experimental.
   Library:
   • [KiBi] libx11: new upstream release, adding support for Sinhala unstable.
2. The Graphical Installer started receiving improved portability. There were a few patches floating around adding udebs for generic drivers for non-Linux architectures. I cleaned them up a bit (especially on the vesa side, getting rid of libdrm entirely), got them test-built on a kfreebsd-amd64 box, while Samuel Thibault was doing the same on a hurd-i386 box. I raised the topic on debian-boot@, debian-bsd@, and debian-hurd@, mentioning the remaining steps. Drivers (all accepted by ftpmasters after a tiny trip to the NEW queue):
   • [KiBi] xserver-xorg-input-keyboard experimental.
   • [KiBi] xserver-xorg-input-mouse experimental.
   • [KiBi] xserver-xorg-video-vesa experimental.
3. Here are some other packages which got updated. Applications:
   • [Julien] x11-xserver-utils: Julien did everything for DSA-2213 unstable, squeeze-security, lenny-security.
   Library:
   • [Chris,Julien,KiBi] mesa 7.10.1: long-awaited upload, finally checked, built, and uploaded experimental.
4. Finally, let s mention migration to testing (from now on I ll use testing instead of wheezy so that it s clear it s about week after week migrations to the testing distribution, rather than our final plans for the next stable release). After a while, and thanks to some hand-holding from our nice release managers (hi, Adam!), linux-2.6, libdrm, mesa, xorg-server, and several dozen drivers migrated to testing. Yay!
5. As a consequence, some other packages got updated shortly after the successful britney run (because they were prepared right before, just in case). Libraries:
   • [KiBi] libdrm: replace 2.4.23 with 2.4.24 (which was in experimental previously) unstable.
   • [KiBi] mesa: new stable release, 7.10.2 supersedes both 7.10 in unstable and 7.10.1 in experimental (see above) unstable.
   • [KiBi] pixman: new development snapshot, 0.21.6 comes from experimental and supersedes 0.21.4 unstable.
   Drivers:
   • [KiBi] xserver-xorg-input-vmmouse: new upstream release, functionally the same as the last release candidate unstable.
   • [KiBi] xserver-xorg-video-ati: new upstream release, was waiting for the migration to happen, see second bullet of DXN#9 unstable.
   • [KiBi] xserver-xorg-video-intel: new upstream release, same story as for the ati driver unstable.

As already blogged by Riku, getting replaced by script is really great! Until now, I ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part. Since we no longer have to worry about this boring and time-consuming task, I ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration. After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:

~s "Bug#.*FTBFS" ~P ~d 01/04/2011-

(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.) Figuring out whether that s due to another package s bug, an outdated chroot, a temporary glitch, etc. might take some time; that s why it s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I d be very happy if maintainers could at least check what s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

About a week ago, I wrote about doing cross package checks in Lintian. At that time I had only played with looking up manpages in direct dependencies, which I hope will greatly improve the current binary-without-manpage stats (around 677 packages and 2750ish tags incl. overrides). Today, I decided to take on another challenge. Detection of circular dependencies between binary packages (created from the same source). We already have a little library for building dependency relationships; however I ended up not using it, since it has an important limitation. It cannot tell how the circular dependencies relate to each other. Let me demonstrate what I mean with an example. Suppose we have a couple packages that depend on each other like this:
pkg-core => pkg-A, pkg-D
# circle 1: A, B, C
pkg-A => pkg-B
pkg-B => pkg-C
pkg-C => pkg-A # circle 2: D, E, F
pkg-D => pkg-E
pkg-E => pkg-F
pkg-F => pkg-D
In this case, our current tool will be able to tell that all packages (possibly except root I did not check) are in a circular relationship. However, we can find better results by pretending we are trying to find Strongly Connected Components (actually that is exactly what we are trying to do here). So today, I implemented Tarjan s algorithm in Perl to solve this particular issue and committed it to my Lintian branch. If this branch is merged into the Lintian master branch, we can close #316283.

Spammer Number 2:Tata Technologies (aka myigetit.com) via Streamsend Again, it looks like Streamsend are being spamming bastards. Guilty of: spamming lots of Debian mailing lists. They claim to offer "Online Self-Paced Training for Engineers". I guess that's training in "how to be obnoxious to people on the internet" then. It looks like it's a good idea to simply drop all connections from machines in the mailengine1.com domain. Following up through whois, that's another domain owned by EZ Publishing, the same folks who own streamsend.com. Spamming bastards all over...

At about 12:45 today, I completed my third Paris Marathon and my 7th marathon overall (incl. 2 unofficial ones, ran alone). As I wrote earlier, the challenge this year was not breaking a record. I wanted to complete two long races in only two week, as a gift for my birthday that happened between both. So, after Paris Paris Ecotrail 55km race, I ran my beloved Paris Marathon. So, I ended up in 3h54'37", 5 minutes more than last year and 14 minutes more than my personal best The heat was the ennemy, today. A wonderful sun was shining over Paris, which is nice....but brings the temperature up to 23 C. So, the solution had to be "drink, drink, drink". I think I drank something like 4 liters, today. I was planning to start around 5'25/km but finally ended up with about 5'20", which I sustained up to km 25 and the terrible Louvre tunnel (1km in a tunnel on the right bank speedway, under Quai du Louvre). That one was a killer this year and many runners blew up in it. I then decided to use the opportunity to walk a little bit, eat my mid-marathon glucides and slow down slightly later on for the upcoming tunnels (two more...though less long). That was in some way the famous 30km wall, which, for me, was moved to km28..:-) Later on, as usual, courage enters the game and I roughly managed to keep a 5'30"-5'45" pace up to the end of the race. Cramps signs appeared around km 35 but, here again, a wise slowdown and some walking, a lot of drinking helped me in controlling them. Finally, the result is about what I intended to do. Over 4h, I would have been disappointed even if happy to finish (as everybody tells me that my challenge was kinda crazy). Abandoning would have been the real defeat. I did not..:-) And, thanks, of course, to my beloved Elizabeth who again managed to deal with his "Kiki" logistics, includiung waking up at 6am on a Sunday. Now, my running schedule will slow down a little with only training for 5 weeks. Next race: Trail des Cerfs, a 35km trail in Rambouillet Forest close to home. I may again schedule a solo marathon, at training pace, end of May, in Versailles Castle park. Next marathon: Berlin, Sept 25th. Here, the goal is breaking the personal best and head up to 3h35.

I d like to paint you a picture of the sorts of things that have been going on around here the past few months, and with growing fervor the past few days. I ll start with church basements. Possibly a little chilly, but with a bunch of women getting together to make some quilts along with some conversation, maybe some snacks. Or perhaps about hundreds of kitchens throughout Kansas, warm with baking pies, cookies, breads, and all sorts of items. Then there are a bunch of wood shops, turning up sawdust, building things from toys to furniture. Or even a body shop donating its time and materials to put some finishing touches on a classic car. I ve also seen around 300 men getting together to practice for a men s chorus concert. I know there was large crowd of people gathering to make verenike. People always wind up running 5km on a particular Saturday morning, rain or shine. Or ride 35 miles on a bicycle on a different Saturday. Or even help build a house using as much volunteer labor and donated materials as possible. And then, of course, comes this week, where Mennonites from all over Kansas start to converge on Hutchinson, KS. I can imagine you might see some odd sights rolling down the road: a vehicle called the borscht buggy for preparing large quantities of the delicious soup. Several old tractors being hauled down the road on trailers. Semi loads of food. Vanloads of pie and cookies. Plants, trees, rugs, quilts, even a lawn mower. And then, yesterday and today, excited people ready to buy all of these things. Families with children excited to get a ride on the largest slide they ve ever seen. And, of course, so many people wanting to eat the famous food that, despite the many parallel serving areas, lines still can extend for blocks. It s all because people are hungry. Not these Kansans with pie-laden kitchens, though it s to help those in need. It s all part of the annual Kansas MCC Relief Sale. The idea is that people make, bake, build, sing, or give things to the sale. The items are then sold, and the proceeds go to Mennonite Central Committee, one of the world s most efficient charities. MCC not only helps with directly bringing people out of hunger, but also supports sustainable projects, such as building hand-operated wells to give those in need a safe source of drinking water. Virtually all of the money you spend on those pies winds up helping someone in poverty. Each year, the relief sale and related events raise around half a million dollars for charity. It s not unusual to see a quilt sell for thousands of dollars. Most of the things sell at more normal prices, but last year someone decided to add a loaf of bread to an auction and it sold for $100. And so it was this that we took the boys to today. We started with the Feeding the Multitude a wonderful meal with some traditional Kansas Mennonite food. Here s a photo: That bread is zwieback, then there is cherry moos, bohne berrogi, verenike, and of course, sausage. Here are Jacob and Oliver enjoying their food: After that, we went over to the giant slide. I m not sure how many stories tall it is, but it s big enough that they have a strip of carpet there at the bottom to slow people down at the end. Here s a photo of Jacob on my lap after going down the slide. If you zoom in, you can see the giant smile on his face. After that, we hopped on the mass transit at the sale: a wagon being pulled by a tractor. We checked out the general auction, with Jacob wanting to be sure to peer under the hood of each car present. Then after a stop to buy some kettle corn for Jacob, we checked out the plants, quilt auction, and then on to buy cheese curds. After another stop at the slide, it was time to head home. And then tomorrow is a concert of the Kansas Mennonite Men s Chorus (motto: We Sing That Others May Live). You get around 300 men on a stage signing together and wow no recording can do it justice. It s amazing to hear the power of the choir at the loud parts, but still more amazing to listen to 300 men signing as softly as they possibly can. I ve been singing with that choir for 3 years, and we ve been practicing for a few months now. If you ever hear some Mennonites boasting about something, it s probably going to be about how much money they ve raised for charity. And on that note, I ll nudge those Indiana folks reading this and point out that you have some catching up to do with the Kansas sale

Although I often don t agree with Erich (especially if GNOME is involved ;-), he recently posted something on Planet Debian which I found very helpful. I also own a netbook where disk space is sacre. It s an ASUS EeePC 701 with just 4GB disk space. And it runs Debian Sid, so dependencies change often, leaving packages installed which formerly had hard dependencies on, but are now left with just recommendations pointing to it. Quite a few times I asked myself if it s possible to find those packages and if so, how to do it. Well, I don t have to ask myself that anymore, since Erich recently posted the appropriate filter patterns for my favourite package manager aptitude for this task in his posting Finding packages for deinstallation . Thanks, Erich! Since those filters aren t very easy to remember, I d like to extend the usefulness of his posting towards the commandline. I for myself added the following aliases to my shell setup:

alias aptitude-just-recommended='aptitude -o "Aptitude::Pkg-Display-Limit=!?reverse-depends(~i) ~M !?essential"'
alias aptitude-also-via-dependency='aptitude -o "Aptitude::Pkg-Display-Limit=~i !~M ?reverse-depends(~i) !?essential"'

As youam suggested on IRC, I also added the filter !?essential since we won t touch essential packages when cleaning up the list of installed packages anyway. Hope this helps further.