Grml users out there: We are interested in getting your feedback so we can further improve Grml. We are also working on a webpage which lists happy Grml users and also some quotes and use cases. Now we need your help: Please provide your feedback and take part in Grml s user survey!

So David Watson and Michal iha are doing Project 52 this year? Well, lemme in ;)Actually, me and some friends were doing so the last year already and we will to continue this year too. We re calling it wir knipsen! which translates into English as we snap! .This week my contributions look like this:
Yepp, these are three images as these are our rules: three pictures every week :)Hope you enjoy them and don t forget to have a look at the other pictures at wirknipsen.de.

I just got inspired by David Watson and will try the same challenge. I find it interesting to take and publish one photo every week, but I'm not really sure if I will last. First week photo is from Sun Eclipse few days ago, though it is not much visible :-).

Filed under: English Photography 3 comments Flattr this!

Last August I listened to Axel Beckert's (abe) talk at FrOSCon about Automated building .deb packages from VCS snapshots. Axel builds the web browser Conkeror this way and I daydreamed from a nightly built Icedove. Mozilla provides nightly snapshots of Thunderbird, but these are compressed tar files and I'm too lazy to do things (download, extract, remove, purge, ...) which a package manager does better and faster than me. Today, four months later, I want to announce my nightly build service for Icedove. It provides binary packages - shredder-nightly - for i386 and amd64 in a signed APT repository.

Obviously. In contrast to what I claimed a few years ago, I am now also part of the FOSDEM info team, the central team that organizes this great meeting that happens every year in Brussels, Belgium. Currently, my involvement is limited to doing the same things that I did last year (except then by actually being part of the team rather than talking to them through mail), but this might change for future editions. These "things" involve organizing the cross-distro development room. The schedule isn't finalized yet (that'll happen sometime later this week), but interested parties can go have a look at the list of proposed talks for the cross-distro devroom. There's an interesting lot, IMO.

After finding that Sonim's software uses GPL licensed Gammu, the obvious step was to ask them for sources of the software. They quickly transferred their responsibility to company which made software for them - A&W (Anwsoft). It took some iterations to explain them that I'm pretty sure that their software is based on Gammu and finally they gave up pointing to some external contributor for being guilty of this:

Due to the product was developed years ago, and the source code was bought from a SOHO programmer on the first beginning, so we didn t notice it included some open source code inside.

The good thing in the same thing was that they were willing to cooperate:

We are willing to cooperate with you to follow GPL License and provide corresponding sources.

As it turned out in upcoming communication, they didn't have (and still don't have) idea what GPL license contains and what they should publish. But that's story for the next post.

Filed under: English Gammu Gpl 0 comments Flattr this!

As some of my readers may now, I'm a regular user of public transport. Even though I'm living in an area (far suburbs of Paris) where the use of cars for nearly everything is common, I managed up to now to not use my car for my daily commute. I was using the public bus line of our town, that starts close from our house and ends up at the local train station where I can commute to U line of Paris transport system (then C line, then another bus ride). You can compare this complicated 1h30 travel to the 35 minutes drive I would have if I was using my car. I *was*. I'll stop from tomorrow. The reason is simple: my U train start hour is 6h57. The bus formerly started at 6h36, then reached the train station at 6h51, which was a quite good commute. That made me leave our house at about 6h25, considering a 10min walk from the house to the bus stop. That's 32 minutes for....3 kilometers. Already needs some motivation, right? This changed today (with minimal notice). To catch the same train, I should have a bus at 6h31, thus leave 5 minutes earlier, so *nearly 40 minutes before the train schedule*. Considering that driving from our place to the train station is about 12 minutes, the deal is now made. I'll stop being the only non captive person using the bus in our neighbourhood (all others are people who can't use a car). So much for environment, etc. This is an 'interesting' way to understand why it is so easy to discourage proper use of public transport and minimize the impact on environment. A small change can lead to such effects. Of course, as you may expect, I won't stop there. Letters to the (public-funded) bus company and people in charge of public transport in our city (the bus line deficit is funded by the city), will follow very soon. Tehre are indeed many other reasons why people don't use our local buses that much. One being that, even though there are 2 trains every 15 minutes leaving the station (U and N lines), both alternated with a 7.5 minutes interval....there is only one bus every 15 minutes....on each bus line. Sometimes, even, you don't know why, there's a 23 minutes gap. Imagine waiting for your bus for more than 20 minutes at night in winter...when you're about 2-3 kilometers away from your home... Sure, that would need a lot of funding to have a really convenient system. But how about spending the billions of euros spent in super-highways, toll tunnels, etc., in public transport infrastructure? Funding my local bus line to have 2 buses every 15 minutes at peak hours would cost about the price of 100m of a 3-lane highway, for one year. Make the deal. (All that will indeed reinforce my backup system : run from my house to the train station, for 3km and 15 minutes...which involves another run at the end of my train ride, for 4km and 20 minutes. That, however, involves some "logistics" organization to be sure that I don't spend the day working in my stinking running suit. That also means up to 56km run every week, which I can't always do, particularly if I plan a race for the next week-end!) Another side effect: I will have less time for Debian as my bus commutes were used for hacking, while it will be much more difficult when driving my car to the train station, isn't it?

So this is that misterious red type of produce known only to a certain US ex-vicepresident? (seen at a Mexico City supermarket. Note that there was no label stating what the misterious thing was in Spanish)

Otavio Salvador requested early testers for squeeze debian-installer rc1. (This paragraph will be edited once the official announcement is published.) Graphical installer snapshots A few snapshots follow, using various non-Latin languages to make sure rendering was doing fine.

• Sinhala, prompting for the root password:
• Thai, prompting for popularity-contest configuration:
• Traditional Chinese, prompting for the non-privileged user s name:
• Japanese, loading d-i components from the CD-ROM:
• Hindi, prompting for a hostname:

To avoid any manual drawing, tiny imagemagick magick for the snapshots cropped to 800x300:

convert cropped-snap.png -fill none -stroke black -draw \
    "stroke-dasharray 10 10 path 'M 0,299 L 800,299'" dashed-cropped-snap.png

X/experimental + g-i = ? Premises:

• Fetch libxfont1-udeb, xserver-xorg-core-udeb, xserver-xorg-input-evdev-udeb, xserver-xorg-video-fbdev-udeb from experimental.
• Store them under localudebs/ in a d-i build tree.
• Build a netboot-gtk image with: make rebuild_netboot-gtk
• [Optional: Be amused by the not so tiny CD image that boots the graphical netboot installer parameter to the update-manifest command.]

Result:

X/experimental + g-i = Win

Proof: Comments:

• It looks like we managed not to break the X-related udebs in experimental, even by jumping directly from 1.7 to 1.9. \o/
• Yes, Christian, I managed to highlight French in some way in this blog post. ;)

After aptitude or similar upgrade tool completes its job, new versions of files are installed into filesystem. However, some running processes may be still using old files (and actually Linux file systems continue to store invisible copies of old files while those are mapped by running processes). In case of a security update, having old versions running keeps system vulnerable even after update completes, which is not good. A reboot is possible, but that s an ugly solution. Fortunately tools exist to find processes that have deleted files mapped. One of these tools is checkrestart (from debian-goodies package). Just run checkrestart -p after upgrade, and you will see what to restart to be safe and even what init.d scripts to run with restart argument. P.S.
On a server with hundreds of running processes, checkrestart -p is terribly slow, likely because it makes separate queries to dpkg about files mapped by each process. Perhaps it could be seriously accelerated if first all names to query are gathered, and then each name is queried only once. Any volunteers to do that?

With help of LWN site, I ve discovered in-progress effort of writing a serious book about parallel programming, in form of a real open-source project where people can contribute. Book is titled Is Parallel Programming Hard, And, If So, What Can You Do About It?, edited by Paul E. McKenney. It is still far from being complete, but even in current state it definitely is a recommended reading. Many things are explained using Linux kernel code and environment. So it is also a good kernel resource. As for project things are managed in git repository, with commits from several people. Book sources are in TeX.

Just before Xmas, Conrad Sanderson released version 1.1.0 of Armadillo, his templated C++ library for linear algebra. Which I only noticed this week, so here comes version 0.2.11 of RcppArmadillo, our Rcpp-based integration into R. The only other change is the addition of an unexported function SHLIB which can be used to compiled a single source file into a loadable shared library file for R, while automagically find Rcpp and RcppArmadillo headers and the Rcpp library. The short NEWS file extract follows, also containing Conrad's entry for 1.1.0:

0.2.11  2011-01-06
    o   Upgraded to Armadillo Version 1.1.0    Climate Vandal 
         * Extended submatrix views, including access to elements whose
           indices are specified in a separate vector
         * Added handling of raw binary files by save/load functions
         * Added cumsum()
         * Added interpretation of matrices as triangular via
           trimatu()/trimatl() 
         * Faster solve(), inv() via explicit handling of triangular matrices 
         * The stream for logging of errors and warnings can now be changed 
    o   New unexported R function SHLIB, a small wrapper around R CMD SHLIB,
        which can be used as   Rscript -e "RcppArmadillo:::SHLIB('foo.cpp')"

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

 ChangeLog                                                   17 
 DESCRIPTION                                                 12 
 R/SHLIB.R                                                only
 inst/NEWS                                                   13 
 inst/doc/Makefile                                            5 
 inst/doc/RcppArmadillo-unitTests.pdf                     binary
 inst/doc/unitTests-results/RcppArmadillo-unitTests.html     16 
 inst/doc/unitTests-results/RcppArmadillo-unitTests.txt      34 
 inst/include/armadillo                                       9 
 inst/include/armadillo_bits/Col_meat.hpp                    25 
 inst/include/armadillo_bits/Col_proto.hpp                    5 
 inst/include/armadillo_bits/Cube_meat.hpp                   54 +
 inst/include/armadillo_bits/Cube_proto.hpp                   7 
 inst/include/armadillo_bits/Mat_meat.hpp                   469 ++++++++++++
 inst/include/armadillo_bits/Mat_proto.hpp                   54 +
 inst/include/armadillo_bits/Proxy.hpp                       63 +
 inst/include/armadillo_bits/Row_meat.hpp                    25 
 inst/include/armadillo_bits/Row_proto.hpp                    3 
 inst/include/armadillo_bits/arma_version.hpp                11 
 inst/include/armadillo_bits/auxlib_meat.hpp                102 ++
 inst/include/armadillo_bits/auxlib_proto.hpp                13 
 inst/include/armadillo_bits/debug.hpp                      101 +-
 inst/include/armadillo_bits/diskio_meat.hpp                280 +++++++
 inst/include/armadillo_bits/diskio_proto.hpp                 9 
 inst/include/armadillo_bits/field_meat.hpp                  23 
 inst/include/armadillo_bits/field_proto.hpp                  3 
 inst/include/armadillo_bits/fn_cumsum.hpp                only
 inst/include/armadillo_bits/fn_dot.hpp                      66 +
 inst/include/armadillo_bits/fn_elem.hpp                  only
 inst/include/armadillo_bits/fn_inv.hpp                      27 
 inst/include/armadillo_bits/fn_max.hpp                      17 
 inst/include/armadillo_bits/fn_mean.hpp                     17 
 inst/include/armadillo_bits/fn_median.hpp                   15 
 inst/include/armadillo_bits/fn_min.hpp                      21 
 inst/include/armadillo_bits/fn_misc.hpp                    604 ----------------
 inst/include/armadillo_bits/fn_prod.hpp                     15 
 inst/include/armadillo_bits/fn_solve.hpp                    22 
 inst/include/armadillo_bits/fn_stddev.hpp                   15 
 inst/include/armadillo_bits/fn_sum.hpp                      25 
 inst/include/armadillo_bits/fn_trimat.hpp                only
 inst/include/armadillo_bits/fn_var.hpp                      15 
 inst/include/armadillo_bits/forward_proto.hpp                7 
 inst/include/armadillo_bits/glue_solve_meat.hpp             32 
 inst/include/armadillo_bits/glue_solve_proto.hpp            12 
 inst/include/armadillo_bits/lapack_proto.hpp               103 ++
 inst/include/armadillo_bits/op_cumsum_meat.hpp           only
 inst/include/armadillo_bits/op_cumsum_proto.hpp          only
 inst/include/armadillo_bits/op_dot_meat.hpp                 46 +
 inst/include/armadillo_bits/op_dot_proto.hpp                 9 
 inst/include/armadillo_bits/op_find_meat.hpp                59 -
 inst/include/armadillo_bits/op_inv_meat.hpp                 13 
 inst/include/armadillo_bits/op_inv_proto.hpp                14 
 inst/include/armadillo_bits/op_trimat_meat.hpp           only
 inst/include/armadillo_bits/op_trimat_proto.hpp          only
 inst/include/armadillo_bits/podarray_meat.hpp                7 
 inst/include/armadillo_bits/span.hpp                         9 
 inst/include/armadillo_bits/subview_elem1_meat.hpp       only
 inst/include/armadillo_bits/subview_elem1_proto.hpp      only
 inst/include/armadillo_bits/subview_meat.hpp               321 ++++++--
 inst/include/armadillo_bits/subview_proto.hpp                1 
 inst/include/armadillo_bits/typedef.hpp                      4 
 inst/include/armadillo_bits/unwrap.hpp                     135 +++
 62 files changed, 2155 insertions(+), 829 deletions(-)

More information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Older versions of Psi jabber client required manual changing status to online to leave auto-offline state. It was very handy for me: I connect to my jabber account from two locations (from home and from office), so after I left one of these locations, auto-offline soon happened, and Psi at that location did not return online until I returned and manually instructed it to re-login. Unfortunately newer versions of Psi (I guess, starting from commit 4a54500c on git://git.psi-im.org/psi.git, which was between 0.11 and 0.12 releases), and also Psi+, behave differently: if user activity is detected on the desktop, auto-offline state is left, and status becomes online again similar to leaving auto-away and auto-xa states. This change is not good for me, at least in two situations:

• vnc connection to home from office or to office from home I use this fairy often,
• occasional use of my home session by my wife for quick web browsing or similar.

In both these situations, Psi client not at my current location becomes online, which can cause routing incoming messages to wrong location. I don t state that new behaviour is somehow worse than old behaviour. But for my use cases, I want to get old behaviour back. I ve done some code reading. I think that point to fix is near the bottom of PsiAccount::secondsIdle() method, where any auto status is disabled if no timeout condition currently exists. This should be changed so that auto-offline state won t be left if some config key is set. I will try to implement this change soon (or at least I hope I will try ) P.S.
To make things even better, a check of some external condition could be performed to decide if client should return online from auto-offline or not. Then fancy things could be set up, e.g. return to online at office only if my mobile phone is currently registered in the office wifi network not really required but cool.

I use a lot of code in my lectures, in many different programming languages. I use highlight to generate HTML (via ikiwiki) for web pages. For class presentations, I mostly use the beamer LaTeX class. In order to simplify generating overlays, I wrote a perl script hl-beamer.pl to preprocess source code. An htmlification of the documention/man-page follows.

---

NAME hl-beamer - Preprocessor for hightlight to generate beamer overlays. SYNOPSIS hl-beamer -c // InstructiveExample.java highlight -S java -O latex > figure1.tex DESCRIPTION hl-beamer looks for single line comments (with syntax specified by -c) These comments can start with @ followed by some codes to specify beamer overlays or sections (just chunks of text which can be selectively included). OPTIONS

• -c commentstring Start of single line comments
• -k section1,section2 List of sections to keep (see @( below).
• -s number strip number spaces from the front of every line (tabs are first converted to spaces using Text::Tabs::expand)
• -S strip all directive comments.

CODES

• @( section named section. Can be nested. Pass -k section to include in output. The same name can (usefully) be re-used. Sections omit and comment are omitted by default.
• @) close most recent section.
• @< [overlaytype] [overlayspec] define a beamer overlay. overlaytype defaults to visibleenv if not specified. overlayspec defaults to +- if not specified.
• @> close most recent overlay

EXAMPLE Example input follows. I would probably process this with

hl-beamer -s 4 -k encodeInner

Sample Input

 // @( omit
 import java.io.BufferedReader;
 import java.io.FileReader;
 import java.io.IOException;
 import java.io.Serializable;
 import java.util.Scanner;
 // @)
     // @( encoderInner
     private int findRun(int inRow, int startCol) 
         // @<
         int value=bits[inRow][startCol];
         int cursor=startCol;
         // @>
         // @<
         while(cursor<columns && 
               bits[inRow][cursor] == value) 
             //@<
             cursor++;
             //@>
         // @>
         // @<
         return cursor-1;
         // @>
      
     // @)

BUGS AND LIMITATIONS Currently overlaytype and section must consist of upper and lower case letters and or underscores. This is basically pure sloth on the part of the author. Tabs are always expanded to spaces.

Just discovered Psi+ project. It is a fork of well-known Psi jabber client, with many improvements and new features. Among others things, Psi+ implements plugins feature, and comes with several interesting and useful plugins. One of those provides anti-spam protection, and other is designed specifically for ICQ users. Psi+ is a drop-in replacement for Psi, it uses same per-user configuration. Package is available for Debian Squeze, so if you are already running that version, just run

aptitude install psi-plus psi-plus-plugins

Then restart Psi and enjoy .

For some reason, I don t really know why, I decided to switch my keyboard layout over to something weird. No, not the french brainfuck :) that is actually possible to type on in a halfway acceptable speed (shutup Bubulle), but the Neo thing for german keyboards. Hell. I didn t know how slow one can be typing. About a letter in 3 seconds, or something like it. I think, we should add something to our mandantory set of rules for anyone on any Debian Mailinglist: Whenever a flamewar starts, everyone who participates has to switch their keyboard layout to a random new layout. For every paragraph of every mail they write. Would stop the thread before it really happens. Ohwell, lets see where I stand in a week/month from now. Maybe I can actually use it then. And maybe I really type with 10 fingers then, and not something like the 3 til 8 i currenly use (depends on moon phase how many, i think). I m not slow with my current system, far from it, but I do sometimes have pain in my hands. Maybe that goes away too if I adopt something better, with less weird hand/finger movings. Though the way over will be painful in itself.

I have been pointed that the changelog for libreoffice packages in Debian shows that the Debian maintainer (Ren Engelhard) and the Ubuntu maintainer (Matthias Klose, aka doko) for LibreOffice are obviously sharing their packaging work. That's of course what I would expect to happen...so let's put some light on this. I can actually only hope that more formal announcements from Canonical won't forget to mention such contribution. The link pointed by the announcement I indirectly linked in my former blog post was a post by Matthias in ubuntu-devel. It does not mention the work in Debian, but I can't really blame doko for that....that wasn't meant to be a formal announcement (doko even said he should have been skiing instead of doing libreoffice packaging work...:-)). So, shortly said, my concerns were probably exxagerated and we should celebrate the arrival of LibreOffice packages in both Debian and Ubuntu. And let's hope that both communities will cook together a nice formal announcement about this! It could very well be posted the same day in Debian News and the equivalent announcement channel in the Ubuntu community. And, let's dream, even involve people from The Document Foundation too.

Hardly anything ruins a glorious day of coding like fat-fingering the commit message late at night as you doze off, and then pushing it out for the world to see. To prevent that, I have equipped my Emacs configuration with a few little tools now.

First, I found the git-commit-mode, a special mode for Git commit messages. This helps you format the commit messages according to convention, and will use ugly colors if, for example, you write lines that are too long or you do not keep the second line blank. It also allows the use of things like M-q without shredding the whole file template.

Second, I integrated on-the-fly spell checking into the git-commit-mode. It won't stop you from writing nonsense, but it will catch the silly mistakes.

Here's a simple configuration snippet:

(require 'git-commit)
(add-hook 'git-commit-mode-hook 'turn-on-flyspell)
(add-hook 'git-commit-mode-hook (lambda () (toggle-save-place 0)))

The last line is handy if you have save-place on by default. When you make a new commit, it would then normally place the cursor where a previously edited commit message was finished, because to the save-place functionality, it looks as though it's the same file.

I use Delicious from time to time to save bookmarks and search for stuff I can t remember where I found it. It was sad to read rumors that Yahoo! will shut it down, but that s not the point here now.In the last months I noticed some strange behavior with their site: when surfing a page of a bookmark, you see the total number of people who have bookmarked that particular link and that number started to jump from view to view. First loaded you see a total of 183 bookmarks, 10 minutes later it s 265 bookmarks, and then 183 again. What s going on there? I guess that is some inconsistency between their datacentres or something, but I m not sure (and I am sure that this should not happen!).Today I noticed another funny thing: bookmarks without an owner:

Again, not sure what is happening here. Did the user delete his account? Delicious says all bookmarks will be gone when deleting, so this should be something different, but again, I have no clue.I fear I will have to search a new home for my bookmarks. Any (open-source) social bookmarking service out there worth a try?

New feature for Debian CDs We've had a wishlist bug (#551951) open against debian-cd for some time, asking for the creation of "isohybrid" CD images for i386 and amd64. These are special in that as well as the normal CD-based ISO9660 filesystem they also contain a valid-looking DOS-style partition table. Thus, if you simply copy one of these images raw to a USB stick a normal PC BIOS will boot the image directly. This would be a neat feature, making it much easier for people to use standard Debian installer images on their USB sticks without having to follow a lot more instructions. Support for this feature was added in syslinux/isolinux quite a while back (thanks to H Peter Anvin and the other syslinux contributors), but this depended on post-processing images with the isohybrid program. Due to the special way that we make our CD and DVD images to produce jigdo images as well, that wouldn't work for us: the jigdo files would no longer match the ISO files. Bugger...! Recently, along came more help in the form of Thomas Schmitt (author of xorriso) and George Danchev, its Debian maintainer. Recent versions of xorriso support creating isohybrid images directly, which is very handy. We've worked together in the last few months on porting my old JTE code (which creates our jigdo images) from cdrkit to xorriso, and after a lot of testing and debugging we now have things working fully. I've added a small amount of code in debian-cd to use the new xorriso features, and for the last couple of weeks all of the i386, amd64 and i386-amd64 multi-arch CDs and DVDs have been built as hybrids. It's been a delight working with Thomas and George - they're enthusiastic, helpful and friendly. Thanks, guys! What does this mean for end users? Instead of having to specially prepare USB sticks for the installer, you can now simply use dd to write the image straight to the raw stick, e.g.:

# dd if=debian-testing-i386-netinst.iso of=/dev/sdX

The USB stick should now boot directly, showing exactly the same bootup screen as if you'd written the image directly to a CD. Yay! I'm expecting to be using this code from now on for new releases, i.e. d-i beta and RC releases and for Squeeze itself when we get there. I'm not planning on backporting this code into the Lenny branch of debian-cd as it's a lot of work and I don't want to destabilise things there. What's next? We need to clear up some of the maintenance around the code as it stands; I'm planning on moving libjte inside my existing jigit package, as that's a sensible place to put it. That will come after the Squeeze release, though. We need to finalise boot support for other architectures in xorriso; I added support for them into mkisofs/genisoimage a long time ago and we've already moved some of that into xorriso. Thomas and George have also been working hard to give me faster/better size estimation code, useful for making debian-cd run faster. Finally: I'd like to add support into xorriso for creating the nasty HFS hybrid images that are needed for booting Macs. The code that does this in cdrkit is probably some of the worst that I've ever worked with, and I'd like to get away from it. If only Apple hadn't stupidly built their proprietary platform around this shit and had used open standards instead. :-( Once we have these bits in xorriso, I'll be able to move production of all of the CDs across from genisoimage to xorriso. Very nearly there for being able to drop the last remnants of Schily-ware from the Debian archive...