What happened in the Reproducible Builds effort between Sunday October 30 and Saturday November 5 2016: Upcoming events

• Chris Lamb and Holger Levsen will be presenting at MiniDebConfCambridge 2016 in Cambridge, United Kingdom on November 10th-13th.
• Vagrant Cascadian will be presenting Introduction to Reproducible Builds at the SeaGL.org Conference in Seattle, USA on November 12th.
• The next IRC meeting will be held on November 15th.
• Reproducible Debian Hackathon - A small hackathon organized in Boston, USA on December 3rd and 4th. If you are interested in attending, please contact Valerie Young (spectranaut in the #debian-reproducible IRC channel on irc.oftc.net.)
• The second Reproducible Builds World Summit will be held in Berlin, Germany on December 13th-15th.

Reproducible work in other projects

• Patches to GCC to generate reproducible output independently of the build-path were submitted by Ximin Luo.
• The new Firefox Security Roadmap includes Reproducible Builds (via a tweet by Debian Developer Sylvestre).

Bugs filed

• #842708 filed against haskell-devscripts by Chris Lamb.
• #842864 filed against aewan by Reiner Herrmann.
• #842865 filed against atanks by Reiner Herrmann.
• #842867 filed against i3status by Reiner Herrmann.
• #842868 filed against gip by Reiner Herrmann.
• #842875 filed against lastpass-cli by Reiner Herrmann.
• #842986 filed against zathura-pdf-poppler by Reiner Herrmann.
• #842988 filed against masscan by Reiner Herrmann.
• #842991 filed against python-axolotl-curve25519 by Reiner Herrmann.
• #842992 filed against pyephem by Reiner Herrmann.
• #843097 filed against spacenavd by Reiner Herrmann.
• #843100 filed against python-clips by Reiner Herrmann.
• #843101 filed against python-hiredis by Reiner Herrmann.
• #843109 filed against zathura-ps by Reiner Herrmann.
• #843110 filed against greenbone-security-assistant by Reiner Herrmann.
• #843234 filed against vdr-plugin-sudoku by Reiner Herrmann.
• #843235 filed against vdr-plugin-spider by Reiner Herrmann.
• #843245 filed against distorm3 by Reiner Herrmann.

Reviews of unreproducible packages 81 package reviews have been added, 14 have been updated and 43 have been removed in this week, adding to our knowledge about identified issues. 3 issue types have been updated:

• sphinx_htmlhelp_readdir_sensitive
• random_order_in_dh_haskell_substvars
• sphinx_htmlhelp_readdir_sensitive

1 issue type has been removed:

• unsorted_pdl_output

1 issue type has been updated:

• document some reseach on docbook-to-man

Weekly QA work During of reproducibility testing, some FTBFS bugs have been detected and reported by:

• Chris Lamb (17)

diffoscope development

• diffoscope 62 was uploaded to unstable by Mattia Rizzolo:
  • Add rudimentary support for OpenDocumentFormat files. (Michel Messerschmidt)
  • Detect JSON order-only differences and print them nicely. (Mattia Rizzolo)

buildinfo.debian.net development

• Chris Lamb continued work on our proof-of-concept .buildinfo file server:
  • Show key ID over node name now
  • Show submission timestamp.
  • Accept .udebs
  • Actually show latest submissions on homepage.
  • GPG signatures are now mandatory

tests.reproducible-builds.org Reproducible Debian:

• With thanks to Profitbricks continued sponsorship, Holger setup two new amd64 build nodes (and the associated Jenkins jobs) with 15/16 cores and 48GB RAM each for a total of four such amd64 nodes to double the build capacity of our amd64 build network.

Misc. Also with thanks to Profitbricks sponsoring the "hardware" resources, Holger created a 13 core machine with 24GB RAM and 100GB SSD based storage so that Ximin can do further tests and development on GCC and other software on a fast machine. This week's edition was written by Chris Lamb, Ximin Luo, Vagrant Cascadian, Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

I was going to put a technical post but saw the discussion of one of the meetings of the debconf meets and decided to share a novice s travel experience. Before I start here s the discussion log http://meetbot.debian.net/debconf-team/2016/debconf-team.2016-10-20-20.01.log.html and specifically this part which hit me (using fake names for discussion as haven t taken permission from the folks to cite them by name.)

20:36:52 abcd: $100 CAD is a lot for some, but you d only need it if you won t sleep in sponsored accom, which arguably is acceptable.
20:37:04 it would, efgh, fixed sponsorship sum for everybody and allocation of rooms completely decoupled. Hotel gets the money from everybody and the base fee from DebConf.
20:37:15 people who can t afford also have special needs and may be uncomfortable in sharing rooms. That s quite frequently in our community. Managing each case will be much more complicated.
20:37:31 hijk: we could set aside budget for such special needs, for sure.
20:37:43 I m talking about managing each case
20:37:46 hijk: yes, but we ll have the special cases no matter what.
20:37:48 yes, and the special cases need to be catered for regardless of how everybody else is housed
20:38:06 hijk: room allocation already includes this.
20:38:19 people having to expose their personal problems to have us permitting them staying in the hotel
20:38:23 that s just too weird

It just goes on. I dunno whether I m weird or not or the experience I would share is just normal, this I would leave for you to decide. As have shared before, some friends of mine from the free software community had cajoled me last year to apply for debconf bursary (debconf15), which surprisingly got approved, but as it was late and my pre-conceived myths/notions of visas taking a looooong time decided not to go further. Many things take a long time to happen in the Indian bureaucratic maze. For instance have been in a civil case for almost a decade now among other things so know and accept that things take their own sweet time otherwise known as Indian patience Did the application and again, surprise, surprise this time too I was approved. Luckily, had done the application for bursary early so was a bit positive on the visa-front. There was a goof-up at the embassay but thanks to people at travel.stackexchange.com where I asked quite a few questions, I was a bit informed and travel was relatively hassle-free. Internally though, I was nervous as hell. I had been feeling like a conman or a fraud or being an imposter because I knew before-hand that the project is so huge and had done the mistake of putting up a talk and a workshop where the big guns would be, which again was accepted (not good). The only thing I was thinking of as a saving grace is that there might be some newbies who don t know about the project at all (on Open Day) and hopefully I could help with that but as you will see, even there I was fully inadequate. I live in Pune which is around 3.5 hours from Mumbai (BOM) from where international flights take off. While Pune has an Airport, due to defence considerations, there cannot be much improvement either for domestic or International carriers. There have been attempts to have an exclusive civilian Airport for a long time (almost a decade) and would still take a decade or more. Hence had decided to take an early morning train from Pune to Mumbai, change couple of locals and finally land up at the Mumbai International Airport. Hind-sight as they say is 50:50, while I do have friends in Mumbai, I also found about a homestay which is closer to the Airport and still relatively budget-friendly. Anyways, met few friends but as was paranoid about missing connections found myself in front of the Airport at 20:00 hrs. with about 7 hours + to go before my flight. While there is nothing to do around the airport rather than hanging around, just hung around outside the airport as knew that inside the airport will be chilling and once you go in, you cannot come out or at least it s an inconvenience to the security therein. The International Airport in on three levels, the basement is for vehicles, the first level to receive International and Domestic passengers and the upper-most level exclusively for people flying internationally. This again, came to know when I tried to enter into the ones meant for Domestic and International Passengers coming into the city. Came to the check-in counter at around 02:00 hrs, did the security thing and just had to wait as the flight was of 0400 hrs (from my limited search experience, the cheapest flights are at such times when nobody else (i.e.civilized people) wants to fly). Entered Doha around 5:15 Doha time and saw a much much bigger airport than either the Mumbai International Airport or/and the Delhi International Airport . While I have written some negative stuff about Doha, there were two positives that I am sure, I had forgotten to share a. There were no transit Visa Fees that I had to pay. Most countries and airports I researched have something called transit visa and that can really get expensive, so saved money on that. b. The free ride into the city and back with voluntary tipping the driver or/and guide (approx. 3-4 hours) While the second from what I could tell/know is a gimmick, this is something I wish other countries and airports emulate. There are hotels in the airport and I could have had hotel accommodation if I had booked a slightly more expensive ticket, roughly INR 5k/- each way which would have given me a bit more legroom as well as stay as my layover was more than 24 hours. But this information was known at last minute. Qatar Airways has just a toll-free number and trying more than a few times gave up. They don t have an office in the city. When I reached the check-in counter they said if I had upgraded to Y class I would have had the hotel thing. Changing tickets at the last moment was too expensive and anyways for hotel accommodation for layovers they required at least 24 hours notice. Had to make do with recliners and chairs which are not really comfortable. There were only a couple of waiting rooms on air-side which had a view of the aircraft and hence were a bit more pleasing than those which were on the land-side and were fully blocked without a view. I wish there was a map of the Airport from within the Airport as even with the single terminal it is really easy to get lost. Somehow the day and night went by and took my second flight and reached Cape Town, South Africa. Throughout the journey had been stressed as had to be awake at all times and make sure that nothing gets stolen. Having attendants at toilets were also good so that there is no possibility of any violence there. So it had been 2 days, no shower and no sleep. Later also came to know about Airport Sleeping Pods and shower stalls but these also seem to be less in number, at few airports and there always be a bit of premium attached to them as airports are a monopoly business. Anyways, reached the venue. Throughout the travel there was quite a bit of unnamed fear which I later came to know after seeing Dr. Ramanujan s The Man who knew Infinity . It was/is the fear or unknown, while in the movie it is articulated as fear of crossing seven seas, symbolically it is the fear or unknown. Now while I was dead tired, I still pushed myself as I didn t want to have the effects of jet lag interfere with the normal sleeping and waking patterns. I did freshen myself but didn t allow myself the luxury of the bath-tub as I knew that if I went in, I would not come out that day. Met all the people, learnt who s who, where things are happening etc. and slowly night came. Night came and I was so-looking forward to sleep but sleep was not to be. I later learnt it could be either of the two reasons, it could either have been travel-induced insomnia or/and what is known as the first night effect . It was only on the second day when I was in bath-tub for about 2/3 hours I could feel the tension leaving my body. I finally realized that I am in Cape Town, South Africa and could enjoy and be surprised at seeing birds within few feet of me . Now I don t know whether I m the only weird/paranoid one, I do know that it would not have been easier for me at least for the first night as I was turning and twisting throughout the night. I opened the lights, read for some time hoping for sleep to take over but that didn t work. Tried quite a few things but sleep didn t come. If I had been sleeping with other people I dunno how they would have reacted. I myself am a light sleeper (most of the time) and if I had sleep coming and somebody else acted or been the way I was, I wouldn t been able to sleep. However much you try, whatever is the natural reaction is, will be. There are still some bits to share but that would be in part 2.
Filed under: Miscellenous Tagged: #air-travel, #Debconf16, #paranoia, #sleep

Review: Digger, by Ursula Vernon

Publisher:	Sofawolf
Copyright:	October 2013
ISBN:	1-936689-32-4
Format:	Graphic novel
Pages:	837

As Digger opens, the eponymous wombat is digging a tunnel. She's not sure why, or where to, since she hit a bad patch of dirt. It happens sometimes, underground: pockets of cave gas and dead air that leave one confused and hallucinating. But this one was particularly bad, it's been days, she broke into a huge cave system, and she's thoroughly lost. Tripping on an ammonite while running from voices in the dark finally helps her come mostly to her senses and start tunneling up, only to break out at the feet of an enormous statue of Ganesh. A talking statue of Ganesh. Digger is a web comic that ran from 2005 to 2011. The archives are still on the web, so you can read the entire saga for free. Reviewed here is the complete omnibus edition, which collects the entire strip (previously published in six separate graphic novels containing two chapters each), a short story, a bonus story that was published in volume one, a bunch of random illustrated bits about the world background, author's notes from the web version, and all of the full-color covers of the series chapters (the rest of the work is in black and white). Publication of the omnibus was originally funded by a Kickstarter, but it's still available for regular sale. (I bought it normally via Amazon long after the Kickstarter finished.) It's a beautiful and durable printing, and I recommend it if you have the money to buy things you can read for free. This was a very long-running web comic, but Digger is a single story. It has digressions, of course, but it's a single coherent work with a beginning, middle, and end. That's one of the impressive things about it. Another is that it's a fantasy work involving gods, magic, oracles, and prophecies, but it's not about a chosen one, and it's not a coming of age story. Digger (Digger-of-Needlessly-Convoluted-Tunnels, actually, but Digger will do) is an utterly pragmatic wombat who considers magic to be in poor taste (as do all right-thinking wombats), gods to be irritating underground obstacles that require care and extra bracing, and prophecies to not be worth the time spent listening to them. It's a bit like the famous Middle Earth contrast between the concerns of the hobbits and the affairs of the broader world, if the hobbits were well aware of the broader world, able to deal with it, but just thought all the magic was tacky and irritating. Magic and gods do not, of course, go away just because one is irritated by them, and Digger eventually has to deal with quite a lot of magic and mythology while trying to figure out where home is and how to get back to it. However, she is drawn into the plot less by any grand danger to the world and more because she keeps managing to make friends with everyone, even people who hate each other. It's not really an explicit goal, but Digger is kind-hearted, sensible, tries hard to do the right thing, and doesn't believe in walking away from problems. In this world, that's a recipe for eventual alliances from everything from warrior hyenas to former pirate shrews, not to mention a warrior cult, a pair of trolls, and a very confused shadow... something. All for a wombat who would rather be digging out a good root cellar. (She does, at least, get a chance to dig out a good root cellar.) The characters are the best part, but I love everything about this story. Vernon's black and white artwork isn't as detailed as, say, Dave Sim at his best, and some of the panels (particularly mostly dark ones) seemed a bit scribbly. But it's mostly large-panel artwork with plenty of room for small touches and Easter eggs (watch for the snail, and the cave fish graffiti that I missed until it was pointed out by the author's notes), and it does the job of telling the story. Honestly, I like the black and white panels better than the color chapter covers reproduced in the back. And the plot is solid and meaty, with a satisfying ending and some fantastic detours (particularly the ghosts). I think my favorite bits, though, are the dialogue.

"Do you have any idea how long twelve thousand years is?"
"I know it's not long enough to make a good rock."

Digger is snarky in all the right ways, and sees the world in terms of tunnels, digging, and geology. Vernon is endlessly creative in how she uses that to create comebacks, sayings, analysis, and an entire culture. This is one of the best long-form comics I've read: a solid fantasy story with great characters, reliably good artwork, a coherent plot arc, wonderful dialogue, a hard-working and pragmatic protagonist (who happens to be female), and a wonderfully practical sense of morality and ethics. I'm sorry it's over. If you've not already read it, I highly recommend it. Remember tunnel 17! Rating: 9 out of 10

Yesterday, I just uploaded apt-file 3.1.2 into unstable, which comes with a few things I would like to highlight.

• We fixed an issue where apt-file would not show top-level files in source packages. (bug#676642). Thanks to Paul Wise for the proposed solution.
• Paul Wise also fixed a bug where apt-file list -I dsc <source-pkg> would fail to list all files in the source package if said file was also in other packages.
• We added filter-suites / filter-origins options that can be used to narrow the search space. Example: apt-file search --filter-suites unstable lintian/checks/

You can also set defaults in the config file if you want to always search in unstable, simply do:

# echo 'apt-file::Search-Filter::Suite "unstable";' >> /etc/apt/apt-file.conf

For the suite filter, either a code name ( sid ) or a suite name ( unstable ) will work. Please note that the filters are case-sensitive suites/code names generally use all lowercase, whereas origins appear to use title-case (i.e. unstable vs. Debian ).
Filed under: apt-file, Debian

For a long time the Thinkpad has been widely regarded as the Rolls-Royce of laptops . Since 2003 one could argue that Rolls-Royce is no longer the Rolls-Royce of cars [1]. The way that IBM sold the Think business unit to Lenovo and the way that Lenovo is producing both Thinkpads and cheaper Ideapads is somewhat similar to the way the Rolls-Royce trademark and car company were separately sold to companies that are known for making cheaper cars. Sam Varghese has written about his experience with Thinkpads and how he thinks it s no longer the Rolls-Royce of laptops [2]. Sam makes some reasonable points to support this claim (one of which only applies to touchpad users not people like me who prefer the Trackpoint), but I think that the real issue is whether it s desirable to have a laptop that could be compared to a Rolls-Royce nowadays. Support The Rolls-Royce car company is known for great reliability and support as well as features that other cars lack (mostly luxury features). The Thinkpad marque (both before and after it was sold to Lenovo) was also known for great support. You could take a Thinkpad to any service center anywhere in the world and if the serial number indicated that it was within the warranty period it would be repaired without any need for paperwork. The Thinkpad service centers never had any issue with repairing a Thinkpad that lacked a hard drive just as long as the problem could be demonstrated. It was also possible to purchase an extended support contract at any time which covered all repairs including motherboard replacement. I know that not everyone had as good an experience as I had with Thinkpad support, but I ve been using them since 1998 without problems which is more than I can say for most hardware. Do we really need great reliability from laptops nowadays? When I first got a laptop hardly anyone I knew owned one. Nowadays laptops are common. Having a copy of important documents on a USB stick is often a good substitute for a reliable laptop, when you are in an environment where most people own laptops it s usually not difficult to find someone who will let you use theirs for a while. I think that there is a place for a laptop with RAID-1 and ECC RAM, it s a little known fact that Thinkpads have a long history of supporting the replacement of a CD/DVD drive with a second hard drive (I don t know if this is still supported) but AFAIK they have never supported ECC RAM. My first Thinkpad cost $3,800. In modern money that would be something like $7,000 or more. For that price you really want something that s well supported to protect the valuable asset. Sam complains about his new Thinkpad costing more than $1000 and needing to be replaced after 2.5 years. Mobile phones start at about $600 for the more desirable models (IE anything that runs Pokemon Go) and the new Google Pixel phones range from $1079 to $1,419. Phones aren t really expected to be used for more than 2.5 years. Phones are usually impractical to service in any way so for most of the people who read my blog (who tend to buy the more expensive hardware) they are pretty much a disposable item costing $600+. I previously wrote about a failed Nexus 5 and the financial calculations for self-insuring an expensive phone [3]. I think there s no way that a company can provide extended support/warranty while making a profit and offering a deal that s good value to customers who can afford to self-insure. The same applies for the $499 Lenovo Ideapad 310 and other cheaper Lenovo products. Thinkpads (the higher end of the Lenovo laptop range) are slightly more expensive than the most expensive phones but they also offer more potential for the user to service them. Features My first Thinkpad was quite underpowered when compared to desktop PCs, it had 32M of RAM and could only be expanded to 96M at a time when desktop PCs could be expanded to 128M easily and 256M with some expense. It had a 800*600 display when my desktop display was 1280*1024 (37% of the pixels). Nowadays laptops usually start at about 8G of RAM (with a small minority that have 4G) and laptop displays start at about 1366*768 resolution (51% of the pixels in a FullHD display). That compares well to desktop systems and also is capable of running most things well. My current Thinkpad is a T420 with 8G of RAM and a 1600*900 display (69% of FullHD), it would be nice to have higher resolution but this works well and it was going cheap when I needed a new laptop. Modern Thinkpads don t have some of the significant features that older ones had. The legendary Butterfly Keyboard is long gone, killed by the wide displays that economies of scale and 16:9 movies have forced upon us. It s been a long time since Thinkpads had some of the highest resolution displays and since anyone really cared about it (you only need pixels to be small enough that you can t see them). For me one of the noteworthy features of the Thinkpads has been the great keyboard. Mechanical keys that feel like a desktop keyboard. It seems that most Thinkpads are getting the rubbery keyboard design made popular by Apple. I guess this is due to engineering factors in designing thin laptops and the fact that most users don t care. Matthew Garrett has blogged about the issue of Thinkpad storage configured as RAID mode without any option to disable it [4]. This is an annoyance (which incidentally has been worked around) and there are probably other annoyances like it. Designing hardware and an OS are both complex tasks. The interaction between Windows and the hardware is difficult to get right from both sides and the people who design the hardware often don t think much about Linux support. It has always been this way, the early Thinkpads had no Linux support for special IBM features (like fan control) and support for ISA-PnP was patchy. It is disappointing that Lenovo doesn t put a little extra effort into making sure that Linux works well on their hardware and this might be a reason for considering another brand. Service Life I bought my curent Thinkpad T420 in October 2013 [5] It s more than 3 years old and has no problems even though I bought it refurbished with a reduced warranty. This is probably the longest I ve had a Thinkpad working well, which seems to be a data point against the case that modern Thinkpads aren t as good. I bought a T61 in February 2010 [6], it started working again (after mysteriously not working for a month in late 2013) and apart from the battery lasting 5 minutes and a CPU cooling problem it still works well. If that Thinkpad had cost $3,800 then I would have got it repaired, but as it cost $796 (plus the cost of a RAM upgrade) and a better one was available for $300 it wasn t worth repairing. In the period 1998 to 2010 I bought a 385XD, a 600E, a T21, a T43, and a T61 [6]. During that time I upgraded laptops 4 times in 12 years (I don t have good records of when I bought each one). So my average Thinkpad has lasted 3 years. The first 2 were replaced to get better performance, the 3rd was replaced when an employer assigned me a Thinkpad (and sold it to be when I left), and 4 and 5 were replaced due to hardware problems that could not be fixed economically given the low cost of replacement. Conclusion Thinkpads possibly don t have the benefits over other brands that they used to have. But in terms of providing value for the users it seems that they are much better than they used to be. Until I wrote this post I didn t realise that I ve broken a personal record for owning a laptop. It just keeps working and I hadn t even bothered looking into the issue. For some devices I track how long I ve owned them while thinking can I justify replacing it yet , but the T420 just does everything I want. The battery still lasts 2+ hours which is a new record too, with every other Thinkpad I ve owned the battery life has dropped to well under an hour within a year of purchase. If I replaced this Thinkpad T420 now it will have cost me less than $100 per year (or $140 per year including the new SSD I installed this year), that s about 3 times better than any previous laptop! I wouldn t feel bad about replacing it as I ve definitely got great value for money from it. But I won t replace it as it s doing everything I want. I ve just realised that by every measure (price, reliability, and ability to run all software I want to run) I ve got the best Thinkpad I ve ever had. Maybe it s not like a Rolls-Royce, but I d much rather drive a 2016 Tesla than a 1980 Rolls-Royce anyway.

• [1] https://en.wikipedia.org/wiki/Rolls-Royce_Motor_Cars
• [2] http://www.itwire.com/open-sauce/75569-thinkpad-no-longer-the-rolls-royce-of-laptops.html
• [3] https://etbe.coker.com.au/2016/10/22/another-broken-nexus-5/
• [4] http://mjg59.dreamwidth.org/44694.html
• [5] https://etbe.coker.com.au/2013/10/23/thinkpad-t420/
• [6] https://etbe.coker.com.au/2010/03/16/thinkpad-t61/
• [7] https://etbe.coker.com.au/2011/09/08/laptop-to-cloud-lifestyle/

Review: The Just City, by Jo Walton

Series:	Thessaly #1
Publisher:	Tor
Copyright:	2014
Printing:	January 2015
ISBN:	0-7653-3266-3
Format:	Hardcover
Pages:	368

The premise for The Just City is easy to state: The time-traveling goddess Athene (Athena) decides to organize and aid an attempt to create the society described in Plato's Republic. She chooses Thera (modern Santorini) before the eruption, as a safe place where this experiment wouldn't alter history. The elders of the city are seeded by people throughout history who at some point prayed to Athene, wanting to live in the Republic. The children of the age of ten that Plato suggested starting with are purchased as slaves from various points in history and transported by Athene to the island. Apollo, shaken and confused by Daphne wanting to turn into a tree rather than sleep with him, finds out about this experiment as Athene tries to explain the concept of consent to him. He decides that becoming human for a while might help him learn about volition and equal significance, and that this is the perfect location. He's one of the three viewpoint characters. The others are two women: one (Maia) from Victorian times who prayed to Athene in a moment of longing for the tentative sexual equality of the Republic and was recruited as one of the elders, and another (Simmea) who is bought as a slave and becomes one of the children. I should admit up-front that I've never read Plato's Republic, or indeed much of Plato at all, just small bits for classes. The elders (and of course the gods) all have, and are attempting to stick quite closely to Plato's outline of the ideal city. The children haven't, though, so the book is quite readable for people like me who only remember a few vague aspects of Plato's vision from school. The reader learns the principles alongside Simmea. One of Walton's strengths is taking a science fiction concept, putting real people into it, and letting the quotidian mingle with the fantastic. Simmea is my favorite character here: her journey to the city is deeply traumatic, but the opportunity she gets there is incredible and unforeseen, and she comes to love the city while still understanding, and arguing about, its possible flaws. Maia is nearly as successful; Walton does a good job with committee debates and discussions, avoids coming down too heavily on the drama, and shows a believable picture of people with very different backgrounds and beliefs coming together to flesh out the outlines of something they all agree with, or at least want to try. I found Apollo less engaging as a character, partly because I never quite understood his motives or his weird failure to understand the principles of consent. Walton doesn't portray him as either hopelessly arrogant or hopelessly narcissistic, which would have been easy outs, but in avoiding those two obvious explanations for his failures of empathy, I felt like she left him with an odd and unexplained hole in his personality. He's a weirdly passive half-character for much of the book, although he does develop a bit more towards the end (which was probably the point). Half the fun of this book is working out what the Republic would be like in practice, and what breakdowns and compromises would happen as soon as you put real people in it. Athene obviously has to do a bit of cheating to make a utopia invented as an intellectual exercise work out in practice, plus a bit more for comfort (electricity and indoor plumbing, for instance). The most substantial cheat is robots to replace slaves and do quite a bit that slaves couldn't. Birth control (something Plato obviously never would have thought of) is another notable cheat; it's postulated to be an ancient method since lost, but even if that existed, there's no way it would be this reliable. But otherwise, the society mostly works, and Walton shows enough of the arguing and mechanics to make that believable, while still avoiding infodumps and boring descriptions. It's neatly done, although I'm still a bit dubious that the elders from later eras would have put up with the primitive conditions with this little complaint. The novel needs a plot, of course, and that's the other half of the fun. I can't talk about this in any detail without spoiling the book, since the plot only kicks in about halfway through once the setup and character introductions are complete. That makes it hard to explain why I found this a bit less successful, although parts of it are brilliant. What worked for me is the growth of Simmea and her friends as students and philosophers, the arguments and discussions (and their growing enthusiasm for argument and discussion), and the way Greek mythology is woven subtly and undramatically into the story. It really does feel like sitting in on ancient Greek philosophical arguments and experiments, and by that measure Walton has succeeded admirably in her goal. What didn't work for me was the driving conflict of the story, once it's introduced. I can't describe it without spoilers, but it's an old trope in science fiction and one with little scientific basis. It may seem weird to argue that point in a book with time-traveling Greek gods, a literal Lethe, and a Greek idea of souls, but those are mythological background material. The SF trope is something about which I have personal expertise and which simply doesn't work that way, and I had a harder time getting past that than alternate metaphysical properties. It threw me out of the book a bit. I see why Walton chose the conflict she did, but I felt like she could have gotten to the same place in the plot, admittedly with more difficulty, by using some of the more dubious aspects of Plato's long-term plan plus some other obstacles that were already built into the world. This more direct approach added a bit of SF-style analysis of the unknown that seemed weirdly at odds with the rest of the story (even if the delight of one of the characters is endearing). That complaint aside, I really enjoyed reading this book. Apollo didn't entirely work for me, but all of the other characters are excellent, and Walton keeps the story moving at a comfortable clip. Given the amount of description required, particularly for an audience that may not have read the Republic, a lesser writer could have easily slipped into the infodump trap. Walton never does. Fair warning, though: The Just City does end on a cliffhanger, and is in no way a standalone novel. You will probably want to have the sequel on hand. Followed by The Philosopher Kings. Rating: 7 out of 10

This year, Outreachy featured internships from organizations such as Debian, Fedora, GNOME, the Linux Kernel, Mozilla, Python, and Wikimedia, just to name a few. Each organization features mentored projects and in order to apply, applicants must contact the mentor, introduce themselves on the appropriate channels and make a small contribution to the project. After that, applicants might be required to fulfill additional tasks to demonstrate their abilities. Successful applicants will make quality contributions, communicate effectively with mentors, ask questions, fulfill tasks, help out their peers via mailing lists, and/or blog about their experience. One of the projects I applied to was the Clean Room for PGP and X.509 (PKI) Key Management. The project aims to create a Live Disc that enables users to create and manage their PGP keys easily and securely, using a text-based UI. I ve been a Debian user for about a year, but before applying to the project I didn t know much about GnuPG or public key encryption. Since then, I ve made some contributions and attended my first keysigning event in San Francisco featuring a lecture by Neal Walfield (more on that below). For my initial contribution, Daniel Pocock, the mentor for this project, asked that I write a script that lists the USB flash devices connected to the system and specifies which device the system booted from. Here s the bash script that I wrote, and that was enough to submit an application for Debian. My next task was to write a dns hook script for the dehydrated project, a shell client for signing certificates with Let s Encrypt (for free!). The script completes a dns challenge sent by the ACME-server by provisioning a TXT record for a given domain in order to prove ownership of the domain. I chose to write it in python and used the dnspython API. I posted my solution on github and there are many more here. At the lecture, Neal talked about good practices for key creation and management. Here are a few of those points:

• Don t store your master key locally
• Store your master key offline on a smartcard such as GnuK or NitroKey and store backups on a USB stick.
• Neal mentioned that the OpenPGP card is not open hardware and according to this recent post neither is the Yubikey
• To manage the key, use a dedicated offline computer such as a relatively cheap x40 or x60 Thinkpad (my two cents: use a Thinkpad like X200 or T400 flashed with Libreboot, which solves the proprietary firmware problem) and remove the wireless network card.
• Use Tails which wipes memory on shutdown.
• Use subkeys an encryption subkey is automatically created with gpg2 --gen-key. Create an additional signing subkey.
• Generate a secure passphrase for your master key using 5-12 words. Example: pipe after harm horse split seize radar bulb
  • Funny cartoon illustrating this concept
• Refresh your keys regularly for new preferences and revokation certificates. An alternative to gpg2 --refresh-keys is parcimonie, which uses tor and refreshes keys one at a time.
• Don t back up .gnupg/random_seed
• More OpenPGP Best Practices

See the slides for Neal s full presentation.

This year, Outreachy featured internships from organizations such as Debian, Fedora, GNOME, the Linux Kernel, Mozilla, Python, and Wikimedia, just to name a few. Each organization features mentored projects and in order to apply, applicants must contact the mentor, introduce themselves on the appropriate channels and make a small contribution to the project. After that, applicants might be required to fulfill additional tasks to demonstrate their abilities. Successful applicants will make quality contributions, communicate effectively with mentors, ask questions, fulfill tasks, help out their peers via mailing lists, and/or blog about their experience. One of the projects I applied to was the Clean Room for PGP and X.509 (PKI) Key Management. The project aims to create a Live Disc that enables users to create and manage their PGP keys easily and securely, using a text-based UI. I ve been a Debian user for about a year, but before applying to the project I didn t know much about GnuPG or public key encryption. Since then, I ve made some contributions and attended my first keysigning event in San Francisco featuring a lecture by Neal Walfield (more on that below). For my initial contribution, Daniel Pocock, the mentor for this project, asked that I write a script that lists the USB flash devices connected to the system and specifies which device the system booted from. Here s the bash script that I wrote, and that was enough to submit an application for Debian. My next task was to write a dns hook script for the dehydrated project, a shell client for signing certificates with Let s Encrypt (for free!). The script completes a dns challenge sent by the ACME-server by provisioning a TXT record for a given domain in order to prove ownership of the domain. I chose to write it in python and used the dnspython API. I posted my solution on github and there are many more here. At the lecture, Neal talked about good practices for key creation and management. Here are a few of those points:

• Don t store your master key locally
• Store your master key offline on a smartcard such as GnuK or NitroKey and store backups on a USB stick.
• Neal mentioned that the OpenPGP card is not open hardware and according to this recent post neither is the Yubikey
• To manage the key, use a dedicated offline computer such as a relatively cheap x40 or x60 Thinkpad (my two cents: use a Thinkpad like X200 or T400 flashed with Libreboot, which solves the proprietary firmware problem) and remove the wireless network card.
• Use Tails which wipes memory on shutdown.
• Use subkeys an encryption subkey is automatically created with gpg2 --gen-key. Create an additional signing subkey.
• Generate a secure passphrase for your master key using 5-12 words. Example: pipe after harm horse split seize radar bulb
  • Funny cartoon illustrating this concept
• Refresh your keys regularly for new preferences and revokation certificates. An alternative to gpg2 --refresh-keys is parcimonie, which uses tor and refreshes keys one at a time.
• Don t back up .gnupg/random_seed
• More OpenPGP Best Practices

See the slides for Neal s full presentation.

I have used non-standard RSA key size for maybe 15 years. For example, my old OpenPGP key created in 2002. With non-standard key sizes, I mean a RSA key size that is not 2048 or 4096. I do this when I generate OpenPGP/SSH keys (using GnuPG with a smartcard like this) and PKIX certificates (using GnuTLS or OpenSSL, e.g. for XMPP or for HTTPS). People sometimes ask me why. I haven t seen anyone talk about this, or provide a writeup, that is consistent with my views. So I wanted to write about my motivation, so that it is easy for me to refer to, and hopefully to inspire others to think similarily. Or to provoke discussion and disagreement that s fine, and hopefully I will learn something. Before proceeding, here is some context: When building new things, it is usually better to use the Elliptic Curve technology algorithm Ed25519 instead of RSA. There is also ECDSA which has had a comparatively slow uptake, for a number of reasons that is widely available and is a reasonable choice when Ed25519 is not available. There are also post-quantum algorithms, but they are newer and adopting them today requires a careful cost-benefit analysis. First some background. RSA is an asymmetric public-key scheme, and relies on generating private keys which are the product of distinct prime numbers (typically two). The size of the resulting product, called the modulus n, is usually expressed in bit length and forms the key size. Historically RSA key sizes used to be a couple of hundred bits, then 512 bits settled as a commonly used size. With better understanding of RSA security levels, the common key size evolved into 768, 1024, and later 2048. Today s recommendations (see keylength.com) suggest that 2048 is on the weak side for long-term keys (5+ years), so there has been a trend to jump to 4096. The performance of RSA private-key operations starts to suffer at 4096, and the bandwidth requirements is causing issues in some protocols. Today 2048 and 4096 are the most common choices. My preference for non-2048/4096 RSA key sizes is based on the simple and na ve observation that if I would build a RSA key cracker, there is some likelihood that I would need to optimize the implementation for a particular key size in order to get good performance. Since 2048 and 4096 are dominant today, and 1024 were dominent some years ago, it may be feasible to build optimized versions for these three key sizes. My observation is a conservative decision based on speculation, and speculation on several levels. First I assume that there is an attack on RSA that we don t know about. Then I assume that this attack is not as efficient for some key sizes than others, either on a theoretical level, at implementation level (optimized libraries for certain characteristics), or at an economic/human level (decision to focus on common key sizes). Then I assume that by avoiding the efficient key sizes I can increase the difficulty to a sufficient level. Before analyzing whether those assumptions even remotely may make sense, it is useful to understand what is lost by selecting uncommon key sizes. This is to understand the cost of the trade-off. A significant burden would be if implementations didn t allow selecting unusual key sizes. In my experience, enough common applications support uncommon key sizes, for example GnuPG, OpenSSL, OpenSSH, FireFox, and Chrome. Some applications limit the permitted choices; this appears to be rare, but I have encountered it once. Some environments also restrict permitted choices, for example I have experienced that LetsEncrypt has introduced a requirement for RSA key sizes to be a multiples of 8. I noticed this since I chose a RSA key size of 3925 for my blog and received a certificate from LetsEncrypt in December 2015 however during renewal in 2016 it lead to an error message about the RSA key size. Some commercial CAs that I have used before restrict the RSA key size to one of 1024, 2048 or 4096 only. Some smart-cards also restrict the key sizes, sadly the YubiKey has this limitation. So it is not always possible, but possible often enough for me to be worthwhile. Another cost is that RSA signature operations are slowed down. This is because the exponentiation function is faster than multiplication, and if the bit pattern of the RSA key is a 1 followed by several 0 s, it is quicker to compute. I have not done benchmarks, but I have not experienced that this is a practical problem for me. I don t notice RSA operations in the flurry of all of other operations (network, IO) that is usually involved in my daily life. Deploying this on a large scale may have effects, of course, so benchmarks would be interesting. Back to the speculation that leads me to this choice. The first assumption is that there is an attack on RSA that we don t know about. In my mind, until there are proofs that the currently known attacks (GNFS-based attacks) are the best that can be found, or at least some heuristic argument that we can t do better than the current attacks, the probability for an unknown RSA attack is therefor, as strange as it may sound, 100%. The second assumption is that the unknown attack(s) are not as efficient for some key sizes than others. That statement can also be expressed like this: the cost to mount the attack is higher for some key sizes compared to others. At the implementation level, it seems reasonable to assume that implementing a RSA cracker for arbitrary key sizes could be more difficult and costlier than focusing on particular key sizes. Focusing on some key sizes allows optimization and less complex code. At the mathematical level, the assumption that the attack would be costlier for certain types of RSA key sizes appears dubious. It depends on the kind of algorithm the unknown attack is. For something similar to GNFS attacks, I believe the same algorithm applies equally for a RSA key size of 2048, 2730 and 4096 and that the running time depends mostly on the key size. Other algorithms that could crack RSA, such as some approximation algorithms, does not seem likely to be thwarted by using non-standard RSA key sizes either. I am not a mathematician though. At the economical or human level, it seems reasonable to say that if you can crack 95% of all keys out there (sizes 1024, 2048, 4096) then that is good enough and cracking the last 5% is just diminishing returns of the investment. Here I am making up the 95% number. Currently, I would guess that more than 95% of all RSA key sizes on the Internet are 1024, 2048 or 4096 though. So this aspect holds as long as people behave as they have done. The final assumption is that by using non-standard key sizes I raise the bar sufficiently high to make an attack impossible. To be honest, this scenario appears unlikely. However it might increase the cost somewhat, by a factor or two or five. Which might make someone target a lower hanging fruit instead. Putting my argument together, I have 1) identified some downsides of using non-standard RSA Key sizes and discussed their costs and implications, and 2) mentioned some speculative upsides of using non-standard key sizes. I am not aware of any argument that the odds of my speculation is 0% likely to be true. It appears there is some remote chance, higher than 0%, that my speculation is true. Therefor, my personal conservative approach is to hedge against this unlikely, but still possible, attack scenario by paying the moderate cost to use non-standard RSA key sizes. Of course, the QA engineer in me also likes to break things by not doing what everyone else does, so I end this with an ObXKCD.

This month s update falls onto a national holiday in Japan. My recent start as a normal company employee in Japan doesn t leave me enough time during normal days to work on Debian, so things have to wait for holidays. There have been a few notable changes in the current packages, and above all I wanted to fix an RC bug and on the way fixed also several other (sometimes rather old) bugs.
From the list of new packages I want to pick apxproof: I have written something myself for one of my rather long papers (with proofs about 60pp), where at times I had to factor out the proofs into an appendix. I did this my own way, but I would have preferred to have a nice package! Another interesting change is the upstream merge of collection-mathextra (which translated to the Debian package texlive-math-extra) and collection-science (Debian: texlive-science) into a new collection collection-mathscience. Since introducing new packages and phasing out old ones is generally a pain in Debian, I decided to digress from the upstream naming convention and use texlive-science for the new collection-mathscience. In the end Mathematics is the most important science of all Finally also a word about removals: Several ConTeXt packages have been removed due to the fact that they are outdated. These removals will find their way in an update of the Debian ConTeXt package in near future. The TeX Live packages lost voss-mathmode, which was retracted by the author due to various reasons. He is working on an updated version that will hopeful reappear in both TeX Live and Debian in near future. Well, that s it for now. Here now the full list with links. Enjoy. New packages apxproof, bangorexam, biblatex-gb7714-2015, biblatex-lni, biblatex-sbl, context-cmscbf, context-cmttbf, context-inifile, context-layout, delimset, latex2nemeth, latexbangla, latex-papersize, ling-macros, notex-bst, platex-tools, testidx, uppunctlm, wtref, xcolor-material. Removed packages voss-mathmode. Updated packages apa6, autoaligne, babel-german, biblatex-abnt, biblatex-anonymous, biblatex-apa, biblatex-manuscripts-philology, biblatex-nature, biblatex-realauthor, bibtex, bidi, boondox, bxcjkjatype, chickenize, churchslavonic, cjk-gs-integrate, context-filter, cooking-units, ctex, denisbdoc, dvips, europasscv, fixme, glossaries, gzt, handout, imakeidx, ipaex-type1, jsclasses, jslectureplanner, kpathsea, l3build, l3experimental, l3kernel, l3packages, latexindent, latexmk, listofitems, luatexja, marginnote, mcf2graph, minted, multirow, nameauth, newpx, newtx, noto, nucleardata, optidef, overlays, pdflatexpicscale, pst-eucl, reledmac, repere, scanpages, semantic-markup, tableaux, tcolorbox, tetex, texlive-scripts, ticket, todonotes, tracklang, tudscr, turabian-formatting, updmap-map, uspace, visualtikz, xassoccnt, xecjk, yathesis.

Since some time everybody (read developer) want to run his new microservice stacks in containers. I can understand that building and testing an application is important for developers.
One of the benefits of containers is, that developer (in theory) can put their new version of applications into production on their own. This is the point where operations is affected and operations needs to evaluate, if that might evolve into better workflow. For yolo^WdevOps people there are some challenges that needs to be solved, or at least mitigated, when things needs to be done in large(r) scale.

• Which Orchestration Engine should be considered?
• How to provide persistent (shared) storage?
• How to update the base image(s) the apps are build upon and to test/deploy them?

Orchestration Engine Running Docker, which is actual the most preferred container solution, on a single host with docker command line client is something you can do, but there you leave the gap between dev and ops.

UI For Docker Since some time there is UI For Docker available for visualizing and managing containers on a single docker node. It's pretty awesome and the best feature so far is the Container Network view, which also shows the linked container.

Portainer Portainer is pretty new and it can be deployed as easy as UI For Docker. But the (first) great advantage: it can handle Docker Swarm. Beside that it has many other great features.

Rancher Rancher describes themselves as 'container management platform' that 'supports and manages all of your Kubernetes, Mesos, and Swarm clusters'. This is great because this are all of the relevant docker cluster orchestrations at the market actually. For the use cases, we are facing, Kubernetes and Mesos seems both like bloated beasts. Usman Ismail has written a really good comparison of Orchestration Engine options which goes into details.

Docker Swarm As there is actually no clear defacto standard/winner of the (container) orchestration wars, I would prevent to be in a vendor lock-in situation (yet). Docker swarm seems to be evolving and is getting more nice features other competitors doesn't provide.
Due the native integration into the docker framework and great community I believe Docker Swarm will be the Docker Orchestration of the choice on the long run. This should be supported by Rancher 1.2 which is not released yet.
From this point of view it looks very reasonable that Docker Swarm in combination with Rancher (1.2) might be a good strategy to maintain your container farms in the future. If you think to put Docker Swarm into production in the actual state, I recommend to read Docker swarm mode: What to know before going live on production by Panjamapong Sermsawatsri.

Persistent Storage While it is a best practice to use data volume container these days, providing persistent storage across multiple hosts for shared volumes seems to be tricky. In theory you can mount a shared-storage volume as a data volume and there are several volume plugins which supports shared storage. For example you can use the convoy plugin which gives you:

• thin provisioned volumes
• snapshots of volumes
• backup of snapshots
• restore volumes

As backend you can use:

• Device Mapper
• Virtual File System(VFS)/Network File System(NFS)
• Amazon Elastic Block Store(EBS)

The good thing is, that convoy is integrated into Rancher. For more information I suggest to read Setting Up Shared Volumes with Convoy-NFS, which also mentions some limitations. If you want test Persistent Storage Service, Rancher provides some documentation. Actually I did not evaluate shared-storage volumes yet, but I don't see a solution I would love to use in production (at least on-premise) without strong downsides. But maybe things will go further and there might be a great solution for this caveats in the future.

Keeping base images up-to-date Since some time there are many projects that tries to detect security problems in your container images in several ways.
Beside general security considerations you need to deal somehow with issues in your base images that you build your applications on. Of course, even if you know you have a security issue in your application image, you need to fix it, which depends on the way how you based your application upon.

Ways to base your application image

• You can build your application image entire from scratch, which leaves all the work to your development team and I wouldn't recommend it that way.
• You also can create one (or more) intermediate image(s) that will be used by your development team.
• The development team might ground their work on images in public available or private (for example the one bundled to your gitlab CI/CD solution) registries.

Whats the struggle with the base image? If you are using images being not (well) maintained by other people, you have to wait for them to fix your base image. Using external images might also lead into trust problems (can you trust those people in general?).
In an ideal world, your developers have always fresh base images with fixed security issues. This can probably be done by rebuilding every intermediate image periodically or when the base image changes.

Paradigm change Anyway, if you have a new application image available (with no known security issues), you need to deploy it to production. This is summarized by Jason McKay in his article Docker Security: How to Monitor and Patch Containers in the Cloud:

To implement a patch, update the base image and then rebuild the application image. This will require systems and development teams to work closely together.

So patching security issues in the container world changes workflow significant. In the old world operation teams mostly rolled security fixes for the base systems independent from development teams.
Now hitting containers the production area this might change things significant.

Bringing updated images to production Imagine your development team doesn't work steady on a project, cause the product owner consider it feature complete. The base image is provided (in some way) consistently without security issues. The application image is build on top of that automatically on every update of the base image.
How do you push in such a scenario the security fixes to production? From my point of view you have two choices:

• Let the development team require to test the resulting application image and put it into production
• Push the new application image without review by the development team into production

The first scenario might lead into a significant delay until the fixes hit production created by the probably infrequent work of the development team. The latter one brings your security fixes early to production by the notable higher risk to break your application. This risk can be reduced by implementing massive tests into CI/CD pipelines by the development team. Rolling updates provided by Docker Swarm might also reduce the risk of ending with a broken application. When you are implementing an update process of your (application) images to production, you should consider Watchtower that provides Automatic Updates for Docker Containers.

Conclusion Not being a product owner or the operations part of an application that is facing a widely adopted usage that would compensate the actual tradeoffs we are still facing I tend not to move large scale production projects into a container environment.
This means not that this might be a bad idea for others, but I'd like to sort out some of the caveats before. I'm still interested to put smaller projects into production, being not scared to reimplement or move them on a new stack.
For smaller projects with a small number of hosts Portainer looks not bad as well as Rancher with the Cattle orchestration engine if you just want to manage a couple of nodes. Things are going to be interesting if Rancher 1.2 supports Docker swarm cluster out of the box. Let's see what the future will bring us to the container world and how to make a great stack out of it.

Update I suggest to read Docker in Production: A History of Failure and the answer Docker in Production: A retort to understand the actual challenges when running Docker in larger scale production environments.

What happened in the Reproducible Builds effort between Sunday October 23 and Saturday October 29 2016: Upcoming events The second Reproducible Builds World Summit will be held from December 13th-15th in Berlin! See the link for more details. Other events: Introduction to Reproducible Builds - Vagrant Cascadian will be presenting at the SeaGL.org Conference In Seattle, USA on November 12th, 2016. Reproducible Debian Hackathon - A small hackathon organized in Boston, USA on December 3rd and 4th. If you are interested in attending, contact Valerie Young - spectranaut in the #debian-reproducible IRC channel on irc.oftc.net. IRC meeting The next IRC meeting will be held on 2016-11-01 at 18:00 UTC. The meeting after that will be held on 2016-11-15 at 18:00 UTC. Reproducible work in other projects Ximin Luo has had his fix to bug 77985 accepted into GCC. This is needed to be able to write test cases for patches to make GCC produce debugging symbols that are reproducible regardless of the build path. There was continued discussion on the mailing list regarding our build path proposals. It has now been decided to use an environment variable SOURCE_PREFIX_MAP instead of the older proposal SOURCE_ROOT_DIR. This would be similar to GCC's existing -fdebug-prefix-map option, which allows for better disambiguation between paths from different packages. mandoc's makewhatis is now reproducible. It is used by all the BSDs, including FreeBSD, as well as Alpine Linux and Void Linux. Packages reviewed and fixed, and bugs filed Chris Lamb:

• #842477 filed against git
• #842115 filed against partclone
• #842356 filed against bio-eagle
• #842050 filed against tj3
• #842203 filed against seabios

Reiner Herrmann:

• #841777 filed against perl-tk
• #841783 filed against patchutils
• #841779 filed against netkit-rsh
• #842628 filed against mwparserfromhell
• #842629 filed against terminix
• #842622 filed against libvterm
• #842548 filed against libmsv
• #842624 filed against mdp-src
• #842625 filed against fuse-zip
• #842546 filed against rsbackup
• #842583 filed against paulstretch
• #842550 filed against the
• #842581 filed against cryptsetup

Reviews of unreproducible packages 145 package reviews have been added, 608 have been updated and 94 have been removed in this week, adding to our knowledge about identified issues. 3 issue types have been updated:

• Added 1 new issue docbook_to_man_one_byte_delta.
• Updated 2 existing issues randomness_in_r_rdb_rds_databases and r_base_appends_built_header_to_description_files.

Weekly QA work During of reproducibility testing, some FTBFS bugs have been detected and reported by:

• Chris Lamb (17)
• Matthias Klose (2)

tests.reproducible-builds.org Debian:

• Valerie improved the SQL code so that the scheduler job again runs within minutes. She did the same to the job updating the notes about known issues, though this job still runs 12min and not 2min as it used to do
• Thanks to a patch from Chris, which was improved by dkg and h01ger after discussions on our list, the .buildinfo files submitted to buildinfo.debian.net are now GPG signed by our build nodes.

General:

• Holger fixed the NetBSD and coreboot jobs which were broken due to work on the LEDE+OpenWRT jobs.
• As squid on jessie/i386 (but not on jessie/amd64) crashes frequently, we have have monitoring for this and Holger fixed a subtile bug there.

diffoscope development

• Daniel Shahaf:
  • json: detect order-only differences and print them nicely
• Mattia Rizzolo:
  • tests: skip test using a format accepted by older pytest

Misc. This week's edition was written by Ximin Luo, Chris Lamb and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

I accidentally made an ansible connector plugin for schroot. I haven't even used ansible yet, so I have no idea what I am doing. You can choose the chroot type by setting something like schroot_type: jessie in your variables. You can install this locally as connection_plugins/schroot.py.

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you. Debian Android

• I sponsored and reviewed android-platform-external-libunwind and android-platform-frameworks-base for Kai-Chung. Two more packages, android-framework-23 and android-platform-tools-swt, are currently waiting in the NEW queue and hopefully they become available soon. Kai-Chung also became Debian Maintainer this month and I granted him upload permissions for android-platform-tools-base for a start. Congratulations.
• I packaged a new upstream release of apktool (2.2.1).

Debian Games

• I fixed RC bugs in lordsawar (#839323) and doomsday (#839338).
• I packaged new upstream releases of atanks, lordsawar, blockattack and peg-e.
• I completed the Bullet transition (#839243). Bullet 2.85 has also been released this month but it is now too late for Stretch because the transition freeze is already on the 5th of November. I expect more point releases a la 2.85.x during the coming weeks and I intend to provide an updated package in experimental soon.
• I did some cleanups, package upgrades and bug fixes for box2d and redeclipse (apparently redeclipse-server requires the -data package to be present now).
• I uploaded Redeclipse 1.5.6 to jessie-backports in the hope that more players will be able to connect to the multiplayer servers. Unfortunately network compatibility breaks rather frequently.
• I applied a patch from Gianfranco Costamagna to address an Multiarch installation issue (#841824) in FreeOrion.

Debian Java

• This month I tended to upgrade more Java packages including new upstream releases of libjide-oss-java, activemq, easymock, libapache-mod-jk, svnkit, sweethome3d-furniture-editor, sweethome3d-textures-editor, sweethome3d-furniture, sweethome3d, sweethome3d-furniture-nonfree, maven-enforcer, bsaf, libjcommon-java, libjfreechart-java, libcsv-java, jansi, jansi-native, jboss-xnio and undertow.
• The update of maven-enforcer caused a regression in its reverse-dependencies (#841197) and required a patch and upload of another revision. The Jfreechart library upgrade also required a compatibility patch for statcvs.
• I updated stegosuite and fixed an incorrect Section field in debian/control.
• I updated the Debian packaging of libjgraph-java and libjemmy2-java.
• I decided to work on getting Eclipse into shape again. The current version is outdated and affected by several bugs at the moment and I really think it should not be released with Stretch. The new version though requires a major package update because the build system is Maven based now. Luca Vercelli already worked on sat4j and Tycho, two preconditions for packaging Eclipse. I reviewed sat4j and uploaded an NMU (#815911) later. I m still working on Tycho (#816604) and I hope to finish it soon.
• Netbeans 8.2 was released. I have already completed the work on libnb-platform18-java (updated package is available in Git) but I haven t started yet with netbeans itself. I intend to continue the fun in November.

Debian LTS This was my eight month as a paid contributor and I have been paid to work 13 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:

• From 10. October until 17. October I was in charge of our LTS frontdesk. I triaged bugs in libgd2, graphicsmagick, libxrender, mupdf, libxfixes, guile-2.0, glance, inspircd, libxi, libxv, libxst, spip, libxml2, libarchive and jasper.
• DLA-648-1. Issued a security update for c-ares fixing 1 CVE.
• DLA-664-1. Issued a security update for libxrender fixing 2 CVE.
• DLA-666-1. Issued a security update for guile-2.0 fixing 2 CVE.
• DLA-667-1. Issued a security update for libxv fixing 1 CVE.
• DLA-668-1. Issued a security update for libass fixing 2 CVE. I triaged CVE-2016-7970 and marked the version in Wheezy as not affected.
• DLA-673-1. Issued a security update for kdepimlibs fixing 1 CVE.

Non-maintainer uploads

• I fixed various RC bugs in gnudoq and xsok which are not maintained by the Games Team. The following games are available in Stretch again: gnudoq (#817296, #817484), xsok (#817738) and I also worked on four more bug fixes to improve the game s desktop integration and internationalization support.
• I fixed another RC bug in trackballs (#831119) but while I was working on the update I discovered that the game frequently segfaults which makes it kind of unplayable (#839788). I haven t found a solution yet but I suspect the switch to guile-2.0 and related patches introduced this behavior.

QA

• I uploaded a new revision of criticalmass and applied a patch from Adrian Bunk to fix #811816, a FTBFS.
• I triaged an RC bug for raptor2 (#824735) and the issue could be closed after the bug reporter confirmed that raptor2 built fine again.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS Last month I started to work on tiff3 but had not enough time to complete an update, it turns out the issues were hairy enough that nobody else picked up the package. So this month I started again with tiff3 and tiff and I ended up spending my 13h on those two packages. I filed bugs for issues that were not yet reported to the BTS (#842361 for CVE-2016-5652, #842046 for CVE-2016-5319/CVE-2016-3633/CVE-2015-8668). I marked many CVE as not affecting tiff3 as this source package does not ship the tools (the tiff source package does). Since upstream decided to drop many tools instead of fixing the corresponding security issues, I opted to remove the tools as well. Before doing this, I looked up reverse dependencies of libtiff-tools to ensure that none of the tools removed are used by other packages (the maintainer seems to agree too). I backported upstream patches for CVE-2016-6223 and CVE-2016-5652. But the bulk of the time, I spent on CVE-2014-8128, CVE-2015-7554 and CVE-2016-5318. I believe they are all variants of the same problem and upstream seems to agree since he opened a sort of meta-bug to track them. I took inspiration from a patch suggested in ticket #2499 and generalized it a bit by trying to add the tag data for all tags manipulated by the various tools. It was a tiresome process as there are many tags used in multiple places. But in the end, it works as expected. I can no longer reproduce any of the segfaults with the problematic files. I asked for review/test on the mailing list but did not get much feedback. I m going to upload the updated packages soon. Distro Tracker I noticed a sudden raise in the number of email addresses being automatically unsubscribed from the Debian Package Tracker and I got a few request of bounces. It turns out the BTS has been relaying lots of spam with executables files and those are bounced by Google (and not silently discarded). This is all very unfortunate the spam flood is unlikely to stop soon and I can t expect Google to change either, so I had little choice except trying to make the bounce handler smarter. That s what I did: I have a list of regular expression that will discard a bounce. In other words, once matched the bounce won t count towards the limit that triggers the automatic unsubscription. Misc Debian work Bugs filed. In #839403, I suggest the possibility to set the default pin priority for a source in the sources.list file directly. In #840436 I ask the selenium-firefoxdriver maintainer to do what is required to get this non-free package auto-built. Packaging. I sponsored puppet-lint 2.0.2-0.1 and I reviewed the rozofs package (wihch I just sponsored into experimental for a start). Publicity. I m maintaining the Debian account on Twitter and Facebook. I have been using twitterfeed.com up to now but it s closing down. I followed their recommendations and switched to dlvr.it to automatically post entries out of the micronews.debian.org feed. In #841165, I reported that the chroots created by sbuild-createchroot are lacking the usual IPv6 entries created by netbase. In #841503, I report a very common cryptsetup upgrade failure that I saw multiple times (both in Debian and in Kali). Thanks See you next month for a new summary of my activities.

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

Wishing every one a happy Gujarati New Year, Vikram Samvat 2073 named Kilaka and hoping the upcoming year will be yuuge for you. These next couple of paragraphs are totally not an excuse for why it will take a few more days for me to reach seven blog posts. Reading reports about Diwali in the American press, I see a bit of confusion whether Diwali is one day or five. Well, technically it is just one (Sunday 30th this year.) but there are a number of other observances around it which could be classed as subsidiaries if you want to look at it that way. The season commenced last Wednesday with Rama Ekadashi. (where the Gujarati name is different I'll use that and put the Sanskrit name in parentheses.) That's a fast day and therefore not much fun. Thursday was Vagh Barash (vyaghra dvadashi) which as the name suggests is something to do with tigers but we don't in my experience particularly do anything special that day. Friday, things began in earnest with Dhan Terash (dhana trayodashi) when Lakshmi the Goddess of prosperity is worshipped. It is also a good day to buy gold. Saturday was Kali Chaudash (Kali Chaturdashi or Naraka Chaturdashi) On this day many Gujarati families including mine worship their Kuladevi (patron Goddess of the family) even if She is not an aspect of Kali. (Others observe this on the Ashtami of Navaratri.) The day is also associated with the God Hanuman. Some people say it is His Jayanti (birthday) though we observe it in Chaitra (March-April.) It is also the best day for learning mantras and I initiated a couple of people including my son into a mantra I know. Sunday was Diwali (Deepavali) proper. As a Brahmana I spent much of the day signing blessings in the account books of shopkeepers. Well, nowadays only a few old people have actual account books so usually the print out a spreadsheet and I sign that. But home is where the main action is. Lights are lit, fireworks are set off, and prayers are offered to Lakshmi. But most important of all, this is the day good boys and girls get presents. Unfortunately I have nothing interesting to report; just the usual utilitarian items of clothing. Fireworks by the way are technically illegal in New Jersey not that that ever stopped anyone from getting them. The past few years, Jersey City has attempted to compromise by allowing a big public fireworks display. Although it was nice and sunny all day, by nighttime we had torrential rain and the firework display got washed out. So I'm glad I rebelled against the system with my small cache of sparklers. Today (or yesterday by the time this gets posted.) was the Gujarati New Years Day. There is also the commemoration of the time the God Krishna lifted up Mt Govardhan with one finger which every mandir emulates by making an annakuta or mountain of food. Tuesday is Bhai Beeja (Yama Dvitiya in Sanskrit or Bhai Duj in Hindi) when sisters cook a meal for their brothers. My son is also going to make something (read: microwave something) for his sister. So those are the five days of Diwali. Though many will not consider it to be truly over until this Saturday, the lucky day of Labh Pancham (Labha panchami.) And if I still haven't managed to write seven blog posts by then, there is always Deva Diwali...

Debian Long Term Support (LTS) This is my 7th month working on Debian LTS, started by Raphael Hertzog at Freexian, after a long pause during the summer. I have worked on the following packages and CVEs:

• tre: CVE-2016-8859
• graphicsmagick: CVE-2016-7448, CVE-2016-7996, CVE-2016-7997, CVE-2016-8682, CVE-2016-8683, CVE-2016-8684
• tar: CVE-2016-6321

I have also helped review work on the following packages:

• imagemagick: reviewed BenH's work to figure out what was done. unfortunately, I forgot to officially take on the package and Roberto started working on it in the meantime. I nevertheless took time to review Roberto's work and outline possible issues with the original patchset suggested
• tiff: reviewed Raphael's work on the hairy TIFFTAG_* issues, all the gory details in this email

The work on ImageMagick and GraphicsMagick was particularly intriguing. Looking at the source of those programs makes me wonder why were are still using them at all: it's a tangled mess of C code that is bound to bring up more and more vulnerabilities, time after time. It seems there's always an "Magick" vulnerability waiting to be fixed out there... I somehow hoped that the fork would bring more stability and reliability, but it seems they are suffering from similar issues because, fundamentally, they haven't rewritten ImageMagick... It looks this is something that affects all image programs. The review I have done on the tiff suite give me the same shivering sensation as reviewing the "Magick" code. It feels like all image libraries are poorly implemented and then bound to be exploited somehow... Nevertheless, if I had to use a library of the sort in my software, I would stay away from the "Magick" forks and try something like imlib2 first... Finally, I also did some minor work on the user and developer LTS documentation and some triage work on samba, xen and libass. I also looked at the dreaded CVE-2016-7117 vulnerability in the Linux kernel to verify its impact on wheezy users. I also looked at implementing a --lts flag for dch (see bug #762715). It was difficult to get back to work after such a long pause, but I am happy I was able to contribute a significant number of hours. It's a bit difficult to find work sometimes in LTS-land, even if there's actually always a lot of work to be done. For example, I used to be one of the people doing frontdesk work, but those duties are now assigned until the end of the year, so it's unlikely I will be doing any of that for the forseable future. Similarly, a lot of packages were assigned when I started looking at the available packages. There was an interesting discussion on the internal mailing list regarding unlocking package ownership, because some people had packages locked for weeks, sometimes months, without significant activity. Hopefully that situation will improve after that discussion. Another interesting discussion I participated in is the question of whether the LTS team should be waiting for unstable to be fixed before publishing fixes in oldstable. It seems the consensus right now is that it shouldn't be mandatory to fix issues in unstable before we fix security isssues in oldstable and stable. After all, security support for testing and unstable is limited. But I was happy to learn that working on brand new patches is part of our mandate as part of the LTS work. I did work on such a patch for tar which ended up being adopted by the original reporter, although upstream ended up implementing our recommendation in a better way. It's coincidentally the first time since I start working on LTS that I didn't get the number of requested hours, which means that there are more people working on LTS. That is a good thing, but I am worried it may also mean people are more spread out and less capable of focusing for longer periods of time on more difficult problems. It also means that the team is growing faster than the funding, which is unfortunate: now is a good time as any to remind you to see if you can make your company fund the LTS project if you are still running Debian wheezy.

Other free software work It seems like forever that I did such a report, and while I was on vacation, a lot has happened since the last report.

Monkeysign I have done extensive work on Monkeysign, trying to bring it kicking and screaming in the new world of GnuPG 2.1. This was the objective of the 2.1 release, which collected about two years of work and patches, including arbitrary MUA support (e.g. Thunderbird), config files support, and a release on PyPI. I have had to release about 4 more releases to try and fix the build chain, ship the test suite with the program and have a primitive preferences panel. The 2.2 release also finally features Tor suport! I am also happy to have moved more documentation to Read the docs, part of which I mentionned in in a previous article. The git repositories and issues were also moved to a Gitlab instance which will hopefully improve the collaboration workflow, although we still have issues in streamlining the merge request workflow. All in all, I am happy to be working on Monkeysign, but it has been a frustrating experience. In the last years, I have been maintaining the project largely on my own: although there are about 20 contributors in Monkeysign, I have committed over 90% of the commits in the code. New contributors recently showed up, and I hope this will release some pressure on me being the sole maintainer, but I am not sure how viable the project is.

Funding free software work More and more, I wonder how to sustain my contributions to free software. As a previous article has shown, I work a lot on the computer, even when I am not on a full-time job. Monkeysign has been a significant time drain in the last months, and I have done this work on a completely volunteer basis. I wouldn't mind so much except that there is a lot of work I do on a volunteer basis. This means that I sometimes must prioritize paid consulting work, at the expense of those volunteer projects. While most of my paid work usually revolves around free sofware, the benefits of paid work are not always immediately obvious, as the primary objective is to deliver to the customer, and the community as a whole is somewhat of a side-effect. I have watched with interest joeyh's adventures into crowdfunding which seems to be working pretty well for him. Unfortunately, I cannot claim the incredible (and well-deserved) reputation Joey has, and even if I could, I can't live with 500$ a month. I would love to hear if people would be interested in funding my work in such a way. I am hesitant in launching a crowdfunding campaign because it is difficult to identify what exactly I am working on from one month to the next. Looking back at earlier reports shows that I am all over the place: one month I'll work on a Perl Wiki (Ikiwiki), the next one I'll be hacking at a multimedia home cinema (Kodi). I can hardly think of how to fund those things short of "just give me money to work on anything I feel like", which I can hardly ask for of anyone. Even worse, it feels like the audience here is either friends or colleagues. It would make little sense for me to seek funding from those people: colleagues have the same funding problems I do, and I don't want to empoverish my friends... So far I have taken the approach of trying to get funding for work I am doing, bit by bit. For example, I have recently been told that LWN actually pays for contributed articles and have started running articles by them before publishing them here. This is looking good: they will publish an article I wrote about the Omnia router I have recently received. I give them exclusive rights on the article for two weeks, but I otherwise retain full ownership over the article and will publish them after the exclusive period here. Hopefully, I will be able to find more such projects that pays for the work I do on a day to day basis.

Open Street Map editing I have ramped up my OpenStreetMap contributions, having (temporarily) moved to a different location. There are lots of things to map here: trails, gaz stations and lots of other things are missing from the map. Sometimes the effort looks a bit ridiculous, reminding me of my early days of editing OSM. I have registered to OSM Live, a project to fund OSM editors that, I must admit, doesn't help much with funding my work: with the hundreds of edits I did in October, I received the equivalent of 1.80$CAD in Bitcoins. This may be the lowest hourly salary I have ever received, probably going at a rate of 10 per hour! Still, it's interesting to be able to point people to the project if someone wants to contribute to OSM mappers. But mappers should have no illusions about getting a decent salary from this effort, I am sorry to say.

Bounties I feel this is similar to the "bounty" model used by the Borg project: I claimed around $80USD in that project for what probably amounts to tens of hours of work, yet another salary that would qualify as "poor". Another example is a feature I would like to implement in Borg: support for protocols other than SSH. There is currently no bounty on this, but a similar feature, S3 support has one of the largest bounties Borg has ever seen: $225USD. And the claimant for the bounty hasn't actually implemented the feature, instead backing up to S3, the patch (to a third-party tool) actually enables support for Amazon Cloud Drive, a completely different API. Even at $225, I wouldn't be able to complete any of those features and get a decent salary. As well explained by the Snowdrift reviews, bounties just don't work at all... The ludicrous 10% fee charged by Bountysource made sure I would never do business with them ever again anyways.

Other work

• fixed a bug in python's setuptools_scm that was a blocker for Monkeysign's use of the package to avoid duplicating version numbers everywhere...
• tried to figure out how activitypub was going to work with existing social networking software (TL;DR: it won't)
• improved the sicherboot README so that others that come after me will better understand how that secure boot system works
• more charybdis IRCd work: SIGABRT on jessie and another segfault, still more issues pending here, even
• arbitrary source URL support for the Sphinx Alabaster theme
• a bunch of issues on unattended-upgrades: raspbian configuration fails and point releases upgrades

There are probably more things I did recently, but I am having difficulty keeping track of the last 5 months of on and off work, so you will forgive that I am not as exhaustive as I usually am.

I m at an airport, about to board the first of three flights across the world, from timezone +8 to timezone -8. I ll be in transit 27 hours to get to Seattle, Washington state. I m leaving my wife and two young children behind. My work has given me a days worth of leave under the Corporate Social Responsibility program, and I m taking three days annual leave, to do this. 27 hours each way in transit, for 3 days on the ground. Why? Backstory I started playing in technology as a kid in the 1980s; my first PC was a clone (as they were called) 286 running MS-DOS. It was clunky, and the most I could do to extend it was to write batch scripts. As a child I had no funds for commercial compilers, no network connections (this was pre Internet in Australia), no access to documentation, and no idea where to start programming properly. It was a closed world. I hit university in the summer of 1994 to study Computer Science and French. I d heard of Linux, and soon found myself installing the Linux distributions of the day. The Freedom of the licensing, the encouragement to use, modify, share, was in stark contrast to the world of consumer PCs of the late 1980 s. It was there at the UCC at UWA I discovered Debian. Some of the kind network/system admins at the University maintained a Debian mirror on the campus LAN, updated regularly and always online. It was fast, and more importantly, free for me to access. Back in the 1990s, bandwidth in Australia was incredibly expensive. The vast distances of the country mean that bandwidth was scarce. Telcos were in races to put fiber between Perth and the Eastern States, and without that in place, IP connectivity was constrained, and thus costly. Over many long days and nights I huddled down, learning window managers, protocols, programming and scripting languages. I became a system/network administrator, web developer, dev ops engineer, etc. My official degree workload, algorithmic complexity, protocol stacks, were interesting, but fiddling with Linux based implementations was practical. Volunteer After years of consuming the output of Debian and running many services with it I decided to put my hand up and volunteer as a Debian Developer: it was time to give back. I had benefited from Debian, and I saw others benefit from it as well. As the 2000 s started, I had my PGP key in the Debian key ring. I had adopted a package and was maintaining it load balancing Apache web servers. The web was yet to expand to the traffic levels you see today; most web sites were served from one physical web server. Site Reliability Engineering was a term not yet dreamed of. What became more apparent was the applicability of Linux, Open Source, and in my line-of-sight Debian to a wider community beyond myself and my university peers. Debain was being used to revive recycled computers that were being donated to charities; in some cases, unable to transfer commercial software licenses with the hardware that was no longer required by organisations that had upgraded. It appeared that Debian was being used as a baseline above which society in general had access to fundamental capability of computing and network services. The removal of subscriptions, registrations, and the encouragement of distribution meant this occurred at rates that could never be tracked, and more importantly, the consensus was that it should not be automatically tracked. The privacy of the user is paramount more important than some statistics for the Developer to ponder. When the Bosnia-Herzegovina war ended in 1995, I recall an email from academics there, having found some connectivity, writing to ask if they would be able to use Debian as part of their re-deployment of services for the Tertiary institutions in the region. This was an unnecessary request as Debian GNU/Linux is freely available, but it was a reminder that, for the country to have tried to procure commercial solutions at that time would have been difficult. Instead, those that could do the task just got on with it. There s been many similar project where the grass-roots organisations non profits, NGOs, and even just loose collectives of individuals have turned to Linux, Open Source, and sometimes Debian to solve their problems. Many fine projects have been established to make technology accessible to all, regardless of race, gender, nationality, class, or any other label society has used to divide humans. Big hat tip to Humanitarian Open Street Map, Serval Project. I ve always loved Debian s position on being the Universal operating system. Its vast range of packages and wide range of computing architectures supported means that quite often a litmus test of is project X a good project? was met with is it packaged for Debian? . That wide range of architectures has meant that administrators of systems had fewer surprises and a faster adoption cycle when changing platforms, such as the switch from x86 32 bit to x86 64 bit. Enter the Cloud I first laid eyes on the AWS Cloud in 2008. It was nothing like the rich environment you see today. The first thing I looked for was my favourite operating system, so that what I already knew and was familiar with was available in this environment to minimise the learning curve. However there were no official images, which was disconcerting. In 2012 I joined AWS as an employee. Living in Australia they hired me into the field sales team as a Solution Architect a sort of pre-sales tech with a customer focused depth in security. It was a wonderful opportunity, and I learnt a great deal. It also made sense (to me, at least) to do something about getting Debian s images blessed. It turned out, that I had to almost define what that was: images endorsed by a Debian Developer, handed to the AWS Marketplace team. And so since 2013 I have done so, keeping track of Debian s releases across the AWS regions, collaborating with other Debian folk on other cloud platforms to attempt a unified approach to generating and maintaining these images. This included (for a stint) generating them into the AWS GovCloud Region, and still into the AWS China (Beijing) Region the other side of the so-called Great Firewall of China. So why the trip? We ve had focus groups at the Debconf (Debian conference) around the world, but its often difficult to get the right group of people in the same rooms at the same time. So the proposal was to hold a focused Debian Cloud Sprint. Google was good enough to host this, for all the volunteers across all the cloud providers. Furthermore, donated funds were found to secure the travel for a set of people to attend who otherwise could not. I was lucky enough to be given a flight. So here I am, in the terminal in Australia: my kids are tucked up in bed, dreaming of the candy they just collected for Halloween. It will be a draining week I am sure, but if it helps set and improve the state of Debian then its worth it.