Debian Long Term Support (LTS) This is my monthly Debian LTS report. This time I worked on the famous KRACK attack, git-annex, golang and the continuous stream of GraphicsMagick security issues.

WPA & KRACK update I spent most of my time this month on the Linux WPA code, to backport it to the old (~2012) wpa_supplicant release. I first published a patchset based on the patches shipped after the embargo for the oldstable/jessie release. After feedback from the list, I also built packages for i386 and ARM. I have also reviewed the WPA protocol to make sure I understood the implications of the changes required to backport the patches. For example, I removed the patches touching the WNM sleep mode code as that was introduced only in the 2.0 release. Chunks of code regarding state tracking were also not backported as they are part of the state tracking code introduced later, in 3ff3323. Finally, I still have concerns about the nonce setup in patch #5. In the last chunk, you'll notice peer->tk is reset, to_set to negotiate a new TK. The other approach I considered was to backport 1380fcbd9f ("TDLS: Do not modify RNonce for an TPK M1 frame with same INonce") but I figured I would play it safe and not introduce further variations. I should note that I share Matthew Green's observations regarding the opacity of the protocol. Normally, network protocols are freely available and security researchers like me can easily review them. In this case, I would have needed to read the opaque 802.11i-2004 pdf which is behind a TOS wall at the IEEE. I ended up reading up on the IEEE_802.11i-2004 Wikipedia article which gives a simpler view of the protocol. But it's a real problem to see such critical protocols developed behind closed doors like this. At Guido's suggestion, I sent the final patch upstream explaining the concerns I had with the patch. I have not, at the time of writing, received any response from upstream about this, unfortunately. I uploaded the fixed packages as DLA 1150-1 on October 31st.

Git-annex The next big chunk on my list was completing the work on git-annex (CVE-2017-12976) that I started in August. It turns out doing the backport was simpler than I expected, even with my rusty experience with Haskell. Type-checking really helps in doing the right thing, especially considering how Joey Hess implemented the fix: by introducing a new type. So I backported the patch from upstream and notified the security team that the jessie and stretch updates would be similarly easy. I shipped the backport to LTS as DLA-1144-1. I also shared the updated packages for jessie (which required a similar backport) and stretch (which didn't) and those Sebastien Delafond published those as DSA 4010-1.

Graphicsmagick Up next was yet another security vulnerability in the Graphicsmagick stack. This involved the usual deep dive into intricate and sometimes just unreasonable C code to try and fit a round tree in a square sinkhole. I'm always unsure about those patches, but the test suite passes, smoke tests show the vulnerability as fixed, and that's pretty much as good as it gets. The announcement (DLA 1154-1) turned out to be a little special because I had previously noticed that the penultimate announcement (DLA 1130-1) was never sent out. So I made a merged announcement to cover both instead of re-sending the original 3 weeks late, which may have been confusing for our users.

Triage & misc We always do a bit of triage even when not on frontdesk duty, so I:

• sent another ping to the ca-certificates maintainer
• triaged Puppet's CVE-2016-5714 out of wheezy and other suites, after a thorough analysis of the what has become the intricate numbering scheme for Puppet suites
• triaged ImageMagick as not affecting in wheezy and jessie, but it turned out the latter was a little too enthusiastic as the team wanted to wait for upstream confirmation before skipping jessie
• did some research on tiff's CVE-2017-11613 (skipped by RHEL) and CVE-2017-9935 (no fix upstream)

I also did smaller bits of work on:

• worked on a patch to add a dch --lts flag in Debian bug #762715 which is currently pending review
• golang's CVE-2017-15041 which I originally triaged out but then changed my mind as the patch was small and the impact was large. This turned into DLA-1148-1.

The latter reminded me of the concerns I have about the long-term maintainability of the golang ecosystem: because everything is statically linked, an update to a core library (say the SMTP library as in CVE-2017-15042, thankfully not affecting LTS) requires a full rebuild of all packages including the library in all distributions. So what would be a simple update in a shared library system could mean an explosion of work on statically linked infrastructures. This is a lot of work which can definitely be error-prone: as I've seen in other updates, some packages (for example the Ruby interpreter) just bit-rot on their own and eventually fail to build from source. We would also have to investigate all packages to see which one include the library, something which we are not well equipped for at this point. Wheezy was the first release shipping golang packages but at least it's shipping only one... Stretch has shipped with two golang versions (1.7 and 1.8) which will make maintenance ever harder in the long term.

We build our computers the way we build our cities--over time, without a plan, on top of ruins. - Ellen Ullman

Other free software work This month again, I was busy doing some serious yak shaving operations all over the internet, on top of publishing two of my largest LWN articles to date (2017-10-16-strategies-offline-pgp-key-storage and 2017-10-26-comparison-cryptographic-keycards).

feed2exec beta Since I announced this new project last month I have released it as a beta and it entered Debian. I have also wrote useful plugins like the wayback plugin that saves pages on the Wayback machine for eternal archival. The archive plugin can also similarly save pages to the local filesystem. I also added bash completion, expanded unit tests and documentation, fixed default file paths and a bunch of bugs, and refactored the code. Finally, I also started using two external Python libraries instead of rolling my own code: the pyxdg and requests-file libraries, the latter which I packaged in Debian (and fixed a bug in their test suite). The program is working pretty well for me. The only thing I feel is really missing now is a retry/fail mechanism. Right now, it's a little brittle: any network hiccup will yield an error email, which are readable to me but could be confusing to a new user. Strangely enough, I am particularly having trouble with (local!) DNS resolution that I need to look into, but that is probably unrelated with the software itself. Thankfully, the user can disable those with --loglevel=ERROR to silence WARNINGs. Furthermore, some plugins still have some rough edges. For example, The Transmission integration would probably work better as a distinct plugin instead of a simple exec call, because when it adds new torrents, the output is totally cryptic. That plugin could also leverage more feed parameters to save different files in different locations depending on the feed titles, something would be hard to do safely with the exec plugin now. I am keeping a steady flow of releases. I wish there was a way to see how effective I am at reaching out with this project, but unfortunately GitLab doesn't provide usage statistics... And I have received only a few comments on IRC about the project, so maybe I need to reach out more like it says in the fine manual. Always feels strange to have to promote your project like it's some new bubbly soap... Next steps for the project is a final review of the API and release production-ready 1.0.0. I am also thinking of making a small screencast to show the basic capabilities of the software, maybe with asciinema's upcoming audio support?

Pandoc filters As I mentioned earlier, I dove again in Haskell programming when working on the git-annex security update. But I also have a small Haskell program of my own - a Pandoc filter that I use to convert the HTML articles I publish on LWN.net into a Ikiwiki-compatible markdown version. It turns out the script was still missing a bunch of stuff: image sizes, proper table formatting, etc. I also worked hard on automating more bits of the publishing workflow by extracting the time from the article which allowed me to simply extract the full article into an almost final copy just by specifying the article ID. The only thing left is to add tags, and the article is complete. In the process, I learned about new weird Haskell constructs. Take this code, for example:

-- remove needless blockquote wrapper around some tables
--
-- haskell newbie tips:
--
-- @ is the "at-pattern", allows us to define both a name for the
-- construct and inspect the contents as once
--
--   is the "empty record pattern": it basically means "match the
-- arguments but ignore the args"
cleanBlock (BlockQuote t@[Table  ]) = t

Here the idea is to remove <blockquote> elements needlessly wrapping a <table>. I can't specify the Table type on its own, because then I couldn't address the table as a whole, only its parts. I could reconstruct the whole table bits by bits, but it wasn't as clean. The other pattern was how to, at last, address multiple string elements, which was difficult because Pandoc treats spaces specially:

cleanBlock (Plain (Strong (Str "Notifications":Space:Str "for":Space:Str "all":Space:Str "responses":_):_)) = []

The last bit that drove me crazy was the date parsing:

-- the "GAByline" div has a date, use it to generate the ikiwiki dates
--
-- this is distinct from cleanBlock because we do not want to have to
-- deal with time there: it is only here we need it, and we need to
-- pass it in here because we do not want to mess with IO (time is I/O
-- in haskell) all across the function hierarchy
cleanDates :: ZonedTime -> Block -> [Block]
-- this mouthful is just the way the data comes in from
-- LWN/Pandoc. there could be a cleaner way to represent this,
-- possibly with a record, but this is complicated and obscure enough.
cleanDates time (Div (_, [cls], _)
                 [Para [Str month, Space, Str day, Space, Str year], Para _])
    cls == "GAByline" = ikiwikiRawInline (ikiwikiMetaField "date"
                                           (iso8601Format (parseTimeOrError True defaultTimeLocale "%Y-%B-%e,"
                                                           (year ++ "-" ++ month ++ "-" ++ day) :: ZonedTime)))
                        ++ ikiwikiRawInline (ikiwikiMetaField "updated"
                                             (iso8601Format time))
                        ++ [Para []]
-- other elements just pass through
cleanDates time x = [x]

Now that seems just dirty, but it was even worse before. One thing I find difficult in adapting to coding in Haskell is that you need to take the habit of writing smaller functions. The language is really not well adapted to long discourse: it's more about getting small things connected together. Other languages (e.g. Python) discourage this because there's some overhead in calling functions (10 nanoseconds in my tests, but still), whereas functions are a fundamental and important construction in Haskell that are much more heavily optimized. So I constantly need to remind myself to split things up early, otherwise I can't do anything in Haskell. Other languages are more lenient, which does mean my code can be more dirty, but I feel get things done faster then. The oddity of Haskell makes frustrating to work with. It's like doing construction work but you're not allowed to get the floor dirty. When I build stuff, I don't mind things being dirty: I can cleanup afterwards. This is especially critical when you don't actually know how to make things clean in the first place, as Haskell will simply not let you do that at all. And obviously, I fought with Monads, or, more specifically, "I/O" or IO in this case. Turns out that getting the current time is IO in Haskell: indeed, it's not a "pure" function that will always return the same thing. But this means that I would have had to change the signature of all the functions that touched time to include IO. I eventually moved the time initialization up into main so that I had only one IO function and moved that timestamp downwards as simple argument. That way I could keep the rest of the code clean, which seems to be an acceptable pattern. I would of course be happy to get feedback from my Haskell readers (if any) to see how to improve that code. I am always eager to learn.

Git remote MediaWiki Few people know that there is a MediaWiki remote for Git which allow you to mirror a MediaWiki site as a Git repository. As a disaster recovery mechanism, I have been keeping such a historical backup of the Amateur radio wiki for a while now. This originally started as a homegrown Python script to also convert the contents in Markdown. My theory then was to see if we could switch from Mediawiki to Ikiwiki, but it took so long to implement that I never completed the work. When someone had the weird idea of renaming a page to some impossible long name on the wiki, my script broke. I tried to look at fixing it and then remember I also had a mirror running using the Git remote. It turns out it also broke on the same issue and that got me looking in the remote again. I got lost in a zillion issues, including fixing that specific issue, but I especially looked at the possibility of fetching all namespaces because I realized that the remote fetches only a part of the wiki by default. And that drove me to submit namespace support as a patch to the git mailing list. Finally, the discussion came back to how to actually maintain that contrib: in git core or outside? Finally, it looks like I'll be doing some maintenance that project outside of git, as I was granted access to the GitHub organisation...

Galore Yak Shaving Then there's the usual hodgepodge of fixes and random things I did over the month.

• Beta testing for the new Signal desktop app which is, unfortunately, an Electron app. This means the binary is huge, at 95MB, and the app takes a whopping 300MB of ram right after startup. Compare this with my IRC client (irssi) which takes 15MB of ram or pidgin, which takes 80MB of ram. Then ponder the costs of developer convenience versus impact on the environment and users...
• Routine linkchecker maintenance: 3 PRs merged including a bugfix of my own, one of which inspired me to add the pyxdg dependency in feed2exec.
• When adding "badges" to the feed2exec documentation, I also fixed an issue in badges.debian.net, where Debian was referring to wheezy instead of the symbolic name
• Tested the Wireguard VPN with moderate success. It can only cross NAT one way, so it was useless for my use case. I ended up using end to end IPv6! still, I updated the Turris OS Wireguard version so that I could use this as a way to get end to end IPv4 connectivity to machines behind my NAT.
• Tested a static image gallery generator replacement called Sigal. I suggested a way to add progress information for video processing and did a general issue review. I also looked at how to package it in Debian, in RFP #879239. I looked into Sigal after finally getting a confirmation from the Photofloat maintainer (Jason A. Donenfeld, who's also the Wireguard author) that our patches will never get merged, after 3 years of radio silence. In comparison, the response I got from the communications with Sigal were much more positive. I have therefore requested removal of photofloat from Debian
• More on ham radio stuff: I got a Signalink working, which allowed me to receive and transmit APRS signals using a handheld transmitter
• I worked more on SafeEyes to try and get it to credit me idle time, which is still not working yet, and suggested improvements to the preferences panel
• I found out about the Chrome Lighthouse web page auditor, which doesn't seem to work at all in Chromium, but has a lot of potential. there's a standalone version as well, which could be packaged for Debian, but found that #775925 is for a different lighthouse - a dead Bitcoin-based crowdfunding platform
• I helped Koumbit.org configure load balancing for their HTTPS services. For this, I needed to change my IP address, so I test again the Bitmask client and found problems with polkit and the password failure prompt. I also suggested improvements the kerying package.
• After realizing there was no future in the It's all text! (IAT) extension, I have switched to Ghosttext which works both in Chromium and Firefox and uses a model similar to the Edit in Emacs extension for Chrome, but it also supports Firefox and other editors. I have filed an issue about silent failures with uMatrix and generally tried to help the IAT community find an exit strategy. (Short story: it's impossible to port, and XUL will die a horrible death.)

There is no [web extension] only XUL! - Inside joke

Here is my monthly update covering what I have been doing in the free software world in October 2017 (previous month):

• Wrote and released python-gfshare, a Python library that implements Shamir s method for secret sharing, a cryptography technique to split a file into multiple parts. I blogged about it earlier in the month.
• Improved the new-style URL handling in the 2.x branch of the Django web framework to check for incorrectly migrated calls from the old system. [...]
• Added support for Python 3, Django 1.9 & Django 2.0 to django-auto-one-one-to-one, my library to cleanly manage related model instances.
• Proposed two small pull requests for Redisearch, a search engine module for the Redis key-value storage database:
  • Don't assume that not being Linux is OSX. [...]
  • Install the module into /usr/lib over /var/lib as the latter is for program state, not libraries or modules. [...]
• In Peter Bengtsson's new django-cache-memoize library, suggested an addition to the store_result documentation. [...]
• Made two pull requests for django-auditlog, a Django app that maintains an audit trail of changes in your application:
  • Add missing on_delete to the LogEntry initial migration to ensure compatibility with Django 2.x. [...]
  • Add missing python-dateutil to setup.py. [...]
• Yet more Lintian hacking (previously):
  • New features:
    • Warn when packages unnecessararily set dpkg-architecture(1) variables. (#793554)
    • Check for files that use content from the /etc/init.d/skeleton template. (#879152)
    • Warn about certain files under debian/* that contain trailing whitespace characters. (#748405)
    • Ignore embedded jQuery libraries for Doxygen. (#736360)
    • Warn about Django libraries that do not depend on Django itself. (#877292)
    • Check for Python modules with overly generic names such as tests or test. (#875964)
    • Warn if packages set CFLAGS if the value of DEB_BUILD_OPTIONS contains noopt. (#718640)
    • Ignore embedded jQuery libraries for Doxygen. (#736360)
    • Warn about empty fields in debian/control. (#744388)
    • Add bionic as known Ubuntu distribution. (#880115)
    • Warn if native systemd .service files only wrap the existing SysV/LSB init scripts. (#870704)
    • Emit new empty-section-field tag instead of uninitialized value warnings on an empty Section: field. (#878515)
    • Warn about debian/watch files using insecure URIs, similar to vcs-field-uses-insecure-uri. (#849515)
    • Include the offending URI in debian-watch-uses-insecure-uri output, not the line number.
    • Allow empty md5sums files. (#781372)
    • Move latest-debian-changelog-entry-without-new-date tag into a new check of type source. (#873612)
    • Add cwl-runner to the list of known interpreters. (#851126)
    • Also match packages named python2-* as relating to the Python 2.x migration.
  • Bug fixes:
    • Don't error out when AppStream metadata is invalid; emit appstream-metadata-invalid instead. (#879661)
    • Actually check for a dependency on sensible-utils before emitting script-needs-depends-on-sensible-utils. (#877439)
    • Avoid a false positives in debian-control-has-empty-field when the field is wrapped onto a new line. (#879977)
    • Drop README.source from files to check against file-contains-trailing-whitespace as it can include literal quotes from upstreams that would be ideally left intact.
    • Lower the severity of package-installs-java-bytecode from E: to W:. (#879862)
    • Do not trigger package-installs-java-bytecode if the path contains WEB-INF, demo, doc etc. (#879860)
    • Verify files triggering package-installs-java-bytecode files really are Java .class files. (#879861)
    • Check the Recommends field as well when testing scripts for script-needs-depends-on-sensible-utils. (#879953)
    • Ignore the "magic" http://sf.net/ redirector URI for the debian-watch-uses-insecure-uri tag. (#879206)
    • Revert addition of "none were" -> "none was" multiword spelling correction as it is "acceptable beyond serious criticism". (#878457)
    • Drop copyright-year-in-future; too error prone and time-consuming to maintain given the severity of the issues it can find. (#877766)
    • Exempt debian/copyright from the license-problem-non-free-RFC tag to avoid false-positives "meta" references. (#877999)
    • Ignore privacy breach violations within HTML/Javascript comments. (#877421)
    • Avoid warning for init.d-script-not-marked-as-conffile when the init.d script does not exist as we will already be alerted via the init.d-script-not-included-in-package tag.
    • Do not emit python-foo-but-no-python3-foo for packages ending with -common.
    • Add missing example-script-uses-deprecated-nodejs-location tag. (#877142)
    • Correct invalid link to upgrading-checklist in Standards-Version checks. (#878184)
  • Documentation:
    • Add a note to orig-tarball-missing-upstream-signature regarding support in pristine-tar and git-buildpackage.
    • Add example on how to remove trailing whitespace with sed.
  • Tests:
    • Split out checks for debconf-config-not-executable into a separate test protected by a Test-Requires now that dpkg 1.19.0 will bail out on that condition.
    • Correct Depends of python2.7 python3 in a Python 3 test package.
    • Add test for ignoring python-foo-doc packages for the Python 3 migration and correct short descriptions of test packages.
• Finally, I was interviewed by HostingAdvice about my role as Debian Project Leader.

---

Turns out that it is surprisingly easy to build most packages without (fake)root. You just need to basic changes:

1. A way to set ownership to root:root of paths when dpkg-deb build constructs the binary.
2. A way to have debhelper not do a bunch of (now) pointless chowns to root:root .

The above is sufficient for dpkg, debhelper, lintian, apt-file, mscgen, pbuilder and a long list of other packages that only provide paths owned by root:root . Obviously, packages differ and yours might need more tweaks than this (e.g. dh_usrlocal had to change behaviour to support this). But for me, the best part is that the above is not just some random prototype stuck in two git repos on alioth:

• dpkg and debhelper in unstable have all the bits required to do this and only requires you to opt-in via the Rules-Requires-Root -field (R ) after doing all the necessary tweaks (if any). Most of the above listed packages have actually already opted in by just adding the R -field.
• Guillem and I have posted an RFC for specification of Rules-Requires-Root -field that describes the field and what it is expected from you as a Debian package maintainer , a packaging-tool maintainer and a package builder . Review of this specification is very welcome.
• The implementations in dpkg and debhelper are generally safe for backporters. While YMMV, we expect that the vast majority will find that backporting an R =no package just works.
• Before you upload any R -related changes to unstable, please note that the specification and implementations are still subject to changes (assuming there are any concerns with either). That said, I believe that it is unlikely that there will be fundamental changes to the basic R =no variant. Accordingly, I have started to opt-in in my packages.

Unfortunately, if you are working with games or core packages like shadow with need for static ownership different from root:root (usually with a setuid or setgid bit), then our first implementation does not support your needs at the moment[1]. We are working on a separate way to solve static ownership in a declarative way. [1] Note regarding /usr/local : If your package needs to provide directories there owned by root:staff with mode 02775, then dh_usrlocal can handle that. The non- root:root ownership here works because the directories are created in a maintainer script run as root during installation. Unfortunately, it cannot provide different ownership or modes with R != binary-targets at the moment.
Filed under: Debhelper, Debian

Review: Why We Sleep, by Matthew Walker

Publisher:	Scribner
Copyright:	October 2017
ISBN:	1-5011-4433-2
Format:	Kindle
Pages:	341

The world is full of theories, and corresponding books, about things that will make you healthier or prevent disease. Nearly all of them are scams, either intentional or created through the placebo effect and the human tendency to see patterns that don't exist. The rare ones that aren't have a certain pattern: they're grounded in our best understanding of biology, align with what our body wants to do anyway, have been thoroughly studied using proper testing methodology, and don't make money for powerful corporations. I'm fairly sure this is one of those rare ones that isn't a scam. And, if so, it's rather important and worth your attention. Matthew Walker is a professor of neuroscience and biology at the University of California at Berkeley, where he's the founder of the Center for Human Sleep Science. He's not a doctor; he started medical training, but (as he says in the book) found himself more attracted to questions than answers. He's a professional academic researcher who has been studying sleep for decades. This book is a combination of summary of the current state of knowledge of academic sleep research and a plea: get more sleep, because we're literally killing ourselves with the lack of it. Walker opens the book with a discussion of the mechanisms of sleep: how we biologically fall asleep and why, how this has changed over time, and how it changes with age. Along with that, he defines sleep: the REM and NREM sleep cycle that you may have already heard of, how it manifests itself in most people, and where dreams fit in. The second part then discusses what happens when you sleep, with a focus on what goes wrong when you don't. (Spoiler: A lot. Study after study, all cited and footnoted, has found connections between sleep and just about every aspect of mental and physical health.) The third part does the same for dreams, fitting them into the picture along with a scientific discussion of just what's going on during dreams. The fourth and final part tackles the problem: why don't we get enough sleep, and what can we do about it? I will warn in advance that this book will make you paranoid about your sleeping patterns. Walker has the missionary zeal of an academic who has sunk his teeth into something really important that society needs to take into account and will try to drown you in data, analysis, analogies, and sheer earnestness until you will believe him. He wants you to get at least seven, and preferably eight, hours of sleep a night. Every night, with as little variation as you can manage. Everyone, even if you think you're someone who doesn't need as much sleep (you're probably not). There's a ton of science here, a great popularization of a whole field of research, but this is also a book that's trying to get you to do something. Normally, that sort of book raises my shields. I'm not much of a believer in any book of the general genre of "most people are doing this basic part of life wrong, and should do it my way instead." But the hallmarks of good science are here: very widespread medical consensus, no corporate interest or obvious path to profit, and lots of studies (footnoted here, with some discussions of methodology although not the statistical details, which will require looking up the underlying studies and careful caveats where studies indicate correlation but may not find causes). And Walker makes the very telling point early in the book that nearly every form of life on the planet sleeps in one way or another (defined as a daily recurring period of time during which it doesn't respond to outside stimulus), which is a strong indicator of universal necessity. Given the vulnerability and loss of useful hours that come with sleep, one would expect some species to find an evolutionary path away from it if it were dispensable. But except for extremely short-lived species, we've never found a living creature that didn't sleep. Walker's argument for duration is also backed up by repeated studies on human capability before and after various quantities of sleep, and on studies of the sleep phases in various parts of the night. Study after study used six hours as the cutoff point and showed substantial deterioration in physical and mental capabilities even after only one night of short sleeping. (Reducing sleep to four hours is nearly catastrophic.) And, more worrisomely, that degradation is still measurable after "catching up" on sleep on subsequent nights. Sleeping in on weekends doesn't appear to fully compensate for the damage done by short-sleeping during the week. When Walker gets into the biological reasons for sleep, one starts to understand why it's so important. I think the part I found the most fascinating was the detailed analysis of what the brain is doing while you sleep. It's not inactive at all, even outside of REM sleep. Walker and other sleep researchers have done intriguing experiments showing how different parts of the sleep cycle transfer memories from short to long term storage, transfer physical skills into subconscious parts of the brain, discard short term memories that the conscious brain has tagged as being unwanted, and free up space for new knowledge acquisition. REM sleep appears to attempt to connect otherwise unrelated memories and bits of knowledge, inverting how association normally works in the brain, thus providing some concrete explanation for sleep's role in creativity. And (this research is fairly new), deep NREM sleep causes temporary physical changes in the brain that appear to be involved in flushing metabolic waste products away, including the plaque involved in Alzheimer's. The last part of the book is probably the most concretely useful: what can one practically do to get more sleep? There is quite a lot that's proven effective, but Walker starts with something else: sleeping pills. Here, you can almost see the lines drawn by a lawyer around what Walker should say. He stresses that he's not a medical doctor while laying out study after study that all point in the same direction: sleeping pills are a highly dangerous medical fraud that will shorten your lifespan for negligible benefit in helping you fall asleep, while limiting your brain's ability to enter true sleep. They're sedation, sedation is not sleep, and the four billion dollar sleeping pill market is literally making everything worse. The good news is there is an effective treatment for insomnia that works for many people; the better news is that it's completely free (although Walker does suggest some degree of medical supervision for serious insomnia so that some parts of it can be tailored to you). He walks through CBT-I (cognitive behavior therapy for insomnia), which is now the medically recommended primary treatment for insomnia, and takes apart the pieces to show how they line up with the results of sleep research studies. Alongside that are recommendations for improving sleep for people who don't have clinical insomnia but who aren't regularly getting the recommended amount of sleep. There are a lot of interesting bits here (and he of course talks about blue LED light and its relationship to melatonin cycles), but I think the most interesting for me was that you have to lower your core body temperature by a couple of degrees (Fahrenheit) to enter sleep. The temperature of your sleeping environment is therefore doubly important: temperature changes are one of the signals your body uses to regulate circadian rhythms (cold being a signal of night), and a colder sleeping area helps you lower your core body temperature so that you can fall asleep. (The average person does best with a sleeping room temperature of 65F, 18C.) There's even more in here: I haven't touched on Walker's attack on the US tendency to push high school start times earlier and earlier in the day (particularly devastating for teenagers, whose circadian rhythms move two hours later in the day than adults before slowly returning to an adult cycle). Or the serious problems of waking to an alarm clock, and the important benefits of the sleep that comes at the end of a full night's cycle. Or the benefits of dreams in dealing with trauma and some theories for how PTSD may interfere with that process. Or the effect of sleep on the immune system. Walker's writing style throughout Why We Sleep is engaging and clear, although sometimes too earnest. He really wants the reader to believe him and to get more sleep, and sometimes that leaks around the edges. One can also see the effort he's putting into not reading too much into research studies, but if there's a flaw in the science here, it's that I think Walker takes a few tentative conclusions a bit too far. (I'm sure these studies have the standard research problem of being frequently done on readily-available grad students rather than representative samples of the population, although the universality of sleep works in science's favor here.) Some of the recitations of research studies can get rather dry, and I once again discovered how boring I find most discussion of dreams, but for a first book written by an academic, this is quite readable. This is one of those books that I want everyone to read mostly so that they can get the information in it, not as much for the enjoyment of reading the book itself. I've been paying closer attention to my own sleep patterns for the last few years, and my personal experience lines up neatly with the book in both techniques to get better sleep and the benefits of that sleep. I'd already reached the point where I was cringing when people talk about regularly going on four or five hours of sleep; this is an entire book full of researched reasons to not do that. (Walker points out that both Reagan and Thatcher, who bragged about not requiring much sleep, developed Alzheimer's, and calls out Trump for making the same brag.) The whole book may not be of interest to everyone, but I think everyone should at least understand why the World Heath Organization recommends eight hours a night and labels shift work a probable carcinogen. And, as Walker points out, we should be teaching some of this stuff in school health classes alongside nutrition and sex education. Alas, Walker can't provide much advice on what I think is the largest robber of sleep: the constant time pressure of modern life, in which an uninterrupted nine hour sleep opportunity feels like an unaffordable luxury. Rating: 9 out of 10

Narabu is a new intraframe video codec. You probably want to read part 1, part 2 and part 3 first. So we're at the stage where the structure is in place. How do we decode? Once we have the structure, it's actually fairly straightforward: First of all, we need to figure out where each slice starts and ends. This is done on the CPU, but it's mostly just setting up pointers, so it's super-cheap. It doesn't see any pixels at all, just lengths and some probability distributions (those are decoded on the CPU, but they're only a few hundred values and no FP math is involved). Then, we set up local groups of size 64 (8x8) with 512 floats of shared memory. Each group will be used for decoding one slice (320 blocks), all coefficients. Each thread starts off doing rANS decoding (this involves a lookup into a small LUT, and of course some arithmetic) and dequantization of 8 blocks (for its coefficient); this means we now have 512 coefficients, so we add a barrier, do 64 horizontal IDCTs (one 8-point IDCT per thread), add a new barrier, do 64 vertical IDCTs, and then finally write out the data. We can then do the next 8 coefficients the same way (we kept the rANS decoding state), and so on. Note how the parallelism changes during the decoding; it's a bit counterintuitive at first, and barriers are not for free, but it avoids saving the coefficients to global memory (which is costly). First, the parallelism is over coefficients, then over horizontal DCT blocks, then over vertical DCT blocks, and then we start all over again. In CPU multithreading, this would be very tricky, and probably not worth it at all, but on the GPU, it gives us tons of parallelism. One problem is that the rANS work is going to be unbalanced within each warp. There's a lot more data (and thus more calculation and loading of compressed data from memory) in the lower-frequency coefficients, which means the other threads in the warp are wasting time doing nothing when they do more work. I tried various schemes to balance it better (like making even larger thread groups to get e.g. more coefficient 0s that could work together, or reordering the threads' coefficients in a zizag), but seemingly it didn't help any. Again, the lack of a profiler here is hampering effective performance investigations. In any case, the performance is reasonably good (my GTX 950 does 1280x720 luma-only in a little under 0.4 ms, which equates to ~1400 fps for full 4:2:2). As a side note, GoPro open-sourced their CineForm HD implementation the other day, and I guess it only goes to show that these kind of things really belong on the GPU; they claim similar performance numbers to what I get on my low-end NVIDIA GPU (923.6 fps for 1080p 4:2:2, which would be roughtly 1800 fps on 720p60), but that's on a 4GHz 8-core Broadwell-E, which is basically taking the most expensive enthusiast desktop CPU you can get your hands on and then overclocking it. Kudos to GoPro for freeing it, though (even under a very useful license), even though FFmpeg already had a working reverse-engineered implementation. :-) Next time, we'll look at the encoder, which is a bit more complicated. After that, we'll do some performance tests and probably wrap up the series. Stay tuned.

Review: Provenance, by Ann Leckie

Publisher:	Orbit
Copyright:	September 2017
ISBN:	0-316-38863-7
Format:	Kindle
Pages:	448

In a rather desperate attempt to please her mother, Ingray has spent every resource she has on extracting the son of a political enemy from Compassionate Removal (think life imprisonment with really good marketing). The reason: vestiges, a cultural touchstone for Ingray's native planet of Hwae. These are invitation cards, floor tiles, wall panels, or just about anything that can be confirmed to have been physically present at an important or historical moment, or in the presence of a famous figure. The person Ingray is retrieving supposedly pulled off the biggest theft of vestiges in history. If she can locate them, it would be a huge coup for her highly-placed politician mother, and the one time she would be victorious in her forced rivalry with her brother. About the best thing that could be said for this plan is that it's audacious. The first obstacle is the arrival of the Geck on the station for a Conclave for renegotiation of the treaty with the Presger, possibly the most important thing going on in the galaxy at the moment, which strands her there without money for food. The second is that the person she has paid so much to extract from Compassionate Removal says they aren't the person she was looking for at all, and are not particularly interested in going with her to Hwae. Only a bit of creative thinking in the face of a visit from the local authorities, and the unexpected kindness of the captain from whom she booked travel, might get her home with the tatters of her plan intact. But she's clearly far out of her depth. Provenance is set in the same universe as Ancillary Justice and its sequels, but it is not set in the empire of the Radchaai. This is another human world entirely, one with smaller and more provincial concerns. The aftermath of Ancillary Mercy is playing out in the background (so do not, on risk of serious spoilers, read the start of this book without having read the previous trilogy), but this is in no way a sequel. Neither the characters nor the plot are involved in that aftermath. It's a story told at a much smaller scale, about two political families, cut-throat maneuvering, horrible parenting, the inexplicable importance of social artifacts, the weirdness of human/alien relations, and the merits of some very unlikely allies. Provenance is a very different type of story than Ancillary Justice, and Ingray is a very different protagonist. The shape of the plot reminded me of one of Lois McMaster Bujold's Miles Vorkosigan stories: hair-brained ideas, improvisation, and unlikely allies. But Ingray couldn't be more different than Miles. She starts the book overwhelmed, despairing, and not at all manic, and one spends the first part of the story feeling sorry for her and becoming quite certain that everything will go horribly wrong. The heart of this book is the parallel path Leckie takes the reader and the characters along as they discover just what Ingray's true talents and capabilities are. It's a book about being hopelessly bad at things one was pressured towards being good at, while being quietly and subtly good at the skills that let one survive a deeply dysfunctional family. There are lots of books with very active protagonists, and a depressing number of books with passive protagonists pushed around by the plot. There are very few books that pull off the delicate characterization that Leckie manages here: a protagonist who is rather hopeless at taking charge of the plot in the way everyone wants (but doesn't particularly expect) her to, but who charts her own path through the plot in an entirely unexpected way. It's a story that grows on you. The plot rhythm never works in quite the way one expects from other books, but it builds its own logic and its own rhythm, and reached a very emotionally satisfying conclusion. The Radchaai, or at least one Radchaai citizen, do show up eventually, providing a glimmer of outside view at the Ancillary Justice world. Even better, the Geck play a significant role. I adore Leckie's aliens: they're strange and confusing, but in a refreshingly blunt way rather than abusing gnomic utterances and incomprehensible intelligence. And the foot-stomping of the spider bot made me laugh every time. The stakes are a lot lower here than in Ancillary Justice, and Ingray isn't the sort of character who's going to change the world. But that's okay; indeed, one of the points of this book is why and how that's okay. I won't lie: I'd love more Breq, and I hope we eventually get an exploration of the larger consequences of her story. But this is a delightful story that made me happy and has defter character work than most SF being written. Recommended, but read the Ancillary trilogy first. One minor closing complaint, which didn't change my experience of the book but which I can't help quibbling about: I'm completely onboard with the three-gender system that Leckie uses for the Hwae (I wish more SF authors would play with social as well as technological ideas), and I think she wove it deftly into the story, but I wish she hadn't used Spivak pronouns for the third gender. (e/em/eir, for those who aren't familiar.) Any of the other gender-neutral pronouns look better to me and cause fewer problems for my involuntary proofreader. I prefer zie/zir for personal reasons, but sie/hir, zhe/zhim/zher, or even thon or per would read more smoothly. Eir is fine, but em looks like 'em and throws my brain into dialect mode and forces a re-parse, and e just looks like a typo. I know from lots of Usenet discussions of pronouns that I'm not the only one who has that reaction to Spivak. But it's a very minor nit. Rating: 8 out of 10

Recently, when asked to engage with the Debian Technical Committee, a maintainer chose to orphan their package rather than discuss the issue brought before the committee. In another decision earlier this year, a maintainer orphaned their package indicating a lack of respect for the approach being taken and the process. Unfortunately, this joins an ever longer set of issues where people walk away from the TC process disheartened and upset.

For me personally the situations where maintainers walked away from the process were hard. People I respect and admire were telling me that they were unwilling to participate in our dispute resolution process. In one case the maintainer explicitly did not respect a process I had been heavily involved in. As someone who values understanding and build a team, I feel disappointed and hurt thinking about this.

Unfortunately, I don't feel much better when I consider several of the other issues brought before the TC. In a number of cases, the process has concluded, but it feels like a pyrrhic victory. We have an answer, but often we never reached an understanding of one of the key stakeholder's positions. People are sufficiently disappointed or frustrated that they reduce their involvement. That is, the answer is not one they can live with. Sometimes, I'm not even sure that answering the question was worth the cost.

My initial suspicion as I begin to consider issues that have come before the TC in the last few years is that as a necessary consequence of how the TC operates, we will drive a significant chunk of those who come to us away from our community. I will not be part of that. If I end up eventually agreeing with this suspicion, I will either work to improve the TC process or find a different way to contribute to the project that is more aligned with my goals.


Our Community is More Important than Technical Correctness I firmly believe that Debian's strength is its community. Distributions, upstreams, free-software advocates, corporate interests, and everything in between work together. Because we are working on a concrete product,we actually have to understand how our needs conflict and compliment each other. Also, like any organization, our ability to get things done is dependent on our contributors and the time we all put in.

I cannot think of anything more harmful we can do than drive away a constructive contributor. Technical quality is important: many of us will eventually go away if quality drops too much. However, Debian itself can be improved incrementally. Yes, new people do join Debian. However, it takes a lot of new people to make up for a situation where everyone involved is frustrated, and some leave and tell their friends to stay away from Debian.

When a Disagreement Reaches the TC When a disagreement reaches the TC, we know a few things. First, people have not have not been able to resolve it on their own. Second, the disagreement is important enough to at least one of the parties to ask for outside help.

If the TC were to simply announce a decision, it is very likely that at least one party would feel frustrated and disappointed. If the decision is important to someone it almost always means that they care about the outcome. If previous efforts have not reached agreement then there is an outcome that is undesired. While it's possible under the constitution that two parties could bring an issue to the TC mutually where the dynamics could be different, this does not happen in practice.

When we "lose" When a decision making process decides to select one of my undesired outcomes, I have strong negative feelings. First, there is the technical result itself. Because of an adverse decision it is generally harder for me to do my technical work, or some ethical position or group I care about is disadvantaged. However, the strongest feelings are related to needs about my place in the community, not a direct response to the technical decision. I worry about whether issues I care about will be valued in the future; I would likely feel weary or scared thinking of contributing in an environment where issues that matter to me aren't going to be considered. I tend to feel frustrated if my position was not adequately considered this time around.

Often, the strongest feelings do not stem from how I am impacted by the decision itself. Thus, if my more general needs are addressed, I will feel a lot better about not having my preferred outcome selected. Confidence that my position was understood is the single biggest factor in being able to accept the result. If the community took the time to understand me, then I have confidence that I am valued. I can advocate for change and be part of the ongoing discussion. If I understand the other positions then I can understand that the position was not arbitrary. Understanding the other positions is also a prerequisite to seeing how things I value were considered, especially when the tradeoff did not ultimately favor these values.

My conversations with others about their experience with conflict suggest my feelings and needs are common.


However, the TC focuses almost exclusively on the technical matter before it. I don't think the TC has done a good job of actually understanding maintainers or the people bringing issues to us. Especially when we're fairly sure we understand what the ultimate decision will be, we focus on getting to that decision. Of course part of actually understanding someone is considering what they have to say. Even when you have high confidence in an outcome, if you want someone to feel understood, you do have to listen at a point where you can consider what they bring forward.

Frustration of Being Questioned

On the other side, it's frustrating to have your decisions questioned. Reviewing a decision takes time. Even if the TC agrees with a maintainer, asking that maintainer to sit through a long process can create frustrations as deep as any I discussed in the previous section.

So the process is doubly bad for maintainers. Someone can bring up an issue which requires precious time. Then if the TC decides against the maintainer, we have all the problems I discussed previously.

I acknowledge this. A good process must respect the maintainer's time. However, it must respect the community members who disagree with maintainers. Everyone who brings an issue to the TC is a developer. They have contributed significantly to our community and are part of our team. Yes, we need to protect the process against abuse. But in a very real sense if we aren't willing to consider an issue and we aren't willing to engage with someone, understand why they think the issue should be considered, and work until they understand why we made our decision, we are saying we do not respect them enough to take that time. We should expect that to drive people away.

I wonder if the solution here involves a two phase process. During the first phase we work with someone bringing an issue to us until we understand it. We either engage the maintainer at that point, spend the time to help the person bringing an issue to us understand why we are not engaging the maintainer, or have decided the issue is abusive of the processs/misdirected. For this to work maintainers would have to trust us enough to actually be willing to sit back and not spend a lot of their time.

Sam, It's Just Personalities

One criticism I've heard as I discuss this is that a lot of the negative feelings surround interpersonal conflict and are personality conflicts. Yes, personalities matter. Yes, we re still healing from the Systemd discussion.

However, as a community, I think we need to figure out how we respect the inevitable personality conflicts. I can think of one or two developers I'm still upset with years after an issue. It happens. Perhaps if I were a maintainer when one of these developers raised a concern with my packages, I could ask that someone else be a primary advocate for an issue. Similarly, if a developer wanted to address an issue with me as a maintainer but would prefer not to deal with me, perhaps we could figure out some way that we could see if someone else shared the concern.

Dropping a Package is Sometimes an Answer

My concerns were sparked by instances where a maintainer dropped a package rather than interact with the TC. Sometimes that can be a healthy step in a transition. At Debconf this year, Enrico Zini gave a talk on consent culture in Debian. One of the key points of his talk is that we can find over time that what we're being asked to do in Debian is no longer consistent with our boundaries. If it isn t helping us move forward if it isn t fun then it is likely time to stop.

In that sense, approaching disagreement can be a great time to take stock and ask whether we still enjoy maintaining a package. If we don t, then stepping aside and letting others take it on can be a great way that we and they can be happier. I don t really think that s what happened in these instances though. Based on comments made to me, this sounded more like a lack of faith in being treated well or in our ability as a committee.

Even so, Enrico s talk applies in a number of ways here. He suggests that the approach we should take when someone is done and steps away is to thank then. I couldn t agree more. From the depth of my heart I offer thanks: Thank you for taking care of yourself and stepping away when it is no longer fun. Thank you for all the effort you have put into these packages. I hope to work with you on great things in the future.

Review: The Black Gryphon, by Mercedes Lackey & Larry Dixon

Series:	Mage Wars #1
Publisher:	DAW
Copyright:	1994
Printing:	January 1995
ISBN:	0-88677-643-0
Format:	Mass market
Pages:	460

The Mage Wars series (or the Gryphon series, which isn't its official title but which is in all of the titles) is part of the sprawling Valdemar mega-series, but it's a prequel to all of the other stories. It's also slightly challenging if you're reading in publication order, since it was published simultaneously with the Mage Storms series. If you're following publication order, in theory you should interleave the two series, but I hate doing that. I'm therefore reading it after Mage Winds and before Mage Storms. We'll see whether that was a good idea when I get to the next series. You could, if you really wanted to, read this series before any other Valdemar book. As a prequel from the deep past of Valdemar's world, it doesn't depend on the other series, and you'll get a rediscovery of lost knowledge feel from later books. The downside is that it's a rather boring introduction, and that order would spoil a lot of the revelatory flow of the other series (particularly Elspeth's adventures in the Mage Winds books). I'm now getting into the Valdemar books that I've only read once. I've been putting off continuing my Valdemar re-read because this series was next and I remember being rather bored with it the first time I read it. But I'm re-reading for the world-building and background as much as for the characters, and this is a huge chunk of world background that fills in the bones underneath Winds of Fate and its sequels. Here's why Dhorisha is a crater, here's why the Pelagiris forests are such a mess, here's where Ma'ar starts, here's the origin of both the gryphons and K'Leshya, and here, finally, we get to see the legendary Urtho on the page. The problem with writing novels set in the epic backstory of your universe is that it's hard to live up to the drama that readers have invented for themselves. A lot of The Black Gryphon is background to events Valdemar readers already know will happen, creating a corresponding lack of surprise. I reached the end of the book and said "yup, that's pretty much what everyone said had happened." Lackey and Dixon do try to do some interesting things here, one of which being the backgrounding of the war. The Black Gryphon starts in the middle of a long-running conflict between Urtho and Ma'ar and doesn't follow the generals or the battles. The protagonists, instead, are a kestra'chern (a type of psychiatrist and spiritual healer who also uses sex, with the expected conflicts of people who incorrectly think of them as prostitutes) and the eventual leader of the gryphons (Skandranon, who is referenced in later books and who provides the title). We get some combat scenes from Skandranon and later another gryphon, but a lot of the book is Amberdrake fighting the effects of the war instead of the details of the war itself. There's a deep and moving story in that idea, and in some of the attached love stories that play out in the army camps. There's also a great story somewhere around Urtho: a brilliant but detached mage who is way out of his depth trying to run an army but smart enough to gather good people around him. He's also a creator of new life, including the gryphons. The Black Gryphon tries to talk about Urtho's paternalism, the weird emotional currents of his relationship with his creations, and the places Urtho keeps things from others for, supposedly, their own good. If this book had looked a bit deeper at the support structure for an army that's trying to be humane, or at the ways in which Urtho strays far too close to being an abusive tyrant through inaction despite having the best of intentions at every step, I think it could have said something significant. Unfortunately, that's not this book. This book is full of relentlessly black and white morality (the flaw of much of the Valdemar series) that bleaches away interesting shades of grey. Urtho is good and wise by authorial fiat, and Ma'ar is the same utterly irredeemable force of evil that he is in other books. The story skitters over Urtho's odd tyrannies, making them all better with the pure power of friendship and good intentions. There just isn't much emotional depth, and while I don't expect that of Lackey in general, this story really needed that depth to work. What we get instead is repetition, as Lackey and Dixon hit the same emotional notes with Amberdrake repeatedly. This is one of those books that makes me wonder if Lackey was trying to write too many novels in a short time than was good for their individual quality. (Collaborations often mean that the lesser-known name is doing all the work, but Dixon is Lackey's husband and the tone of the book is sufficiently Lackey that I don't think that happened here.) It felt padded by Amberdrake turning over the same emotional rocks repeatedly, to largely the same effect. This is, in short, not Lackey's finest effort, although it does have its moments. As always, Lackey is at her best when writing psychological healing narratives. Zhaneel's story is a bit too easy, but the dynamic between Amberdrake and Winterhart is the best part of the book. And The Black Gryphon does tell the reader exactly what led up to the Cataclysm and why. There are no major surprises, but there are some small ones, and it's a nice payoff for the lore-obsessed (like me). This is missable unless you want the full world-building behind Valdemar's past, and it's not the best writing. But if you're heavily invested in the Valdemar universe, it's at least readable and provides an important bit of the history. Followed by The White Gryphon. Rating: 5 out of 10

Review: Clean Sweep, by Ilona Andrews

Series:	Innkeeper Chronicles #1
Publisher:	NYLA
Copyright:	2013
ISBN:	1-62517-343-1
Format:	Kindle
Pages:	228

Dina owns a bed and breakfast in a small town in Texas. As the book opens, her neighbor's dogs are being killed by some beast. As far as Dina is concerned, this should be the problem of the local werewolf, given that this is his territory, and she takes him to task for apparently doing nothing about it. The werewolf doesn't take that well, nor wants to admit to being a werewolf, and reacts by threatening Dina. Given Dina's position and the nature of her bed and breakfast, that turns out to be ill-advised. At this point, you're doubtless thinking urban fantasy, and you're not exactly wrong. You're probably also thinking love interest, and you're not entirely wrong there either. The dead dogs are, of course, an early warning sign of an evil monster who has moved into the area and whose violence may escalate. And if I mention that a vampire shows up later in the story and the werewolf and vampire dislike each other at first sight, you'll probably start rolling your eyes. But this also isn't quite what it looks like on the surface. I'm going to gleefully spoil what you find out about a fifth of the way into the book, since it's what got me to buy this book: neither the werewolves nor the vampires are magical creatures. They're aliens. Werewolves are bio-engineered soldiers; vampires are members of a militaristic order with advanced technology and almost imperceptible circulatory systems. And Dina doesn't truly have a bed and breakfast. She maintains an inn: a refuge for aliens traveling on Earth, part of the secrecy that keeps them out of the eyes of normal humans, and an institution sworn to neutrality in local problems. Dina is straining the last part. The alien creatures who are hunting and killing her neighbors' pets aren't exactly threatening the inn, but she's not willing to stand idly by while her neighbors are threatened. It's a dangerous path, since her inn is struggling already. Failure to prioritize correctly and protect her guests might lower her inn's rating, possibly fatally. She's also without a guide ever since her parents (prominent innkeepers themselves) mysteriously disappeared. But she does have an inn. It may be a weaker one, coaxed out of dormancy and desperately in need of more visitors, but it still has considerable technological resources and other abilities that are indistinguishable from magic. It's also sentient, although more like a large animal than a person, and it knows its innkeeper. This is a light, straightforward sort of book that does not take itself particularly seriously, as you might have guessed. It is very aware of the conventions of urban fantasy and is both following them and intentionally poking fun at them. The authors (Ilona Andrews is a husband and wife writing team) play an impish game of wedging fantasy tropes into a science fiction framework, preserving much of the outward appearance while playing with the explanations. I particularly liked the clannish reworking of vampires into a sort of crusader knight, which works considerably better than it has any right to. Clean Sweep is at its best when the story seems to be going down well-trodden urban fantasy paths and then takes an abrupt right turn into science fiction: Dina going through a dimensional gate to an interstellar marketplace to stock up on weapons, for instance. Also, it has a sentient house. This is one of my favorite story elements ever, provided that the story isn't horror (which is all too often the case with sentient houses, but which is not at all the case here). I found the early parts of this book, during which Sean is insulting Dina and Dina is unimpressed but not doing anything about it, rather tedious. Thankfully, once Dina finally loses her patience and knocks some sense into him it gets a lot better. It never becomes great literature, but sometimes that's a feature. If you're in the mood for some urban fantasy with an adequate, if hand-waved, re-spun science fiction justification and an uncomplicated and loyal sentient house, I can wholeheartedly recommend Clean Sweep. I liked it better than I had expected to. Followed by Sweep in Peace. Rating: 7 out of 10

Here's what happened in the Reproducible Builds effort between Sunday October 15 and Saturday October 21 2017:

• The Tails project published a report on how they made their ISO images reproducible.
• dpkg 1.19.0 was uploaded, including support for:
  • Ordering the "unused substitution" warnings to prevent superfluous differences between logs of package builds on the Reproducible Builds test framework. (#870221)
  • A new Build-Kernel-Version field in .buildinfo files that can be generated with a new dpkg-genbuildinfo --always-include-kernel option. (#873937)

Past events

• On Saturday 21st October, Holger Levsen presented at All Systems Go! in Berlin, Germany on reproducible builds. A video recording is available already.

Upcoming events

• On Tuesday 24th October, Chris Lamb will present at All Things Open 2017 in Raleigh, NC, USA.
• On Wednesday 25th October, Holger Levsen will present at the Open Source Summit Europe in Prague, Czech Republic.
• On Saturday 28th October, Chris Lamb will present at freenode.live in Bristol, UK.
• From October 31st November 2nd we will be holding the 3rd Reproducible Builds summit in Berlin, Germany. If you are working in the field of reproducible builds, you should definitely attend. Please see our public invitation mail and contact us if you have any questions.

New York University sessions A three week session will be held at New York University to work on reproducibilty issues in conjunction with the reproducible builds community. Students from the Application Security course will be working for two weeks to work on the reproducible builds effort.

• On Tuesday 24th Oct Ed Maste from FreeBSD will be presenting some reproducible builds work for students.
• On From Tuesday 24th of October to Monday 7th of November students will work on fixing reproducibility issues brought up by the community. A milestone presentation will be held by Santiago Torres-Arias and Preston Moore.
• On Tuesday 7th November Holger Levsen will join the NYU team to wrap up the work.

Packages reviewed and fixed, and bugs filed

• Adrian Bunk:
  • #878883 filed against stoken.
  • #878896 filed against liquidsoap.
  • #878980 filed against belenios.
  • #879042 filed against tuxpaint-config.
  • #879223 filed against websockify.
• Chris Lamb:
  • #878707 filed against python-amqp (randomness in documentation).
  • #878708 filed against geographiclib (build paths).
  • #879169 filed against live-build (timestamps).
• Gilles Filippini:
  • #878818 filed against ovito.

The following reproducible builds-related NMUs were accepted:

• Chris Lamb:
  • gerstensaft (#777414)
  • miniupnpd (#860266)
  • rest2web (#833438)

Patches sent upstream:

• Bernhard M. Wiedemann:
  • singularity (tar+gz)
  • redis (date)
  • tbb (date)
  • nested (sort)
  • nested (date)

Reviews of unreproducible packages 41 package reviews have been added, 119 have been updated and 54 have been removed in this week, adding to our knowledge about identified issues. 2 issue types were removed as they were fixed:

• too_much_input_for_diff
• docbook_to_man_one_byte_delta

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

• Aaron M. Ucko (1)
• Adrian Bunk (49)
• Anthony DeRobertis (1)
• Daniel Schepler (1)
• Gilles Filippini (1)
• James Cowgill (1)
• Matthias Klose (1)
• Matthias Klumpp (1)
• Nobuhiro Iwamatsu (1)

diffoscope development

• Ximin Luo:
  • Tentative support for for parallel diffs

strip-nondeterminism development Version 0.039-1 was uploaded to unstable by Chris Lamb. It included contributions already covered by posts of the previous weeks, including:

• Chris Lamb:
  • Clojure considers the .class file to be stale if it shares the same timestamp of the .clj. We thus adjust the timestamps of the .clj to always be younger. (#877418)
  • dh_strip_nondeterminism: Log which handler processed a file. (#876140)
  • bin/strip-nondeterminism: Print a warning in --verbose mode if no canonical time specified.
  • Use HTTPS URI in debian/watch.

reprotest development

• Ximin Luo:
  • Hopefully fix the autopkgtest tests
• Santiago Torres-Arias:
  • An Arch Linux User Repository package for reprotest has been created.]

tests.reproducible-builds.org

• Holger Levsen:
  • Install rustc on Jenkins for the reproducible-html-build-path-prefix-map-spec job.
• Mattia Rizzolo:
  • health_check: Include the running kernel version when reporting multiple kernel installed in /boot.

Website updates

• Holger Levsen:
  • Berlin 2017:
    • add Qubes OS to participating projects
    • Add NetBSD and EdgeBSD to participating projects
    • Add repeatr.io to participating projects
    • Add disclaimer why only so few projects are listed
    • Add link to Google maps and name the 2nd next subway station on a different line
    • Add first 4 participating projects

Misc. This week's edition was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Santiago Torres & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Reproducible Builds Summit 3 next week in Berlin Next week from Tuesday, the 31st of October until Thursday, November 2nd, we'll have the 3rd Reproducible Builds summit in Berlin, to improve collaboration both between and inside projects, expand the scope and reach of reproducible builds to more projects and to brainstorm designs on tools enabling users to get the most benefits from reproducible builds. We're again expecting contributors from around twenty projects and we're still having some free seats available. If you want to join this meeting, please register by sending us a short mail briefly describing why (eg. by stating you involvement in some project). We also have some funding available to further rextend the diversity of our community, so please also contact us if you think you cannot make it for financial reasons! Personally I'm much looking forward to this event. The reproducible builds crowd is really a lovely bunch of people and thus I expect us to have some great discussions, some cool ideas and also some concrete actionable plans as a result of it. Totally worth it! Talk about Reproducible Builds at OSSE in Prague tomorrow Tomorrow, Wednesday, October 25th I'll be giving a talk at OSSE in Prague about the current status of Reproducible Builds and why we are not 'there' yet. I'd be glad to have a chat with you if you are there!

Review: Raven Stratagem, by Yoon Ha Lee

Series:	Machineries of Empire #2
Publisher:	Solaris
Copyright:	2017
ISBN:	1-78618-046-4
Format:	Kindle
Pages:	400

Raven Stratagem is the sequel to Ninefox Gambit and will make very little sense if you've not read the previous book. In fact, I'll add a rare warning, one that I wish I'd had and followed: you need to be deeply familiar with the details of the end of Ninefox Gambit or large chunks of this book will make no sense. I read the previous book earlier this year, but my memory of some of the specifics of the ending had slipped, and I ended up having to skim the ending of the previous book several times. Consider re-reading that bit before starting this book if you share my lack of memory for plot specifics and it's been more than a few months. I unfortunately can't provide a plot summary, since there's almost nothing I can say about the plot that doesn't spoil Ninefox Gambit. It is basically the story that you would expect from the very end of Ninefox Gambit, though, although the way it's carried out is not quite as dramatic as I was expecting. I wanted to like this book a great deal. Ninefox Gambit introduced a beautiful magitech system, but it was otherwise mostly setup and one extended battle. Its ending promised engagement with larger universe politics, and prospects of doing something about the deep unfairness of the current political system. I was hoping this book would contain the payoff of that escalation. It does deliver on that payoff, but something about it didn't quite work for me. The best description I've been able to come up with is that Raven Stratagem skitters. Some of this is an increase in the number of viewpoint characters, which made it harder for me to get into a reading rhythm with any of them. But most of it, I think, is that the characters have so many layers of deception, emotional shielding, weariness, and resignation that it's hard to find the true emotional beats of the story except in retrospect. I kept bouncing off surfaces, so many different and conflicting surfaces. This book is full of people who are not being honest with each other, or sometimes with themselves, and who are pretending to motives they don't really have. As a reader, I wanted to be placed in a privileged position where I could experience the character emotions even when they were lying about them. For good or ill, Raven Stratagem doesn't do that. There was also something about the dramatic structure of the story that didn't work for me. When describing the book to a friend, I said that the main plot climax was off-camera. In skimming the book again for this review, I found that wasn't the case, but it still felt that way. I think that's because, despite some event build-up, the emotional build-up wasn't in place for me, so I wasn't ready as a reader for the climax when it came. The build-up to the climax is partly sacrificed to keep the secrecy of a couple of long-awaited revelations. I very much enjoyed those revelations (one satisfying one was set up with Cheris's behavior at the start of Ninefox Gambit), but I wanted the catharsis of the climax as well. As written, the strongest emotional hit was from a somewhat ancillary climax, and that involved characters who mattered considerably less to me than Cheris. The climax also involves quite a lot of hand-waving. While some of that is expected in magitech, I would have liked to understand the mechanisms of what happened, not just the effects. Lee introduces several new viewpoint characters here, including two very contrasting Kel. I warmed to them by the end of the book, but I liked Cheris as a viewpoint character considerably better than either of them. Both of them spend most of this book in conditions of varying powerlessness; Cheris, despite difficult circumstances, was at least driving the plot. I can kind of see why Lee picked the viewpoint characters he did, but I still feel grumbly about it. I would have loved to have a servitor as a primary viewpoint character in this story. All that said, I'm still glad I read this book. The climax is satisfying, as is the growing respect of the characters and the growing realization of just how the universe is being changed. I wanted more of that on camera rather than being held for dramatic surprise, but I still savored it when it happened. The mechanisms of the Hexarchate, particularly formation instinct, are considerably creepier than Ninefox Gambit reveals, which is saying something, and yet oddly logical in their own magitech way. I liked all the pieces; I just wanted them to have more emotional oomph and momentum. Instead, I felt like I was bringing my own emotion to the story rather than letting the story sweep me away, which meant being more analytical and less engrossed than I prefer to be in a novel. I'm still going to read the third book, though. By the end of Raven Stratagem, Lee has set most of the scenery on fire, and I want to see what sort of world rises from the flames. Rating: 6 out of 10

Today it s my first day working at the Wikimedia Foundation, the non-profit foundation behind well-known projects like Wikipedia and others. This is a full-time, remote job as part of the Wikimedia Cloud Services team, as Operations Engineer. I will be working with modern infrastructure/hosting technologies such as OpenStack and Kubernetes to provide support to the Wikimedia movement and community. All contributors of the movement that provide value to the Wikimedia movement are welcome to use our resources. The recruitment process took several months and was really challenging, 6 or 7 interviews with different people with, of course, heavy technical checks. The Wikimedia Foundation has been always in my radar due to 2 facts:

1. They serve a very relevant mission, commited to freedom of knowledge, community colaboration, focusing in the benefit that this provides to the society.
2. They have a huge infrastructure/technological deployment which, among other things, allows Wikipedia to be one of the TOP5-TOP10 websites.

This new job is a big challenge for me and I m a bit nervous. I feel like this is a big step forward in my professional career and I will try to do my best :-) My new email address is aborrero@wikimedia.org. You can find me in IRC freenode as well, nick arturo. Great times ahead! :-)

Here s my weekly report for week 42 of 2017. In this week I have replaced my spacebar, failed to replace a HDD and begun the process to replace my YubiKey.

Debian Eariler in the week I blogged about powerline-taskwarrior . There is a new upstream version available that includes the patches I had produced for Python 2 support and I have filed #879225 to remind me to package this. The state of emscripten is still not great, and as I don t have the time to chase this up and I certainly don t have the time to fix it myself, I ve converted the ITP for csdr to an RFP. As I no longer have the time to maintain map.debian.net, I have released this domain name and published the sources behind the service.

• Bugs opened: #879225

Tor Project There was a request to remove the $ from family fingerprint on Atlas. These actually come from Onionoo and we have decided to fix this in Onionoo, but I did push a small fix for Atlas this week that makes sure that Atlas doesn t care if there are $ prefixes or not. I requested that a Trac component be created for metrics-bot. I wrote a seperate post about metrics-bot. I also attended the weekly metrics team meeting.

• Bugs opened: #23926, #23929, #23933, #23934, #23935, #23936, #23937, #23938, #23939, #23941

Sustainability I believe it is important to be clear not only about the work I have already completed but also about the sustainability of this work into the future. I plan to include a short report on the current sustainability of my work in each weekly report. I have not had any free software related expenses this week. The current funds I have available for equipment, travel and other free software expenses remains 60.52. I do not believe that any hardware I rely on is looking at imminent failure. I do not find it likely that I ll be travelling to Cambridge for the miniDebConf as the train alone would be around 350 and hotel accomodation a further 600 (to include both me and Ana).

Narabu is a new intraframe video codec. You probably want to read part 1 and part 2 first. Now having a rough idea of how the GPU works, it's obvious that we need our codec to split the image into a lot of independent chunks to be parallel; we're aiming for about a thousand chunks. We'll also aim for a format that's as simple as possible; other people can try to push the frontiers on research, I just want something that's fast, reasonably good, and not too hard to implement. First of all, let's look at JPEG. It works by converting the image to Y'CbCr (usually with subsampled chroma), split each channel into 8x8 blocks, DCT them, quantize and then use Huffman coding to encode those coefficients. This is a very standard structure, and JPEG, despite being really old by now, is actually hard to beat, so let's use that as a template. But we probably can't use JPEG wholesale. Why? The answer is that the Huffman coding is just too serial. It's all just one stream, and without knowing where the previous symbol ends, we don't know where to start decoding the next. You can partially solve this by having frequent restart markers, but these reduce coding efficiency, and there's no index of them; you'd have to make a parallel scan for them, which is annoying. So we'll need to at least do something about the entropy coding. Do we need to change anything else to reach our ~1000 parallel target? 720p is the standard video target these days; the ~1M raw pixels would be great if we could do all of them independently, but we obviously can't, since DCT is not independent per pixel (that would sort of defeat the purpose). However, there are 14,400 DCT blocks (8x8), so we can certainly do all the DCTs in parallel. Quantization after that is trivially parallelizable, at least as long as we don't aim for trellis or the likes. So indeed, it's only entropy coding that we need to worry about. Since we're changing entropy coding anyway, I picked rANS, which is confusing but has a number of neat properties; it's roughly as expensive as Huffman coding, but has an efficiency closer to that of arithmetic encoding, and you can switch distributions for each symbol. It requires a bit more calculation, but GPUs have plenty of ALUs (a typical recommendation is 10:1 calculation to memory access), so that should be fine. I picked a pretty common variation with 32-bit state and 8-bit I/O, since 64-bit arithmetic is not universally available on GPUs (I checked a variation with 64-bit state and 32-bit I/O, but it didn't really matter much for speed). Fabian Giesen has described how you can actually do rANS encoding and decoding in parallel over a warp, but I've treated it as a purely serial operation. I don't do anything like adaptation, though; each coefficient is assigned to one out of four rANS static distributions that are signaled at the start of each stream. (Four is a nice tradeoff between coding efficiency, L1 cache use and the cost of transmitting the distributions themselves. I originally used eight, but a bit of clustering showed it was possible to get it down to four at basically no extra cost. JPEG does a similar thing, with separate Huffman codes for AC and DC coefficients. And I've got separate distributions for luma and chroma, which also makes a lot of sense.) The restart cost of rANS is basically writing the state to disk; some of that we would need to write even without a restart, and there are ways to combine many such end states for less waste (I'm not using them), but let's be conservative and assume we waste all of it for each restart. At 150 Mbit/second for 720p60, the luma plane of one frame is about 150 kB. 10% (15 kB) sounds reasonable to sacrifice to restarts, which means we can have about 3750 of them, or one for each 250th pixel or so. (3750 restarts also means 3750 independent entropy coding streams, so we're still well above our 1000 target.) So the structure is more or less clear; we'll DCT the blocks in parallel (since an 8x8 block can be expressed as 8 vertical DCTs and then 8 horizontal DCTs, we can even get 8-way parallelism there), and then encode at least 250 coefficients into an rANS stream. I've chosen to let a stream encompass a single coefficient from each of 320 DCT blocks instead of all coefficients from 5 DCT blocks; it's sort of arbitrary and might be a bit unintuitive, but it feels more natural, especially since you don't need to switch rANS distributions for each coefficient. So that's a lot of rambling for a sort-of abstract format. Next time we'll go into how decoding works. Or encoding. I haven't really made up my mind yet.

UNIX distributions used to come with the system source code in /usr/src. This is a concept which fascinates me: if you want to change something in any part of your system, just make your change in the corresponding directory, recomile, reinstall, and you can immediately see your changes in action. So, I decided I wanted to build a tool which can give you the impression of that, without the downsides of additional disk space usage and slower update times because of /usr/src maintenance. The result of this effort is a tool called pk4 (mnemonic: get me the package for ) which I just uploaded to Debian. What distinguishes this tool from an apt source call is the combination of a number of features:

• pk4 defaults to the version of the package which is installed on your system. This means when installing the resulting packages, you won t be forced to upgrade your system in case you re not running the latest available version.
  In case the package is not installed on your system, the candidate (see apt policy) will be used.
• pk4 tries hard to resolve the provided argument(s): you can specify Debian binary package names, Debian source package names, or file paths on your system (in which case the owning package will be used).
• pk4 comes with tab completion for bash and zsh.
• pk4 caps the disk usage of the checked out packages by deleting the oldest ones after crossing a limit (default: 2GiB).
• pk4 allows users to enable supplied or shipped-with-pk4 hooks, e.g. git-init.
  The git-init hook in particular results in an experience that reminds of dgit, and in fact it might be useful to combine the two tools in some way.
• pk4 optimizes for low latency of each operation.
• pk4 respects your APT configuration, i.e. should work in company intranets.
• tries hard to download source packages, with fallback to snapshot.debian.org.

If you don t want to wait for the package to clear the NEW queue, you can get it from here in the meantime:

wget https://people.debian.org/~stapelberg/pk4/pk4_1_amd64.deb
sudo apt install ./pk4_1_amd64.deb

You can find the sources and issue tracker at https://github.com/Debian/pk4. Here is a terminal screencast of the tool in action, availing the sources of i3, applying a patch, rebuilding the package and replacing the installed binary packages:

Narabu is a new intraframe video codec, from the Japanese verb narabu ( ), which means to line up or be parallel. Let me first state straight up that Narabu isn't where I hoped it would be at this stage; the encoder isn't fast enough, and I have to turn my attention to other projects for a while. Nevertheless, I think it is interesting as a research project in its own right, and I don't think it should stop me from trying to write up a small series. :-) In the spirit of Leslie Lamport, I'll be starting off with describing what problem I was trying to solve, which will hopefully make the design decisions a lot clearer. Subsequent posts will dive into background information and then finally Narabu itself. I want a codec to send signals between different instances of Nageru, my free software video mixer, and also longer-term between other software, such as recording or playout. The reason is pretty obvious for any sort of complex configuration; if you are doing e.g. both a stream mix and a bigscreen mix, they will naturally want to use many of the same sources, and sharing them over a single GigE connection might be easier than getting SDI repeaters/splitters, especially when you have a lot of them. (Also, in some cases, you might want to share synthetic signals, such as graphics, that never existed on SDI in the first place.) This naturally leads to the following demands:

• Intraframe-only; every frame must be compressed independently. (This isn't strictly needed for all use cases, but is much more flexible, and common in any kind of broadcast.)
• Need to handle 4:2:2 color, since that's what most capture sources give out, and we want to transmit the raw signals as much as possible. Fairly flexible in input resolution (divisible by 16 is okay, limited to only a given set of resolutions is not).
• 720p60 video in less than one CPU core (ideally much less); the CPU can already pretty be busy with other work, like x264 encoding of the finished stream, and sharing four more inputs at the same time is pretty common. What matters is mostly a single encode+decode cycle, so fast decode doesn't help if the encoder is too slow.
• Target bitrates around 100-150 Mbit/sec, at similar quality to MJPEG (ie. 45 dB PSNR for most content). Multiple signals should fit into a normal GigE link at the same time, although getting it to work over 802.11 isn't a big priority.
• Both encoder and decoder robust to corrupted or malicious data; a dropped frame is fine, a crash is not.
• Does not depend on uncommon or expensive hardware, or GPUs from a specific manufacturer.
• GPLv3-compatible implementation. I already link to GPLv3 software, so I don't have a choice here; I cannot link to something non-free (and no antics with dlopen(), please).

There's a bunch of intraframe formats around. The most obvious thing to do would be to use Intel Quick Sync to produce H.264 (intraframe H.264 blows basically everything else out of the sky in terms of PSNR, and QSV hardly uses any power at all), but sadly, that's limited to 4:2:0. I thought about encoding the three color planes as three different monochrome streams, but monochrome is not supported either. Then there's a host of software solutions. x264 can do 4:2:2, but even on ultrafast, it gobbles up an entire core or more at 720p60 at the target bitrates (mostly in entropy coding). FFmpeg has implementations of all kinds of other codecs, like DNxHD, CineForm, MJPEG and so on, but they all use much more CPU for encoding than the target. NDI would seem to fit the bill exactly, but fails the licensing check, and also isn't robust to corrupted or malicious data. (That, and their claims about video quality are dramatically overblown for any kinds of real video data I've tried.) So, sadly, this leaves only really one choice, namely rolling my own. I quickly figured I couldn't beat the world on CPU video codec speed, and didn't really want to spend my life optimizing AVX2 DCTs anyway, so again, the GPU will come to our rescue in the form of compute shaders. (There are some other GPU codecs out there, but all that I've found depend on CUDA, so they are NVIDIA-only, which I'm not prepared to commit to.) Of course, the GPU is quite busy in Nageru, but if one can make an efficient enough codec that one stream can work at only 5% or so of the GPU (meaning 1200 fps or so), it wouldn't really make a dent. (As a spoiler, the current Narabu encoder isn't there for 720p60 on my GTX 950, but the decoder is.) In the next post, we'll look a bit at the GPU programming model, and what it means for how our codec needs to look like on the design level.

It has been ages that I haven t updated the MegaUpdate package for Kobo. Now that a new and seemingly rather bug-free and quick firmware release (4.6.9995) has been released, I finally took the time to update the whole package to the latest releases of all the included items. The update includes all my favorite patches and features: Kobo Start Menu, koreader, coolreader, pbchess, ssh access, custom dictionaries, and some side-loaded fonts. So what are all these items:

• firmware (thread): the basic software of the device, shipped by Kobo company
• Metazoa firmware patches (thread): fix some layout options and functionalities, see below for details.
• Kobo Start Menu (V08, update 5b thread): a menu that pops up before the reading software (nickel) starts, which allows to start alternative readers (like koreader) etc.
• KOreader (koreader-nightly-20171004, thread): an alternative document reader that supports epub, azw, pdf, djvu and many more
• pbchess and CoolReader (2017.10.14, thread): a chess program and another alternative reader, bundled together with several other games
• kobohack (web site): I only use the ssh server
• ssh access (old post: makes a full computer from your device by allowing you to log into it via ssh
• custom dictionaries (thread): this fix updates dictionaries from the folder customdicts to the Kobo dictionary folder. For creating your own Japanese-English dictionary, see this blog entry
• side-loaded fonts: GentiumBasic and GentiumBookBasic, Verdana, DroidSerif, and Charter-eInk

Install procedure Download Mark6 Kobo GloHD firmware: Kobo 4.6.9995 for GloHD Mega update: Kobo-4.6.9995-combined/Mark6/KoboRoot.tgz Mark5 Aura firmware: Kobo 4.6.9995 for Aura Mega update: Kobo-4.6.9995-combined/Mark5/KoboRoot.tgz Mark4 Kobo Glo, Aura HD firmware: Kobo 4.6.9995 for Glo and AuraHD Mega update: Kobo-4.6.9995-combined/Mark4/KoboRoot.tgz Latest firmware Warning: Sideloading or crossloading the incorrect firmware can break/brick your device. The link below is for Kobo GloHD ONLY. The first step is to update the Kobo to the latest firmware. This can easily be done by just getting the latest firmware from the links above and unpacking the zip file into the .kobo directory on your device. Eject and enjoy the updating procedure. Mega update Get the combined KoboRoot.tgz for your device from the links above and put it into the .kobo directory, then eject and enjoy the updating procedure again. After this the device should reboot and you will be kicked into KSM, from where after some time of waiting Nickel will be started. If you consider the fonts too small, select Configure, then the General, and add item, then select kobomenuFontsize=55 and save. Remarks to some of the items included The full list of included things is above, here are only some notes about what specific I have done.

• Metazoa firmware patches Included patches from the Metazoa firmware patches:

  Custom left & right margins
  Fix three KePub fullScreenReading bugs
  Change dicthtml strings to micthtml
  Default ePub monospace font (Courier)
  Custom reading footer style
  Dictionary pop-up frame size increase
  Increase The Cover Size In Library
  Increasing The View Details Container
  New home screen increasing cover size
  Reading stats/Author name cut when the series is showing bug fix 
  New home screen subtitle custom font
  Custom font to Collection and Authors names
  

  If you need/want different patches, you need to do the patching yourself.
• kobohack-h Kobohack (latest version 20150110) originally provided updated libraries and optimizations, but unfortunately it is now completely outdated and using it is not recommended for the library part. I only include the ssh server (dropbear) so that connections to the Kobo via ssh.
• ssh fixes See the detailed instructions here, the necessary files are already included in the mega upload. It updates the /etc/inittab to run also /etc/init.d/rcS2, and this one again starts the inetd server and run user supplied commands in /mnt/onboard/run.sh which is where your documents are.
• Custom dictionaries The necessary directories and scripts are already included in the above combined KoboRoot.tgz, so nothing to be done but dropping updated, fixed, changed dictionaries into your Kobo root into the directory customdict. After this you need to reboot to get the actual dictionaries updated. See this thread for more information. The adaptions and script mentioned in this post are included in the mega update.

WARNINGS If this is the first time you install this patch, you to fix the password for root and disable telnet. This is an important step, here are the steps you have to take (taken from this old post):

1. Turn on Wifi on the Kobo and find IP address
   Go to Settings Connect and after this is done, go to Settings Device Information where you will see something like
IP Address: 192.168.1.NN
   (numbers change!)
2. telnet into your device
   telnet 192.168.1.NN
   it will ask you the user name, enter root (without the quotes) and no password
3. (ON THE GLO) change home directory of root
   edit /etc/passwd with vi and change the entry for root by changing the 6th field from: / to /root (without the quotes). After this procedure the line should look like
   root::0:0:root:/root:/bin/sh
   don t forget to save the file
4. (ON THE GLO) create ssh keys for dropbear
   [root@(none) ~]# mkdir /etc/dropbear
[root@(none) ~]# cd /etc/dropbear
[root@(none) ~]# dropbearkey -t dss -f dropbear_dss_host_key
[root@(none) ~]# dropbearkey -t rsa -f dropbear_rsa_host_key
5. (ON YOUR PERSONAL COMPUTER) check that you can log in with ssh
   ssh root@192.168.1.NN
   You should get dropped into your device again
6. (ON THE GLO) log out of the telnet session (the first one you did)
   [root@(none) ~]# exit
7. (ON THE GLO) in your ssh session, change the password of root
   [root@(none) ~]# passwd
   you will have to enter the new password two times. Remember it well, you will not be easily able to recover it without opening your device.
8. (ON THE GLO) disable telnet login
   edit the file /etc/inetd.conf.local on the GLO (using vi) and remove the telnet line (the line starting with 23).
9. restart your device

The combined KoboRoot.tgz is provided without warranty. If you need to reset your device, don t blame me!

Here's what happened in the Reproducible Builds effort between Sunday October 8 and Saturday October 14 2017: Upcoming events

• On Saturday 21st October, Holger Levsen will present at All Systems Go! in Berlin, Germany on reproducible builds.
• On Tuesday 24th October, Chris Lamb will present at All Things Open 2017 in Raleigh, NC, USA on reproducible builds.
• On Wednesday 25th October, Holger Levsen will present at the Open Source Summit Europe in Prague, Czech Republic on reproducible builds.
• From October 31st - November 2nd we will be holding the 3rd Reproducible Builds summit in Berlin. If you are working in the field of reproducible builds, you should totally be there. Please contact us if you have any questions! Quoting from the public invitation mail:

  These dates are inclusive, ie. the summit will be 3 full days from "9 to 5".
  Best arrive on Monday October 30th and leave on the evening of Thursday, 3rd
  at the earliest.
  Meeting content
  ===============
  The exact content of the meeting is going to be shaped by the
  participants, but here are the main goals:
   - Update & exchange about the status of reproducible builds in various
     projects.
   - Establish spaces for more strategic and long-term thinking than is possible
     in virtual channels.
   - Improve collaboration both between and inside projects.
   - Expand the scope and reach of reproducible builds to more projects.
   - Brainstorming / Designing several things, eg:
    - designing tools enabling end-users to get the most benefits from
      reproducible builds.
    - design of back-ends needed for that.
   - Work together and hack on solutions.
  There will be a huge variety of topics to be discussed. To give a few
  examples:
  - continuing design and development work on .buildinfo infrastructure
  - build-path issues everywhere
  - future directions for diffoscope, reprotest & strip-nondeterminism
  - reproducing signed artifacts such as RPMs
  - discussing formats and tools we can share
  - sharing proposals for standards and documentation helpful to spreading the
    reproducible effort
  - and many many more.
  Please think about what you want discuss, brainstorm & learn about at this
  meeting!
  Schedule
  ========
  Preliminary schedule for the three days:
  9:00 Welcome and breakfast
  9:30 Meeting starts
  12:30 Lunch
  17:00 End of the official schedule
  Gunner and Beatrice from Aspiration will help running the meeting. We will
  collect your input in subsequent emails to make the best of everyone's time.
  Feel free to start thinking about what you want to achieve there. We will also
  adjust topics as the meeting goes.
  Please note that we are very likely to spend large parts of the meeting away
  from laptops and closer to post-it notes. So make sure you've answered any
  critical emails *before* Tuesday morning! :)
  

Reproducible work in other projects Pierre Pronchery reported that that he has built the foundations for doing more reproducibility work in NetBSD. Packages fixed Upstream bugs and patches:

• Bernhard M. Wiedemann:
  • qutim used RANDOM which is unpredictable and unreproducible.
  • dpdk used locale-dependent sort.

Reproducibility non-maintainer uploads in Debian:

• Chris Lamb:
  • mailfront for bugs #777431 & #847020.
  • plib-doc for bugs #778971 & #557676.
  • ipsvd for bugs #777417 & #846890.
• Holger Levsen
  • keyutils for bug #828681.

QA fixes in Debian:

• Adrian Bunk:
  • #878329 filed against sonic-visualiser.
  • #878333 filed against tree-puzzle.

Reviews of unreproducible packages 6 package reviews have been added, 30 have been updated and 37 have been removed in this week, adding to our knowledge about identified issues. Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by:

• Adrian Bunk (40)
• Eric Valette (1)
• Markus Koschany (1)

diffoscope development

• Ximin Luo:
  • Containers: diff the metadata of containers in one central location in the code, so that deep-diff works between all combinations of different container types. This lets us finally close #797759.
  • Tests: add a complete set of cases to test all pairs of container types.
• Chris Lamb:
  • Temporarily skip the test for ps2ascii(1) in ghostscript > 9.21 which now outputs text in a slightly different format.
  • UI wording improvements.

reprotest development Version 0.7.3 was uploaded to unstable by Ximin Luo. It included contributions already covered by posts of the previous weeks, as well as new ones:

• Ximin Luo:
  • Add a --env-build option for testing builds under different sets of environment variables. This is meant to help the discussion over at #876055 about how we should deal with different types of environment variables in a stricter definition of reproducibility.
  • UI and logging tweaks and improvements.
  • Simplify the _shell_ast module and merge it into shell_syn.

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