I no longer use this PAM module, since I don't use AFS any more, and it's actually orphaned. But there was a bug report against the Debian package that was actually a PAM issue, not an AFS issue, so I went ahead and fixed that. The bug was that running sudo when you had the AFS PAM module enabled would delete your tokens. This was because sudo calls pam_setcred and pam_open_session in a somewhat strange way, leading the PAM module to think that sudo was taking ownership of the token but without putting the user in a new PAG. Then, when sudo closed its PAM session, the module would erroneously delete the token. The fix is to not set the flag to skip subsequent open_session and close_session handling when called with PAM_REINITIALIZE_CRED or PAM_REFRESH_CRED. This preserves correct session handling behavior and avoids this issue. Also with this release, I finally rewrote the test suite to use my generic PAM test suite code, and got rid of a bunch of old, legacy testing code. I lost one test for which the new test framework doesn't have enough hooks, but it wasn't particularly important, and the new code is much cleaner and more data-driven. There are also a few other, accumulated fixes, such as a compilation fix on Solaris 11, and a significant modernization of all of my common support libraries. (The last official release was in 2011!) You can get the latest version from the pam-afs-session distribution page.

Review: Magic's Pawn, by Mercedes Lackey

Series:	Last Herald Mage #1
Publisher:	DAW
Copyright:	June 1989
ISBN:	0-88677-352-0
Format:	Mass market
Pages:	349

Continuing my (very slow) re-read of Mercedes Lackey's Valdemar series. I've read all these books before (this series several times, in fact), but long before I started writing reviews. Vanyel is a legendary hero by the time of Talia (the hero of the first Valdemar series, starting with Arrows of the Queen). Talia was reading stories about him at the start of her story: the mage Herald who defended Valdemar against its enemies in the distant past. This is the first book of the trilogy that tells his story, starting (as Lackey's books often do) from rather inauspicious beginnings. Vanyel is the son of a border lord, and about as poorly suited for it as possible. He's small, pretty, entirely uninterested in the hammer-and-tongs sword fighting the arms master wants to teach him, and also gay, not that he has any idea that's even something that exists and has a name. His only ally was his sister, who is now off serving in Valdemar's military. Most of his life is spent hiding, feeling utterly lost and out of place, and wishing he could be a Bard. This is a Valdemar story, so if you're familiar with the series, you know what's coming next. What might come as a surprise is that "next" is quite some time into the story. Vanyel does not get rescued from his situation by a Companion. Instead, his father decides to exile him to the capital under the care of his aunt, who he's only met once and who didn't think highly of him. He expects to be even more miserable, and shuts emotionally down in anticipation. This is one of those books that I remembered as being better than it actually was, and one of the reasons why I enjoyed it less than I expected is that far too much of this book is devoted to describing Vanyel's mental state. This usually involves various elaborate emo analogies (which can be a failing of this series in general), and it's quite hard to maintain sympathy for Vanyel. Lackey gets us to feel for him at the start of the book, when he's really in a bad situation. But once he gets to the capital, he's his own worst enemy, and it's hard to avoid the desire to shake him. I also didn't remember just how much I disliked Tylendel. I'm sure it will come as a surprise to no one that Vanyel eventually meets someone who draws him out of his shell and gives him a reason to want to live. Unfortunately, that person, despite a positive surface impression, is self-obsessed, unstable, and not above manipulating Vanyel into actions that are so obviously catastrophic that it makes one want to yell at the book. I disliked this part of the book so much that even a Companion's choosing was overshadowed. The book does get a bit better after that truly awful middle, but it never hits the emotional stride that other Valdemar books hit. Lackey does introduce the Tayledras, which will be hugely important in later books in this series (and who are some of my favorite characters), but there too I prefer their later appearances. Vanyel's inability to see a good thing when it hits him in the face, punctuated by being occasionally cruel to the people who try to help him, makes it quite hard to enjoy his slow path to becoming a better person. I remember really liking this trilogy, so I think it gets better. But I also remembered liking Vanyel's claiming, and it didn't do much for me on a re-read. I can only recommend this one as a necessary preface to the later books in the trilogy, and expect to need a high tolerance for constant woe-is-me despair. Followed by Magic's Promise. Rating: 5 out of 10

Finally I found the time and peace to watch one of the strangest movies that I have ever seen, Werner Herzog s (Offical Site, Wikipedia) Fata Morgana (Wikipedia, IMDb). Footage prepared for a SF movie that never realized, converted into an impressionistic allegory and movie full of phantasms.
Fata Morgana is a movie that escapes every description. Having read several critics voices, as well as Herzog s comments in the excellent interview/(auto)biography book Werner Herzog A guide for the perplexed, I was eager to see this old and special movie. Having laid my hand on a collection of Werner Herzog s old movies recently, I prepared some good Japanese sake, and was ready to enjoy the move. The initial sequence of airplanes landing on a very hot day, again and again, sets the stage for a series of dream-like sequences in this movie. Divided into three parts, the movie tells its story only by visual impressions and the reading of the Mayan creation myth Popol Vuh, at times intermixed with some Leonard Cohen songs. Part One Creation introduces the desert as the origin of the world, accompanied by the initial creation myth before humans were formed. Part 2 Paradise is when humans enter into the desert. Full of ramshackle houses and rotten buildings, the contrast of the spoken words and imaginary cannot be more stunning. The final part 3 The Golden Age is full of absurdities and strange appearances, not surprisingly also most humans appear here. Watching this movie is more a visual experience for me than about seeing a story line. While there are many ways to interpret the relation between the Popol Vuh and the movie sequences, for me it is more a visual experiment that tries in some sense to hypnotize the audience. For those who love strange movies, an absolute must. For all others probably a torture.

Review: The Three-Body Problem, by Cixin Liu & Ken Liu

Series:	Three-Body Problem #1
Author:	Liu Cixin ( )
Translator:	Ken Liu
Publisher:	Tor
Copyright:	2006, 2014
Printing:	November 2014
ISBN:	1-4668-5344-1
Format:	Kindle
Pages:	399

Liu Cixin ( ) is one of the best-known and most popular SF authors in China, but, due to the paucity of translated SF in the English-speaking world, was largely unknown to English-speaking SF readers. That made this translation by Ken Liu (no relation) highly anticipated: a window into a large world of SF by authors most of us have never read. And Ken Liu is an excellent writer in his own right (see, for instance, "The Literomancer" or "Altogether Elsewhere, Vast Herds of Reindeer"), which was a hopeful sign for a good translation. Indeed, the translation is very good. One can tell that the book comes from a different literary tradition, but primarily from unusual (to US readers, at least) emotional focal points for the characters and lots of Chinese history that the author feels little need to explain. (Ken Liu adds translator notes for the bits most likely to lose non-Chinese audiences.) I found the characters a bit odd and occasionally hard to identify with, but I didn't mind: it added to the feeling of exploring a slightly different literary tradition with different character conventions. Unfortunately, the end of the book went entirely off the rails, at least for me. The Three-Body Problem opens during the Cultural Revolution, with the murder of Ye Wenjie's father, a physics professor, and the suicide of her advisor and friend. Two years later, she's at a work camp in inner Mongolia, cutting trees, numb, keeping her head down. But a traveling journalist smuggles in a secret copy of Silent Spring and gives it to her. The book both hardens her own belief in the evil of humanity and gets her into deeper trouble when she agrees to recopy a draft of a letter to the central leadership about the environmental devastation caused by the logging. Ye Wenjie is forced to choose permanent exile to an experimental radar facility on a remote mountain in Mongolia. Ye Wenjie is vital to the slowly-developing plot of the book, but this is the last the reader sees of her for some time. Part II jumps to present time and to a different protagonist: Wang Miao, a distinguished nanotechnology researcher who is recruited by the PLA and the police into a secret war room. Distinguished scientists are killing themselves in frighteningly large numbers, including one that Wang Miao had a crush on. She left a suicide note before overdosing on sleeping pills, one that says only, cryptically, that physics doesn't exist. The government is desperate to figure out what's going on. The "radar" facility and the suicide of scientists are linked, of course, but it takes much of the book for Wang Miao and his colleagues to piece together how. Key clues come in the form of an odd puzzle virtual reality MMORPG that becomes a popular sensation. In it, players find themselves on an alien world whose suns rise and set at strange and unpredictable intervals: sometimes far too far away and horribly cold, sometimes far too close and destructively hot, and sometimes not seen for long periods of time. The players can somehow dehydrate themselves and the rest of the population to weather the worst seasons, but life is a constant struggle against apparently unpredictable elements. Despite that, players slowly find ways to build civilizations and attempt to predict the strange cycles of heat and cold. It takes the characters a long time to understand what's happening. Readers will probably be much faster, since they have out-of-band information the characters don't. At first, this game seems entirely unrelated to the suicides of the scientists or, for that matter, to Ye Wenjie, who is easy to almost forget. But they all weave together in a way that's almost compelling. I say almost because the motivations of the characters are quite tangled and interesting, but the science is... awful. Those who have read my other book reviews know that I don't insist on hard science in my SF. Usually I'm willing to roll with it, and I can read past even obvious scientific nonsense. But science is critical to the plot of this book; some very specific actions, with a detailed in-book scientific justifications, are the underpinning of the entire plot. And they make utter nonsense of physics. I've rarely had science in a novel destroy my suspension of disbelief this thoroughly. Physics isn't even alone: biology, chemistry, computing, and astronomy are all in for it as Liu reveals the causes of the book's events. I wanted to be engaged by the conflict of ethics and philosophy that drive the plot, and some of that conflict is quite interesting. But every other page would have another colossal pile of scientific nonsense that would throw me out of the book again, usually in the service of a set piece that missed grand and landed on absurdly silly. Be warned that this book also ends on a bit of a cliff-hanger, and there are two more books in the series. The second has been released in a translated edition, but with a different translator, which is disappointing (Ken Liu did an excellent job); the third isn't out yet. If you can get past the awful science, The Three-Body Problem is doing some interesting things. The characters are a bit wooden and forgettable, but the philosophical problems they encounter are ones I don't see often in western SF. This a refreshing change, and I'm interested enough that I'm still considering picking up the sequels. But the science hurts the book so badly. Followed by The Dark Forest. Rating: 6 out of 10

Key signing parties are a pain and hopefully, one day, we will have better ways to authentication keys than reading hexadecimal strings out loud. The Zimmermann Sassaman key-signing protocol makes them much more bearable already by having only one single hexadecimal string read out loud. That string is the cryptographic hash of a document given to every participant listing all participants and their fingerprints. If everyone has the same hash, then we assume that everyone has the same document. Then, participants in turn will confirm that they fully recognize the fingerprint listed in the document. Alexander Wirt wrote a small key server dedicated to receive keys from the participants. There is also a script that will generate the document from the submitted keys and a ready-to-use keyring. The latter can be run automatically using inoticoming when a new key arrives. Finally, it would be nice if participants could confirm that their key has been properly added to the document, e.g. by making the list available on a web server. Setting all this up seemed like a good opportunity to play with Tor hidden services and systemd-nspawn. Here's the setup log with some comments. This was done on a small armhf device with Debian Jessie. Create a new hidden service Edit /etc/tor/torrc on the host to setup the hidden service:

HiddenServiceDir /var/lib/tor/ksp/
HiddenServicePort 80 10.0.0.2:80
HiddenServicePort 11371 10.0.0.2:11371

Run:

host# systemctl reload tor.service

Then, to learn the name of the newly created hidden service name:

host# cat /var/lib/tor/ksp/hostname
ksp123456789abcd.onion

Install the container debootstrap as always:

host# debootstrap --variant=minbase jessie /var/lib/container/ksp

Preliminary container configuration We do the following step simply using chroot as we are going to use the host network configuration for this stage. The container itself will not have access to the Internet.

host# chroot ksp

Let's set the hostname:

ksp-chroot# echo 'ksp' > /etc/hostname

Set up APT:

ksp-chroot# echo 'deb http://httpredir.debian.org/debian jessie main' > /etc/apt/sources.list
ksp-chroot# apt update

We need dbus to get systemd to work well:

ksp-chroot# apt-get install dbus

Make sure that we can resolve our own hostname:

ksp-chroot# apt-get install libnss-myhostname
ksp-chroot# sed -e '/^hosts:/s/files/myhostname \0/' -i /etc/nsswitch.conf

These are dependencies of the keyserver:

ksp-chroot# apt-get install --no-install-recommends libhttp-daemon-perl \
                liblog-loglite-perl libproc-reliable-perl

These ones are needed for the script generating the list:

ksp-chroot# apt-get install bzip2 inoticoming

And we will use the smallest HTTP server available:

ksp-chroot# apt-get install netcat-traditional micro-httpd

Finally, let's unconfigure all DNS resolvers:

ksp-chroot# echo > /etc/resolv.conf

And we are done with the chroot:

ksp-chroot# exit

Let's retrieve the ksp-tools repository now:

host# cd /var/lib/container/srv
host# git clone https://github.com/formorer/ksp-tools

Container setup We will now start the container with a shell to configure it:

host# systemd-nspawn -D ksp --network-veth

Let's ask systemd to configure the network for us:

ksp# systemctl enable systemd-networkd

Let's not forget to set a root password:

ksp# passwd

We add a dedicated user to run the keyserver and the list generation script:

ksp# adduser --system --group --disabled-password --disabled-login --home /var/lib/ksp ksp

Let's configure the keyserver:

ksp# cp /srv/ksp-tools/keyserver.conf /var/lib/ksp/keyserver.conf

Let's edit /var/lib/ksp/keyserver.conf:

homedir = /var/lib/ksp

Now create the GnuPG homedir for the keyserve:

ksp# mkdir /var/lib/ksp/keys
ksp# install -d -o ksp -g ksp -m 0700 /var/lib/ksp/keys/gpg

Copy the template list generator:

ksp# cp -r /srv/ksp-tools/example /var/lib/ksp/keys/ksp123456789abcd_onion

Create the key repository:

ksp# install -d -o ksp -g ksp -m 0700 /var/lib/ksp/keys/ksp123456789abcd_onion/keys

Create a directory accessible to the web server where the participant list will be generated:

ksp# mkdir -p /var/www
ksp# install -d -o ksp -g ksp -m 0755 /var/www/keys

Let's configure the list generation script by editing /var/lib/ksp/keys/ksp123456789abcd_onion/conf/vars:

KS=ksp123456789abcd.onion
export GNUPGHOME=/tmp/ksp-gpg
KSPFILE="/var/www/keys/ksp-event.txt"

Don't forget to adjust the header in /var/lib/ksp/keys/ksp123456789abcd_onion/conf/list-header. Now we create a unit file for the keyserver in /etc/systemd/system/keyserver.service:

[Unit]
Description=Key signing party keyserver
[Service]
Type=simple
Environment="KSP_HOMEDIR=/var/lib/ksp"
ExecStart=/srv/ksp-tools/bin/kspkeyserver.pl --nodaemonize
User=ksp
Group=ksp
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/ksp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target

Another unit for the list generator as /etc/systemd/system/ksp-list-generator.service:

[Unit]
Description=Key signing party list generator
[Service]
Type=simple
EnvironmentFile=/var/lib/ksp/keys/ksp123456789abcd_onion/conf/vars
ExecStart=/usr/bin/inoticoming --foreground /var/lib/ksp/keys/ksp123456789abcd_onion/keys --chdir /var/lib/ksp/keys/ksp123456789abcd_onion bin/generate-list \;
User=ksp
Group=ksp
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=/var/www/keys
CapabilityBoundingSet=
[Install]
WantedBy=multi-user.target

For the web server, we first configure a socket listening on port 80 in /etc/systemd/system/micro-httpd.socket:

[Unit]
Description=micro-httpd socket
[Socket]
ListenStream=80
Accept=yes
[Install]
WantedBy=sockets.target

And then the web server in /etc/systemd/system/micro-httpd@.service:

[Unit]
Description=micro-httpd server
[Service]
ExecStart=-/usr/sbin/micro-httpd /var/www/ksp
StandardInput=socket
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
CapabilityBoundingSet=

Let's now ask systemd to start all of these at boot time:

ksp# systemctl daemon-reload
ksp# systemctl enable keyserver.service
ksp# systemctl enable ksp-list-generator.service
ksp# systemctl enable micro-httpd.socket

One way to kill the container is to type Control+] three times. Boot the container Let's get this party started!

host# systemd-nspawn -b -D /var/lib/container/ksp --network-veth

Hopefully, things should work now. Participants to the KSP should then be able to send their key with:

$ torsocks gpg --keyserver ksp123456789abcd.onion --send-key $KEYID

(Sadly, this is broken with GnuPG 2.1 at the moment.) The participant list should be available at http://ksp123456789abcd.onion/ksp-event.txt. Final steps We need to tell systemd to start the container started at boot time:

host# systemctl enable systemd-nspawn@ksp.service

But the default command-line will not use a dedicated network, so we need to override that part of the configuration. First create a directory:

host# mkdir /etc/systemd/system/systemd-nspawn@ksp.service.d

And edit /etc/systemd/system/systemd-nspawn@ksp.service.d/use-network-veth.conf:

[Service]
# The empty line because we want to override all previous ExecStart
# and not add an extra command
ExecStart=
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --directory=/var/lib/container/%i --network-veth

Let's reload systemd and verify that our snippet is there:

host# systemctl daemon-reload
host# systemctl cat systemd-nspawn@ksp.service

All good? Let's start it:

host# systemctl start systemd-nspawn@ksp.service

One should also add a firewall to disallow any outgoing connections from the ve-ksp interface as an extra protection.

A few days ago, the French equivalent of Hacker News, called "Le Journal du Hacker", interviewed me about my work on OpenStack, my job at Red Hat and my self-published book The Hacker's Guide to Python. I've spent some time translating it into English so you can read it if you don't understand French! I hope you'll enjoy it.

Hi Julien, and thanks for participating in this interview for the Journal du Hacker. For our readers who don't know you, can you introduce you briefly?

You're welcome! My name is Julien, I'm 31 years old, and I live in Paris. I now have been developing free software for around fifteen years. I had the pleasure to work (among other things) on Debian, Emacs and awesome these last years, and more recently on OpenStack. Since a few months now, I work at Red Hat, as a Principal Software Engineer on OpenStack. I am in charge of doing upstream development for that cloud-computing platform, mainly around the Ceilometer, Aodh and Gnocchi projects.

Being myself a system architect, I follow your work in OpenStack since a while. It's uncommon to have the point of view of someone as implied as you are. Can you give us a summary of the state of the project, and then detail your activities in this project?

The OpenStack project has grown and changed a lot since I started 4 years ago. It started as a few projects providing the basics, like Nova (compute), Swift (object storage), Cinder (volume), Keystone (identity) or even Neutron (network) who are basis for a cloud-computing platform, and finally became composed of a lot more projects. For a while, the inclusion of projects was the subject of a strict review from the technical committee. But since a few months, the rules have been relaxed, and we see a lot more projects connected to cloud-computing joining us. As far as I'm concerned, I've started with a few others people the Ceilometer project in 2012, devoted to handling metrics of OpenStack platforms. Our goal is to be able to collect all the metrics and record them to analyze them later. We also have a module providing the ability to trigger actions on threshold crossing (alarm). The project grew in a monolithic way, and in a linear way for the number of contributors, during the first two years. I was the PTL (Project Technical Leader) for a year. This leader position asks for a lot of time for bureaucratic things and people management, so I decided to leave my spot in order to be able to spend more time solving the technical challenges that Ceilometer offered. I've started the Gnocchi project in 2014. The first stable version (1.0.0) was released a few months ago. It's a timeseries database offering a REST API and a strong ability to scale. It was a necessary development to solve the problems tied to the large amount of metrics created by a cloud-computing platform, where tens of thousands of virtual machines have to be metered as often as possible. This project works as a standalone deployment or with the rest of OpenStack. More recently, I've started Aodh, the result of moving out the code and features of Ceilometer related to threshold action triggering (alarming). That's the logical suite to what we started with Gnocchi. It means Ceilometer is to be split into independent modules that can work together with or without OpenStack. It seems to me that the features provided by Ceilometer, Aodh and Gnocchi can also be interesting for operators running more classical infrastructures. That's why I've pushed the projects into that direction, and also to have a more service-oriented architecture (SOA)

I'd like to stop for a moment on Ceilometer. I think that this solution was very expected, especially by the cloud-computing providers using OpenStack for billing resources sold to their customers. I remember reading a blog post where you were talking about the high-speed construction of this brick, and features that were not supposed to be there. Nowadays, with Gnocchi and Aodh, what is the quality of the brick Ceilometer and the programs it relies on?

Indeed, one of the first use-case for Ceilometer was tied to the ability to get metrics to feed a billing tool. That's now a reached goal since we have billing tools for OpenStack using Ceilometer, such as CloudKitty. However, other use-cases appeared rapidly, such as the ability to trigger alarms. This feature was necessary, for example, to implement the auto-scaling feature that Heat needed. At the time, for technical and political reasons, it was not possible to implement this feature in a new project, and the functionality ended up in Ceilometer, since it was using the metrics collected and stored by Ceilometer itself. Though, like I said, this feature is now in its own project, Aodh. The alarm feature is used since a few cycles in production, and the Aodh project brings new features on the table. It allows to trigger threshold actions and is one of the few solutions able to work at high scale with several thousands of alarms. It's impossible to make Nagios run with millions of instances to fetch metrics and triggers alarms. Ceilometer and Aodh can do that easily on a few tens of nodes automatically. On the other side, Ceilometer has been for a long time painted as slow and complicated to use, because its metrics storage system was by default using MongoDB. Clearly, the data structure model picked was not optimal for what the users were doing with the data. That's why I started Gnocchi last year, which is perfectly designed for this use case. It allows linear access time to metrics (O(1) complexity) and fast access time to the resources data via an index. Today, with 3 projects having their own perimeter of features defined and which can work together Ceilometer, Aodh and Gnocchi finally erased the biggest problems and defects of the initial project.

To end with OpenStack, one last question. You're a Python developer for a long time and a fervent user of software testing and test-driven development. Several of your blogs posts point how important their usage are. Can you tell us more about the usage of tests in OpenStack, and the test prerequisites to contribute to OpenStack?

I don't know any project that is as tested on every layer as OpenStack is. At the start of the project, there was a vague test coverage, made of a few unit tests. For each release, a bunch of new features were provided, and you had to keep your fingers crossed to have them working. That's already almost unacceptable. But the big issue was that there was also a lot of regressions, et things that were working were not anymore. It was often corner cases that developers forgot about that stopped working. Then the project decided to change its policy and started to refuse all patches new features or bug fix that would not implement a minimal set of unit tests, proving the patch would work. Quickly, regressions were history, and the number of bugs largely reduced months after months. Then came the functional tests, with the Tempest project, which runs a test battery on a complete OpenStack deployment. OpenStack now possesses a complete test infrastructure, with operators hired full-time to maintain them. The developers have to write the test, and the operators maintain an architecture based on Gerrit, Zuul, and Jenkins, which runs the test battery of each project for each patch sent. Indeed, for each version of a patch sent, a full OpenStack is deployed into a virtual machine, and a battery of thousands of unit and functional tests is run to check that no regressions are possible. To contribute to OpenStack, you need to know how to write a unit test the policy on functional tests is laxer. The tools used are standard Python tools, unittest for the framework and tox to run a virtual environment (venv) and run them. It's also possible to use DevStack to deploy an OpenStack platform on a virtual machine and run functional tests. However, since the project infrastructure also do that when a patch is submitted, it's not mandatory to do that yourself locally.

The tools and tests you write for OpenStack are written in Python, a language which is very popular today. You seem to like it more than you have to, since you wrote a book about it, The Hacker's Guide to Python, that I really enjoyed. Can you explain what brought you to Python, the main strong points you attribute to this language (quickly) and how you went from developer to author?

I stumbled upon Python by chance, around 2005. I don't remember how I hear about it, but I bought a first book to discover it and started toying with that language. At that time, I didn't find any project to contribute to or to start. My first project with Python was rebuildd for Debian in 2007, a bit later. I like Python for its simplicity, its object orientation rather clean, its easiness to be deployed and its rich open source ecosystem. Once you get the basics, it's very easy to evolve and to use it for anything, because the ecosystem makes it easy to find libraries to solve any kind of problem. I became an author by chance, writing blog posts from time to time about Python. I finally realized that after a few years studying Python internals (CPython), I learned a lot of things. While writing a post about the differences between method types in Python which is still one of the most read post on my blog I realized that a lot of things that seemed obvious to me where not for other developers. I wrote that initial post after thousands of hours spent doing code reviews on OpenStack. I, therefore, decided to note all the developers pain points and to write a book about that. A compilation of what years of experience taught me and taught to the other developers I decided to interview in the book.

I've been very interested by the publication of your book, for the subject itself, but also the process you chose. You self-published the book, which seems very relevant nowadays. Is that a choice from the start? Did you look for an editor? Can you tell use more about that?

I've been lucky to find out about others self-published authors, such as Nathan Barry who even wrote a book on that subject, called Authority. That's what convinced me it was possible and gave me hints for that project. I've started to write in August 2013, and I ran the firs interviews with other developers at that time. I started to write the table of contents and then filled the pages with what I knew and what I wanted to share. I manage to finish the book around January 2014. The proof-reading took more time than I expected, so the book was only released in March 2014. I wrote a complete report on that on my blog, where I explain the full process in detail, from writing to launching. I did not look for editors though I've been proposed some. The idea of self-publishing really convince me, so I decided to go on my own, and I have no regret. It's true that you have to wear two hats at the same time and handle a lot more things, but with a minimal audience and some help from the Internet, anything's possible! I've been reached by two editors since then, a Chinese and Korean one. I gave them rights to translate and publish the books in their countries, so you can buy the Chinese and Korean version of the first edition of the book out there. Seeing how successful it was, I decided to launch a second edition in Mai 2015, and it's likely that a third edition will be released in 2016.

Nowadays, you work for Red Hat, a company that represents the success of using Free Software as a commercial business model. This company fascinates a lot in our community. What can you say about your employer from your point of view?

It only has been a year since I joined Red Hat (when they bought eNovance), so my experience is quite recent. Though, Red Hat is really a special company on every level. It's hard to see from the outside how open it is, and how it works. It's really close to and it really looks like an open source project. For more details, you should read The Open Organization, a book wrote by Jim Whitehurst (CEO of Red Hat), which he just published. It describes perfectly how Red Hat works. To summarize, meritocracy and the lack of organization in silos is what makes Red Hat a strong organization and puts them as one of the most innovative company. In the end, I'm lucky enough to be autonomous for the project I work on with my team around OpenStack, and I can spend 100% working upstream and enhance the Python ecosystem.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In August, 71.50 work hours have been dispatched among 7 paid contributors. Their reports are available:

• Ben Hutchings did 15 hours.
• Guido G nther did 4 hours.
• Mike Gabriel was assigned 8 hours but did not do them. He will catch up in September.
• Rapha l Hertzog did 6.5 hours.
• Santiago Ruano Rinc n did 17 hours.
• Scott Kitterman did 4 hours.
• Thorsten Alteholz did 17 hours.

Evolution of the situation September is stable compared to August (71.50 hours per month) and has not caught up back to the level of July as I hoped. Again it s because 2 sponsors were not able to pay their renewal invoice on time (one of last month paid, but another bigger sponsor failed this month). Those sponsors will continue to support us and I would like to be able to say that things will be back to normal next month, but I can t say it since we have also been informed of the (hopefully temporary) defection of another bronze sponsor that will affect us next month. Fortunately there are also good news, we have 3 new sponsors in the pipe (2 silver, 1 platinum) who shall join the project soon. And Blablacar increased their support from Silver to Gold (from 4h/month to 8h/month). But we still need more support in particular since we would like to commit to support virtualization related packages in Wheezy: that s clearly an objective for us. I recently published the summary of the work session held during DebConf 15 in Heidelberg (video recording). It would be really nice if we could get closer to the goal of funding a full-time position. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 18 packages awaiting an update (2 less than last month), the list of open vulnerabilities in Squeeze shows about 30 affected packages in total (8 more than last month). Thanks to our sponsors

• Gold sponsors:
• The Positive Internet (for 15 months already)
• Blablacar (for 14 months already)
• Linode LLC (for 4 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 15 months already)
• Domeneshop AS (for 14 months already)
• Universit Lille 3 (for 14 months already)
• Trollweb Solutions (for 12 months already)
• Gandi SAS (for 9 months already)
• University of Luxembourg (for 6 months already)
• Rentabiliweb Group (for 4 months already)
• Bronze sponsors:
• Offensive Security (for 15 months already)
• Seznam.cz, a.s. (for 15 months already)
• Evolix (for 14 months already)
• Freeside Internet Service (for 14 months already)
• MyTux (for 14 months already)
• Linuxhotel GmbH (for 12 months already)
• Intevation GmbH (for 11 months already)
• Daevel SARL (for 10 months already)
• FOSSter (for 10 months already)
• Bitfolk LTD (for 9 months already)
• Megaspace Internet Services GmbH (for 9 months already)
• Gree, Inc. (for 8 months already)
• Greenbone Networks GmbH (for 8 months already)
• NUMLOG (for 8 months already)
• WinGo AG (for 7 months already)
• Ecole Centrale de Nantes LHEEA (for 4 months already)
• Sig-I/O

No comment Liked this article? Click here. My blog is Flattr-enabled.

I watched PIXELS in a theater. It subjects about video games, mostly retro 80 s arcade games. I love video games from childhood, my first game played would be Taito s Space Invaders, I was the 4 or 5 yeas old time. It had bring me to the computer world. Fortunately I am working at Akihabara area, so I can play the video games in the movie like Pac-man, Glaga, Cemtipede, Donkey Kong and so on in two gamecenters, Natsuge Museum and Hey (Hirose Entertainment Yard . Natsuge Museum is under private management so it closes week days. They focused to old games between 70 th to 90 th. Hey is a franchised shop ownd by TAITO. They covered almost video games except medal games. You can play old games like Paper-boy, The Tower of Druaga, and newest games like Left4Dead arcade. They correct many titles of the games in the movie, and be playable. They are my recommended place in Akihaba, if you like video games.

Usual regular update of the TeX Live packages. Now that Debian/unstable is back to full development speed thanks to the end of the bit gcc transition, probably this TeX Live update will be lost between the hundreds of others. Anyway a few interesting changes are still in there. Most importantly the fix for unicode-math that was broken for a short time, and for the Japanese users it seems that the LaTeX3 packages have gained support for upTeX. Good to hear. Of course, these are not the only updates and newcomers, see the list below. Updated packages abc, acro, alegreya, animate, arabxetex, babel-bosnian, babel-french, babel-greek, babel-latin, babel-welsh, beamer-FUBerlin, bidi, bigfoot, blochsphere, bxjscls, chemformula, chemmacros, chet, classicthesis, crossrefware, csplain, ctable, ctanify, datetime2, datetime2-basque, detlev-cm, disser, doclicense, drm, dtxgen, dtxtut, dvips, ecclesiastic, eledmac, embrac, etex-pkg, etoc, factura, fbb, fithesis, font-change, fontname, glossaries, gothic, greek-fontenc, IEEEtran, l3build, l3experimental, l3kernel, l3packages, latexconfig, lettrine, luatexja, mathastext, mcf2graph, media9, metrix, mhequ, minted, moderntimeline, newtx, ocgx2, pagecolor, pdftex, pgf, pstricks, reledmac, resphilosophica, roboto, shdoc, siunitx, suftesi, tetex, tex4ht, texlive-scripts, tikz-bayesnet, translations, ucharcat, udesoftec, ulthese, unicode-math, ut-thesis, withargs, xint. New packages checklistings, cleanthesis, easyreview, fei, medstarbeamer, mfirstuc, nevelok, old-arrows, proofread, uassign, xebaposter. Enjoy.

Review: How to Make Your Dreams Come True, by Mark Forster

Publisher:	Hodder
Copyright:	2002
Printing:	2006
ISBN:	0-340-78629-9
Format:	Kindle
Pages:	208

Mark Forster is my favorite time management author. His books are less comprehensive systems and more collections of tips, mental shortcuts, and ways of thinking about time management and prioritization that tend to resonate for me. I've already read and reviewed several other books by Forster, but hadn't read this one because it was thoroughly out of print (at least in the US). When it turned up for the Kindle, I decided to give it a try, if for no other reason than completionism. After reading How to Make Your Dreams Come True, I can see why it fell out of print. It's a rather odd book, and quite different from Forster's other work. The topic is still time management, if you squint at it properly, but in the form of a philosophical discussion of life goals and becoming an artist who creates one's own life. Forster structures the book as a series of dialogues between Forster in the present and his own future self and takes the mental exercise surprisingly seriously, even comparing his own coaching technique with that of his future self. The levels of meta get even deeper towards the end of the book, where Forster writes a dialogue between his future self and his even more future self. Those drift into philosophy of life, high-level (and personal) life goals, and some speculations about the reason for existence. The primary concept Forster is exploring is the difference between push, pull, and drift modes of life. He argues that a lot of time management falls into the category of push systems: you're exerting effort to push yourself along towards goals. In this book, he argues that this is a starting point but not a technique to stop on. Instead, one should try to move to pull mode, where one has a compelling and detailed vision of where one wants to be, repeatedly developing and refining it, and then lets that vision pull you through life. The advantages, in his conception, over the push form of time management is that this requires less expenditure of effort, feels more natural, and lets one be more flexible and nimble in how one achieves one's goals. It can be tricky, however, to avoid settling into the middle ground of drift mode, where one does not have a goal in mind and doesn't act towards anything in particular. I found the idea interesting and mildly useful, but Forster's presentation of it seemed too convinced of its own correctness. The exercises he proposes don't seem interesting to me; the dialogues with one's future self in particular felt very gimmicky. I admire his ability to invent some of the interactions he came up with, but I don't think it would be a useful technique for me, or as universal as he seems to think it could be. Forster talks quite a lot about reducing effort in his blog (somewhat less in his other books), and seems constantly convinced that he's found a new way to reduce the sense of effort around time management. After having tried a few of these, I suspect that new systems feel less effortful than older systems, and that it's the constant changing of systems that reduces the feeling of effort more than the details of any specific system. I can develop a lot of enthusiasm about a new system for tracking work, and enthusiasm makes everything feel like it requires less effort. Other than that central idea, and quite a lot of philosophy that didn't particularly speak to me, this book reiterates a few of Forster's ideas in a less specific framework: adopt a process and trust it, use it for long enough to give it a chance to work, keep refreshing your vision, and try to reach a flow where you're not exerting lots of effort to force yourself to do things. Good ideas, but better, and more practically, presented in Forster's other books. I'd characterize this as an odd and minor work. I like Forster's writing in general and still only read this for the sake of completeness. His other books offer more practical and actionable ideas. Unless this idea and method of presentation really speaks to you, I think you'll get more out of other books. Rating: 5 out of 10

So moving, away from awesome Core-Backbone provided internet at home and to Kabel Deutschland madness. Missing routes for several hours and noone even seems to notice, no mail address to properly report issues. Quality Network.

traceroute to sks-keyservers.net (37.191.220.247), 30 hops max, 60 byte packets
 1  192.168.0.1 (192.168.0.1)  11.033 ms * *
 2  83-169-183-122-isp.superkabel.de (83.169.183.122)  28.413 ms  74.792 ms  75.376 ms
 3  ip5886ea49.dynamic.kabel-deutschland.de (88.134.234.73)  77.083 ms  77.671 ms  79.283 ms
 4  ip5886ee61.dynamic.kabel-deutschland.de (88.134.238.97)  79.833 ms ip5886ed7c.dynamic.kabel-deutschland.de (88.134.237.124)  81.416 ms  83.348 ms
 5  ip5886ca25.dynamic.kabel-deutschland.de (88.134.202.37)  87.592 ms  88.101 ms *
 6  * * *
 7  * * *
 8  * * *
[...]

Needless to say, of course, that it still works perfectly fine from the old network.

This was my ninth month working on Debian LTS. I was assigned 15 hours of work by Freexian's Debian LTS initiative. Front desk I spent another week in the 'front desk' role, largely overlapping with DebConf. I investigated which new CVEs affected LTS-supported packages in squeeze, recorded this in the secure-testing repository, and mailed the package maintainers to give them a chance to handle the updates. I found that one claimed security flaw in glusterfs was actually harmless for all supported Debian releases. conntrack conntrack had one new issue (CVE-2015-6496, possible remote DoS if certain kernel modules aren't loaded). I didn't find a way to reproduce it, but it still seemed to be applicable to squeeze (but for fewer protocols). I was able to backport the upstream fix without difficulty, after which I uploaded and issued DLA-295-1. DebConf I attended the LTS BoF at DebConf 15 to discuss the plans for wheezy LTS. Raphael just posted a summary of these discussions. linux-2.6 I spent some time on kernel security fixes, but haven't uploaded an update yet. That will probably come in September.

Review: The Goblin Emperor, by Katherine Addison

Publisher:	Tor
Copyright:	April 2014
ISBN:	1-4299-4640-7
Format:	Kindle
Pages:	446

Maia is the child of the current emperor of the Elflands, but not a favored one. He's the half-goblin son of a political marriage to a goblin princess, quickly orphaned away from the capital and kept in seclusion well out of the way of his father and court politics. And in the care of his cousin Setheris: cruel and abusive companionship. Then the airship Wisdom of Choharo crashes with no survivors, killing everyone in the line of succession. Except Maia. Maia is in no way prepared to be emperor, but the rules of succession are clear: he is now emperor. We all know from medieval history, both real and fantastic, that clear rules rarely got in the way of aggressive political maneuvering, but Maia's short-term survival is helped considerably by complex factions at play at court (of which he is almost wholly ignorant), and a certain lack of bloodthirstiness in elven politics. Rather than disposing of the unexpected heir, people instead start maneuvering to manipulate and control him. The current Lord Chancellor is the first, beginning his play in the message sent informing Maia of his father's death, and his cousin isn't far behind, but they're only the first two. Meanwhile, Maia, who had never been trained for any sort of court life, has to learn nearly everything about his new life: how to interact with servants, the rituals of court, his new duties, and all of the factions in play. One might expect that Maia would quickly be reduced to a pawn of one faction or another, but he has two secret weapons. One is that he is a legitimately nice person with a strongly developed sense of empathy. Early on, he lucks into some opportunities to show this and wins some popularity and some allies of his own, particularly among those people not used to being treated with respect. And two, he's had enough of his cousin controlling and abusing him. He's determined to make his own decisions and not take orders from someone else, and now has enough nominal power to possibly pull this off. The Goblin Emperor is a fantasy of political agency, and a story about political maneuvering, tricky decisions, navigating alliances, and learning politics. There isn't a lot of action here: most of the plot happens in conversation. The tension is high Maia's situation is precarious but it mostly involves second-guessing his decisions and actions, and hoping that his weaknesses and ignorance don't get him into too much trouble. That is an extremely tricky book to write. Addison had to walk a tightrope between letting Maia's new responsibilities come unrealistically easily, making him seem like a Chosen One with special plot powers, and having readers get too frustrated with realistically bad decisions and lose their desire to read about him. Addison walks that tightrope magnificently. I liked Maia throughout this book, and that's the strength of it. He never felt like the typical fantasy coming of age hero who is magically protected by the plot. He's just a genuine, honest person, reacting to his own past as best he can, making the best decisions he knows how to make. He makes mistakes, but Addison wisely avoids making those mistakes cringe-worthy or too obvious. Instead, they're like bad moves in a chess match: they create problems but also some opportunities, and they're realistically recoverable. And it's a delight to see Maia bring empathy and a disinterested outside perspective to the hothouse mess of court politics and come up with some very creative solutions. Obviously, the situation that allows Maia to succeed is artificial. This is a fantasy: Maia happens to be just the right person the empire needs, and that's clearly an authorial construction. It may be impossible to write a political story about a well-meaning, naive outsider that isn't a tragedy without a bit of cheating. But Addison hides the cheating well. Maia may be very lucky in the empire he inherits, but it feels coherent and believable. By the end of the book, Maia has dealt with everything from international diplomacy to the incredibly complex negotiations around further heirs to the empire. And (realistically) he doesn't stay lucky throughout the book: eventually, no matter how careful he tries to be, he angers some powerful people. I enjoyed every step along the way, and would have happily read more about Maia. In my personal ranking, this was second only to Ancillary Sword in the nominees for the 2015 Hugo, and I wouldn't disagree too strongly with someone who argued it was better. It's not a typical sort of fantasy, but it's one I enjoyed very much. Recommended. One warning: consider going to the back of the book and reading the glossary at the start. There may be some mild spoilers in there, but it also explains the title conventions in the empire, and some of those titles look very much like proper names. If, like me, you don't read this until the end of the book, you may find yourself horribly confused by several apparently similarly-named characters. Rating: 8 out of 10

Review: Let's Pretend This Never Happened, by Jenny Lawson

Publisher:	Berkley
Copyright:	2012, 2013
Printing:	March 2013
ISBN:	0-425-26101-8
Format:	Trade paperback
Pages:	366

Let's Pretend This Never Happened, subtitled (A Mostly True Memoir), is the closest that I've ever found to the book form of a stand-up comedy routine. Lawson grew up in rural Texas with a taxidermist father, frequent contact with animals in various forms of distress, an undiagnosed anxiety disorder, and a talent for creatively freaking out about things that never occur to anyone else. But, more importantly, she has a talent for putting down on paper the random thoughts that go through her head so the rest of us can read them. Not to mention excellent comic timing and absolute mastery of the strangely relevant digression. It's always tricky to review comedy. I think tastes differ more wildly in this genre than any other. Things some people find hilarious others will find offensive or just boring. That may be particularly true of Lawson, who, similar to some of the best stand-up comics, specializes in taking off filters and saying all sorts of offensive things that people might think but not say. This kind of comedy is a knife's edge, since it can easily turn into punching down. Lawson avoids this (rather well, in my opinion) by making herself the punch line of most of the jokes. A pretty typical paragraph of the book, so that you know the sort of thing that you're in for:

The following is a series of actual events pulled form my journal that led me to believe that our home was possessed by demons and/or built over an Indian burial ground. (Also, please note that the first part of this chapter actually happens just before the previous chapter, and the last part of it happens just after it. This could be viewed as "clunky and awkward," but I prefer to think of it as "intellectually challenging and chronologically surreal. Like if Memento was a book. About dead dogs and vaginas and puppets made out of squirrel corpses." You can feel free to use that quote if you're reviewing this chapter, or if you're a student and your teacher asks you, "What was the author trying to say here?" That was it. That's what I was trying to say. That and "Use condoms if you're going to have sex, for God's sake. There are a lot of skanks out there." That's not really covered in this book, but it's still good advice.)

That has a little bit of everything this book had for me: Lawson's somewhat surreal worries, the extended digression, a rhythm that's quite compelling once you start reading it, random uncomfortable topics, and the occasional miss that I don't find funny (the last few sentences). It's all mixed together in a slightly breathless rush of narrative momentum. For more samples, Lawson's writing started as a blog and she's still actively blogging, so you can get a good advance sample by reading some of The Bloggess. Her tone there matches the book closely. What makes this book more than only comedy is that Lawson is very open about her struggles with mental illness (anxiety and depression). A lot of the humor comes from "this is the ridiculous nonsense that my brain throws out on a regular basis" and inviting you to laugh along with her, but the undertone is use of humor as a coping mechanism to deal with anxiety spirals. And alongside that coping mechanism is an open-hearted message of "you are not the only person to have completely irrational reactions to the world please laugh along with mine and feel better about yours." Due to that, the best comparison I can make to another book I've read is to Allie Brosh's Hyperbole and a Half. Brosh is more serious in places, more analytical, and a bit better at generalizing to experiences the reader can identify with. (And, of course, more graphical.) Lawson is more madcap, a bit more manic, and focused on absurd situations that don't normally happen to people. I loved this book from beginning to end, and it had me laughing out-loud in multiple places. Despite being a collection of disconnected stories, it has a rhythm and flow that kept me reading. Some books of this kind are best read in small segments with a break between, but I devoured Let's Pretend This Never Happened in large chunks (and had to be careful about reading it in public and laughing too loudly). Check first whether the sense of humor works for you, but if it does, highly recommended. Rating: 9 out of 10

Just a few days ago another great font designer has passed away, Adrian Frutiger, 24 May 1928 10 September 2015. Famous in particular for his fonts Frutiger, Avenir, and the Univers family. His fonts are used throughout the worlds for visual communication like road signs. Much has been written about him: Linotype s excellent obituary, Adam Twardoch, David Airey, New York Times article. For an interview conducted with Frutiger in 1999, see this Eye Magazine article. An interesting article on Frutiger s typefaces by Charles Bigelow.
Here I want to recall a different quality of Adrian Frutiger his interest in the visual language of symbols, their development and interaction. His book Der Mensch und seine Zeichen (Signs and Symbols) is a profound study on the development, history, and use of all kind of symbols. In this book, translated into many languages, Frutiger explores the depth and breath of symbols, but the most important part for him, easily to be seen from the German title, is the human part ( Der Mensch ). Symbols are created, changed, and used by and for humans. His studies exhibit connections between various cultures when it comes to sign usage and design.
He also explores signets as modern sign language, and their importance for visual communcation and identity building.
The book also discusses the development of the Roman alphabet, and of course passes the Univers font family.
My favorite piece is this overlay of a s from different fonts, to show that there is a common pattern in these fonts.
He concludes this book with a very wise statement:

Zum Festhalten des Gedankens, zur Vermittlung der Aussage gen gen seit langem schon die Alphabet-Zeichen nicht mehr allein. Orientierung und Kommunikation sind heute unm glich ohne Schemata, Zeichen und Signale. Der geschriebene Ausdruck wird durch die Bildvermittlung notwendig erg nzt.

SInce long the alphabet letters alone do not suffice to take hold of thoughts and to transmit statements. Nowadays, orientation and communication are impossible without schemata, signs and signals. The written expression is necessarily enhanced through image transmission.

(my translation) After Hermann Zapf, this is now the second loss of the typographic world in this year. We will miss both of them.

We've been hard working with the Gnocchi team these last months to store your metrics, and I guess it's time to show off a bit. So far Gnocchi offers scalable metric storage and resource indexation, especially for OpenStack cloud but not only, we're generic. It's cool to store metrics, but it can be even better to have a way to visualize them! Prototyping We very soon started to build a little HTML interface. Being REST-friendly guys, we enabled it on the same endpoints that were being used to retrieve information and measures about metric, sending back text/html instead of application/json if you were requesting those pages from a Web browser. But let's face it: we are back-end developers, we suck at any kind front-end development. CSS, HTML, JavaScript? Bwah! So what we built was a starting point, hoping some magical Web developer would jump in and finish the job. Obviously it never happened. Ok, so what's out there? It turns out there are back-end agnostic solutions out there, and we decided to pick Grafana. Grafana is a complete graphing dashboard solution that can be plugged on top of any back-end. It already supports timeseries databases such as Graphite, InfluxDB and OpenTSDB. That was largely enough for that my fellow developer Mehdi Abaakouk to jump in and start writing a Gnocchi plugin for Grafana! Consequently, there is now a basic but solid and working back-end for Grafana that lies in the grafana-plugins repository. With that plugin, you can graph anything that is stored in Gnocchi, from raw metrics to metrics tied to resources. You can use templating, but no annotation yet. The back-end supports Gnocchi with or without Keystone involved, and any type of authentication (basic auth or Keystone token). So yes, it even works if you're not running Gnocchi with the rest of OpenStack. It also supports advanced queries, so you can search for resources based on some criterion and graphs their metrics. I want to try it! If you want to deploy it, all you need to do is to install Grafana and its plugins, and create a new datasource pointing to Gnocchi. It is that simple. There's some CORS middleware configuration involved if you're planning on using Keystone authentication, but it's pretty straightforward just set the cors.allowed_origin option to the URL of your Grafana dashboard. We added support of Grafana directly in Gnocchi devstack plugin. If you're running DevStack you can follow the instructions which are basically adding the line enable_service gnocchi-grafana. Moving to Grafana core Mehdi just opened a pull request a few days ago to merge the plugin into Grafana core. It's actually one of the most unit-tested plugin in Grafana so far, so it should be on a good path to be merged in the future and have support of Gnocchi directly into Grafana without any plugin involved.

Note to myself how the mysql PASSWORD() function works as a one-liner:

echo -n foobar   openssl sha1 -binary   openssl sha1 -hex   sed 's/(stdin)= /*/'   tr '[:lower:]' '[:upper:]'

What happened in the reproducible builds effort this week: Media coverage Motherboard published an article on the project inspired by the talk at the Chaos Communication 15. Journalists sadly rarely pick their headlines. The sensationalist How Debian Is Trying to Shut Down the CIA got started a few rants here and there. One from OpenBSD developper Ted Unangst lead to a good email contact and some thorough comments. Toolchain fixes

• Emmanuel Bourg uploaded maven-ant-helper/7.11 which improved the reproducibility of the Javadoc by removing the timestamps and using the English locale.
• Thomas Schmitt uploaded libisoburn/1.4.0-2 which adds to the ISO image creator xorriso new flags for -alter_date to avoid update ctimes. Report by Daniel Kahn Gillmor.
• Florian Schlichting uplodaded libmodule-build-perl/0.421400-2 which makes linked file ordering deterministic. Original patch by Niko Tyni.

The modified version of gettext has been removed from the experimental toolchain. Fixing individual package seems a better approach for now. Chris Lamb sent two patches for abi-compliance-checker: one to drop the timestamp from generated HTML reports and another to make umask and timestamps deterministic in the abi tarball. Bugs submitted by Dhole lead to a discussion on the best way to adapt pod2man now that we have SOURCE_DATE_EPOCH specified. There is really a whole class of issues that are currently undiscovered waiting for tests running on a different date. This is likely to should happen soon. Chris Lamb uploaded a new version of debhelper in the reproducible repository, cherry-picking a fix for interactions between ddebs and udebs. Packages fixed The following packages became reproducible due to changes in their build dependencies: aspic, django-guardian, erlang-sqlite3, etcd, libnative-platform-java, mingw-ocaml, nose2, oar, obexftp, py3cairo, python-dugong, python-secretstorage, python-setuptools, qct, qdox, recutils, s3ql, wine. The following packages became reproducible after getting fixed:

• bochs/2.6-4 by Santiago Vila.
• codec2/0.4-3 by A. Maitland Bottoms.
• coquelicot/0.9.4-1 by Lunar.
• criticalmass/1:1.0.0-3 by Santiago Vila.
• ekg/1:1.9~pre+r2855-3 by Santiago Vila.
• eterm/0.9.6-3 by Santiago Vila.
• fbi/2.10-2 by Moritz Muehlenhoff.
• fsvs/1.2.6-2 by Santiago Vila.
• glhack/1.2-3 by Santiago Vila.
• httraqt/1.4.6-2 by Anton Gladky.
• libapache-authznetldap-perl/0.07-6 by gregor herrmann, original patch by Dhole.
• libkinosearch1-perl/1.01-3 uploaded by Florian Schlichting, original patch by Niko Tyni.
• liblucy-perl/0.3.3-6 uploaded by Florian Schlichting, original patch by Niko Tyni.
• slony1-2/2.2.4-1 by Christoph Berg.
• slrn/1.0.2-3 uploaded by Moritz Muehlenhoff, original patch by Dmitry Bogatov.
• svtplay-dl/0.10.2015.08.24-1 uploaded by Olof Johansson, fixed upstream.
• swh-plugins/0.4.15+1-8 uploaded by Jarom r Mike , original patch by Chris Lamb.
• sysstat/11.1.6-2 uploaded by Robert Luberda, original patch by Chris Lamb.
• uhd/3.9.0-3 by A. Maitland Bottoms.
• volk/1.1-3 by A. Maitland Bottoms.
• yadifa/2.1.3-2 uploaded by Markus Schade, original patch by Santiago Vila.

Some uploads fixed some reproducibility issues but not all of them:

• dict-jargon/4.4.7-3 uploaded by Ruben Molina, original patch by Dhole.
• ferret-vis/6.9.3-3 uploaded by Alastair McKinstry, original patch by Chris Lamb.

Patches submitted which have not made their way to the archive yet:

• #798366 on lilo by Dmitry Bogatov: remove usage of __TIME__ and __DATE__ macros.
• #798557 on libapache-dbi-perl by Dhole: set date of the manpage to the latest debian/changelog entry.
• #798776 on testdisk by upstream!

reproducible.debian.net The configuration of all remote armhf and amd64 nodes in now finished. The remaining reproducibility tests running on the Jenkins host has been removed. armhf results and graphs are now visible in dashboard. We can now test the whole archive in 2-3 weeks using the current 12 amd64 jobs and 3 months using the current 6 armhf builders. We will be looking at improving the armhf sitation, maybe using more native systems or via arm64. (h01ger) The Jenkins UI is now more responsive since all jobs building packages have been moved to remote hosts. (h01ger) A new job has been added to collect information about build nodes to be included in the variation table. (h01ger) The currently scheduled page has been split for amd64 and armhf. They now give an overview (refreshed every minute, thanks to Chris Lamb) of the packages currently being tested. (h01ger) Several cleanup and bugfixes have been made, especially in the remote building and maintenance scripts. They should now be more robust against network problems. The automatic scheduler is now also run closer to when schroots and pbuilders are updated. (h01ger, mapreri) Package reviews 16 reviews have been removed, 54 added and 55 updated this week. Santiago Vila renamed lc_messages_randomness with the more descriptive different_pot_creation_date_in_gettext_mo_files. New issues added this week: timestamps_in_reports_generated_by_abi_compliance_checker, umask_and_timestamp_variation_in_tgz_generated_by_abi_compliance_checker, and timestamps_added_by_blast2. 23 new FTBFS bugs have been filled by Chris Lamb, and Niko Tyni. Misc. Red Hat developper Mike McLean had a talk at Flock 2015 about reproducible builds in Koji. Slides and video recording are available. Koji is the build infrastructure used by Fedora, Red Hat and other distributions. It already keeps track of the environment used for a given build, so the required changes for handling the environment are smaller than the ones in Debian. Fedora is still missing a team effort to fix non-determinism in the package builds, but it is great to see Fedora moving forward.

Sharing a scanner over the network using SANE is fairly straightforward. Here's how I shared a scanner on a server (running Debian jessie) with a client (running Ubuntu trusty).

Install SANE The packages you need on both the client and the server are:

• libsane
• sane-utils

You should check whether or your scanner is supported by the latest stable release or by the latest development version. In my case, I needed to get a Canon LiDE 220 working so I had to grab the libsane 1.0.25+git20150528-1 package from Debian experimental.

Test the scanner locally Once you have SANE installed, you can test it out locally to confirm that it detects your scanner:

scanimage -L

This should give you output similar to this:

device  genesys:libusb:001:006' is a Canon LiDE 220 flatbed scanner

If that doesn't work, make sure that the scanner is actually detected by the USB stack:

$ lsusb   grep Canon
Bus 001 Device 006: ID 04a9:190f Canon, Inc.

and that its USB ID shows up in the SANE backend it needs:

$ grep 190f /etc/sane.d/genesys.conf 
usb 0x04a9 0x190f

To do a test scan, simply run:

scanimage > test.ppm

and then take a look at the (greyscale) image it produced (test.ppm).

Configure the server With the scanner working locally, it's time to expose it to network clients by adding the client IP addresses to /etc/sane.d/saned.conf:

## Access list
192.168.1.3

and then opening the appropriate port on your firewall (typically /etc/network/iptables in Debian):

-A INPUT -s 192.168.1.3 -p tcp --dport 6566 -j ACCEPT

Then you need to ensure that the SANE server is running by setting the following in /etc/default/saned:

RUN=yes

if you're using the sysv init system, or by running this command:

systemctl enable saned.socket

if using systemd. I actually had to reboot to make saned visible to systemd, so if you still run into these errors:

$ service saned start
Failed to start saned.service: Unit saned.service is masked.

you're probably just one reboot away from getting it to work.

Configure the client On the client, all you need to do is add the following to /etc/sane.d/net.conf:

connect_timeout = 60
myserver

where myserver is the hostname or IP address of the server running saned.

Test the scanner remotely With everything in place, you should be able to see the scanner from the client computer:

$ scanimage -L
device  net:myserver:genesys:libusb:001:006' is a Canon LiDE 220 flatbed scanner

and successfully perform a test scan using this command:

scanimage > test.ppm