On Sunday I arrived to DebConf 13. It has been so much fun that I didn't have the time to post anything about it! As usual, I really enjoy meeting old friends and putting faces to nick names. Last night the Cheese and Wine party was once again great. Not everything has been partying, though. I've been discussing with Enrico ideas for recognising Debian Contributors, as he presented on his talk on Sunday. We still have to discuss further, and obviously, sit down and write a lot of code Yesterday we also met with Luk, and discussed what to do with the ancient net-tools package. We had had the idea of writing compatibility wrappers using iproute2, but that turned out to be too complicated and brittle. After looking a the current state of net-tools, and its reverse dependencies, we decided that the best way to go is to deprecate it by asking rdepends to migrate to iproute2 (for most of them it should be trivial), and then downgrade net-tools to optional. It won't be removed from the archive, as people will still want it, but it will not be required by any core functionality any more. In the next few days, we will be sending an email to debian-devel, and filling about 80 bugs to get rid of the dependency on net-tools, many with patches.

I ve been using Android phones for 2.5 years and for all my phones (Sony-Ericsson Xperia X10, Samsung Galaxy S, Samsung Galaxy S3, and LG Nexus 4) I ve bought gel cases. The gel cases are made of soft rubber which allows phones to bounce rather than break if dropped and also provide better grip (both for holding the phone and for resting it on a vibrating surface such as a tray in a car or plane). The cases have cost me between $12.50 and $15, I haven t felt inclined to pay any more because a case has always seemed like a needless expense, something that merely compensates for deficiencies in phone design. There are some problems with the gel cases, the first one is that they are rather ugly, while I m not really interested in decorating my phones it seems a waste to have a nice phone like the Nexus 4 which has a neat sparkling pattern on the back and then use a case that entirely covers it. The next problem is the fact that the gel cases tend to restrict access to the buttons on the outside of the case. I have been given a Rearth Ringke Fusion case for my Nexus 4 by MobileZap (this is a link for the Nexus 4 cases they sell) [1]. The case features a transparent layer of plastic at the back which protects the phone against having the rear glass of the case break (a known risk with the Nexus 4) while still allowing the user to admire it. With good lighting the sparkling pattern on the back of the phone can still be enjoyed, unfortunately this doesn t show up at all in my photo. It s impossible for a photo to capture a shimmering effect although other photographers have done a better job at showing off a Nexus 4. Also the transparent back to the case gives the option of putting any form of decoration between the phone and the case, for example one could print the logo of their Ingress team and put it between the phone and the case. One thing that is visible in the photo is the feet on the back of the case. With small feet at the corners the transparent back usually won t touch a surface that it rests on, this should prevent unsightly scratches to the back of the case. Also the feet can get some grip on the surface that it rests on, my car has a tray suitable for resting a phone which has a pattern of dimples that catch the feet of the Ringke case and prevent it from sliding. Finally the external buttons for power and volume control are not obstructed in any way. After using 7 phones of 4 different models with gel cases I ve become accustomed to buttons either being difficult to press or easy to press accidentally. The Ringke case allows the buttons to be pressed easily when needed but doesn t seem prone to accidental presses. I m not about to buy a new case for my Galaxy Note 2 (my main phone at the moment) because I don t like paying to replace something that works. But next time I buy a case I ll look for something better than a plain gel case, it s worth paying an extra $9 to get a good case for a phone that costs $350 (the current discount rate for a Nexus 4) or more. I definitely recommend the Ringke case for a Nexus 4.

• [1] http://www.mobilezap.com.au/32387/google/nexus-4/cases.htm

This blog post is a little recipe to do a Debian migration for a node using Puppet and some other good practices. We do all the following commands as root, which on of the exceptional situation where you should have a real root session (login through console, or su -). I tend to avoid using the X server while doing an upgrade, so my 'best' setup is to have a laptop to take note and check things on the internet and a session to the computer to upgrade (ssh + su - or login as root into console). In both case, I use screen during the upgrade so that I can handle disconnection. Create or update your admin-syscheck script First of all, a good practice is to have a script that runs various test on the system that checks everything is ok. This is not only for upgrade but in general. But in the case of upgrade, it can be particularly useful. I call this script admin-syscheck. This is a simple bash script. This script check various aspect of the system and serve me as my external worker to check the most advanced knowledge I have gathered about setting up a service. For example, I know that having *.bak or *.dpkg-dist in /etc/ means that something needs to be merged and a file should be deleted. Another example is about setting up the right alias for 127.0.0.1 and ::1 (which you can differentiate using getent ahostsv4 and getent ahostsv6). I have packaged this script and distributed it using a specific apt-get repository. You can just distribute it using puppet. I recommend to run it daily to track changes (e.g. after an apt-get dist-upgrade) and to check that my setup is aligned with my most up-to-date knowledge about setting up a service (i.e. this is my external worker). In our case we are interested in checking presence of old and new configuration files, before and after upgrading. Here is this specific section of my script:

if ! $IS_ROOT; then
  warning "Not trying to detect dpkg leftover file in /etc/."
else
  LEFTOVER_FILES=( $(find /etc/ \
      -name "*.dpkg-dist" -o \
      -name "*.dpkg-old" -o \
      -name "*.ucf-old" -o \
      -name "*.ucf-dist" -o \
      -name "*.bak") )
  for i in "$ LEFTOVER_FILES[@] "; do
    if [ "$i" = "/etc/hosts.deny.purge.bak" ]; then
      continue
    fi
    if $fix; then
      BASE=$ i%.* 
      cond_exec vim -d $BASE $i
      read -p "Delete $i (y/N)? " ans
      if [ "$ans" = "y" ]; then
        cond_exec rm $i
      fi
    else
       report_error "dpkg leftover file: '$i'."
    fi
  done
fi

(cond_exec allows to do a dry run, you can just remove it). Setting $fix to true will spawn a vim -d old new command where you can edit and then delete the leftover file. This is extremly handy. Upgrading to Wheezy I strongly recommend to read first the upgrade chapter of the release notes. This gives you a more complete overview of the upgrade procedure. I just go through the basic step here. 1. Update everything on the system:

$> apt-get update 
$> apt-get dist-upgrade

2. Check that the current configuration apply cleanly:

$> puppet agent --test

3. Run admin-syscheck:

$> admin-syscheck

And fix all the problems. 4. Disable puppet: I use a cronjob to run puppet, so I just comment the line for the job (/etc/cron.d/puppet-custom). You should disable puppet by stopping the daemon and preventing it to run by editing /etc/default/puppet and set START=no. 4. Fix your sources and pinning: Change squeeze to wheezy in /etc/apt/sources.list and remove useless files in /etc/apt/sources.lists.d/. (You may keep certain sources that refers to stable, like google-chrome.list).

$> rm /etc/apt/sources.list.d/* # Check if this ok to do this with your system.

Although, I tend to fully purge /etc/apt/sources.list expect for the main line (removing backports and security is fine for a short time). The first run of puppet after upgrade will anyway reset this file.

$> rm /etc/apt/preferences.d/* # (at least the ones that do pin some version)

You can although remove all pinning from /etc/apt/preferences. 5. Now you start the real upgrade:

$> apt-get update 
$> apt-get dist-upgrade

6. During the upgrade you will be asked if you want to keep old configuration files or install the newer one from the maintainer. I have always wondered what to answer to this. But here is the answer after a few major upgrade: always install configuration files from maintainer if the service has no ultra-specific settings that could break during the upgrade. The only file, that I should not upgrade on my system, is /etc/sudoers. In this very specific case, you need to make sure before the upgrade that the old and new configuration can coexist. In the squeeze to wheezy case, I have just setup a few extra augeas rules to set the secure_path before the upgrade and it was fine. This is typically the kind of situation where you are thankful to have a real root session. 7. The upgrade can be long and require various fixing to remove/re-add packages to circumvent problems. At the end you will have a set of file *.dpkg-old and *.ucf-old (and some *.dpkg-dist and *.ucf-dist). The *-old files are your old version of the file, while the corresponding files match the maintainer version of it. The *-dist files are the maintainer version of the file and the corresponding files match your old version of it. Starting from here you have 2 options:

• This is one of the first computer you upgrade, go to 'first upgrade'.
• Your puppet configuration for wheezy is already bullet proof, go to 'further upgrade'.

First upgrade This is the tricky part, you'll have to spend a little time on it: 1. Go over all *. ucf,dpkg - old,dist and merge them with the corresponding configuration file. Use admin-syscheck with fix=true 2. Make a copy of your /etc directory into /etc.new:

$> cp -rp /etc /etc.new

3. Run puppet again:

$> puppet agent --test

4. Disable again the automatic run of puppet, if the previous command has re-enabled it. 5. Make a diff between /etc and /etc.new. Since you have a run of puppet, you know what has changed and should not have changed.

$> diff -Nurd /etc.new /etc

Everytime you find some files that doesn't match your expectation for the upgrade with puppet, change the corresponding puppet manifest to have what you expect. For example, if this is a file:

if ($lsbdistcodename == 'wheezy')  
  file  
    "/etc/foo":
        source => "puppet:///files/foo.wheezy"
    
  else  
  file  
    "/etc/foo":
        source => "puppet:///files/foo.squeeze"
    
 

People working with augeas and puppet, will appreciate the fact that they probably have 0 changes to make for this to work (since it only does a few replacement in configuration files). 6. Once you are happy with the changes, copy back /etc.new to /etc and go to step 3 until the difference is almost 0. 7. Re-enable automatic run of puppet. Do this procedure for a least each computer category you have (e.g. Desktop and Server nodes). Once you are fully confident your new puppet setup works, you will be able to use 'further upgrade' for the other nodes. Further upgrade. This one is super easy compare to a first upgrade: 1. Re-enable puppet and have it run at least once:

$> puppet agent --test

2. Merge *. dpkg,ucf - dist,old with corresponding files (you can run admin-syscheck with fix=true). This is mostly a sanity check since you should have already solved most problem with the 'first upgrade' procedure. That's it. Enjoy your upgrade to Wheezy with puppet.

Since becoming interested in triathlon in October of last year, my goal in 2013 was not to just finish a "70.3" (or "Half-Ironman"), but to complete one in under 5 hours. At the time, each discipline was woefully inadequate; I had not swum in over a decade, my cycling was average and I had only begun running again after years away from exercise. The somewhat arbitrary target time would dictate my training. For example, the high proportion of time spent on the bike combined with the injury-sensitive nature of running meant that cycling would have a highest return on investment of the three disciplines. Despite that, I would need to take the run seriously but carefully - I decided to enter a series of monthly 10K races where I could steadily reduce my times over the year. Races themselves formed a crucial part of my preparation and a carefully balanced race calendar was surprisingly important, balancing upcoming milestones that would provide an achievable goal as well as uncovering weaknesses in enough time so they could be worked on. Whilst I did post about my first triathlon, I felt no compulsion with the interleaving five or six races as I was evaluating them in the context of the 70.3 rather than as races in their own right.

DebConf! The venue here at Le Camp is pretty much perfect. Short walking distances, organic layout of the buildings, and a stunning view of the lake. I would be hard pressed to think of other venues which could be as nice... After arriving Fri/Sat night at 0330, Saturday was spent setting up the Access points: This little green valve caused a power outage in the server room, messing with servers, and resetting several switches to old configs. Xtaran had a lot of fun as a result of this. The ikiwiki BoF on sunday was rather interesting. I will try to publish some notes from this BoF and the other Git-related ones towards the end of the week. The Gitify ALL the things BoF managed to fill the room from "full-ish" over "good thing we don't need the beamer and can use the space in front of the whitescreen" over "out of chairs" over "the chairs from other rooms won't fit any more" to the final state of "people stand around near the walls and in the doors". At a total of 54 people, turnout has been... unexpectedly high.. The BoF started at 1130 and usually, slots are 45 minutes long. We extended our BoF into lunch time (I chose the slot just prior to lunch for precisely that reason) and finally finished at around 1245, i.e. 30 minutes late. After a quick show of hands on if there's interest in another BoF, I applied for and got the next slot, tomorrow at 11:30, once again in BoF room 1 and just before lunch. It's called Gitify EVEN MORE of the things and will expand on use cases and best practices. At a guess, we will focus on managing configurations and photos in default and complex situations. Sadly, neither of those BoF are taped. Afterwards, I had a chance to sit down with Lucas Nussbaum to talk over some points regarding the Debian Trademark Team. Finally, during Why Debian should (or should not) make systemd the default (it probably should not, but that's a different story), my kernel panicked. 3.9 and 3.10 have been less than ideal on my new X1 Carbon, but this was the first panic. I was not even done cussing and Ben Hutchings suddenly appeared on my side, telling me that yes, this particular module (mei) has been causing issues recently. As a closing note, I am really enjoying my first DebConf. Great venue, great people, great content, winebeer and cheese party tonight, and I found out that we have a fire place and fire wood...

Seems like DebConf 13 is in full swing, I'm not heading over until tomorrow because I spent the weekend at the Bloodstock Festival. As sad as I am to miss the Cheese and Wine party tonight, having seen a dozen or so excellent bands since Friday, lubricated by a few gallons of Hobgoblin, and rounded off by Exodus, Anthrax & Slayer last night I think I made the right call! So I got home around lunchtime today, unpacked my rucksack, scrubbed myself clean, repacked again for Switzerland (no tent this time). Next up is a curry with my parents tonight and then catching the Eurostar tomorrow morning, I'll have plenty of time for hacking on my cubieboard2 on the train and finally arrive in Vaumarcus tomorrow evening. See everyone soon!

Debian France and Debian Swiss associations are now selling products at Debconf. We are now selling

Buff		23 CHF / 18 euros
Black polo		31 CHF / 25 euros
Rugby polo		50 CHF / 40 euros
Mousepad		13 CHF / 10 euros

We have also some new hoodies.
They come in 4 colors: black, white, grey and dark blue.
With or without zip: Without zip: 44 CHF / 35 euros
With zip: 50 CHF / 40 euros With also have hats: Price: 10 CHF / 9 euros We have also the Debian umbrellas and knifes.
Photo credit Kibi For those who are at Debconf, they are for sell at the Debconf front desk from 4 to 6 and will be probably available for sell on enventelibre after the event.

The Fay compiler is a simple way to build fairly comprehensible javascript code from Haskell source. It occurs to me that it should be rather easy to modify Fay to emit perl code rather than javascript. This would allow contributing things like plugins to various perl programs, without writing perl. Of course, the same idea could probably be used to compile Haskell to other languages like python, but perl seems particularly well suited as a second Fay target, since javascript and it have quite similar syntax and similar support for features like closures which Fay relies on. I do not have time to work on this idea myself. It would be a good project for a beginning Haskell programmer. You probably don't even need to fully understand monads to do it! Essentially, look at Fay output examples, translate them from javascript to perl, and then much of the code changes in Fay would probably be in simple string generation code.

---

I will forward any bitcoins sent to the address 149eBtWS6i8cwQdPQJJ8hAGpDuEqNidyTj to whoever makes this. If it doesn't happen in 1 year, any donations will be forwarded to the EFF instead.

Woken at 3 am by fil singing "Join Us Now And Share The Software" (all verses!) I could not get back to sleep and spent 3 hours thinking up a new take on the hopelessly blocked dpkg-source v3 (git) format. A diagram of the new plan, which should meet all ftpmaster requirements, is posted in Hacklab 1. I am looking for reviewers. A rather hard to read photo (DebConf needs mandatory whiteboards!) is available here: Fil has paid me back in full for his drunken carousing by gifting me a Rhombus-Tech system on a chip on a PCMCIA card. I've checked this new computer, which features a modern multicore ARM CPU, into my wallet. And that's 10% of what went on today at DebConf for me, and we've not even gotten to the cheese and wine party tonight.

grep is designed to print lines matching a given pattern, but I often need to print only the matching part, discarding the remaining. I used to do that with sed, but it involves several actions: match, replace the line by only the matching pattern and print. Fortunately, GNU grep has an option to do just that:

-o, --only-matching

Print only the matched (non-empty) parts of a matching line, with each such part on a separate output line.

Unfortunately it is not a standard option, so it may be missing on non-GNU systems.

I also soon will be on my way to Debconf13 and those who asked for more photos from the place on Planet Debian will soon start getting their fill Privacy note: as always, I will be trying to balance the need for people to get lots of pictures as fast as possible with privacy of people, who do not want to be in published photos. The way this has been done before and will be done this time (at least from my side) is that:

• I will myself filter the photos so that bad or embarrassing photos would not be published
• If you see a photo of yourself published that you do not want to be, ask me and I will take it down ASAP
• If you see me taking a picture that you don t want to be taken or published, just come up to me and say so and I will erase it
• If you do not want to show up on any published pictures, please come up to me at any time and say so. I will have to then to take a full face portrait of you for my own reference (my memory is not that great) and will be my best to avoid even taking pictures with you in the shot

Update: http://www.aigarius.com/blog/2013/08/12/not-going-after-all/

I was very excited to go to Debconf13, but in the last minute I caught some kind of virus and went down with fever in the night before the flight. I am sure Wouter will take over group photo duties. And I will just take this week of vacation to rest up and check out the video streaming

A hectic day and now we use GMime for all MIME-fu. This has allowed me to decode headers correctly, setup MIME parts properly in outgoing mails with attachments, and cleanup the code-base. The next release of Lumail will contain basically just this change, as it is pretty drastic. But first I need to work out how to make binaries for Squeeze compiled against the back-ported version of gmime-2.6.x. (Previously we used libmimetic. Which was awesome in its way, but caused me some pain with RFC 2047 header-decoding.)

I m heading to DebConf! Hooray!

Two months ago I complained about how hard it was to get patches into PHP as the core member didn t give much attention for pull requests on github. After posting it on the blog, I raised the issue in the developers mailing list and was suggested to join and help. A month ago, I started sending a weekly report about new / pending / merged / closed pull requests and got cooperation from the community with reviewing the pull requests and processing them. In this period 40 requests were dealt with (obviously not all merged), and much more are work in progress while the developers are commenting on the requests. The credit is obviously for the contributors for the patches and the core developers for the work. Stas Malyshev was of special help with this change. You re welcome to follow at https://github.com/php/php-src/pulls
Filed under: PHP

Hi everyone! We now have both Qt4 and Qt5 in the archive. Those using Qt4 should not need to make any changes in their packages, although you can be extra-safe with a few steps. Don't rush, just read below.
Some backgroundSune took the time some months ago to consult upstream for a sane way to allow both SDKs to coexist without us distros having to reinvent the wheel choosing which tools have to be in use in each case.

After a long discussion, upstream decided to write qtchooser (already in the archive) to be able to select between Qt4, Qt5 and even special user's cases like cross-platform builds.

So instead of going trough Debian's alternatives as we did with Qt3/Qt4, we will make use of this new tool.
My package uses Qt, how should I proceed?There are many ways of choosing either of the versions of Qt:

- Using any qtchooser method (preferred):

* Exporting QT_SELECT with 4, qt4, 5 or qt5 as a value in debian/rules.
* Call the tool using the '-qtx' parameter, where x can be replaced with any of the options above.

- Build-depending on qt4-default or qt5-default. You can't B-D on both of them, as they can't coexist.

It is good to notice that:

- any qtchooser method will take precedence over build depending on qtX-default.
- If you export XDG_CONFIG_DIRS it will ignore the default paths to qtchooser's configs we setted up in the packages.

We have also provided qt4-[arch-triplet] and qt5-[arch-triplet] options for special cases.

Once again, if you are already using Qt4, there is no need to rush. See below.

Can is use both Qt4 and Qt5 in my package?You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this. At the time of this writing I don't know of any examples yet.

So are you going to break the archive with a big transition?No, we have done our best to avoid having to make any changes to existing Qt4 packages. Qt tools should default to Qt4 except if overriden by any method described above.

My package uses Qt4, can I leave it as it is?While there is no need to apply the changes in this case, explicitly setting the Qt version will surely not hurt at all. But don't rush ;-)

[no pictures here, just a short report]. Today DebConf, this year's edition of the annual Debian developer conference, started with two inspiring talks about Debian proper, one by Lucas Nussbaum, the other by Joey Hess. This also means that yesterday DebCamp ended, the period preceeding DebConf and dedicated to working on Debian together with others. Here's a short report from my point of view: I arrived here on Tuesday, the first day of DebCamp. I immediately fell in love with the venue, & despite the early stage of setup, everything I needed was working fine for me from the very start. Like in previous years, I used the time to do work in the Debian Perl Group, especially taking advantage of the presence of other team members. That's the great thing about DebCamp & DebConf: collaborating in real-life & real-time, from quickly asking a question over sitting together to think about solutions for a problem to "just" chatting & thereby developping ideas for the future. In the previous days I

• tried to get down the amount of packages with not-yet uploaded new upstram releases;
• looked into the pending bugs around the Perl 5.18 transition;
• investigated with others the details of the upcoming new timezone file handling in the Perl world, which will make our lives easier but still needs some work on the Debian side;
• prepared with others the Perl Group's BoF that will take place during DebConf on Thursday;
• helped with the creation of a new pkg-perl-tools package.

I really enjoy my time here, & I'm especially happy to meet some people for the first time in meat space. This is only possible due to the generous support of the DebConf sponsors & the immense efforts of the DebConf team. Thank you!

Yesterday evening I've arrived at DebConf 13. I was quite tired after traveling so I just had few beers and went to bed. The travel went quite well besides somebody else broke wine and my suitcase was all wet from it. Fortunately almost nothing got inside so I have some clean clothes for next week :-). As I went to bed quite early, I woke up early as well so I went to short walk to see what is nearby:

Filed under: English Debian Photography 0 comments Flattr this!

Cloud is passing the hype curve and we are seeing more stable developments and offerings on the market. Lately I ve been playing with RedHat s Openshift. Openshift is a PaaS (Platform as a Service) offering that intends to be an alternative for vendors such as Heroku. The focus for such offerings is to give developers enough flexibility and tools that handle the application deployment and maintenance process in a way that is integrated with their existing development workflow and tools. I ve been using Heroku for a while to deploy small to medium size projects. I liked the tools and developer-centered experience they offer. Openshift is quite new on the market and it comes in two flavors: Openshift Online, which is a PaaS service, and Openshift Enterprise, which allows organization to setup a PaaS within their own infrastructure. Both of them powered by the Openshift origin software. I ll not compare Heroku vs. Openshift feature by feature but from my experience I can tell that Openshift is far from mature and will need to give developers more features to increase adoption. When developing applications for Openshift developers are given a set of application stack components, similar to Heroku s buildpacks. They call them cartridges. You can think of them as operating system packages, since the idea is the same: have a particular application stack component ready to be used by application developers. Most of the cartridges offered by the service are base components such as application server, programming language interpreters (Ruby, Python, etc), web development frameworks and data storage, such as relational and non-relational databases. Cartridges are installed inside a gear, which is a sort of application container (I believe it uses LXC internally). Unsurprisingly this Openshift component doesn t leverage on existing packaging for RHEL 64bit, the OS that powers the service. I d expect such things from the RedHat ecosystem. I had to develop a cartridge to have a particular BI engine to be used as embed component by application developers. After reading docs and reference I realized this can be piece of cake, since I have packaging experience. Wrong. Well, quite so. The tricky part for Openshift Online is that it does not offer enough information on the cartridge install process so you can see what s going wrong. To be able to see more details on the process you ll need to setup an Openshift origin server and use it as a testing facility. Turns out that having a Origin server to operate correctly is also a challenging task and consumed a lot of my time. Over the recent weeks I ve learned from origin developers that such features are on the road map for the upcoming releases. That s good news. One of the challenges I had, and still have to figure out, is that unlike the normal cartridges mine didn t required to launch any service. Since it is a BI engine I just needed to configure and deploy to an application server such as JBoss. Cartridge format requires to have a sort of service init.d script under bin along with setup, install and configuration scripts that are ran on install. Although every day I become more familiar with origin and Openshift internals I still have work to do. Nice thing is that I was already familiar with LXC and Ruby-based applications so I could figure where things are placed and where to look for errors on origin quite easily. The cartridges are on my github account if you care to take a look and offer advice.

In the Dutch language area (Netherlands and Flanders) most e-book publishers changed from using DRM to using a watermark since February. It's now something like 62% with watermark, 24% with DRM and 14% without either. I was hoping that more with move to the watermark, but it doesn't seem to change much. The watermark in the e-books are used to find the original buyer in case of piracy. The information in the e-book does not itself identify the buyer, it just some random ID. That ID can then be used to trace back to buyer. We work with a 3rd party to deliver the e-books to our consumers. They get a random string from us that we can use to trace back the order, and from there we can trace back who bought it. The 3rd party than generates their own random string and puts that in the e-book. They only only keep those 2 random strings, and so have no way to trace this back to the buyer, we are the only one that known who bought it. And I think this is how it should work. I think this is also what the privacy laws require us to do. But now we got a new contract that states that we must directly give information about the buyer if some anti-piracy agency (BREIN) finds an e-book file online. We must keep the information about the buyer for minimum of 2 years and maximum of 5 years. And if we don't sign the contract we won't be allowed to sell e-books with watermark anymore. So this means that they want to bypass the normal judicial system, and probably contact those buyers they accuse of piracy directly. I questioned that this was legal. They say that it is legal according to the Dutch privacy law, but I have a hard time interpreting any of the options in article 8 as that we can give that information without the explicit consent of the person. I guess you can interpret option f in several ways, and that their lawyers do it differently than me. This will probably remain unclear until some court decides on it.