Writing this because there seems to be no correct documentation on the relevant google websites and it turns out to be non-trivial. Our goal here is to unsubscribe from a ordinary google group. Mails from the google group contain the quoted footer:

-- 
You received this message because you are subscribed to the Google
Groups "FOO" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to FOO+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/FOO
For more options, visit https://groups.google.com/groups/opt_out.

Seems easy enough, so let's send a Mail to this FOO+unsubscribe address. Back comes a E-Mail:

From: FOO <FOO+unsubconfirm@googlegroups.com>
Subject: Unsubscribe request for FOO [ EJzZjpgFhDHd9seTdRA0 ]
To: Christoph Egger <christoph@example.com>
Date: Tue, 18 Feb 2014 18:55:24 +0000 (38 minutes, 53 seconds ago)
 [Leave This Group]
Visit Go 
[Start] your own group, [visit] the help center, or [report]
abuse.

So click on the [Leave This Group] link and be done? Unfortunately not. Looking at the link you notice it's called http://groups.google.com/group/FOO/subscribe -- no token and "subscribe"? I actually want to unsubscribe! And indeed, clicking gets an Interface that offers to "Enter the email address to subscribe:" + Captcha. And whatever it does, it -- of course -- doesn't unsubscribe. (My guess is, it would actually work if you had a real google account associated with that email address and were logged in to that account but there's no way of verifying this as already the first condition is false in this case) Now if you disable HTML completely for the email, a totally different content emerges:

Hello christoph@example.com,
We have received your request to unsubscribe from FOO. In order for us to complete the request, please reply to this email or visit the following confirmation URL:
http://groups.google.com/group/FOO/subscribe
If you have questions related to this or any other Google Group, visit the Help Center at http://groups.google.com/support/.
Thanks,
Google Groups

Still the non-functional link, however it also mentions a different solution: "please reply to this email" which was not present in the HTML mail at all. And it works.

The XDG Basedirectory specification proposes default homedir folders for the categories DATA (~/.local/share), CONFIG (~/.config) and CACHE (~/.cache). One category however is missing: STATE. This category has been requested several times but nothing happened.
Examples for state data are:

• history files of shells, repls, anything that uses libreadline
• logfiles
• state of application windows on exit
• recently opened files
• last time application was run
• emacs: bookmarks, ido last directories, backups, auto-save files, auto-save-list

The missing STATE category is especially annoying if you're managing your dotfiles with a VCS (e.g. via VCSH) and you care to keep your homedir tidy.
If you're as annoyed as me about the missing STATE category, please voice your opinion on the XDG mailing list.
Of course it's a very long way until applications really use such a STATE directory. But without a common standard it will never happen.

Debian Women is proud to announce that it will hold a MiniDebConf in Barcelona on 15-16 March 2014, where Debian enthusiasts from far and wide will gather to talk about the latest Debian changes and the Debian community, as well as to meet new and old friends. The MiniDebConf is fast approaching, be sure to make your travel arrangements! It is going to be an exciting event, in a beautiful venue, in one of the most famous European cities! Schedule A draft schedule (still subject to some last minute changes) is already available. The list of talks promises two days packed with great talks! If you have an exciting idea for a talk, but missed the deadline, please get in touch with us, we might still have a slot for you. Crowd-funding We are still raising funds to cover the costs of running the conference and to offer travel sponsorship to people who can't pay for it. Please, consider donating any amount you can, everything helps! Sponsorship If you want to attend the conference, but are unable to cover the costs. Please contact us! We don't have a big budget, but we will make our best to help. Naturally, priority will be given to participants who have an accepted talk. About this MiniDebConf We want to have a MiniDebConf with both talks and social events, to which everyone in Debian is invited but where the speakers in the talks are all people who identify themselves as female. We consider this important to

• Encourage women who haven't yet given their first DebConf talk
• Provide role models for women who are interested in contributing
• Debunk the myth that there are not enough women who can give talks in DebConf

The idea behind the conference is not to talk about women in free software, or women in Debian, but rather to make discussion about Debian subjects more inclusive for women. If you agree with this goal, spread the word. Forward this announcement and help us make this event a great success! About our sponsors This event is possible thanks to the help provided by our generous sponsors. In particular, we'd like to thank our platinum sponsor, Google. We hope to see you in Barcelona! For more information, visit http://bcn2014.mini.debconf.org

I really like to read code written by different people. I've always been the type of learner that can cover a lot of ground by looking at examples. A few of the programming tricks I acquired over time have definitely been learnt by reading programs written by other people. There are of course cases of disagrement with coding style (lets put that very mildly), so not every project is fun to read. But I tend to find projects I like enough to actually look at their source code. Now, if you get into this habit, there is also the occasional spotting of a bug. Many are really cosmetic, like typos in comments or documentation. Others are maybe more serious, who knows what can happen if you read a few lines of code written by someone you have never met in person. This is one of the original arguments of open source and free software. It basically goes like: "People will read your code and report problems." I know that happens, but I also know that there are cases of people finding relatively minor things during a small code review, which they don't report, or which get lost in some developers INBOX. I remember waiting months to see memory corruption fixes for a particular project I submitted by email to actually appear in the development repository. In some cases you really need to track your patches and prod someone to remind them about your contribution if need be. True, some of these issues are probably minor enough to not really hurt if they get lost, but I have a feel that a lot of minor things also sort of add up. This is where GitHub comes into play. We have had project hosting services since at least a decade now, but none of them (to my experience) have ever made it so easy for all involved parties to submit and merge changes into projects. Pull requests are just amazing. Well, at least for me, they are since a few months. I have a sort of mixed hate-love relationship with GitHub when it comes to a topic that is very important to me, Accessibility. The last project hosting site I really liked for their simple web interface (read, still usable with Lynx) was Google Code. That was in the days when Google still seemed to care about such things. These days, their newer services are next to unusable to me (with the tools I prefer). SourceForge was always a catastrophy. Many things were cumbersome to do, because the site is so loaded with links to all sorts of things I never need. However, at the time I was using it, all the things I really needed did work. GitHub is a different beast, in a different era of the internet. While I can read project pages and a few basic things perfectly fine, some parts of the GitHub site are simply unusable for no particular reason. For instance, I can edit (some of my) preferences and even save them. But I can not star a project, nor can I follow other developers. Invoking these links gives me a 404, which seems to indicate that some JavaScript (read, client side code execution) is required which my browser does not perform. However, I really wonder why. Because something like "I want to star this project" will eventually have to end up as a request on the server anyway, so it seems technically unnecessary to rely on Javascript for such an operation to succeed. Luckily, these days, hip projects do have an API. An GitHub is no exception. I want to emphasis that an API alone is not an accessibility fix, since you rarely have the time to implement a clinet for a random API, just to get access to a service you want to use. Sometimes you do, and an API is a great enabler in such situations, but a reference client with a rich feature-set is much better. I have to admit that I haven't evaluated any of the possible alternatives, but one client I found for GitHub's API did really boost my productivity in the last year. I am talking about Hub. It is a simple wrapper around Git that adds a few and enhances some other git commands. Most importantly, hub fork will fork the current checkout on GitHub, and hub pull-request allows you to quickly (and I really mean quickly!) open a pull request for some commits you've just done to your fork of some project. This is very helpful, and very accessible. While it does not solve all my accessibility problems with GitHub, it at least enables me to take part in the GitHub workflow. I can easily fork projects and submit pull reuqests for changes I did. And that is what I did, at least a bit, in roughly the past year. I am not sure exactly, but I think it was spring when someone made me aware of Hub. One approach would be to check my GitHub activity graph, but I probably don't have to mention that it is not accessible. Here is a list of some of my contributions to open source projects on GitHub since I discovered a good client for the GitHub API:

• pelican is the Python based static site generator which runs this blog.
• spirit_x3 is the experimental C++11 implementation of Boost.Spirit.
• music21 is a music notation processing framework for Python from the MIT. They have just recently moved to GitHub. Some of my (small) contributions to the braille music module of music21 predate the move to GitHub.
• teq (and teqqer) aim to provide an API for tracker-style sequencing and a coresponding terminal based client. To me a very exciting project. Clear separation between the Engine and the GUI is rare in the Linux Audio Landscape. Notable good exceptions are SuperCollider. But many end-user oriented tools tend to blend the functionality provided and the user interface into a single program, which makes it very hard to use if there are any accessibility issues. This is not true for teq/teqqer. teq is a tracker engine, and teqqer the coresponding reference user interface. Lets see what comes of it, the project is rather new.

To summarize: I love GitHub for what it does to the free software community. I think the simplicity (and transparency) of contributions is to the benefit of free and open source software. However, I also hate GitHub sometimes when I need to ask a friend to do relatively trivial changes for me. What I actually want, is a command-line client like Hub that makes most or even all functionality provided on the website available. True, some things like graphs are not immediately easy to adapt. But I really shouldn't need to use a modern full-fledged web browser to tell GitHub that I am interested in the activities of a certain user. Or delete a fork. Yes, thats right. I can use Hub to fork a project, but there is no way to delete it again. Sort of strange for casual small-scale contributions. I guess the workflow there is: fork, commit, pull-request, wait for merge, delete. I don't want to have all sorts of forks on GitHub that I actually don't actively use/maintain. So once a pull request was merged, and I don't have any other things I am working on right now, I actually want to get rid of the fork again. It is easy enough to do a fork should I ever need it again.

I really like to read code written by different people. I've always been the type of learner that can cover a lot of ground by looking at examples. A few of the programming tricks I acquired over time have definitely been learnt by reading programs written by other people. There are of course cases of disagrement with coding style (lets put that very mildly), so not every project is fun to read. But I tend to find projects I like enough to actually look at their source code. Now, if you get into this habit, there is also the occasional spotting of a bug. Many are really cosmetic, like typos in comments or documentation. Others are maybe more serious, who knows what can happen if you read a few lines of code written by someone you have never met in person. This is one of the original arguments of open source and free software. It basically goes like: "People will read your code and report problems." I know that happens, but I also know that there are cases of people finding relatively minor things during a small code review, which they don't report, or which get lost in some developers INBOX. I remember waiting months to see memory corruption fixes for a particular project I submitted by email to actually appear in the development repository. In some cases you really need to track your patches and prod someone to remind them about your contribution if need be. True, some of these issues are probably minor enough to not really hurt if they get lost, but I have a feel that a lot of minor things also sort of add up. This is where GitHub comes into play. We have had project hosting services since at least a decade now, but none of them (to my experience) have ever made it so easy for all involved parties to submit and merge changes into projects. Pull requests are just amazing. Well, at least for me, they are since a few months. I have a sort of mixed hate-love relationship with GitHub when it comes to a topic that is very important to me, Accessibility. The last project hosting site I really liked for their simple web interface (read, still usable with Lynx) was Google Code. That was in the days when Google still seemed to care about such things. These days, their newer services are next to unusable to me (with the tools I prefer). SourceForge was always a catastrophy. Many things were cumbersome to do, because the site is so loaded with links to all sorts of things I never need. However, at the time I was using it, all the things I really needed did work. GitHub is a different beast, in a different era of the internet. While I can read project pages and a few basic things perfectly fine, some parts of the GitHub site are simply unusable for no particular reason. For instance, I can edit (some of my) preferences and even save them. But I can not star a project, nor can I follow other developers. Invoking these links gives me a 404, which seems to indicate that some JavaScript (read, client side code execution) is required which my browser does not perform. However, I really wonder why. Because something like "I want to star this project" will eventually have to end up as a request on the server anyway, so it seems technically unnecessary to rely on Javascript for such an operation to succeed. Luckily, these days, hip projects do have an API. An GitHub is no exception. I want to emphasis that an API alone is not an accessibility fix, since you rarely have the time to implement a clinet for a random API, just to get access to a service you want to use. Sometimes you do, and an API is a great enabler in such situations, but a reference client with a rich feature-set is much better. I have to admit that I haven't evaluated any of the possible alternatives, but one client I found for GitHub's API did really boost my productivity in the last year. I am talking about Hub. It is a simple wrapper around Git that adds a few and enhances some other git commands. Most importantly, hub fork will fork the current checkout on GitHub, and hub pull-request allows you to quickly (and I really mean quickly!) open a pull request for some commits you've just done to your fork of some project. This is very helpful, and very accessible. While it does not solve all my accessibility problems with GitHub, it at least enables me to take part in the GitHub workflow. I can easily fork projects and submit pull reuqests for changes I did. And that is what I did, at least a bit, in roughly the past year. I am not sure exactly, but I think it was spring when someone made me aware of Hub. One approach would be to check my GitHub activity graph, but I probably don't have to mention that it is not accessible. Here is a list of some of my contributions to open source projects on GitHub since I discovered a good client for the GitHub API:

• pelican is the Python based static site generator which runs this blog.
• spirit_x3 is the experimental C++11 implementation of Boost.Spirit.
• music21 is a music notation processing framework for Python from the MIT. They have just recently moved to GitHub. Some of my (small) contributions to the braille music module of music21 predate the move to GitHub.
• teq (and teqqer) aim to provide an API for tracker-style sequencing and a coresponding terminal based client. To me a very exciting project. Clear separation between the Engine and the GUI is rare in the Linux Audio Landscape. Notable good exceptions are SuperCollider. But many end-user oriented tools tend to blend the functionality provided and the user interface into a single program, which makes it very hard to use if there are any accessibility issues. This is not true for teq/teqqer. teq is a tracker engine, and teqqer the coresponding reference user interface. Lets see what comes of it, the project is rather new.

To summarize: I love GitHub for what it does to the free software community. I think the simplicity (and transparency) of contributions is to the benefit of free and open source software. However, I also hate GitHub sometimes when I need to ask a friend to do relatively trivial changes for me. What I actually want, is a command-line client like Hub that makes most or even all functionality provided on the website available. True, some things like graphs are not immediately easy to adapt. But I really shouldn't need to use a modern full-fledged web browser to tell GitHub that I am interested in the activities of a certain user. Or delete a fork. Yes, thats right. I can use Hub to fork a project, but there is no way to delete it again. Sort of strange for casual small-scale contributions. I guess the workflow there is: fork, commit, pull-request, wait for merge, delete. I don't want to have all sorts of forks on GitHub that I actually don't actively use/maintain. So once a pull request was merged, and I don't have any other things I am working on right now, I actually want to get rid of the fork again. It is easy enough to do a fork should I ever need it again.

To "pedestal" an aerobar means to elevate the bars above the basebar using risers instead of using headset spacers: You might do this for a few reasons:

• The rider is in a more aerodynamic position when cornering or descending on the basebars.
• Lowers the rider's centre of gravity, improving cornering confidence.
• Less flex when climbing or accelerating under high wattage.
• Teardrop-shaped risers are more aerodynamic than a cylindrical steerer tube:

So, assuming you currently have a bike that uses headset spacers, what would be the effect on your position if you were to replace, say, a 10mm headset spacer with a 10mm armrest riser? First, let us consider the effect of removing the headset spacer. The crucial insight is that removing a 10mm spacer will not lower the stack height ie. the vertical distance relative to the bottom bracket by 10mm. This is because spacers are not oriented perpendicular to the ground; they are stacked along the steerer tube at the head tube angle of the frame. We will assume a head tube angle of 72.5 degrees. We can calculate that removing a 10mm spacer will reduce the stack height by:

sin(72.5 )   10mm = 9.54mm

... and by the same argument it will also increase the effective reach ie. the horizontal distance relative to the bottom bracket by:

cos(72.5 )   10mm = 3.01mm

Next, let us consider the impact of adding the riser. These are oriented perpendicular to the ground, so its addition makes no further change to the reach. However, we can now calculate the overall change in stack height:

  stack = -(sin(72.5 )   10mm) + 10mm = 0.46mm

We can then repeat the calculation for any length of replacement:

Replacement (mm)	stack (mm)	reach (mm)
10	+0.46	+3.01
20	+0.93	+6.01
30	+1.39	+9.02
40	+1.85	+12.0
50	+2.31	+15.0
60	+2.78	+18.0

From this table, I can discover that if I were to replace 30mm of headset spacers with 30mm of risers it would:

1. Increase my effective stack height by 1.39mm (likely neglible).
2. Increase my reach by 9.02mm. This might require me to use a shorter stem to get the same position. If that was undesirable for example, if was already using an extremely short stem I might be forced to abandon the idea altogether.

Three further considerations must be noted:

1. The resultant low height of the base bar could be quite drastic and prevent you breathing properly whilst climbing.
2. Having the steerer tube cut down after to removing headset spacers will reduce the resale value of your bike.
3. You might need to re-cable your brakes as you may have changed the distance the cables must span.

(It may seem odd to provide results for up to 60mm of headset spacers when such a large number of spacers would at the very least void one's warranty. However, I suspect such setups are transiently common within the confines of a fitting studio.)

A couple of days ago, AO3 reached 1 million fanworks in 14,353 fandoms. The AO3 is an archive of fanfiction for multiple fandoms, founded and run by a non-profit organization, Organization for Transformative Works with the aim of "providing access to and preserving the history of fanworks and fan culture in its myriad forms." The code behind AO3 is open source, their servers run Debian and they even have a Diversity Statement! How cool is that? :) And, well, there's also the fact that...

"[...] the Archive is one of a very small number of open-source projects founded and largely staffed by women, another contribution fans have made to the internet as a whole. Many women who were not previously involved in technology have learned new skills in the name of fannish activities, and the AO3 is proud to stand as a shining example of this growth."

So, congratulations AO3!

I wrote in a previous post that Youtube changed their way of delivering videos, with the use of Dynamic Adaptive Streaming over HTTP. On top of that, they started serving both the audio and the video in separate streams, which meant trouble for downloader tools like youtube-dl. As I mentioned in that previous post:

What does this mean in practical terms for users of youtube-dl? Well, if you wanted to download videos in resolutions like the 480p (format 35) that I mentioned, then you will probably have to change your way of doing things, until a more automated solution is in place. You will have to download both the audio and the video and, then, "combine" them (that is, multiplex them) to create one "normal" video file with both the audio and the video.

And latter, I wrote:

Otherwise, to download 480p videos (which I do for lectures and so on with other projects of mine, like edx-dl) I have to call youtube-dl twice: once for format 135 and another for format 140, since the old format 35 files are much smaller than the lower resolution 360p files (due to the former being encoded in High profile vs. the latter being encoded in Constrained Baseline profile).

(...) Well, now, we don't have this problem anymore: The new release of youtube-dl brings us many goodies, including that it is possible to automatically combine/merge/multiplex audio and video formats that Youtube now offers separately (See the previous comments about separate audio and video). Now, if you want a 480p video in H.264 format, High profile, with 128kbps AAC audio (this used to be Youtube's format 35), you can specify format -f 135+140 on the command-line and it will download both the audio, the video and multiplex it with ffmpeg (or avconv, depending on what you have installed). Besides being convenient, this automatic downloading and merging makes it unnecessary to write scripts to, say, retrieve all the videos in a playlist that contains a lot of lectures (see one example here, taught by Benedict Gross). Version 2014.02.17 of youtube-dl will be soon in your favorite mirror of the Debian archives.

Enrico and me have just started a census on Debian Services floating around, and we want YOU to participate!

MicroPeak Approved for NAR Contests The NAR Contest Board has approved MicroPeak for use in contests requiring a barometric altimeter starting on the 1st of April, 2014. You can read the announcement message on the contestRoc Yahoo message board here: Contest Board Approves New Altimeter The message was sent out on the 30th of January, but there is a 90 day waiting period after the announcement has been made before you can use MicroPeak in a contest, so the first date approved for contest flights is April 1. After that date, you should see MicroPeak appear in Appendix G of the pink book, which lists the altimeters approved for contest use Thanks much to the NAR contest board and all of the fliers who helped get MicroPeak ready for this!

Process Identifiers (PIDs) are a scarce resource. On Linux they are only 15 bits by default. The Process Identifier Preservation Society (PIPS) aims to reduce abuse and wastage of the PID space. To join the society please read the following advice.

Common issues Several languages generally allow you to run all your code in one process. Some of the code that you might want to incorporate or use is not available in the form of ELF libraries or language specific libraries but only in the form of ELF binaries or interpreted scripts. As a result using additional PID space is sometimes unavoidable. Many languages have multiple methods of starting external processes and usually some of them waste PID space by running commands in a shell. You can avoid those methods or use the exec builtin to preserve the shell PID. It might be tempting to explicitly use shell in languages that don't allow implicit shell use but that just wastes extra PIDs. Several languages allow you to fork one process into two, this uses an extra PID and is to be avoided unless necessary.

Shell Programs written in the shell languages use a lot of PIDs. Even shells that have a lot of shell builtins (like busybox sh) appear to use the PID space by forking a child process. To join PIPS you should just stop writing programs in shell or use as many builtins as possible and use exec to preserve PIDs.

Init Several init systems are written in or use shell extensively and thus eat huge bowls of PIDs for breakfast. To join the PIPS you should switch away from sysvinit, openrc, init=/bin/sh etc.

C/C++ The common issues section applies to the C/C++ language. To join PIPS you should rewrite your code to use fork()+exec(), g_spawn*() or libpipeline instead of the g_spawn_command_line*(), system() and popen() functions.

Perl The common issues section applies to the Perl language. To join PIPS you should rewrite your code to avoid backticks and only pass arrays to the system(), open(), open2(), open3() functions.

PHP The common issues section applies to the PHP language. To join PIPS you should rewrite your code to use pcntl_exec() instead of backticks, exec(), system(), passthru(), shell_exec(), popen() and proc_open(). Apparently pcntl_exec() is disabled by default on Debian and pcntl_* are often unavailable so you should just not spawn processes. You could also just drop PHP already.

Python The common issues section applies to the Python language. To join PIPS you should rewrite your code to use the subprocess module and avoid passing shell=True to the subprocess.Popen() function. The os.system(), os.popen() functions and the commands module all run their commands in a shell, wasting PID space. The popen2 module requires passing arrays instead of strings in order to avoid the command being run in a shell.

Java The common issues section applies to the Java language. To join PIPS you should rewrite your code to use ProcessBuilder or only pass arrays of strings to Runtime.getRuntime().exec().

Haskell The common issues section applies to the Haskell language. To join PIPS you should only ever pass a RawCommand to createProcess and never use the shell, system, runCommand or runInteractiveCommand functions from the System.Process and System.Cmd libraries.

OCaml The common issues section applies to the OCaml language. To join PIPS you should rewrite your code to use fork+exec or the create_process* wrappers instead of system, open_process, open_process_in, open_process_out and open_process_full.

Go Go allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Rust Rust allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Erlang The common issues section applies to the Erlang language. To join PIPS you should rewrite your code to use erlang:open_port( spawn_executable, ... , ...) instead of os:cmd or the other options to erlang:open_port.

Node.js The common issues section applies to the Node.js language. To join PIPS you should rewrite your code to use the child_process.execFile() function (or other child_process functions) instead of child_process.exec().

Julia Julia allows running external processes but doesn't allow you to waste PID space by running commands in shell. It emulates a lot of shell features instead. Avoid explicitly running the shell though.

Dart The common issues section applies to the Dart language. To join PIPS simply do not enable the runInShell parameter of the Process object.

PS Let me know if I missed something in one of these languages. You should also do most of the above to avoid shell metacharacter injection attacks that usually allow arbitrary code execution. Dear language authors, don't allow running external processes in shell, kthxbye!

Today was another Kindergarten day. Zoe was complaining about being sweaty before we even left the house this morning, so I gave her the choice of going by car or by bike, and she chose car, which was fine by me. It's been stinking hot the last few days. Summer is going out with a bang. Drop off went pretty smoothly. It was another morning where she was happy to have me hang out with her for a little bit, and then I was allowed to leave without any issues. I decided to use this Monday as a Debian day as planned. I mostly ran into a snag with my email setup, but I did manage to do some bug triage and upload one package. It had been hot all day, and I was feeling sapped by it, so I picked up Zoe in the car as well. I was surprised to find she wasn't asleep and hadn't had a nap at all. She seemed in good spirits despite this. Megan's Dad has quit his job, so I don't need to pick her up any more on Mondays and Wednesdays. We dropped by the post office to check my PO box on the way home. Zoe enjoyed peering through the mailbox into the post office. Today's TV diversion was to build a rocket ship out of one of the big moving boxes I've kept aside from the move back. Zoe had great fun blinging up the inside and outside with various craft "gems", and drew a bunch of aliens on the outside. I could have quite easily strung this out until Sarah arrived to pick her up, but I let her watch a little bit of TV right at the end. It was a pretty good afternoon. I liked how Zoe ran with the rocket ship idea and added her own embellishments all by herself. After Sarah picked up Zoe I went for a run. I'd intended to do 10km, but the heat took it out of me, and I lacked the willpower, so I stopped at 5km. After that I had the sweatiest yoga class yet.

Sarah had her training course again today, so she dropped Zoe around to me to take to Kindergarten. She apparently had a disrupted night's sleep and was a bit emotional this morning. She wasn't cooperative, so we ended up having to drive to Kindergarten instead of take the bike. Drop off itself went pretty well. She just wanted to sit in a teacher's lap, and was otherwise fine. I'm still working through the long tail of document collation for my tax return. I spent most of the day sorting through poorly filed papers. I ended up refiling a bunch of them. I biked to Kindergarten for pickup. My preferred route seems to take me about 13 minutes, door to door. Zoe was still napping today, but woke up pretty well. The hairdresser I take Zoe to does free fringe trims in between haircuts, so we dropped in there on the way home to get a fringe trim. They have a little fenced off children's play area in the corner, and she always likes to have a play. We probably spent 15 minutes there after the fringe trim. I had to use some creative imaginative play to encourage her to leave (Cowie called to ask her to come home and give her a cuddle). Before she left, she had to pack all her toys away again, which I was very impressed by. Once we got home, I was able to use the box rocket as a TV diversion again, and we made a steering wheel for it, and she put more bling on the outside, and also used some water colours to paint it. The water colours didn't work terribly well on the cardboard. After that, we drilled the hole in the base for the second clothes line I made and glued the pole into it, and then Zoe watched a little bit of TV. Sarah finished her course early today. I'm just waiting for my girlfriend to get here and we're going to hang out with my cousin who is having round four of chemotherapy today, and drive her home afterwards.

(Or "Today's yak shaving exercise") I'm trying to get back into some Debian work today, which involved trying to send an email from my laptop, relayed through daedalus, which is in a colo facility. Then I started shaving my yak. daedalus rejected the email, because the relay attempt wasn't authenticated. It wasn't authenticated because Exim on my laptop wasn't happy about the Diffie-Hellman parameters Sendmail on daedalus was advertising, and had failed STARTTLS, and like a sensible person, I only allow encrypted authentication. Along the way, I figured I'd need to address the fact that the host certificate has expired long ago (truth is, I probably just needed to fix the Diffie-Hellman parameters file), but my whole CA certificate expired over a year ago. I couldn't find the encrypted USB key with my CA on it, so I decided to cut my losses and start from scratch. It's good to see OpenSSL hasn't got any more user friendly with time. I futzed around and generated a new CA key and certificate, a new CSR for Sendmail, signed it, did the appropriate sacrifices, and confirmed that STARTTLS now worked using OpenSSL s_client. Still couldn't send an email. Still had some bleating in the Exim logs:

2014-02-17 11:29:26 1WFD1M-00086p-KI TLS error on connection to daedalus.andrew.net.au [203.33.60.161] (gnutls_handshake): The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

Back on daedalus, /etc/mail/tls/sendmail-common.prm has been an empty file since time immemorial. I managed to find something in Google's cache suggesting I should put something in it with openssl dhparam -out /etc/mail/tls/sendmail-common.prm -2 1024 I initially went for 4096 bits, because it must be better, right? I'm still waiting for the key generation to come back, while I'm writing this. At least it warned me in advance it was going to take a long time. How thoughtful. What would be more thoughtful was verifying the write permission to the file before the long operation so it could fail fast, rather. Sigh. I ended up giving up on 4096 and sticking with 1024, because I was getting old waiting. Yak shaved, I can send mail from my laptop now.

Today as it was raining and I couldn t do much gardening, psmisc version 22.21 was released. The files are located up on sourceforge at https://sourceforge.net/projects/psmisc/files/latest/download or at your favorite distro repository soon. Once again, thanks to all patch submitters, bug reports and translators for all their help in getting this out. Apologies to the translation teams for having two alpha versions. So what does psmisc 22.21 bring you? Amongst a lot of minor bug fixes it has:

• If you started a process and then spawned some threads and then decided to change the names of the threads, pstree would show the old name, it now shows the correct new name
• pstree has a new flag (-N) for namespace support, thanks Aristeu for the patches
• Previously fuser -M flag only worked if it was before -m, now it can be either order

The Debian psmisc package should be out in the next few hours.

An issue which I always find depressing but sadly unsurprising in discussions of process with software is the frequent disregard for human elements; indeed often the goal people have in creating process is to try to control and eliminate human elements. Little thought is given to what is going to motivate people to do what s asked and if they are going to follow it at all, or in the spirit it was intended. One example I ve seen several times is the idea that some engineers work on irrelevant things and that this can be fixed by requiring every commit to be tied to the project plan or a bug so off project work is obvious. This isn t really attacking the problem so much as putting a roadblock in place to try to avert it; the real problem is normally people not communicating about what they re doing and what s important but those problems are really hard to address. Sadly what tends to happen is that people work around the roadblock and cause some collateral damage; for example devaluing the bug tracker by referencing irrelevant bugs or creating meaningless bugs solely to allow commits, while continuing to behave like they did originally. This is often worse than the original situation. This sort of issue is one of the things I appreciate most about working on Linux there s quite a bit of process but because of the way it has been evolved the incentives are usually right to make sure they are followed in the spirit in which they were intended. For example the patch submission process is essentially just best practices for making sure changes go to people who care in a form which makes it easy for them to work with it; there is a bunch of tooling around it which built on those practices (and in turn influenced the practices) but it all comes back to that basic thing of getting attention for changes and making them easy to work with. As a result people mostly do the right thing (or close enough) so everything runs smoothly. The trick is to remember to standardize and write things down when it s needed notice the good practice and spread its adoption. The key difference here seems to be if process is viewed as something to solve problems for people or if it is viewed as a way to solve problems with people. If the problem is with the people then the view starts off negative and it s perhaps unsurprising that there is little consideration of how they will react. Sometimes it s not so much that a problem is seen with people as that the people doing don t have any real interest in the process (write only timesheets often bear no relation to reality for example) but there is an assumption that they are going to just do what they re asked (but instead they for example don t fill in their time sheets or don t provide accurate information). The end result is the same, their needs don t get considered and their actions end up being counterproductive. Starting to avoid these problems is fairly straightforward take a step back and consider why the people expected to carry out the process are going to want to do so. How does it help them? How will they see it helping others? Generally what s in it for them? If these are difficult questions to answer then there may be a problem it is likely people will ignore the process or do it badly without a lot of active enforcement, but perhaps that s OK for the situation. Beware of using metrics to provide incentives, metrics are gameable and that game can cause problems without care. But do think about people; making software is all about people.

I've started backporting some Perl modules to wheezy-backports - for starters, libbread-board-perl, which is now waiting in BACKPORTS-NEW. At work I've recently been trying to automate the deployment of our platform, and was originally trying to use Carton to manage the CPAN dependencies for us. It seems like it ought to be possible to make this work using CPAN-only tools. However, in practice, I've seen two strong negatives with this approach:

• it's a lot of work for developers to manage the entire dependency chain, and
• it takes forever to get the environment running.

Consider, when you spin up a fresh VM, you need to build Perl from source, and then compile every CPAN module you depend on. This includes all the modules needed to run all the test suites. That's not going to be fast. All that, and you still need a solution that works with the distro's package management, because you still need to install all the build dependencies. So, I'm trying a new approach - if someone else benefits from the packages I backport, even better.

For those of you who didn't yet know it: My mother is a painter. A serious, professional, respected painter. But she sometimes goes to the funny side as well Of course, with all due professionalism! So, she gave us this great gift: She took one of our pictures from DebConf12 (from the "Conference Dinner" night), and painted it. Real size even! So, next time you come to our house, even if we are not around to greet you, we will be glad to welcome you to the Residence!

This is the 2nd point release of OpenStack Havana (this is the name of the current stable release of OpenStack). It was out on Thursday (US time), and I uploaded it on Friday (Chinese time). Unfortunately, I realized that the latest python-keystoneclient didn t support the token and endpoint command line options, effectively breaking Keystone itself, and all automated endpoint registration in all core packages. So after fixing Keystone and openstack-pkg-tools, I had to re-upload a 2nd Debian release. However, after this glitch, the packages passed successfully our CI testing suite: my friends at eNovance and I run the tempest functional test suite each time there s this kind of major update, so that we can validate the packages are working as expected. And all went well after the new keystone command line options were fixed in the postinst scripts. As a side note, I fail to see consistency on deprecating these interfaces. While we still have the old glance index thing in the Glance client (this is really old), keystoneclient just broke backward compatibility, when keystone is quite recent. So, it looks to me that it wasn t a great idea to just remove token and endpoint this way (though I can understand the need of consistency). Hopefully, this will all be fixed anyway, when we move to the unified python-openstackclient command lines instead of per-project clients. I realized today that the pkg-openstack team now maintains more than 100 packages. This of course includes general purpose Python modules, which probably will move to the Python module team if it one day supports Git (life is too short: I do not wish to learn such a deprecated technology as SVN). Though this is still a lot of packages, and some more are coming: as per the OpenStack TODO list wiki page, Ironic (a replacement for nova-baremetal), TripleO (OpenStack on OpenStack), Tuskar (contols where things are deployed with TripleO) and Designate (DNS as a Service) are already packaged, and I am waiting for the Icehouse (this is the name of the next stable release) beta3 to be out to upload them to Experimental. This is scheduled for the 6th of March. I believe I am currently nearly up-to-date with the current global-requirements.txt (eg: python dependencies of OpenStack), pending a few Python module upgrades, so hopefully, packaging OpenStack Icehouse beta3 will smooth.