New scratching post

Vi, taking a break as I make the bed.

I've just voted Stefano Zacchiroli for Debian Project Leader (DPL). The voting period closes tonight, so if you are a Debian developer and haven't yet voted, please do! Debian uses a Condorcet voting system, which to my non-expert eyes, bears some resemblance to "Single Transferrable Vote" (STV), at least compared to "First Past the Post" (FPTP). There is a debate raging in the UK as to whether Government elections should be counted based on an STV method instead of FPTP, with a referendum on the subject in May. I'm leaning towards "Yes to AV", but this opinion piece by journalist Stuart Campbell (which argues that people should spoil their ballots) is worth a read.

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.

As the project for the course System specification and implementation , which introduced the Event-B formalism to us, I modeled the algorithm given in one of the constructive proofs of Vizing s theorem and showed it to be correct, using the Event-B tool Rodin. Vizing s theorem states

For a finite undirected graph without autoloops and without multiple edges, at any vertex of which no more than N edges meet, N+1 colors suffice for an edge coloring such that edges incident on the same vertex are of different color.

You can find more details about my approach and my conclusions about Event-B and Rodin in the project report and you can download my Rodin model. I was asked in the comments about my conclusions, so I ll reply here. The proof looks unweidly, but I do think that refinement based proofs, where possible, increase clarity, as more, but smaller steps have to be looked at. Also note that I had no prior exposure to Rodin, so some thing could have been done quicker and easier with more experience. But Rodin itself is not the theorem proving tool of my choice. More detail in the report, shortly put: Its math is too weak and not expressive enough, individual proofs are WORN (write-once-read-never) and can easily be lost when changing the models and there is too little emphasis on correctness, e.g. no trusted core base approach known from dedicated theorem provers. So I would use a different tool for proving mathematical statements, nevertheless the idea of refinements, and trying to find those small-steps-refinements, can also help coming up with better proofs in those tools.

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)

I stumbled across this file whilst sorting through some old backups. It's a "sortpaper": a wallpaper designed to aid people with sorting out files on their desktops. I thought I would share it in case anybody thought the concept was interesting: The size/aspect of the picture probably make it less practically useful today than whenever I first made it.

This is old actually old news, but I suspect some people have forgotten or maybe do not understand to what extend. We decided to break overrides in 2.5.0~rc1[1], as explained in Raphael s email to d-d-a@l.d.o. As the email mentions there were two breakages the tag merges and the file prefix change. Especially the latter seem to be causing confusion (or at least pings/questions/emails for me). The long story short:

All overrides listing files with a prefix of ./ or / will not work as of 2.5.0~rc1

If you are curious as to why, please have a look at #534940. Fixing the override is simply a matter of removing the ./ or / prefix(es). If you discover a tag that still uses ./ or / as file name prefix, please file a bug (assuming someone did not beat you to it). I am not entirely sure if the FTP-masters have updated the copy of Lintian that handles auto-rejects[2], so you may have keep the old/broken override if it is for a non-fatal auto-reject tag. This is especially true for the embedded-zlib tag that were merged into embedded-library. [1] On a related note, this is why this is 2.5.0~rc1 and not 2.4.4. [2] I also do not know when they plan to do it if they have not already done so, but Tolimar has informed me that 2.5.0~rc2 is in squeeze-backports. >.>

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.

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!

Yes, it's that time of the year: I am blogging. I was using Jaws as my blogging tool and CMS for the past few years more or less and I am finally switching to something new. I was running a SVN snapshot of Jaws and haven't updated nor maintained that one for about 3 years. This reduced my abilility to blog a lot as I had to look after bugs and jumping through the hoops to make a post. At some point I wanted to replace Jaws with something better that fits my needs but didn't find anything. I have been keeping an eye on Joey Hess' ikiwiki for quite some time, but never felt the desire to blog something important and thus postponed solving my website mess. For those who don't know ikiwiki yet, it is a wiki compiler based on a version control system like git which generates the website when you push your commits to the git repository. The wiki uses the markdown syntax but also supports other engines. ikiwiki is written in Perl which is not my favourite language, but I have seen worse. When I wrote the Debian packaging tools for the Common Language Infrastructure, which are based on debhelper, I had to study code written by Joey Hess. Putting the syntax aside (I mean it's Perl, it can't be beautiful because of that) he does well designed and implemented software and this is the reason ikiwiki is a great candidate despite the used language. Jo Shields suggested dogfeeding myself with a .NET based blog, but ASP.NET is just junk, but with Manos de Mono I am actually considering it! Manos is written in beautiful C# without any ASP.NET close to it, but is extremely new and has no blogging or wiki engine written for it yet. I was involved in Jaws's development and I didn't want to run into the same issue again for now (more hacking the tools, less using them). So last night I finally made the decision, installed ikiwiki and made my first post with it, yay! The markdown syntax feels very naturaly to me. I usually end up searching for the syntax documentation every 2nd paragraph, but not on this one...

A brand new 0.9.4 release of Rcpp is now on CRAN and Debian. This version contains an improvement to loading and initialization of Rcpp modules, a bug fix for vectors of factors, another build issue fix as well as (per common practice with JSS) citation information for the article Rcpp: Seamless R and C++ Integration which is now Volume 40, Issue 8 in the Journal of Statistical Software (or JSS for short). The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.4   2011-04-12
    o   New R function "loadRcppModules" to load Rcpp modules automatically
        from a package. This function must be called from the .onLoad function
        and works with the "RcppModules" field of the package's DESCRIPTION file
    o   The Modules example wrapped the STL std::vector received some editing
        to disambiguate some symbols the newer compilers did not like
    o   Coercing of vectors of factors is now done with an explicit callback
        to R's "as.character()" as Rf_coerceVector no longer plays along
    o   A CITATION file for the published JSS paper has been added, and 
        references were added to Rcpp-package.Rd and the different vignettes

Thanks to CRANberries, there is also a diff to the previous release 0.9.3:

Diff between Rcpp versions 0.9.3 dated 2011-04-05 and 0.9.4 dated 2011-04-12
 Rcpp-0.9.3/Rcpp/build                                              only
 Rcpp-0.9.3/Rcpp/inst/skeleton/yada.Rd                              only
 Rcpp-0.9.3/Rcpp/inst/unitTests/testRcppModule/R/Modules.R          only
 Rcpp-0.9.3/Rcpp/inst/unitTests/testRcppModule/man/yada.Rd          only
 Rcpp-0.9.4/Rcpp/ChangeLog                                             55 
 Rcpp-0.9.4/Rcpp/DESCRIPTION                                           10 
 Rcpp-0.9.4/Rcpp/NAMESPACE                                             29 
 Rcpp-0.9.4/Rcpp/R/Rcpp.package.skeleton.R                             11 
 Rcpp-0.9.4/Rcpp/R/loadRcppModules.R                                only
 Rcpp-0.9.4/Rcpp/inst/CITATION                                      only
 Rcpp-0.9.4/Rcpp/inst/NEWS                                             17 
 Rcpp-0.9.4/Rcpp/inst/doc/Makefile                                      2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-FAQ.pdf                              binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-FAQ/Rcpp-FAQ.Rnw                       153 +-
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-extending.pdf                        binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-extending/Rcpp-extending.Rnw             2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-introduction.Rnw                       734 ++++------
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-introduction.pdf                     binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-modules.pdf                          binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-modules/Rcpp-modules.Rnw                36 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-package.pdf                          binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-package/Rcpp-package.Rnw                 4 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-quickref.pdf                         binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-quickref/Rcpp-quickref.Rnw              34 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-sugar.pdf                            binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-sugar/Rcpp-sugar.Rnw                     2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-unitTests.pdf                        binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp.bib                                     73 
 Rcpp-0.9.4/Rcpp/inst/doc/unitTests-results/Rcpp-unitTests.html        18 
 Rcpp-0.9.4/Rcpp/inst/doc/unitTests-results/Rcpp-unitTests.txt         40 
 Rcpp-0.9.4/Rcpp/inst/include/Rcpp/config.h                             2 
 Rcpp-0.9.4/Rcpp/inst/skeleton/zzz.R                                   11 
 Rcpp-0.9.4/Rcpp/inst/unitTests/runit.Module.client.package.R          27 
 Rcpp-0.9.4/Rcpp/inst/unitTests/runit.Vector.R                         18 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/DESCRIPTION              2 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/NAMESPACE                3 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/R/zzz.R              only
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/src/rcpp_module.cpp      6 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/src/stdVector.cpp       18 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/tests/modules.R         21 
 Rcpp-0.9.4/Rcpp/man/Rcpp-package.Rd                                    6 
 Rcpp-0.9.4/Rcpp/man/loadRcppModules.Rd                             only
 Rcpp-0.9.4/Rcpp/src/r_cast.cpp                                         9 
 43 files changed, 647 insertions(+), 696 deletions(-)

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

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.

As I got some e-mails about this: if you're on amd64 and Wine complains that it couldn't find a 3D acceleration card, then this is no bug in my wine-unstable packages but #614805. The short-term workaround for you is to use LIBGL_DRIVERS_PATH=/usr/lib32/dri. You can either put it in front of every Wine invocation or you can export the variable in a specific shell session (don't export it globally), in which you'll run Wine or other programs needing the 32 bit libraries. #614805 should be fixed automatically by the next ia32-libs upload, if it contains a version of Mesa containing Git commit cdd1912f.

I've been running at capacity for a while now, and something went "snap" recently, so I decided to take a few days off to clear my head a bit. One of the things that came to mind is that I have too many 'side project' things. I have had lots of fun (and a few flame wars) over the years with LangPop.com but I decided that it's another thing that should probably go, in order to simplify my life some. It's a fairly popular site amongst programmers, as I think it's the best of the bunch in terms of guaging an admittedly tricky subject like language popularity, but there's lots of room to add to it. I've got various ideas for whoever ends up buying it! About money: it doesn't earn a lot. Programmers, I think, are fairly blind to advertisements. In the right hands I think it could do better, but most likely, it would work best as a bit of branding/advertising for your own business, much as TIOBE's index has spread their name far and wide. For the time being, I'll accept private bids, and depending on how well that does or doesn't go, may consider using something like Flippa.com later. Write me at davidw@dedasys.com if you're interested. I'd be happy to share some numbers and information with you. Perhaps I'll update this posting with them too. What you get: everything! Historicaly data, code, scripts to manage it, the domain. It could use some cleaning up and love, but it does get the job done. Running it just takes a few minutes a month, so I could hold on to it with no trouble, but I've decided that I want one less thing to think about. Update: Some Numbers In the last year, according to Google Analytics, the site had: 174,645 visits. In the last month, it had 17,047 visits. Revenue? Think of it as zero and you won't be too far off. You would have to rework things significantly to make money from ads on it, I think. Hosting costs? Not sure, particularly, it's on my Linode. It utilizes Ruby on Rails, but creates static HTML pages, so it's fairly cheap.

My brother was so kind to improve the looks of the Pornyness Calculator which I recently presented here a small web application that tells you how porny a given word is, by comparing the filtered and the non-filtered Google Image search results. The new look is slightly unsuitable for work, so the plain old version is still available.

This went out to d-d-a a couple of days ago already but I figured that this might be of interest here too: The fourth Debian Groupware Meeting was held in the LinuxHotel, Essen, Germany. This is a short summary of what happened during the weekend:

• We pushed new versions of icedove and iceowl to unstable fixing several issues with gnome-shell in the later. Unstable now ships packages based on Thunderbird's current 3.1 branch.
• The iceowl-l10n language package got resurrected (currently sitting in NEW) providing translations for iceowl-extension and (in a yet incomplete way) for iceowl. (Update: it's already in unstable now)
• We've done Citadel ice dove,owl interop testing and bug fixing.
• Work was done on Citadel's event driven SMTP client and IPv6 compatibility
• The z-push package got updated to 1.5.1. The patent restrictions are resolved now and we're closer to resolving the trademark issues. So hopefully an upload to main can happen real soon now.
• SOGo packaging made nice progress. Remaining issues involve linking against GNUTLS to resolve the OpenSSL GPL license incompatibility, and handling of the embedded copies of JavaScript libraries.
• We updated the groupware overview page.
• We were invited by the FrOSCon organizers to join their barbecue. Many thanks for that!

As a followup action to my recent Talk about PyGI I now re-used my notes to provide some real wiki documentation. It would be great if you could add package name info for Fedora/SUSE/etc., and perhaps add more example links for porting different kinds of software! Please also let me know if you have suggestions how to improve the structure of the page.