Dad-o, I m so glad you re a pilot! My 9-year-old son Jacob has been saying that, always with a big hug and his fond nickname for me ( dad-o ). It has now been a year since the first time I sat in the pilot s seat of a plane, taking my first step towards exploring the world from the sky. And now, one year after I first sat in the pilot s seat of an airborne plane, it s prompted me to think back to my own memories.

Flying over the airport at Moundridge, KS Memories Back when I was a child, maybe about the age my children are now, I d be outside in the evening and see this orange plane flying overhead. Our neighbor Don had a small ultralight plane and a grass landing strip next to his house. I remember longing to be up in the sky with Don, exploring the world from up there. At that age, I didn t know all the details of why that wouldn t work I just knew I wanted to ride in it. It wasn t until I was about 11 that I flew for the first time. I still remember that TWA flight with my grandma, taking off early in the morning and flying just a little ways above the puffy clouds lit up all yellow and orange by the sunrise. Even 25 years later, that memory still holds as one of the most beautiful scenes I have ever seen. Exploring I have always been an explorer. When I go past something interesting, I love to go see what it looks like inside. I enjoy driving around Kansas with Laura, finding hidden waterfalls, old county courthouses, ghost towns, beautiful old churches, even small-town restaurants. I explore things around me, too once taking apart a lawnmower engine as a child, nowadays building HF antennas in my treetops or writing code for Linux. If there is little to learn about something, it becomes less interesting to me. I see this starting to build in my children, too. Since before they could walk, if we were waiting for something in a large building, we d go exploring.

A patch of rain over Hillsboro, KS The New World A pilot once told me, Nobody can become a pilot without it changing the way they see the world and then, changing their life. I doubted that. But it was true. One of the most poetic sights I know is flying a couple thousand feet above an interstate highway at night, following it to my destination. All those red and white lights, those metal capsules of thousands of lives and thousands of stories, stretching out as far as the eye can see in either direction.

Kansas sunset from the plane When you re in a plane, that small town nowhere near a freeway that always seemed so far away suddenly is only a 15-minute flight away, not even enough time to climb up to a high cruise altitude. Two minutes after takeoff, any number of cities that are an hour s drive away are visible simultaneously, their unique features already recognizable: a grain elevator, oil refinery, college campus, lake, whatever. And all the houses you fly over each with people in them. Some pretty similar to you, some apparently not. But pretty soon you realize that we all are humans, and we aren t all that different. You can t tell a liberal from a conservative from the sky, nor a person s race or religion, nor even see the border between states. Towns and cities are often nameless from the sky, unless you re really low; only your navigation will tell you where you are. I ve had the privilege to fly to small out-of-the-way airports, the kind that have a car that pilots can use for free to go into town and get lunch, and leave the key out for them. There I ve met many friendly people. I ve also landed my little Cessna at a big commercial airport where I probably used only 1/10th of the runway, on a grass runway that was barely maintained at all. I ve flown to towns I d driven to or through many times, discovering the friendly folks at the small airport out of town. I ve flown to parts of Kansas I ve never been to before, discovered charming old downtowns and rolling hills, little bursts of rain and beautiful sunsets that seem to turn into a sea.

Parked at the Smith Center, KS airport terminal, about to meet some wonderful people For a guy that loves exploring the nooks and crannies of the world that everyone else drives by on their way to a major destination, being a pilot has meant many soul-filling moments. Hard Work I knew becoming a pilot would be a lot of hard work, and thankfully I remembered stories like that when I finally concluded it would be worth it. I found that I had an aptitude for a lot of things that many find difficult about being a pilot: my experience with amateur radio made me a natural at talking to ATC, my fascination with maps and navigation meant I already knew how to read aviation sectional maps before I even started my training and knew how to process that information in the cockpit, my years as a system administrator and programmer trained me with a careful and methodical decision-making process. And, much to the surprise of my flight instructor, I couldn t wait to begin the part of training about navigating using VORs (VHF radio beacons). I guess he, like many student pilots, had struggled with that, but I was fascinated by this pre-GPS technology (which I still routinely use in my flight planning, as a backup in case the GPS constellation or a GPS receiver fails). So that left the reflexes of flight, the art of it, as the parts I had to work on the hardest. The exam with the FAA is not like getting your driver s license. It s a multi-stage and difficult process. So when the FAA Designated Pilot Examiner said congratulations, pilot! and later told my flight instructor that you did a really good job with this one, I felt a true sense of accomplishment.

Some of my prep materials Worth It Passengers in a small plane can usually hear all the radio conversations going on. My family has heard me talking to air traffic control, to small and big planes. My 6-year-old son Oliver was playing yesterday, and I saw him pick up a plane and say this: Two-four-niner-golf requesting to land on runway one-seven . Two-four-niner-golf back-taxi on one-seven Two-four-niner-golf ready to takeoff on runway one-seven! That was a surprisingly accurate representation of some communication a pilot might have (right down to the made-up tailnumber with the spelling alphabet!)

It just got more involved from there! Jacob and Oliver love model train shows. I couldn t take them to one near us, but there was one in Joplin, MO. So the day before Easter, while Laura was working on her Easter sermon, two excited boys and I (frankly also excited) climbed into a plane and flew to Joplin. We had a great time at the train show, discovered a restaurant specializing in various kinds of hot dogs (of course they both wanted to eat there), played in a park, explored the city, and they enjoyed the free cookies at the general aviation terminal building while I traded tips on fun places to fly with other pilots. When it comes right down to it, the smiles of the people I fly with are the most beautiful thing in the air.

Jacob after his first father-son flight with me

Let's Encrypt is a certificate authority (CA) that just left beta stage, that provides domain name-validated (DV) X.509 certificates for free and in an automated way: users just have to run a piece of software on their server to get and install a certificate, resulting in a valid TLS setup. A threat to other certificate authorities By providing certificates for free and automatically, Let's Encrypt is probably a threat a other CAs, a least for part of their activity. Indeed, for people that are satisfied with DV certificates, there are not many reasons to pay a commercial CA to get certificates in a non-automated way. For the CAcert non-commercial CA, that may mean a slow death, as this is their main activity . For people that want organization-validated (OV) or extended validation (EV) certificates, Let's Encrypt is not suitable, so it will not change anything regarding that. An opportunity for the most reactive The entrance of Let's Encrypt is also a significant opportunity for the certificate authorities that will be reactive enough to take advantage of their innovation. Indeed, they introduced automation in both domain name validation and certificate issuance (and revocation), by defining an open protocol that is meant to become an Internet standard. That protocol, named ACME, is not tied to Let's Encrypt and has several free software implementations, so it could be used for the same purpose by commercial CAs. A certification authority could, for instance:

• ask the customer to provision some pre-paid account;
• manually validate the customer's identity once;
• allow the customer to register using ACME, and associate that registration to his validated identity;
• allow the customer to get organization-validated, or perhaps even extended validation certificates using ACME, and making corresponding debits to his pre-paid account.

Such processes may require or benefit from improvements of the ACME protocol, which is the very reason Internet standards are defined in an open way. The first certification authority that would implement such a process could gain an advantage over its competitors, as it would greatly simplify getting and renewing certificates. I think even Let's Encrypt people would be happy to see that happen, as it would serve their goal, that is basically to help securing the Internet! Personally, I could buy such a service (assuming it is not restricted to juridical persons, according to a quite common (and detestable) sale discrimination against natural persons ). Notes

1. CAcert is an unrecognised certificate authority, that provides an identity validation through a web of trust, and issues DV server certificates that do not include the validated identity. Now that Let's Encrypt can issue valid DV certificates, CAcert is no longer relevant for that activity. It also issues personal certificates, that do include the validated identity, and that can be used for encryption (e.g. S/MIME), signing (e.g. code signing) or authentication, which is an activity Let's Encrypt does not compete with.
2. Yes, the Organization field of a certificate is probably not relevant to indicate a physical person's name, but the CommonName field is. Yes, that field is usually abused to store the domain name, but a proper use would be to put the owner's name in the CommonName field, and the domain names in the subjectAltName field.

The first time I was paid to do software development came as something of a surprise to me. I was working as a sysadmin in a computational physics research group when a friend asked me if I'd be willing to talk to her PhD supervisor. I had nothing better to do, so said yes. And that was how I started the evening having dinner with David MacKay, and ended the evening better fed, a little drunker and having agreed in principle to be paid to write free software.

I'd been hired to work on Dasher, an information-efficient text entry system. It had been developed by one of David's students as a practical demonstration of arithmetic encoding after David had realised that presenting a visualisation of an effective compression algorithm allowed you to compose text without having to enter as much information into the system. At first this was merely a neat toy, but it soon became clear that the benefits of Dasher had a great deal of overlap with good accessibility software. It required much less precision of input, it made it easy to correct mistakes (you merely had to reverse direction in order to start zooming back out of the text you had entered) and it worked with a variety of input technologies from mice to eye tracking to breathing. My job was to take this codebase and turn it into a project that would be interesting to external developers.

In the year I worked with David, we turned Dasher from a research project into a well-integrated component of Gnome, improved its support for Windows, accepted code from an external contributor who ported it to OS X (using an OpenGL canvas!) and wrote ports for a range of handheld devices. We added code that allowed Dasher to directly control the UI of other applications, making it possible for people to drive word processors without having to leave Dasher. We taught Dasher to speak. We strove to avoid the mistakes present in so many other pieces of accessibility software, such as configuration that could only be managed by an (expensive!) external consultant. And we visited Dasher users and learned how they used it and what more they needed, then went back home and did what we could to provide that.

Working on Dasher was an incredible opportunity. I was involved in the development of exciting code. I spoke on it at multiple conferences. I became part of the Gnome community. I visited the USA for the first time. I entered people's homes and taught them how to use Dasher and experienced their joy as they realised that they could now communicate up to an order of magnitude more quickly. I wrote software that had a meaningful impact on the lives of other people.

Working with David was certainly not easy. Our weekly design meetings were, charitably, intense. He had an astonishing number of ideas, and my job was to figure out how to implement them while (a) not making the application overly complicated and (b) convincing David that it still did everything he wanted. One memorable meeting involved me gradually arguing him down from wanting five new checkboxes to agreeing that there were only two combinations that actually made sense (and hence a single checkbox) - and then admitting that this was broadly equivalent to an existing UI element, so we could just change the behaviour of that slightly without adding anything. I took the opportunity to delete an additional menu item in the process.

I was already aware of the importance of free software in terms of developers, but working with David made it clear to me how important it was to users as well. A community formed around Dasher, helping us improve it and allowing us to develop support for new use cases that made the difference between someone being able to type at two words per minute and being able to manage twenty. David saw that this collaborative development would be vital to creating something bigger than his original ideas, and it succeeded in ways he couldn't have hoped for.

I spent a year in the group and then went back to biology. David went on to channel his strong feelings about social responsibility into issues such as sustainable energy, writing a freely available book on the topic. He served as chief adviser to the UK Department of Energy and Climate Change for five years. And earlier this year he was awarded a knighthood for his services to scientific outreach.

David died yesterday. It's unlikely that I'll ever come close to what he accomplished, but he provided me with much of the inspiration to try to do so anyway. The world is already a less fascinating place without him.

comments

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

• Antoine Beaupr did 8h.
• Ben Hutchings did 12.75 hours (out of 11 hours allocated + 7.25 extra hours remaining, meaning that he still has 5.50 extra hours to do over April).
• Brian May did 10 hours.
• Chris Lamb did 7 hours (instead of the 14.25 hours he was allocated +, compensating the extra hours he did last month).
• Damyan Ivanov did nothing out of the 7.25 remaining hours he had, he opted to give them back and come back to LTS work later.
• Guido G nther did 13 hours (out of 12 hours allocated + 4.25 remaining hours, leaving 3.25 extra hours for April).
• Markus Koschany did 14.25 hours.
• Mike Gabriel did nothing and opted to give back the 8 hours allocated. He will stop LTS work for now as he has other projects taking all his time.
• Santiago Ruano Rinc n did 10 hours (out of 12h allocated + 1.50 remaining, thus keeping 3.50 extra hours for April).
• Scott Kitterman did a few hours but was not able to provide his report in time due to sickness. His next report will cover two months.
• Thorsten Alteholz did 14.25 hours.

Evolution of the situation The number of sponsored hours started to increase for April (116.75 hours, thanks to Sonus Networks) and should increase even further for May (with a new Gold sponsor currently joining us, Babiel GmbH). Hopefully the trend will continue so that we can reach our objective of funding the equivalent of a full-time position. At the end of the month the LTS team will be fully responsible of all Debian 7 Wheezy updates. For now paid contributors are still helping the security team by fixing packages that were fixed in squeeze already but that are still outstanding in wheezy. They are also looking for ways to ensure that some of the most complicated packages can be supported over the wheezy LTS timeframe. It is likely that we will seek external help (possibly from credativ which is already handling support of PostgreSQL) for the maintenance of Xen and that some other packages (like libav, vlc, maybe qemu?) will be upgraded to newer versions which are still maintained (either upstream or in Debian Jessie by the Debian maintainers). Thanks to our sponsors New sponsors are in bold.

• Platinum sponsors:
• TOSHIBA (for 6 months)
• Gold sponsors:
• The Positive Internet (for 22 months)
• Blablacar (for 21 months)
• Linode LLC (for 11 months)
• Silver sponsors:
• Domeneshop AS (for 21 months)
• Universit Lille 3 (for 21 months)
• Trollweb Solutions (for 19 months)
• Nantes M tropole (for 15 months)
• University of Luxembourg (for 13 months)
• Dalenys (for 11 months)
• Univention GmbH (for 7 months)
• Universit Jean Monnet de St Etienne (for 7 months)
• Sonus Networks
• Bronze sponsors:
• David Ayers IntarS Austria (for 22 months)
• Offensive Security (for 22 months)
• Seznam.cz, a.s. (for 22 months)
• Evolix (for 21 months)
• Freeside Internet Service (for 21 months)
• MyTux (for 21 months)
• Linuxhotel GmbH (for 19 months)
• Intevation GmbH (for 18 months)
• Daevel SARL (for 17 months)
• Bitfolk LTD (for 16 months)
• Megaspace Internet Services GmbH (for 16 months)
• Greenbone Networks GmbH (for 15 months)
• NUMLOG (for 15 months)
• WinGo AG (for 14 months)
• Ecole Centrale de Nantes LHEEA (for 11 months)
• Sig-I/O (for 8 months)
• Entr ouvert (for 6 months)
• Adfinis SyGroup AG (for 3 months)

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

Recently, Digital Ocean (which I am a customer of) asked me "how they were doing". Well, yet another survey... Let's ignore this one for now... I thought some days ago. And then yesterday, I added IPv6 support to my main mail server (which runs at Hetzner, Germany). All my hosted/rented/whatever systems report back to this main mailserver. Now that that main mail server finally has its AAAA record and its own IPv6 address, all associated systems try to reach this main mail server via IPv6. Of course. Crippling IPv6 support by adding Port Blocks But, then, I see messages like these in my syslog files on droplets hosted at Digital Ocean:

Apr 13 10:10:59 <do-droplet> postfix/smtp[23469]: connect to mail.<mydomain>[<ipv6-address>]:25: Connection timed out

After some more research [1], I realized that the folks out there at DO really apply some port blockings to IPv6 networks, but not to IPv4 networks. Pardon me? From my DO droplets, I can nmap any port on my mail server (25,80,143,443, 465, 587, etc.) via the IPv4 connection, but not over the IPv6 connection. Wait, not fully true: ports 80 and 443 are not blocked, but the other aforementioned ports are definitely blocked. Is Digital Ocean a professional ISP or a WiFi hotspot provider at my nearest coffee place? (This really makes me scratch my head...). Routing only the first 16 addresses of allocated /64 prefixes The above was the second IPv6 brokeness I learned about DO, recently. An earlier issue with DO's IPv6 support, I encountered while I was deploying an IPv6 capable OpenVPN internet gateway via a droplet hosted at DO. Digital Ocean assigns full IPv6 /64 prefixes to each individual droplet (which is great), but only properly routes the first 16 IP addresses of such a /64 prefix [2]. Urgh? I had to work around this flaw by adding an IPv6-over-IPv4 tunnel and attaching an IPv6 /56 prefix obtained from Hurricane Electrics' tunnel broker service [3] to the OpenVPN server. Thanks, Digital Ocean, for reminding me about giving feedback So, today, I luckily received a reminder mail about DO's yet-another-survey survey. My opportunity!!! Here is the feedback, I gave:

DO service is basically good.
BUT: You as a provider SUCK when it comes to IPv6.
(1) http://pixelschatten.net/blocked-ipv6-ports/
-> SMTP/IMAP traffic blocked over IPv6, but not over IPv4... WTF?). I normally have all my systems report back to my main mail server. I expect this to work as it is the default on all Linux hosts nowadays, and that is: prefer IPv6 over IPv4.
(2) https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestion...
-> Droplets get a full /64 prefix assigned, but only the first 16 addresses (or such) get routed properly. WTF?
Please do your homework on IPv6 and don't cripple your service by offering crippled IPv6 support.
I tell people, DO is great, but their IPv6 support is broken-by-design. Let me know, once this is about to change.
Mike Gabriel (aka sunweaver at debian dot org, Debian Developer)

Apology for the tone of the wording Now reading the feedback given, I realize that my tone has been quite impolite. I am sorry about this. However, the experienced IPv6 issues are indeed annoying. So please excuse me for having expressed my annoyance with such harsh words. And... I am still annoyed about myself paying an ISP for such a crippled IPv6 support. (I need to consider migrating the VMs to another hoster, unless there will be some dynamics observable in the near future). @Digital Ocean: Keep up the good work that you do in the realm of VM hosting. Evolve and grow up in the realm of IPv6 networking. Thank you! light+love
Mike [1] http://pixelschatten.net/blocked-ipv6-ports/
[2] https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestion...
[3] https://tunnelbroker.net/

It is time of the year where Debian project members should elect a new project leader. This year, only one candidate has stepped up, yours truly. As a reminder, my platform is published here. The campaign has been quite calm, comparing to past editions, which is not surprising given the number of candidates. There have been some interesting questions though as detailed below:

• Thoughts about quantity of DPL candidates? (reply)
• Thoughts about liw's non-platform (reply)
• Broader vision on Debian and its role in the FOSS/IT ecosystem (reply)
• DPL job profile (reply)

There are not many questions. It will take little time to read, if you haven't already.

Last but not least, please do vote! You have until 2016-04-16 23:59:59 UTC to vote (as announced here). It is very important to share your opinion and take part in the reflection around the future of the project. That every project member takes part in the evolutions that should be implemented to stay relevant and innovative in what we do.

That s a longer title than I d like, but I want to try and catch the attention of anyone who might have missed more directed notifications about this. If you re not an SPI contributing member there s probably nothing to see here Although I decided not to stand for re-election at the Software in the Public Interest (SPI) board elections last July, I haven t stopped my involvement with the organisation. In particular I ve spent some time working on an overhaul of the members website and rolling it out. One of the things this has enabled is implementation of 2009-11-04.jmd.1: Contributing membership expiry, by tracking activity in elections and providing an easy way for a member to indicate they consider themselves active even if they haven t voted. The plan is that this will run at some point after the completion of every board election. A first pass of cleanups was completed nearly a month ago, contacting all contributing members who d never been seen to vote and asking them to update their status if they were still active. A second round, of people who didn t vote in the last board election (in 2014), is currently under way. Affected members will have been emailed directly and there was a mail to spi-announce, but I m aware people often overlook these things or filter mail off somewhere that doesn t get read often. If you are an SPI Contributing member who considers themselves an active member I strongly recommend you login to the SPI Members Website and check the Last active date displayed is after 2014-07-14 (i.e. post the start of the last board election). If it s not, click on the Update link beside the date. The updated date will be shown once you ve done so. Why does pruning inactive members matter? The 2015 X.Org election results provide at least one indication of why ensuring you have an engaged membership is important - they failed to make a by-laws change that a vast majority of votes were in favour of, due to failing to make quorum. (If you re an X.org member, go vote!)

That s a longer title than I d like, but I want to try and catch the attention of anyone who might have missed more directed notifications about this. If you re not an SPI contributing member there s probably nothing to see here Although I decided not to stand for re-election at the Software in the Public Interest (SPI) board elections last July, I haven t stopped my involvement with the organisation. In particular I ve spent some time working on an overhaul of the members website and rolling it out. One of the things this has enabled is implementation of 2009-11-04.jmd.1: Contributing membership expiry, by tracking activity in elections and providing an easy way for a member to indicate they consider themselves active even if they haven t voted. The plan is that this will run at some point after the completion of every board election. A first pass of cleanups was completed nearly a month ago, contacting all contributing members who d never been seen to vote and asking them to update their status if they were still active. A second round, of people who didn t vote in the last board election (in 2014), is currently under way. Affected members will have been emailed directly and there was a mail to spi-announce, but I m aware people often overlook these things or filter mail off somewhere that doesn t get read often. If you are an SPI Contributing member who considers themselves an active member I strongly recommend you login to the SPI Members Website and check the Last active date displayed is after 2014-07-14 (i.e. post the start of the last board election). If it s not, click on the Update link beside the date. The updated date will be shown once you ve done so. Why does pruning inactive members matter? The 2015 X.Org election results provide at least one indication of why ensuring you have an engaged membership is important - they failed to make a by-laws change that a vast majority of votes were in favour of, due to failing to make quorum. (If you re an X.org member, go vote!)

Last week was focused on our SQL parser as several issues have been found there. If was for me also first release of SQL parser to packagist repository. Besides code changes, there was quite some time spent on reviewing incoming issues. Most of they have been already fixed and users will get fixes in the 4.6.1 release. Handled issues:

• #12147 Fix #12143 Cannot login with certain password
• #12168 Internal Server Error message
• #12166 More compact table list / tree
• #12164 Error 200 when creating a table
• #12130 Error for Browser when got error 500
• #12165 Soft lock when typing DEFAULT 0 in SQL tab
• #12159 4.6.0: Export generating error 500 (was working in 4.5.5.1)
• #12157 Simplify SSL setup
• #12129 Slow database list on 4.6
• #12161 SkipLockedTables broken in master
• #12154 Cannot redeclare __()
• #12029 4.5.5 ExportSql.class.php incorrect call to SqlParser\Context
• #12152 phpMyAdmin difference between display and display HTML web page
• #20 Formatting
• #41 Unrecognized keywords and statement types on 4.5.5.1
• #47 "closing bracket expected" when creating table
• #45 FULLTEXT unrecognized data type
• #1 Fix composer install procedure

Filed under: English phpMyAdmin 0 comments

X.org Election Time Vote Now It's more important than usual to actually get your vote in we're asking the membership to vote on changes the the X.org bylaws that are necessary for X.org to become a SPI affiliate project, instead of continuing on as a separate organization. While I'm in favor of this transition as I think it will provide much needed legal and financial help, the real reason we need everyone to vote is that we need of the membership to cast ballots for the vote to be valid. Last time, we didn't reach that value, so even though we had a majority voting in favor of the change, it didn't take effect. If you aren't in favor of this change, I'd still encourage you to vote as I'd like to get a valid result, no matter the outcome. Of course, we're also electing four members to the board. I'm happy to note that there are five candidates running for the four available seats, which shows that there are enough people willing to help serve the X.org community in this fashion.

What happened in the reproducible builds effort between March 27th and April 2nd: Toolchain fixes

• Emmanuel Bourg uploaded ant/1.9.6-2 which makes the Tstamp task support the SOURCE_DATE_EPOCH variable, and the Javadoc task use en as the default locale if none was specified and SOURCE_DATE_EPOCH is set.

Packages fixed The following packages have become reproducible due to changes in their build dependencies: ctioga2, erlang-bitcask, libcommons-collections3-java, libjgoodies-animation-java, libjide-oss-java, octave-gsl, octave-interval, octave-io, octave-quaternion, octave-signal, octave-stk, segment, service-wrapper-java, sqlline, svnkit, uddi4j, velocity-tools. The following packages became reproducible after getting fixed:

• angular.js/1.3.20-3 uploaded by Laszlo Boszormenyi, patch by Dhole.
• boa-constructor/0.6.1-16 by Reiner Herrmann.
• fgetty/0.7-1 by Dmitry Bogatov.
• hexchat/2.12.0-1 uploaded by Jesse Rhodes, fixed upstream.
• littlewizard/1.2.2-4 uploaded by Kari Pahula, original patch by Reiner Herrmann.
• logback/1:1.1.6-1 by Emmanuel Bourg.
• pcsxr/1.9.94-2 by James Cowgill.
• pybtex/0.19-2 by Daniel Stender.
• python-structlog/16.0.0-1 by Filippo Giunchedi.
• sbmltoolbox/4.1.0-3 by Afif Elghraoui, original patch by Reiner Herrmann.
• tiles/2.2.2-7 by Emmanuel Bourg.

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

• dash/0.5.8-2.2 uploaded by Niels Thykier, original patch by Lunar.
• gle-graphics/4.2.5-4 by Christian T. Steigies.
• prospector/0.11.7-6 by Daniel Stender.
• therion/5.3.16-10 by Wookey.
• vim/2:7.4.1689-1 uploaded by James McCoy, original patch by Reiner Herrmann.

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

• #783239 on kexec-tools by Lunar: follow-up patch to cope with locale variations.
• #819347 on starvoyager by Sascha Steinbiss: sort the list of input object files.
• #819352 on xpdf by Sascha Steinbiss: sort the list of linked object files.
• #819512 on breeze by Dhole: force grep to treat all files as text to avoid locale-related issues.
• #819726 on ckbuilder by boyska: add support for SOURCE_DATE_EPOCH.
• #819767 on libtool by rain1: removes extra timestamps from the build system, ensure a stable file order when creating the source archive, and replace uses of the hostname command with the fixed string "localhost".

tests.reproducible-builds.org The i386 builders are now testing packages on i386 for reproducibility. It will probably take 4 weeks until everything has been build twice, on this arch. (h01ger) Package reviews 52 reviews have been removed, 24 added and 4 updated in the previous week. Chris Lamb reported 13 new FTBFS. New issue: copyright_year_in_comments_generated_by_ckbuilder. Misc. This week's edition was mostly written by Lunar, with some help by Reiner Herrmann and h01ger.

What happened in the reproducible builds effort between March 20th and March 26th: Toolchain fixes

• Sebastian Ramacher uploaded breathe/4.2.0-1 which makes its output deterministic. Original patch by Chris Lamb, merged upstream.
• Rafael Laboissiere uploaded octave/4.0.1-1 which allows packages to be built in place and avoid unreproducible builds due to temporary build directories appearing in the .oct files.

Daniel Kahn Gillmor worked on removing build path from build symbols submitting a patch adding -fdebug-prefix-map to clang to match GCC, another patch against gcc-5 to backport the removal of -fdebug-prefix-map from DW_AT_producer, and finally by proposing the addition of a normalizedebugpath to the reproducible feature set of dpkg-buildflags that would use -fdebug-prefix-map to replace the current directory with . using -fdebug-prefix-map. Sergey Poznyakoff merged the --clamp-mtime option so that it will be featured in the next Tar release. This option is likely to be used by dpkg-deb to implement deterministic mtimes for packaged files. Packages fixed The following packages have become reproducible due to changes in their build dependencies: augeas, gmtkbabel, ktikz, octave-control, octave-general, octave-image, octave-ltfat, octave-miscellaneous, octave-mpi, octave-nurbs, octave-octcdf, octave-sockets, octave-strings, openlayers, python-structlog, signond. The following packages became reproducible after getting fixed:

• atheme-services/7.0.7-1 by Antoine Beaupr .
• boa-constructor/0.6.1-16 by Reiner Herrmann.
• calculix-ccx/2.10-1 by Wolfgang F tterer, fixed upstream.
• deap/1.0.2.post2-2 by Daniel Stender.
• debian-keyring/2016.03.22 uploaded by Jonathan McDowell, fix by Niels Thykier, obsolete patch by Satyam Zode.
• firefox-kwallet5/1.0-2 by Sandro Knau .
• fox1.6/1.6.51-1 by Joachim Wiedorn.
• gdnsd/2.2.3-1 by Faidon Liambotis.
• glib2.0/2.48.0-1 uploaded by Iain Lane, original patch by Lunar, merged upstream.
• jwm/2.3.4-1 uploaded by Samuel Henrique Oltramari Pinto, fix by Reiner Herrmann.
• libasm4-java/5.0.4-2 by Emmanuel Bourg.
• libjna-java/4.2.2-1 by Emmanuel Bourg.
• libsynthesis/3.4.0.47.5+syncevolution-1.5.1-1 uploaded by Tino Mettler, patch by Reiner Herrmann.
• logback/1:1.1.6-1 by Emmanuel Bourg.
• nethack/3.6.0-2 uploaded by James Cowgill, patch by Reiner Herrmann.
• php-htmlpurifier/4.7.0-2 by David Pr vot.
• psocksxx/1.1.0-1 by Gianfranco Costamagna.
• sbmltoolbox/4.1.0-3 uploaded by Afif Elghraoui, original patch by Reiner Herrmann.
• spades/3.7.1+dfsg-2 by Sascha Steinbiss.
• sprng/2.0a-10 uploaded by Dirk Eddelbuettel, original patch by Reiner Herrmann.

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

• gle-graphics/4.2.5-2 by Christian T. Steigies.
• kexec-tools/1:2.0.10-2 uploaded by Khalid Aziz, original patch by Lunar.
• pdal/1.1.0-4 by Bas Couwenberg.
• tcl8.5/8.5.19-2 uploaded by Sergei Golovan, original patch.
• tcl8.6/8.6.5+dfsg-2 uploaded by Sergei Golovan, original patch.

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

• #818742 on milkytracker by Reiner Herrmann: sorts the list of source files.
• #818752 on tcl8.4 by Reiner Herrmann: sort source files using C locale.
• #818753 on tk8.6 by Reiner Herrmann: sort source files using C locale.
• #818754 on tk8.5 by Reiner Herrmann: sort source files using C locale.
• #818755 on tk8.4 by Reiner Herrmann: sort source files using C locale.
• #818952 on marionnet by ceridwen: dummy out build date and uname to make build reproducible.
• #819334 on avahi by Reiner Herrmann: ship upstream changelog instead of the one generated by gettextize (although duplicate of #804141 by Santiago Vila).

tests.reproducible-builds.org i386 build nodes have been setup by converting 2 of the 4 amd64 nodes to i386. (h01ger) Package reviews 92 reviews have been removed, 66 added and 31 updated in the previous week. New issues: timestamps_generated_by_xbean_spring, timestamps_generated_by_mangosdk_spiprocessor. Chris Lamb filed 7 FTBFS bugs. Misc. On March 20th, Chris Lamb gave a talk at FOSSASIA 2016 in Singapore. The very same day, but a few timezones apart, h01ger did a presentation at LibrePlanet 2016 in Cambridge, Massachusetts. Seven GSoC/Outreachy applications were made by potential interns to work on various aspects of the reproducible builds effort. On top of interacting with several applicants, prospective mentors gathered to review the applications.

I'm happy to report that the French paperback edition of my project to translate the Free Culture book by Lawrence Lessig is now available for sale on Lulu.com. Once I have formally verified my proof reading copy, which should be in the mail, the paperback edition should be available in book stores like Amazon and Barnes & Noble too. This French edition, Culture Libre, is the work of the dblatex developer Beno t Guillon, who created the PO file from the initial translation available from the Wikilivres wiki pages and completed and corrected the translation to match the original docbook edition my project is using, as well as coordinated the proof reading of the final result. I believe the end result look great, but I am biased and do not read French. In addition to the paperback edition, the book is available in PDF, EPUB and Mobi format from the github project page linked to above. When enabling book store distribution on Lulu.com, I had to nearly triple the price to allow the book stores some profit. I also had to accept that I will get some revenue when a book is sold via Lulu.com. But because of the non-commercial clause in the book license (CC-BY-NC), this might be a problem. To bypass the problem I discussed how to handle the revenue with the author, and we agreed that the revenue for these editions go to the Creative Commons non-profit Corporation who handle donations to the Creative Commons project. So far they have earned around USD 70 on sales of the English and Norwegian Bokm l editions, according to Lulu.com. They will get the revenue for the French edition too. Their revenue is higher if you buy the book directly from Lulu.com instead of via a book store, so I recommend you buy directly from Lulu.com. Perhaps you would like to get the book published in your language? The translation is done using a web based translator service, so the technical bar to enter is fairly low. Get in touch if you would like to make this happen.

Greetings! This is a (4 days delay) copy of the announce I made on the openstack-dev@lists.openstack.org on the 8th of April 2016. I am overjoyed, thrilled and delighted to announce the release of the Debian packages for Mitaka. All of the DefCore packages were validated successfully this morning through our package-only-based Tempest CI. Content of this release
This release includes the following 23 services:
aodh 2.0.0
barbican 2.0.0
ceilometer 6.0.0
cinder 8.0.0
congress 3.0.0+dfsg1
designate 2.0.0
glance 12.0.0
gnocchi 2.0.2
heat 6.0.0
horizon 9.0.0
ironic 5.1.0
keystone 9.0.0
magnum 2.0.0
manila 2.0.0
mistral 2.0.0
murano 2.0.0
neutron 8.0.0
nova 13.0.0
trove 5.0.0
sahara 4.0.0
senlin 1.0.0
swift 2.7.0
zaqar 2.0.0 Where to find these packages
1/ Sid
All of Mitaka was uploaded to Debian Sid this week. You can use Debian Sid directly to use them. 2/ Official jessie-backports
As soon as everything migrates to Debian Testing (currently aka: Stretch), in 5 days if no RC bug is reported, it will be possible to upload all of Mitaka to the Debian official jessie-backports. 3/ Non-official Jessie and Trusty backports
In the meantime, the packages are available through Mirantis Jenkins automatic Debian Jessie backport repository. The full sources.list is available here: http://mitaka-jessie.pkgs.mirantis.com/ You can use the Trusty backports as well: http://mitaka-trusty.pkgs.mirantis.com/ To use these repositories, simply add the described sources.list to (for example) /etc/apt/sources.list.d/openstack.list, and run apt-get update. If you want to install the GPG key of the repositories, you can either install the mitaka-jessie-archive-keyring or mitaka-trusty-archive-keyring package (depending on your distribution of choice). Alternatively apt-key add the public key available at /debian/dists/pukey.gpg in these repositories. As a reminder, the URLs above contain the word Mirantis only because the service is sponsored by my employer. These repositories are straight backports from what is available in Debian Sid, without any modification. Remember that the packages listed below are maintained separately in Debian and Ubuntu, and therefore, packages are different in these distributions:
aodh, barbican, ceilometer, cinder, designate, glance, heat, horizon, ironic, keystone, manila, neutron, nova, trove, swift. All other packages (including all OpenStack libraries like Oslo and python-*clients) are maintained in Debian, with the contribution of Canonical, and then synced to Ubuntu, so they are the exact same packages (or at least, with a minimal difference). I hope we can further improve collaboration between Debian and Canonical during the Newton cycle. Bug reporting
As always, bug reports are welcome, and considered as high value contributions. Please follow the instructions available at https://www.debian.org/Bugs/Reporting to report bugs to the Debian BTS. Moving forward with higher QA and the Packaging-deb project in Newton
Currently, DefCore packages are tested through a package-only (ie: no puppet, chef, you-name-it system management involved) Tempest CI. Results can be seen at:
https://mitaka-jessie.pkgs.mirantis.com/job/openstack-tempest-ci/ Though not all packages are included in this CI. It is my intention, during the Newton cycle, to also include services like Designate, Trove, Barbican, Congress, in this CI. Individual upstream team for these services are more than welcome to approach us to get this happen quicker. Also, as we re slowing starting to get the Packaging-Deb project (ie: packaging using upstream OpenStack gerrit and gating), it is also in the pipe to use the above mentioned tempest CI system as a gate system for the packaging. Hopefully, this will lead us to a full CI/CD working from trunk. We also hope to be able to use these packages to help the Puppet team to test packaged OpenStack from trunk. Greetings
On each release, I ask myself who I should thank. This time, I would like to thank everyone, because this release was overall very nice and working well. The whole OpenStack community is always very helpful and understand the requirements of downstream distributions. Guys, you re awesome, I love my work, and I love working with you all! Cheers,

I've been working on TPMTOTP a little this weekend. I merged a pull request that adds command-line argument handling, which includes the ability to choose the set of PCRs you want to seal to without rebuilding the tools, and also lets you print the base32 encoding of the secret rather than the qr code so you can import it into a wider range of devices. More importantly it also adds support for setting the expected PCR values on the command line rather than reading them out of the TPM, so you can now re-seal the secret against new values before rebooting.

I also wrote some new code myself. TPMTOTP is designed to be usable in the initramfs, allowing you to validate system state before typing in your passphrase. Unfortunately the initramfs itself is one of the things that's measured. So, you end up with something of a chicken and egg problem - TPMTOTP needs access to the secret, and the obvious thing to do is to put the secret in the initramfs. But the secret is sealed against the hash of the initramfs, and so you can't generate the secret until after the initramfs. Modify the initramfs to insert the secret and you change the hash, so the secret is no longer released. Boo.

On EFI systems you can handle this by sticking the secret in an EFI variable (there's some special-casing in the code to deal with the additional metadata on the front of things you read out of efivarfs). But that's not terribly useful if you're not on an EFI system. Thankfully, there's a way around this. TPMs have a small quantity of nvram built into them, so we can stick the secret there. If you pass the -n argument to sealdata, that'll happen. The unseal apps will attempt to pull the secret out of nvram before falling back to looking for a file, so things should just magically work.

I think it's pretty feature complete now, other than TPM2 support? That's on my list.

comments

Started in 2008, lldpd is an implementation of IEEE 802.1AB-2005 (aka LLDP) written in C. While it contains some unit tests, like many other network-related software at the time, the coverage of those is pretty poor: they are hard to write because the code is written in an imperative style and tighly coupled with the system. It would require extensive mocking¹. While a rewrite (complete or iterative) would help to make the code more test-friendly, it would be quite an effort and it will likely introduce operational bugs along the way. To get better test coverage, the major features of lldpd are now verified through integration tests. Those tests leverage Linux network namespaces to setup a lightweight and isolated environment for each test. They run through pytest, a powerful testing tool.

pytest in a nutshell pytest is a Python testing tool whose primary use is to write tests for Python applications but is versatile enough for other creative usages. It is bundled with three killer features:

• you can directly use the assert keyword,
• you can inject fixtures in any test function, and
• you can parametrize tests.

Assertions With unittest, the unit testing framework included with Python, and many similar frameworks, unit tests have to be encapsulated into a class and use the provided assertion methods. For example:

class testArithmetics(unittest.TestCase):
    def test_addition(self):
        self.assertEqual(1 + 3, 4)

The equivalent with pytest is simpler and more readable:

def test_addition():
    assert 1 + 3 == 4

pytest will analyze the AST and display useful error messages in case of failure. For further information, see Benjamin Peterson s article.

Fixtures A fixture is the set of actions performed in order to prepare the system to run some tests. With classic frameworks, you can only define one fixture for a set of tests:

class testInVM(unittest.TestCase):
    def setUp(self):
        self.vm = VM('Test-VM')
        self.vm.start()
        self.ssh = SSHClient()
        self.ssh.connect(self.vm.public_ip)
    def tearDown(self):
        self.ssh.close()
        self.vm.destroy()
    def test_hello(self):
        stdin, stdout, stderr = self.ssh.exec_command("echo hello")
        stdin.close()
        self.assertEqual(stderr.read(), b"")
        self.assertEqual(stdout.read(), b"hello\n")

In the example above, we want to test various commands on a remote VM. The fixture launches a new VM and configure an SSH connection. However, if the SSH connection cannot be established, the fixture will fail and the tearDown() method won t be invoked. The VM will be left running. Instead, with pytest, we could do this:

@pytest.yield_fixture
def vm():
    r = VM('Test-VM')
    r.start()
    yield r
    r.destroy()
@pytest.yield_fixture
def ssh(vm):
    ssh = SSHClient()
    ssh.connect(vm.public_ip)
    yield ssh
    ssh.close()
def test_hello(ssh):
    stdin, stdout, stderr = ssh.exec_command("echo hello")
    stdin.close()
    stderr.read() == b""
    stdout.read() == b"hello\n"

The first fixture will provide a freshly booted VM. The second one will setup an SSH connection to the VM provided as an argument. Fixtures are used through dependency injection: just give their names in the signature of the test functions and fixtures that need them. Each fixture only handle the lifetime of one entity. Whatever a dependent test function or fixture succeeds or fails, the VM will always be finally destroyed.

Parameters If you want to run the same test several times with a varying parameter, you can dynamically create test functions or use one test function with a loop. With pytest, you can parametrize test functions and fixtures:

@pytest.mark.parametrize("n1, n2, expected", [
    (1, 3, 4),
    (8, 20, 28),
    (-4, 0, -4)])
def test_addition(n1, n2, expected):
    assert n1 + n2 == expected

Testing lldpd The general plan for to test a feature in lldpd is the following:

1. Setup two namespaces.
2. Create a virtual link between them.
3. Spawn a lldpd process in each namespace.
4. Test the feature in one namespace.
5. Check with lldpcli we get the expected result in the other.

Here is a typical test using the most interesting features of pytest:

@pytest.mark.skipif('LLDP-MED' not in pytest.config.lldpd.features,
                    reason="LLDP-MED not supported")
@pytest.mark.parametrize("classe, expected", [
    (1, "Generic Endpoint (Class I)"),
    (2, "Media Endpoint (Class II)"),
    (3, "Communication Device Endpoint (Class III)"),
    (4, "Network Connectivity Device")])
def test_med_devicetype(lldpd, lldpcli, namespaces, links,
                        classe, expected):
    links(namespaces(1), namespaces(2))
    with namespaces(1):
        lldpd("-r")
    with namespaces(2):
        lldpd("-M", str(classe))
    with namespaces(1):
        out = lldpcli("-f", "keyvalue", "show", "neighbors", "details")
        assert out['lldp.eth0.lldp-med.device-type'] == expected

First, the test will be executed only if lldpd was compiled with LLDP-MED support. Second, the test is parametrized. We will execute four distinct tests, one for each role that lldpd should be able to take as an LLDP-MED-enabled endpoint. The signature of the test has four parameters that are not covered by the parametrize() decorator: lldpd, lldpcli, namespaces and links. They are fixtures. A lot of magic happen in those to keep the actual tests short:

• lldpd is a factory to spawn an instance of lldpd. When called, it will setup the current namespace (setting up the chroot, creating the user and group for privilege separation, replacing some files to be distribution-agnostic, ), then call lldpd with the additional parameters provided. The output is recorded and added to the test report in case of failure. The module also contains the creation of the pytest.config.lldpd object that is used to record the features supported by lldpd and skip non-matching tests. You can read fixtures/programs.py for more details.
• lldpcli is also a factory, but it spawns instances of lldpcli, the client to query lldpd. Moreover, it will parse the output in a dictionary to reduce boilerplate.
• namespaces is one of the most interesting pieces. It is a factory for Linux namespaces. It will spawn a new namespace or refer to an existing one. It is possible to switch from one namespace to another (with with) as they are contexts. Behind the scene, the factory maintains the appropriate file descriptors for each namespace and switch to them with setns(). Once the test is done, everything is wipped out as the file descriptors are garbage collected. You can read fixtures/namespaces.py for more details. It is quite reusable in other projects².
• links contains helpers to handle network interfaces: creation of virtual ethernet link between namespaces, creation of bridges, bonds and VLAN, etc. It relies on the pyroute2 module. You can read fixtures/network.py for more details.

You can see an example of a test run on the Travis build for 0.9.2. Since each test is correctly isolated, it s possible to run parallel tests with pytest -n 10 --boxed. To catch even more bugs, both the address sanitizer (ASAN) and the undefined behavior sanitizer (UBSAN) are enabled. In case of a problem, notably a memory leak, the faulty program will exit with a non-zero exit code and the associated test will fail.

---

1. A project like cwrap would definitely help. However, it lacks support for Netlink and raw sockets that are essential in lldpd operations.
2. There are three main limitations in the use of namespaces with this fixture. First, when creating a user namespace, only root is mapped to the current user. With lldpd, we have two users (root and _lldpd). Therefore, the tests have to run as root. The second limitation is with the PID namespace. It s not possible for a process to switch from one PID namespace to another. When you call setns() on a PID namespace, only children of the current process will be in the new PID namespace. The PID namespace is convenient to ensure everyone gets killed once the tests are terminated but you must keep in mind that /proc must be mounted in children only. The third limitation is that, for some namespaces (PID and user), all threads of a process must be part of the same namespace. Therefore, don t use threads in tests. Use multiprocessing module instead.

Let's see if I can scrounge through all of my now-organized directories of ebooks and figure out what I haven't recorded here yet. At least the paper books make that relatively easy, since I don't shelve them until I post them. (Yeah, yeah, I should actually make a database.) Hugh Aldersey-Williams Periodic Tales (nonfiction)
Sandra Ulbrich Almazan SF Women A-Z (nonfiction)
Radley Balko Rise of the Warrior Cop (nonfiction)
Peter V. Brett The Warded Man (sff)
Lois McMaster Bujold Gentleman Jole and the Red Queen (sff)
Fred Clark The Anti-Christ Handbook Vol. 2 (nonfiction)
Dave Duncan West of January (sff)
Karl Fogel Producing Open Source Software (nonfiction)
Philip Gourevitch We Wish to Inform You That Tomorrow We Will Be Killed With Our Families (nonfiction)
Andrew Groen Empires of EVE (nonfiction)
John Harris @ Play (nonfiction)
David Hellman & Tevis Thompson Second Quest (graphic novel)
M.C.A. Hogarth Earthrise (sff)
S.L. Huang An Examination of Collegial Dynamics... (sff)
S.L. Huang & Kurt Hunt Up and Coming (sff anthology)
Kameron Hurley Infidel (sff)
Kevin Jackson-Mead & J. Robinson Wheeler IF Theory Reader (nonfiction)
Rosemary Kirstein The Lost Steersman (sff)
Rosemary Kirstein The Language of Power (sff)
Merritt Kopas Videogames for Humans (nonfiction)
Alisa Krasnostein & Alexandra Pierce (ed.) Letters to Tiptree (nonfiction)
Mathew Kumar Exp. Negatives (nonfiction)
Ken Liu The Grace of Kings (sff)
Susan MacGregor The Tattooed Witch (sff)
Helen Marshall Gifts for the One Who Comes After (sff collection)
Jack McDevitt Coming Home (sff)
Seanan McGuire A Red-Rose Chain (sff)
Seanan McGuire Velveteen vs. The Multiverse (sff)
Seanan McGuire The Winter Long (sff)
Marc Miller Agent of the Imperium (sff)
Randal Munroe Thing Explainer (graphic nonfiction)
Marguerite Reed Archangel (sff)
J.K. Rowling Harry Potter: The Complete Collection (sff)
K.J. Russell Tides of Possibility (sff anthology)
Robert J. Sawyer Starplex (sff)
Bruce Schneier Secrets & Lies (nonfiction)
Mike Selinker (ed.) The Kobold Game to Board Game Design (nonfiction)
Douglas Smith Chimerascope (sff collection)
Jonathan Strahan Fearsome Journeys (sff anthology)
Nick Suttner Shadow of the Colossus (nonfiction)
Aaron Swartz The Boy Who Could Change the World (essays)
Caitlin Sweet The Pattern Scars (sff)
John Szczepaniak The Untold History of Japanese Game Developers I (nonfiction)
John Szczepaniak The Untold History of Japanese Game Developers II (nonfiction)
Jeffrey Toobin The Run of His Life (nonfiction)
Hayden Trenholm Blood and Water (sff anthology)
Coen Teulings & Richard Baldwin (ed.) Secular Stagnation (nonfiction)
Ursula Vernon Book of the Wombat 2015 (graphic nonfiction)
Ursula Vernon Digger (graphic novel) Phew, that was a ton of stuff. A bunch of these were from two large StoryBundle bundles, which is a great source of cheap DRM-free ebooks, although still rather hit and miss. There's a lot of just fairly random stuff that's been accumulating for a while, even though I've not had a chance to read very much. Vacation upcoming, which will be a nice time to catch up on reading.

Do you fancy a hack-camp in a place like this? As you might have heard by now, Ana (Guerrero) and I are organising a small Debian event this spring: the Debian SunCamp 2016. It is going to be different to most other Debian events. Instead of a busy schedule of talks, SunCamp will focus on the hacking and socialising aspect. We have tried to make this event the simplest event possible, both for organisers and attendees. There will be no schedule, except for the meal times at the hotel. But these can be ignored too, there is a lovely bar that serves snacks all day long, and plenty of restaurants and caf s around the village. One of the things that makes the event simple, is that we have negotiated a flat price for accommodation that includes usage of all the facilities in the hotel, and optionally food. We will give you a booking code, and then you arrange your accommodation as you please, you can even stay longer if you feel like it! The rooms are simple but pretty, and everything has been renovated very recently. We are not preparing a talks programme, but we will provide the space and resources for talks if you feel inclined to prepare one. You will have a huge meeting room, divided in 4 areas to reduce noise, where you can hack, have team discussions, or present talks. Of course, some people will prefer to move their discussions to the outdoor area. Or just skip the discussion, and have a good time with your Debian friends, playing p tanque, pool, air hockey, arcades, or board games. Do you want to see more pictures? Check the full gallery

---

Debian SunCamp 2016 Hotel Anabel, LLoret de Mar, Province of Girona, Catalonia, Spain May 26-29, 2016

---

Tempted already? Head to the wikipage and register now, it is only 7 weeks away! Please reserve your room before the end of April. The hotel has reserved a number of rooms for us until that time. You can reserve a room after April, but we can't guarantee the hotel will still have free rooms. Comment

The Debian repository format was designed a long time ago. The oldest versions of it were produced with the help of tools such as dpkg-scanpackages and consumed by dselect access methods such as dpkg-ftp. The access methods just fetched a Packages file (perhaps compressed) and used it as an index of which packages were available; each package had an MD5 checksum to defend against transport errors, but being from a more innocent age there was no repository signing or other protection against man-in-the-middle attacks. An important and intentional feature of the early format was that, apart from the top-level Packages file, all other files were static in the sense that, once published, their content would never change without also changing the file name. This means that repositories can be efficiently copied around using rsync without having to tell it to re-checksum all files, and it avoids network races when fetching updates: the repository you re updating from might change in the middle of your update, but as long as the repository maintenance software keeps superseded packages around for a suitable grace period, you ll still be able to fetch them. The repository format evolved rather organically over time as different needs arose, by what one might call distributed consensus among the maintainers of the various client tools that consumed it. Of course all sorts of fields were added to the index files themselves, which have an extensible format so that this kind of thing is usually easy to do. At some point a Sources index for source packages was added, which worked pretty much the same way as Packages except for having a different set of fields. But by far the most significant change to the repository structure was the package pools project. The original repository layout put the packages themselves under the dists/ tree along with the index files. The dists/ tree is organised by suite (modern examples of which would be stable , stable-updates , testing , unstable , xenial , xenial-updates , and so on). This meant that making a release of Debian tended to involve copying lots of data around, and implementing the testing suite would have been very costly. Package pools solved this problem by moving individual package files out of dists/ and into a new pool/ tree, allowing those files to be shared between multiple suites with only a negligible cost in disk space and mirror bandwidth. From a database design perspective this is obviously much more sensible. As part of this project, the original Debian dinstall repository maintenance scripts were replaced by da-katie or dak , which among other things used a new apt-ftparchive program to build the index files; this replaced dpkg-scanpackages and dpkg-scansources, and included its own database cache which made a big difference to performance at the scale of a distribution. A few months after the initial implementation of package pools, Release files were added. These formed a sort of meta-index for each suite, telling APT which index files were available (main/binary-i386/Packages, non-free/source/Sources, and so on) and what their checksums were. Detached signatures were added alongside that (Release.gpg) so that it was now possible to fetch packages securely given a public key for the repository, and client-side verification support for this eventually made its way into Debian and Ubuntu. The repository structure stayed more or less like this for several years. At some point along the way, those of us by now involved in repository maintenance realised that an important property had been lost. I mentioned earlier that the original format allowed race-free updates, but this was no longer true with the introduction of the Release file. A client now had to fetch Release and then fetch whichever other index files such as Packages they wanted, typically in separate HTTP transactions. If a client was unlucky, these transactions would fall on either side of a mirror update and they d get a Hash Sum Mismatch error from APT. Worse, if a mirror was unlucky and also didn t go to special lengths to verify index integrity (most don t), its own updates could span an update of its upstream mirror and then all its clients would see mismatches until the next mirror update. This was compounded by using detached signatures, so Release and Release.gpg were fetched separately and could be out of sync. Fixing this has been a long road (the first time I remember talking about this was in late 2007!), and we ve had to take care to maintain client/server compatibility along the way. The first step was to add inline-signed versions of the Release file, called InRelease, so that there would no longer be a race between fetching Release and fetching its signature. APT has had this for a while, Debian s repository supports it as of stretch, and we finally implemented it for Ubuntu six months ago. Dealing with the other index files is more complicated, though; it isn t sensible to inline them, as clients usually only need to fetch a small fraction of all the indexes available for a given suite. The solution we ve ended up with, thanks to Michael Vogt s work implementing it in APT, is called by-hash and should be familiar in concept to people who ve used git: with the exception of the top-level InRelease file, index files for suites that support the by-hash mechanism may now be fetched using a URL based on one of their hashes listed in InRelease. This means that clients can now operate like this:

• Fetch dists/xenial/InRelease
• Fetch dists/xenial/main/binary-amd64/by-hash/SHA256/46316a202cdae76a73b555414741b11d08c66620b76c470a1623cedcc8a14740 (and so on)
• Fetch individual package files

This is now enabled by default in Ubuntu. It s only there as of xenial (16.04), since earlier versions of Ubuntu don t have the necessary support in APT. With this, hash mismatches on updates should be a thing of the past. There will still be some people who won t yet benefit from this. debmirror doesn t support by-hash yet; apt-cacher-ng only supports it as of xenial, although there s an easy configuration workaround. Full archive mirrors must make sure that they put new by-hash files in place before new InRelease files (I just fixed our recommended two-stage sync script to do this; ubumirror still needs some work; Debian s ftpsync is almost correct but needs a tweak for its handling of translation files, which I ve sent to its maintainers). Other mirrors and proxies that have specific handling of the repository format may need similar changes. Please let me know if you see strange things happening as a result of this change. It s useful to check the output of apt -o Debug::Acquire::http=true update to see exactly what requests are being issued.

I've just released version 1.2.0 of Nageru, my live video mixer. The main new feature is support for Blackmagic's PCI (and Thunderbolt) series of cards through their driver (in addition to the preexisting support for their USB3 cards, through my own free one), but the release is really much more than that. In particular, 1.2.0 has a lot of those small tweaks that takes it just to that point where it starts feeling like software I can use and trust myself. Of course, there are still tons of rough edges (and probably also bad bugs I didn't know about), but in a sense, it's the first real 1.x release. There's not one single thing I can point to it's more the sum. To that end, I will be using it at Solskogen this summer to run what's most likely the world's first variable-framerate demoparty stream, with the stream nominally in 720p60 but dropping to 720p50 during the oldschool compos to avoid icky conversions on the way, given that almost all oldschool machines are PAL. (Of course, your player needs to handle it properly to get perfect 50 Hz playback, too :-) Most likely through G-SYNC or similar, unless you actually have a CRT you can set to 50 Hz.) For more details about exactly what's new, see the NEWS file, or simply the git commit log.