A short announcement to mark the release of the first stable OpenID provider for Drupal. Started by James Walker around 4 years ago, I have since then got commit access and taken care of the module for the last 2 years. And while it was not an easy task, with the help of the community, this module was able to mature to a fully featured, flexible and standard implementation during that time. One has to wonder however, is it too late for OpenID?

A bit of history Drupal was one of the pioneers in OpenID support. Back in 2006 when the protocol was still in its infancy (less than a year old!), Drupal was adding OpenID support to its 4.7 release through a contrib module and two years later, the Drupal 6.0 release was sporting OpenID in core, although not without significant interoperability issues. Still, we could say that rapid adoption by such a popular CMS as Drupal really boosted OpenID's adoption. At about the same time, Yahoo, Sourceforge, Myspace, Microsoft and Google would all join the OpenID bandwagon. On the OpenID "provider" side of things, things were not so great however. Back when I started experimenting with this, it wasn't actually that easy to host your own OpenID provider, to allow your users to login to other OpenID-enabled sites. While there are a lot of different libraries to provide OpenID support in your application there was not (and still isn't) any software that gives you an OpenID provider and is dedicated to that. No official reference implementation either, other than the code from the one of the founding companies of OpenID, JanRain. There was an OpenID provider module in Drupal, but there was no official release done until a two beta releases in 2010.

Koumbit's community involvement It is about that time I started getting involved in the project. Koumbit needed an easy way for our workers to log into multiple sites without too much trouble, so I started looking at OpenID provider implementations. The lack of dedicated software somehow made the Drupal implementation a natural fit, and I started experimenting with the module, filing bugs and reviewing patches, as there were a lot of interoperability and design issues with the provider. After a while, walkah was kind enough to give me full access to the project and I started doing regular releases (every few months), culminating in today's official 1.0 release for both Drupal 6 and Drupal 7, which I am very proud and happy about. While I am here, I want to send many thanks to the people behind the Drupal 7 port: paranojik, mikecar, xamanu and testing from neizod. A lot of issues were also patched, reviewed and tested by numerous contributors that are unfortunately difficult to track down other than reading the commit log. So we at Koumbit have been running our own OpenID provider for a good while now, and it has the key advantage of being connected to our LDAP directory (with the D6 LDAP integration module so it is, in a sense, a central point for authentication at Koumbit. Very often people don't clearly understand what their LDAP password does, and I can easily remind them "it's the OpenID thing", or "try your password in the OpenID site" if they think they have forgotten it. So much goes on in the web browser these days that it makes everything much easier.

The problem with Drupal's OpenID provider However, it is kind of embarrassing that it took so long. More than 6 years after the OpenID protocol was written, we have a stable OpenID provider. Now, this may be because I am overly conservative about stable releases, but I don't think so: the OpenID provider module had, for a long time, serious interoperability issues with OpenID sites. There was also a clear lack of features on the OpenID provider, a gap that various third party modules, now documented on the OpenID provider homepage are now trying to fill. There is also serious security issues with the protocol itself. The complexity and lack of clarity of the OpenID specification have rendered my work quite difficult at time, as the protocol has significant ambiguities and no clear reference implementation. OpenID is unfortunately renowned to be vulnerable to phishing and while Koumbit's use of the HTTPS protocol alleviates some of those issues (especially the redirect session hijack), tools like sslstrip can bypass those protections easily. The privacy aspect is also problematic, as the user is usually not free to choose which information from his or her profile is divulged to the site they are logging into. Of course those issues may be overlooked if the security trade off is not worth it. In the case of Koumbit, we use OpenID on a lot of client sites, but usually nothing critical, and we train our users to pay attention to the HTTPS icon when login in their OpenID account.

Are there alternatives? But unfortuantely, the reality is that there are not really any alternatives to OpenID out there. Mozilla's new BrowserID initiative (now rebranded Persona, boy those guys sure love rebranding..) is interesting, but actually has even more flaws than OpenID itself. Not only is it not resolving the phishing problem, it actually creates new problems, including my personal favorite, trusting server-side Javascript code, which OpenID is not using that much. I should also mention the Shibboleth module which has a surprising number of installs recorded on Drupal.org, but that depends on the much more complicated Shibboleth federation, for which there is no server implementation for Drupal, from what I understand. Oauth, on the other end, is even more widely used, and has server-side components like Oauth Login Provider and Services 3.x. We could also simply give up and use our souls stored at Facebook, Google and Twitter for authentication everywhere. Maybe OpenID opened the door for those corporations to see that there is a real opportunity in leveraging user's profile to track their online activity. It is not something that OpenID was necessarily designed for but it's an idea that certainly permeates Facebook connect and "like" buttons or Twitter and Google online business strategies, where you are the product sold to advertisers. I personally believe we should keep the struggle for distributed and standard identity mechanisms for the web that respect users' privacy. With Drupal's OpenID Provider, it is possible to create a secure, privacy-aware identity provider, although I still have to perform that damn security audit. Experiments with those third party modules should also be encouraged and I welcome any feedback on those modules. While I do not plan to attend OpenID conferences or do significant development on the OpenID provider right now, I will certainly make sure Koumbit keeps its commitment to maintaining stewardship on the OpenID provider module in Drupal. I encourage people to try it out, submit issues and patches to make it even better. Long life to OpenID! PS: if people are interested in funding that security audit, I would be happy to perform this through my regular work at Koumbit.org, just file a request at services@koumbit.org.

Another month, another update to http.debian.net. This time around most of the work was done outside the redirector's code base, as strange as it may sound.

The redirector heavily relies on the mirrors doing at least a couple of things right, for the rest it can and does compensate. When it needs to compensate, certain requests are redirected to automatically-detected good mirrors, thus avoiding mirrors that might work fine for some parts of the day but cause headaches during the rest.

So, part of the work done since the last update was to prod more mirror administrators to upgrade to the latest version of ftpsync. This reduces the number of mirrors for which compensation is needed in order to avoid errors during installations and upgrades. Hopefully, no additional work is needed for the redirector to notice the upgrades. This results in immediate improvements.

However, not all mirrors comply with the bare minimum requirements. As stated in my previous blog post, running rsync once is not enough. When mirrors break these assumptions they lead to the "bad apple" effect. The effects in this case are temporary errors, as experienced by some people. The interesting part of those issues is that the affected population may quickly change given the redirector's use of geo location and the way it creates mirror subsets.

As interesting as the distribution of the effects may be, they are not really welcome. So I put together some code to attempt to detect the bad apples. This resulted in a list of mirrors that have now been disabled in the redirector and whose administrators are going to be contacted so that they comply with the minimum requirements. Given that detection is time-sensitive, there's no 100% guarantee that all of them have been identified so far. The code to detect them will have to be adapted and integrated into the redirector's code base to be proactive on avoiding this kind of issues.

Last but not least, the redirector is now using a database of AS peers for better (re-)routing. This is the next move towards a decision making based more on network location/topology than in geographic location. This first use of a peers database is limited to IPv4 and is based on a recent routing table dump and on feedback provided by interested people. If you are a mirror or network administrator, or you are familiar with the topology of your network please drop me an email so that the redirector can make a better use of your peering agreements.

N.b. in the case of the database, the term peer may also include transit providers. It is used to refer to and establish a relationship between two AS(N)s.


Feedback is, as always, welcome. I read each and every email but it may take me some time to get to it, or reply.

Next week end, November 24th and 25th, the mini Debconf will take place at EPITA in Paris. Mehdi Dogguy and I worked hard on the organization and on building a great program for this 2012 conference. This mini debconf will cover many subjects like Gnome (both as upstream and downstream), the Release team, how the Linux is packaged in Debian, etc.
The keynote will be "Free software and Debian, 20 years after" by Roberto Di Cosmo. Also, some merchandising will be proposed during the event by the association Debian France. Here is a quick list: Polos

Long-sleeved polo
40 euros - 10 pieces
Sleeveless polo
25 euros - 100 pieces Thanks to Tanguy Ortolo for taking take of the order. Buff

Buff Debian
18 euros - 75 pieces. It is described as Original Multifunctional Headwear. Real life example in video.
I love them! Finally, we will sell two kinds of Debian branded Sticker Portable:

Sticker Debian
1 euro - 100 pieces. They can be also ordered on the it2l website. Thanks to J r me Lemaire for providing these great products. If these products are successful, we will probably produce more for FOSDEM! For more information about the conference:
The official website
Wiki page for subscription

Last week, just before the branching of 3.6.4 was the peak of my recent work in LibreOffice. The motivation from attending the conference and working with others lasted long for me with the help of a few collaborations done since (thanks Caolan and Eike). My own patches were approved just in time to make it to the 3-6 branch, which, along other fixes, pretty much makes 3.6.4 a better release to the RTL users in general, and Hebrew users specifically. Things aren t perfect, but they re improving nicely (on going status is at RTL bugs wiki page). I m also very happy that most RTL related fixes since the conference have been cherry-picked from master to 3-6 branch, so the users won t have to wait till February for the 4.0 release. Last year I had to wait till the 3.5 release to see some of my work fruits, now I can see them in much shorter intervals. The motivation and involvement go hand in hand, each enhances the other for me. I ve started reviewing patches sent for RTL bugs to verify the suggested fixes with private builds and marking bugs as verified when the patches do get accepted. Compering to a month ago, I m now busy with helping the developers do their part instead of just reporting problems. Seeing things go forward (and helping them do so) is much more motivating than waiting for someone to pick the bug report and try solve it. I hope having fast response to their code changes is also motivating for the developers, in that case everyone enjoys the collaboration.
Filed under: LibreOffice

As a followup to my toy over at debtree, I ve taken some suggestions from my buddy Arno and found some time in the hotel during a visit for work up to Canada with the Open North folks hacking on open13. The hack is called debfriends (I need to purge personal details from the source tree before I can push it to VCS, since it uses the nm.d.o dump. Sorry, I should have been better about that.) I ve posted a cute front-end on my staging machine to play with over at graph.lucifer.pault.ag There s also an API, but it has all the data in the NM dump exposed. If you re a DD who will treat this data right, I can add a key (it s not secure, like, at all). I m going to publish the source ASAP so that others can stand up an instance if they d like. It s a cute toy, though! In the tradition of using nhandler for my examples, here s an example path from pabs to Nathan: pabs > nhandler

• nhandler was advocated by paultag
• paultag was advocated by mako
• micah was advocated by mako
• pabs was advocated by micah

Also, we re a shockingly well connected bunch. Well done :) Feel free to play with it!

A year ago I wrote in Useful but Unknown Unix Tools: How wdiff and colordiff help to choose the right Swiss Army Knife about using wdiff and colordiff together. Colordiff ed wdiff output looks like this:

$ wdiff foobar.txt barfoo.txt   colordiff
[-foo-]bar fnord
gnarz hurz quux
bla  +foo+  fasel

But if you have colour, why still having these hard to read wdiff markers still in the text? There exists a tool named dwdiff which can do word diffs in colour without textual markers and with even less to type (and without being git diff --color-words ;-). Actually it looks like git diff --color-words, just without the git:

$ dwdiff -c foobar.txt barfoo.txt
foo bar fnord
gnarz hurz quux
bla foo fasel

Another cool thing about dwdiff (and its name giving feature) is that you can defined what you consider whitespace, i.e. which character(s) delimit the words. So lets do the example above again, but this time declare that f is considered the only whitespace character:

$ dwdiff -W f -c foobar.txt barfoo.txt
foo bar bar fnord
gnarz hurz quux
bla foo fasel

dwdiff can also show line numbers:

$ dwdiff -c -L foobar.txt barfoo.txt
   1:1    foo bar fnord
   2:2    gnarz hurz quux
   3:3    bla foo fasel
$ dwdiff -c -L foobar.txt quux.txt
   1:1    foo bar fnord
   1:2    foobar floedeldoe
   2:3    gnarz hurz quux
   3:4    bla foo fasel

(coloured shell screenshots by aha)

With python-dbusmock you can provide mocks for arbitrary D-BUS services for your test suites or if you want to reproduce a bug. However, when writing actual tests for gnome-settings-daemon etc. I noticed that it is rather cumbersome to always have to set up the skeleton of common services such as UPower. python-dbusmock 0.2 now introduces the concept of templates which provide those skeletons for common standard services so that your code only needs to set up the particular properties and specific D-BUS objects that you need. These templates can be parameterized for common customizations, and they can provide additional convenience methods on the org.freedesktop.DBus.Mock interface to provide more abstract functionality like add a battery . So if you want to pretend you have one AC and a half-charged battery, you can now simply do

  def setUp(self):
     (self.p_mock, self.obj_upower) = self.spawn_server_template('upower',  )
  def test_ac_bat(self):
     self.obj_upower.AddAC('mock_AC', 'Mock AC')
     self.obj_upower.AddChargingBattery('mock_BAT', 'Mock Battery', 50.0, 1200)

Or, if your code is not in Python, use the CLI/D-BUS interface, like in shell:

  # start a fake system bus
  eval  dbus-launch 
  export DBUS_SYSTEM_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
  # start mock upower on the fake bus
  python3 -m dbusmock --template upower &
  # add devices
  gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
      -m org.freedesktop.DBus.Mock.AddAC mock_ac 'Mock AC'
  gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
      -m org.freedesktop.DBus.Mock.AddChargingBattery mock_bat 'Mock Bat' 50.0 1200

In both cases upower --dump or gnome-power-statistics will show you the expected devices (of course you need to run that within the environment of the fake $DBUS_SYSTEM_BUS_ADDRESS, or run the mock on the real system bus as root). Iftikhar Ahmad contributed a template for NetworkManager, which allows you to easily set up ethernet and wifi devices and wifi access points. See pydoc3 dbusmock.templates.networkmanager for details and the test cases for how this looks like in practice. I just released python-dbusmock 0.2.1 and uploaded the new version to Debian experimental. I will sync it into Ubuntu Raring in a few hours.

A (well, now former) coworker let me know about a problem he was having with a Lenovo Thinkcentre M92p. It booted Fedora UEFI install media fine, but after an apparently successful installation refused to boot. UEFI installs on Windows worked perfectly. Secure Boot was quickly ruled out, but this could still have been a number of things. The most interesting observation was that the Fedora boot option didn't appear in the firmware boot menu at all, but Windows did. We spent a little while comparing the variable contents, gradually ruling out potential issues - Linux was writing an entry that had an extra 6 bytes in a structure, for instance[1], and a sufficiently paranoid firmware implementation may have been tripping up on that. Fixing that didn't help, though. Finally we tried just taking the Windows entry and changing the descriptive string. And it broke.

Every UEFI boot entry has a descriptive string. This is used by the firmware when it's presenting a menu to users - instead of "Hard drive 0" and "USB drive 3", the firmware can list "Windows Boot Manager" and "Fedora Linux". There's no reason at all for the firmware to be parsing these strings. But the evidence seemed pretty strong - given two identical boot entries, one saying "Windows Boot Manager" and one not, only the first would work. At this point I downloaded a copy of the firmware and started poking at it. Turns out that yes, actually, there is a function that compares the descriptive string against "Windows Boot Manager" and appears to return an error if it doesn't match. What's stranger is that it also checks for "Red Hat Enterprise Linux" and lets that one work as well.

This is, obviously, bizarre. A vendor appears to have actually written additional code to check whether an OS claims to be Windows before it'll let it boot. Someone then presumably tested booting RHEL on it and discovered that it didn't work. Rather than take out that check, they then addded another check to let RHEL boot as well. We haven't yet verified whether this is an absolute string match or whether a prefix of "Red Hat Enterprise Linux" is sufficient, and further examination of the code may reveal further workarounds. For now, if you want to run Fedora[2] on these systems you're probably best off changing the firmware to perform a legacy boot.

[1] src/include/efi.h: uint8_t padding[6]; /* Emperically needed */, says the efibootmgr source code. Unhelpful.
[2] Or Ubuntu, or Suse, or

comments

TL;DR: There s a summary at the end of the article. Today I wanted to see why a dependency in a .deb-package from an external APT repository changed so that it became uninstallable. While dpkg-deb --info foobar.deb easily shows the control information, the changelog is in the filesystem part of the package. I could extract that one dpkg-deb, too, but I d have to extract either to some temporary directory or pipe it into tar which then can extract a single file from the archive and sent it to STDOUT:

dpkg-deb --fsys-tarfile foobar.deb   tar xOf - ./usr/share/doc/foobar/changelog.Debian.gz   zless

But that s tedious to type. The following command is clearly less to type and way easier to remember:

acat foobar.deb ./usr/share/doc/foobar/changelog.Debian.gz   zless

acat stands for archive cat is part of the atool suite of commands:

als

lists files in an archive.

$ als foobar.tgz
drwxr-xr-x abe/abe           0 2012-11-15 00:19 foobar/
-rw-r--r-- abe/abe          13 2012-11-15 00:20 foobar/bar
-rw-r--r-- abe/abe          13 2012-11-15 00:20 foobar/foo

acat

extracts files in an archive to standard out.

$ acat foobar.tgz foobar/foo foobar/bar
foobar/bar
bar contents
foobar/foo
foo contents

adiff

generates a diff between two archives using diff(1).

$ als quux.zip
Archive:  quux.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2012-11-15 00:23   quux/
       16  2012-11-15 00:22   quux/foo
       13  2012-11-15 00:20   quux/bar
---------                     -------
       29                     3 files
$ adiff foobar.tgz quux.zip
diff -ru Unpack-3594/foobar/foo Unpack-7862/quux/foo
--- Unpack-3594/foobar/foo      2012-11-15 00:20:46.000000000 +0100
+++ Unpack-7862/quux/foo        2012-11-15 00:22:56.000000000 +0100
@@ -1 +1 @@
-foo contents
+foobar contents

arepack

repacks archives to a different format. It does this by first extracting all files of the old archive into a temporary directory, then packing all files extracted to that directory to the new archive. Use the --each (-e) option in combination with --format (-F) to repack multiple archives using a single invocation of atool. Note that arepack will not remove the old archive.

$ arepack foobar.tgz foobar.txz
foobar.tgz: extracted to  Unpack-7121/foobar'
foobar.txz: grew 36 bytes

apack

creates archives (or compresses files). If no file arguments are specified, filenames to add are read from standard in.

aunpack

extracts files from an archive. Often one wants to extract all files in an archive to a single subdirectory. However, some archives contain multiple files in their root directories. The aunpack program overcomes this problem by first extracting files to a unique (temporary) directory, and then moving its contents back if possible. This also prevents local files from being overwritten by mistake.

(atool subcommand descriptions from the atool man page which is licensed under GPLv3+. Examples by me.) I though miss the existence of an agrep subcommand. Guess why? atool supports a wealth of archive types: tar (gzip-, bzip-, bzip2-, compress-/Z-, lzip-, lzop-, xz-, and 7zip-compressed), zip, jar/war, rar, lha/lzh, 7zip, alzip/alz, ace, ar, arj, arc, rpm, deb, cab, gzip, bzip, bzip2, compress/Z, lzip, lzop, xz, rzip, lrzip and cpio. (Not all subcommands support all archive types.) Similar Utilities There are some utilities which cover parts of what atool does, too: Tools from the mtools package Yes, they come from the handle MS-DOS floppy disks tool package, don t ask me why. :-)

uz

gunzips and extracts a gzip d tar d archives

Advantage over aunpack: Less to type. :-)

Disadvantage compared to aunpack: Supports only one archive format.

lz

gunzips and shows a listing of a gzip d tar d archive

Advantage over als: One character less to type. :-)

Disadvantage compared to als: Supports only one archive format.

unp unp extracts one or more files given as arguments on the command line.

$ unp -s
Known archive formats and tools:
7z:           p7zip or p7zip-full
ace:          unace
ar,deb:       binutils
arj:          arj
bz2:          bzip2
cab:          cabextract
chm:          libchm-bin or archmage
cpio,afio:    cpio or afio
dat:          tnef
dms:          xdms
exe:          maybe orange or unzip or unrar or unarj or lha 
gz:           gzip
hqx:          macutils
lha,lzh:      lha
lz:           lzip
lzma:         xz-utils or lzma
lzo:          lzop
lzx:          unlzx
mbox:         formail and mpack
pmd:          ppmd
rar:          rar or unrar or unrar-free
rpm:          rpm2cpio and cpio
sea,sea.bin:  macutils
shar:         sharutils
tar:          tar
tar.bz2,tbz2: tar with bzip2
tar.lzip:     tar with lzip
tar.lzop,tzo: tar with lzop
tar.xz,txz:   tar with xz-utils
tar.z:        tar with compress
tgz,tar.gz:   tar with gzip
uu:           sharutils
xz:           xz-utils
zip,cbz,cbr,jar,war,ear,xpi,adf: unzip
zoo:          zoo

So it s very similar to aunpack, just a shorter command and it supports some more exotic archive formats which atool doesn t support. Also part of the unp package is ucat which does more or less the same as acat, just with unp as backend. dtrx From the man page of dtrx:

In addition to providing one command to extract many different archive types, dtrx also aids the user by extracting contents consistently. By default, everything will be written to a dedicated directory that s named after the archive. dtrx will also change the permissions to ensure that the owner can read and write all those files. Supported archive formats: tar, zip (including self-extracting .exe files), cpio, rpm, deb, gem, 7z, cab, rar, and InstallShield. It can also decompress files compressed with gzip, bzip2, lzma, or compress.

dtrx -l lists the contents of an archive, i.e. works like als or lz. dtrx has two features not present in the other tools mentioned so far:

• It can extract metadata instead of the normal contents from .deb and .gem files.
• It can extract archives recursively, i.e. can extract archives inside of archives.

Unfortunately you can t mix those two features. But you can use the following tool for that purpose: deepfind deepfind is a command from the package strigi-utils and recursively lists files in archives, including archives in archives. I ve already written a detailed blog-posting about deepfind and its friend deepgrep. tardiff tardiff was written to check what changed in source code tarballs from one release to another. By default it just lists the differences in the file lists, not in the files contents and hence works different than adiff. Summary atool and friends are probably the first choice when it comes to DWIM archive handling, also because they have an easy to remember subcommand scheme. uz and lz and the shortest way to extract or list the contents of a .tar.gz file. But nothing more. And you have to install mtools even if you don t have a floppy drive. unp comes in handy for exotic archive formats atool doesn t support. And it s way easier to remember and type than aunpack. dtrx is neat if you want to extract archives in archives or if you want to extract metadata from some package files with just a few keystrokes. For listing all files in recursive archives, use deepfind.

Here is another interview with one of the people in the Debian Edu and Skolelinux community. I am running short on people willing to be interviewed, so if you know about someone I should interview, Please send me an email. After asking for many months, I finally managed to lure another one of the people behind the German "IT-Zukunft Schule" project out from maternity leave to conduct an interview. Give a warm welcome to Angela Fu . :) Who are you, and how do you spend your days? I am a 39-year-old woman living in the very north of Germany near Denmark. I live in a patchwork family with "my man" Mike Gabriel, my two daughters, Mikes daughter and Mikes and my rather newborn son. At the moment - because of our little baby - I am spending most of the day by being a caring and organising mom for all the kids. Besides that I am really involved into and occupied with several inner growth processes: New born souls always bring the whole familiar system into movement and that needs time and focus ;-). We are also in the middle of buying a house and moving to it. In 2013 I will work again in my job in a German foundation for nature conservation. I am doing public relation work there. Besides that - and that is the connection to Skolelinux / Debian Edu - I am working in our own school project "IT-Zukunft Schule" in North Germany. I am responsible for the quality assurance, the customer relationship management and the communication processes in the project. Since 2001 I constantly have been training myself in communication and leadership. Besides that I am a forester, a landscaping gardener and a yoga teacher. How did you get in contact with the Skolelinux / Debian Edu project? I fell in love with Mike ;-). Very soon after getting to know him I was completely enrolled into Free Software. At this time Mike did IT-services for one newly founded school in Kiel. Other schools in Kiel needed concepts for their IT environment. Often when Mike came home from working at the newly founded school I found myself listening to his complaints about several points where the communication with the schools head or the teachers did not work. So we were clear that he would not work for one more school if we did not set up a structure for communication between him, the schools head, the teachers, the students and the parents. Together with our friend and hardware supplier Andreas Buchholz we started to get an overview of free software solutions suitable for schools. One day before Christmas 2010 Mike and I had a date with Kurt Gramlich in G tersloh. As Kurt and I are really interested in building networks of people and in being in communication we dived into Skolelinux and brought it to the first grammar schools in Northern Germany. For information about our school project you can read the interview with Mike Gabriel. What do you see as the advantages of Skolelinux / Debian Edu? First I have to say: I cannot answer this question technically. My answer comes rather from a social point of view. The biggest advantage of Skolelinux / Debian Edu I see is the large and strong international community of Debian Developers in the background which is very alive and connected over mailinglists, blogs and meetings. My constant feeling for the Debian Community is: If something does not work they will somehow fix it. All is well ;-). This is of course a user experience. What I also get as a big advantage of Skolelinux / Debian Edu is that everybody who uses it and works with it can also contribute to it - that includes students, teachers, parents... What do you see as the disadvantages of Skolelinux / Debian Edu? I will answer this question relating to the internal structure of Skolelinux / Debian Edu. What I see as a major disadvantage is that there is a gap between the group of developers for Debian Edu and the people who make the marketing, that means the people that bring Skolelinux to the schools. There is a lack of communication between these two groups and I think that does not really work for Skolelinux / Debian Edu. Further I appreciate that Skolelinux / Debian Edu is known as a do-ocracy. Nevertheless I keep asking myself if at some points a democracy or some kind of hierarchical project structure would be good and helpful. I am also missing some kind of contact between the Skolelinux / Debian Edu communities in Europe or on an international level. I think it would be good if there was more sharing between the different countries using Skolelinux / Debian Edu. Which free software do you use daily? On my laptop I am still using an Ubuntu 10.04 with a Gnome Desktop on. As applications I use Openoffice.org, Gedit, Firefox, Pidgin, LaTeX and GnuCash. For mails I am using Horde. And I am really fond of my N900 running with Maemo. Which strategy do you believe is the right one to use to get schools to use free software? I am really convinced that in our school project "IT-Zukunft Schule" we have developed (and keep developing) a great way to get schools to use Free Software. We have written a detailed concept for that so I cannot explain the whole thing here. But in a nutshell the strategy has three crucial pillars:

• We really take time to get what sort of stories, questions and concerns the schools head and the teachers have about using different kinds of IT and we take time to enrol them into Free Software.
• Our solution for schools is never just technical. In the centre are always the people who are going to use the software. From the very beginning of the planning for a school, we tell the schools head that they are paying us not only for a technical solution for their school, they also pay us for leading all the communication processes needed. If they do not want that, we are not working with them because we cannot give a guarantee for the quality of our work then.
• Another focus lies in the training of teachers and students in co-administrating the IT-System at their school. They start getting in contact with the Skolelinux / Debian Edu community and they get the offer to become more and more independent from us.

Rcpp release 0.10.0 is now on CRAN and being uploaded to Debian. This is a new feature release, and we are very exciting about the changes, notably Rcpp attributes which make using C++ from R even easier than inline (see below as well as the new vignette for details and first examples), the extensions to Rcpp modules (see below) and more as for example new Rcpp sugar functions, a new error output device syncing to R, and a new namespace R> for the statistical functions from Rmath.h. The complete NEWS entry for 0.10.0 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.0 (2012-11-13)

• Support for C++11 style attributes (embedded in comments) to enable use of C++ within interactive sessions and to automatically generate module declarations for packages:
  • Rcpp::export attribute to export a C++ function to R
  • sourceCpp() function to source exported functions from a file
  • cppFunction() and evalCpp() functions for inline declarations and execution
  • compileAttribtes() function to generate Rcpp modules from exported functions within a package
  • Rcpp::depends attribute for specifying additional build dependencies for sourceCpp()
  • Rcpp::interfaces attribute to specify the external bindings compileAttributes() should generate (defaults to R-only but a C++ include file using R_GetCCallable can also be generated)
  • New vignette "Rcpp-attribute"
• Rcpp modules feature set has been expanded:
  • Functions and methods can now return objects from classes that are exposed through modules. This uses the make_new_object template internally. This feature requires that some class traits are declared to indicate Rcpp's wrap/as system that these classes are covered by modules. The macro RCPP_EXPOSED_CLASS and RCPP_EXPOSED_CLASS_NODECL can be used to declared these type traits.
  • Classes exposed through modules can also be used as parameters of exposed functions or methods.
  • Exposed classes can declare factories with ".factory". A factory is a c++ function that returns a pointer to the target class. It is assumed that these objects are allocated with new on the factory. On the R side, factories are called just like other constructors, with the "new" function. This feature allows an alternative way to construct objects.
  • "converter" can be used to declare a way to convert an object of a type to another type. This gets translated to the appropriate "as" method on the R side.
  • Inheritance. A class can now declare that it inherits from another class with the .derives<Parent>( "Parent" ) notation. As a result the exposed class gains methods and properties (fields) from its parent class.
• New sugar functions:
  • which_min implements which.min. Traversing the sugar expression and returning the index of the first time the minimum value is found.
  • which_max idem
  • unique uses unordered_set to find unique values. In particular, the version for CharacterVector is found to be more efficient than R's version
  • sort_unique calculates unique values and then sorts them.
• Improvements to output facilities:
  • Implemented sync() so that flushing output streams works
  • Added Rcerr output stream (forwarding to REprintf)
• Provide a namespace 'R' for the standalone Rmath library so that Rcpp users can access those functions too; also added unit tests
• Development releases sets variable RunAllRcppTests to yes to run all tests (unless it was alredy set to 'no'); CRAN releases do not and still require setting which helps with the desired CRAN default of less testing at the CRAN server farm.

Thanks to CRANberries, you can also look at a diff to the previous release 0.9.15. 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

Update: One link corrected.

Dear lazyweb, we need a new printer-scanner combination for our new office, ideally a laser printer and a high-resolution scanner (1200dpi). It must integrate nicely with CUPS and SANE, without requiring any proprietary, closed-licence drivers or plugins. It also has to come with an automatic document feeder in addition to the plain flatbed scanner. Additional, would-be-nice features in decreasing order of preference are

• Colour printing (separate cartridges a must)
• Duplex printing (real duplex preferred over soft solutions)
• Direct scanning to PDF (distribution by E-mail, Samba or FTP)

I have investigated the Samsung CLX-6220FX, but the driver situation was such a nightmare (and the printer so loud), that we returned it right away. I should have read this article by Peter beforehand I have recently seen the HP Laserjet Pro 200 M276n, the successor of the HP Laserjet CM1415nf which looks promising, but according to LinuxPrinting.org, a proprietary plugin is required (WTF HP?). Does anyone have experience with these HP models and can recommend them for use with Debian stable? Does anyone have another recommendation? Please send me a message. Thanks!

Tomorrow (Thursday 15th November), there will be a PGP key signing and CAcert assurance party in Prague. It will be held in SUSE offices and it will start at 17:00. If you are interesting in having your PGP key signed, bring papers with your key fingerprint (you can use for example these slips) and some government issued ID. For CAcert assurance it is recommended to bring printed out assurance papers (you can get them from CAcert website) and of course IDs as well. You can find more information on Facebook or Google+ event pages.

Filed under: English Suse 2 comments Flattr this!

New Laptop: Thinkpad x120e My travels the last few days have not been to anywhere new. I spent a few days at Tumco, then spent today in Algodones and am staying the night at Quechen Casino. Since I never described my new computer due to network problems, I figured now would be a good time to do so. I purchased a discontinued Lenovo Thinkpad x120e laptop. It has 2gb ram, a 320gb hard drive, dual-core AMD processor, and no optical drive. The first thing I did was wipe windows off of it and install Debian Squeeze (stable), then attempt to upgrade to Debian Wheezy (testing). (Squeeze lacked the drivers for some hardware.) Wheezy lacked the drivers for the display, so during the boot sequence it would switch to an unreadable screen. I eventually found that Sid (unstable) had the driver for the display in non-free. (To install it I needed to boot with the Squeeze kernel.) The most significant thing I have not yet debugged is hibernate mode. One thing I really like about this system is the 4-6 hour battery life. This is enough that I can charge during the day when my solar is in absorption mode (meaning the panels are producing more power than the house battery can safely take) and use it at night and in the morning when there is no spare solar power without depleting the house battery. The 12v charger that I had purchased for my old Thinkpad (which died, prompting the replacement) works fine on my new one. I purchased a USB powered DVD writer to give me optical capability when I need it. This uses two of the three USB ports. The network problem I had this summer was the Millenicom 3g USB stick glitched and needed to be reset with their proprietary software that is only available for Windows and Mac. Lacking access to a Windows system that I could install software on, this meant that I was without my network connection. I used the Sandy Library (fast, free wifi) 30 miles from my worksite and occasionally wifi at a closer coffee shop or cafe which were both unreliable.

In recent times we have worked quite a bit to improve the NM process, i.e. the process newcomers go through to become members of the Debian Project. As it happens, I've just read Nathan's recent post on his NM experience and I think it is a perfect example of the joining experience we are trying to offer to all newcomers. But examples, be them positive or negative, are only anecdotal. To evaluate a process one needs actual data and someone analyzing them, ideally with a scientific approach. This is why I'm happy to host below a guest blog post by Kevin Carillo, who is doing a pretty thorough scientific study about how newcomers join a wide range of Free Software projects, including KDE, OpenSUSE, GNOME, and Debian, of course! TL;DR: if you started contributing to Debian after January 2010, there's a survey for you; participating will help us improving the NM process even further. Kevin's guest blog post follows.

---

Newcomer experience in Debian and other FOSS communities - Survey My name is Kevin Carillo. I am a PhD student currently living in Wellington (New Zealand) and I am doing some research on Free/Open Source Software communities. If you have started contributing to the Debian project after January 2010 (within approximately the last 3 years), I would like to kindly request your help. I am interested in hearing from people who are either technical or non-technical contributors, and who have had either positive or negative newcomer experiences. The purpose of the research is to work out how newcomers to a FOSS community become valued sustainable contributors. The survey is online and will be available until Tuesday, 27 November, 2012. Inspiration from Debian New Member Debian is a successful community that keeps attracting new contributors and that relies on a very unique way to handle the integration of new contributors: the New Member process. The idea behind the NM process is that it is some sort of filtering procedure allowing to only retain the individuals who have the potential to become valued sustainable contributors in Debian. Within Debian, there is a lot of enthusiasm and pride around the NM process as it seems to be functioning pretty well but the question is: Is this really enough to ensure that Debian remains a healthy and growing community? How does it compare to the way newcomers are integrated in other large projects such as KDE, GNOME, or in other non-Linux related communities such as Mozilla? I have to admit that the Debian NM process has been among the main sources of inspiration that made me embark in this research project. I have kept being quite impressed when talking to people who had gone through the process as all of them came out of it with a real passion for the project and love for its community. When reflecting on the reasons why the NM process succeeds, I have a feeling it is some instance of ritualized socialization. In other words, barriers and initiation rituals that require some effort from newcomers, generate members with higher commitment and sense of identification towards the Debian community. What do newcomers really experience? The main assumption that motivated this project is that attracting new members has become crucial for a large majority of FOSS communities but this is not a sufficient condition to ensure the success and prosperity of a project. A proportion of a community's newcomers must contribute to the well-being and growth of the community. Keeping all that in mind, FOSS projects have thus to do a good job at "socializing" their newcomers and turning them into 'good' contributors. Doing a good job here means that FOSS projects shall ensure that they help generate citizenship-like behaviors from newcomers by designing appropriate newcomer programs and procedures. FOSS communities rely on a wide array of initiatives to facilitate the integration of newcomers but it seems like the other side of the coin is less understood: What do newcomers really experience? And how does this influence their contributions and actions within a project? How is this study going to help Debian? The data will help gain insights about the experience of newcomers within the Debian community. In addition, it will allow to understand how to design effective newcomer initiatives to ensure that Debian will remain a successful and healthy community. The dataset will be released under a share-alike ODbL license so that Debian contributors can extract as much value as possible from the data. Since this survey also involves other large FOSS projects such as Mozilla, KDE, Gnome, Ubuntu, Gentoo, OpenSUSE, and NetBSD, it will also be possible to compare practices across projects in order to identify what works from what does not work when facilitating the integration of newcomers. About the survey This survey is anonymous. The raw dataset of everything one fills in the survey will be released under the ODbL. Since all the questions but one are optional, one is free to control the amount of information they are giving away about themselves. I expect the survey to take around 20 minutes of your time. If you know members of the Debian community who you think would be interested in completing it, please do not hesitate to let them know about this research. I will post news about my progress with this research, and the results on my blog. Don't hesitate to contact me. --- Kevin Carillo

For the last couple of years, one of the topics I have tackled with several columns and a couple of articles published, several presentations on conferences and many comments wherever I can is raising awareness on why security experts around the world oppose electronic voting. Slightly over a year ago, I started gathering all the published news (in Spanish, with some notes in English if I feel them relevant enough) that came to my greedy hands and archiving them, categorized as well as I could, into what I came to call an Electronic voting observatory. I don't feed it with the frequency I'd like, but overall I do feel there is an interesting amount of information in there. About a month and a half ago, via Twitterfeed, I set up a Twitter account where my bot echoes everything I get on that regard. So, while you can follow the observatory via RSS (as probably most readers of my blog will do), I know there are many Twitter users among you @e_voto might be interesting to you if you speak Spanish and are interested in the topic. I try not to be partisan on the information I copy there; of course I am subjective (I try not to refer to news which don't provide new insight or data points, or to obvious repeats), but I am doing this effort to follow the development as it unfolds, not to push my viewpoints.

So. for some reason, the danish tax authorities (Skat) has started requiring Adobe Acrobat for being able to see pdf files to work around a bug with handling of temporary files on Windows8 and shared computers and such. Luckily there is a couple of easy workarounds. Like modifying the Javascript to check things at runtime using some browser specific addons. Or just do it like I did and write a actual browserplugin. I cheated and used QtBrowserPlugin. Then my actual code was a couple of lines. Want to check it out? Look here: http://quickgit.kde.org/?p=scratch%2Fsune%2Ffakeacrobat.git. It just does enough to ensure the test succeeds. Work in: iceweasel and arora. For some reason, it doesn t work in konqueror/webkit nor in konqueror/khtml.

This is slightly old news now, but I've decided to starting blogging and this seems like a good place to start. At this year's debconf in Nicaragua I finally got around to applying to be a Debian Maintainer. Thanks to the various people who advocated me (and prodded me to apply in the first place!). My key was added to the DM keyring in mid-August. I intend to continue to maintain the various IVTV capture card packages that I maintain (ivtv-utils and xserver-xorg-video-ivtv) as well as continuing my involvement with the packaging of Xen and associated stuff like the kernel and installer. I also plan keep working on improved support for the DreamPlug, for which I have a few fixes queued up for post-Wheezy already. More recently I've bought a QNAP TS-210 (which is a nice little NAS that can run Debian) and ended up adopting the qcontrol package, which ended up being my first actual upload to Debian! Anyway, hopefully I'll manage to post here at least semi-regularly.