This post is long past due, but I figured it is better late than never. At the start of the year, I set a goal to get more involved with attending and speaking at conferences. Through work, I was able to attend the Southern California Linux Expo (SCALE) in Pasadena, CA in January. I also got to give a talk at O'Relly's Open Source Convention (OSCON) in Austin, TX in May. However, I really wanted to give a talk about my experience contributing in the Ubuntu community. Jos Antonio Rey encouraged me to submit the talk to FOSSCON. While I've been aware of FOSSCON for years thanks to my involvement with the freenode IRC network (which has had a reference to FOSSCON in the /motd for years), I had never actually attended it before. I also wasn't quite sure how I would handle traveling from San Francisco, CA to Philadelphia, PA. Regardless, I decided to go ahead and apply. Fast forward a few weeks, and imagine my surprise when I woke up to an email saying that my talk proposal was accepted. People were actually interested in me and what I had to say. I immediately began researching flights. While they weren't crazy expensive, they were still more money than I was comfortable spending. Luckily, Jos had a solution to this problem as well; he suggested applying for funding through the Ubuntu Community Donations fund. While I've been an Ubuntu Member for over 8 years, I've never used this resource before. However, I was happy when I received a very quick approval. The conference itself was smaller than I was expecting. However, it was packed with lots of friendly and familiar faces of people I've interacted with online and in person over the years at various Open Source events. I started off the day by learning from Jos how to use Juju to quickly setup applications in the cloud. While Juju has definitely come a long way over the last couple of years, and it appears t be quite easy to learn and use, it still appears to be lacking some of the features needed to take full control over how the underlying applications interact with each other. However, I look forward to continuing to watch it grow and mature. Net up, we had a lunch break. There was no catered lunch at this conference, so we decided to get some cheesesteak at Abner's (is any trip to Philadelphia complete without cheesesteak?). Following lunch, I took some time to make a few last minute changes to my presentation and rehearse a bit. Finally, it was time. I got up in front of the audience and gave my presentation. Overall, I was quite pleased. It was not perfect, but for the first time giving the talk, I thought it went pretty well. I will work hard to make it even better for next tme. Following my talk was a series of brief lightning talks prior to the closing keynote. Another long time friend of mine, Elizabeth Krumbach Joseph, was giving the keynote about listening to the needs of your global open source community. While I have seen her speak on several other occassions, I really enjoyed this particular talk. It was full of great examples and anecdotes that were easy for the audience to relate to and start applying to their own communities. After the conference, a few of us went off and played tourist, paying the Liberty Bell a visit before concluding our trip in Philadelpha. Overall, I had a great time as FOSSCON. It was great being re-united with so many friends. A big thank you to Jos for his constant support and encouragement and to Canonical and the Ubuntu Community for helping to make it possible for me to attend this conference. Finally, thanks to the terrific FOSSCON staff for volunteering so much time to put on this great event.

It is the first of October and that means the transition freeze is roughly one month away (Nov 5th 2016). In other words, this is the final boarding call for transitions . Other milestone dates:

• If you want new packages into Stretch, you have about 3 months (Jan 5th 2017). This includes auto removed packages.
• Automatic updates of existing packages stop in 4 months (Feb 5th 2017)

Filed under: Debian, Release-Team

Review: Sailing to Sarantium, by Guy Gavriel Kay

Series:	Sarantine Mosaic #1
Publisher:	HarperPrism
Copyright:	1998
Printing:	January 2000
ISBN:	0-06-105990-0
Format:	Mass market
Pages:	533

Crispin is a well-respected mosaicist, a Rhodian, heir to a long tradition of artistic accomplishment. Rhodias is largely in ruins, and the kings that fight over its land are far removed from the emperors of Rhodias at its height, but there's still demand for skilled craftsmanship. Crispin has a partner, assistants, and the opportunity to do at least adequate work. It's not a bad life, or at least wasn't before plague took his wife and daughters while he watched, helpless. Now, he's closed off, angry, and consumed by fatalism and futility. His partner, Martinian, could never say why, when the imperious and obnoxious courier came from the far-off and half-legendary of Sarantium to summon him to assist with the rebuilding of the Sanctuary of Jad, he pretended not to be himself and pointed the courier at Crispin instead. Nor was Crispin entirely sure why he played along, although the courier was so arrogant and officious that he invited such treatment. He had no intention of going in Martinian's place and name until his friends intervened, united in their conviction that he needed something to focus on and a reason to live. But nothing about Sarantium is simple. Even before Crispin leaves, the local queen, precariously balancing between warring factions, reveals her own reason to send Crispin to the capital of the far-off empire: using him as a desperate messenger to propose an alliance through marriage. And when he finally arrives, after unexpected perils on the road, he tumbles immediately into the deep complexities of the Sarantine court and its remarkable rulers. Most of Guy Gavriel Kay's work is historical fiction with the serial numbers partly filed off and some magic added. The degree to which the serial numbers are removed varies by work; here, the history is obvious. Sarantium is Byzantium, fallen Rhodias is Rome, and the emperor Valerius and his former dancer empress Alixana are clearly Justinian and Theodora. Knowing that will provide a lot of context, but can also be distracting, since the temptation to scramble for Wikipedia and line things up with real history is strong. I read this book the first time without knowing the history and this second time knowing it. I think I enjoyed it a bit more on its own terms, instead of as a reflection and reinterpretation. Either way, though, it's one of Kay's best novels, which is saying quite a bit. Sailing to Sarantium has two very different parts: Crispin's journey to Sarantium, and then what happens when he arrives. The first is a fairly linear travel narrative mixed with old religion, magic, and an experience in the woods that's a little disconnected from the rest of the story. The second is the fast-entangling politics and factionalism of the city itself, which wastes no time pulling Crispin into meetings with the most influential people at court. In my memory, I liked the Sarantium narrative the best, and found the travel story less significant. Re-reading, I'm not sure I agree with my earlier self. Kay does write some of the best conversations in fiction; if you want to see careful verbal maneuvering or gut reactions with wide-ranging consequences, I can't think of any author who shows both the words and the nuances as well as Kay. He makes the court maneuvering feel truly epic. Watching Crispin's blunt competence cut through the Sarantine court, and seeing him stay focused on his life work despite all those distractions, is a truly rewarding experience. But that second part of the book also has some structural problems, and a few characterization problems. The structural problem is that Kay wants to tell the same story from multiple angles, viewpoints, and timelines to show the reader every implication of the hornet's nest that Crispin kicks over, since quite a lot happens in the course of one day and night. This mostly works, but it is so laden with flashbacks, foreshadowing, and rewinds that I started losing track of the time relationship between the scenes. Kay is a very skilled author, so he avoids confusing the reader entirely, but I think he still tried too complex of a temporal structure here. The characterization problem is that I previously wasn't paying as close of attention to Kay's portrayal of women and of male sexual reactions to women. It didn't bother me before; this time, it started getting on my nerves. Yes, this is historical fiction (although limitations on roles for women in history is rather overstated in fiction), and to give Kay credit it does feature a very strong female character in Alixana. But the male protector and female seducer dynamic is very strong, and all the women in this book seem to get shoehorned into it. And perhaps I'm missing some weakness that other men have, but I have never had the sort of overwhelming, thought-destroying reaction to the presence of a seductive woman as Kay's men seem to routinely have in this book. To give Crispin credit, he maneuvers his way through those conversations without doing anything stupid. (Kay's characters very rarely do stupid things, which is refreshing.) But the effort required started undermining my suspension of disbelief. Even making allowances for a culture that might consider a woman with her hair down the equivalent of an entirely nude woman, I simply don't believe that a man who had been married with two daughters, had a long career, and had the life experience Crispin had would have that much difficulty with an aggressively seductive woman that he already doesn't trust. As a result, as much as I love Kay's political conversational fencing, I enjoyed the travel portion of the book more on this re-read. Crispin is a type of character Kay writes extremely well: an honest, honorable man trying to navigate unfamiliar waters without a lot of context, but with a firm sense of internal morality, a lot of natural intelligence, and a true passion for something. At one point in this book, another character decides to walk away from his current job and follow Crispin wherever he goes. Kay makes you believe that and want to do it yourself. It's a very rewarding experience as a reader to watch a character you can trust find careful, courageous, and tricky solutions to complicated problems. But I think the best part of this book is Kay's ability to put Crispin's art, the creation of mosaics, on the page in a way that lets the reader viscerally appreciate it. Crispin is passionate about mosaics, about how to make them and how to think about them, and the passion is contagious and forms the heart and soul of this novel. Kay manages to make mosaics overshadow some of the most dramatic politics in history, which says quite a lot. There is almost nothing I love more than reading about talented, passionate people doing things they are extremely good at. I know nothing about mosaic that I haven't read in this book and its sequel, so I have no basis from which to judge the accuracy of Kay's portrayal, but he made me feel like I could appreciate some of the nuance, skill, and design constraints of the art form. It's a wonderful reading experience. Sailing to Sarantium is best thought of half of a long book that was divided for publication reasons, so don't expect much of an ending here. It can only be read in combination with Lord of Emperors, which you'll want to have on hand when you finish this book so that you can continue the story. Followed by Lord of Emperors. Rating: 9 out of 10

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

• Fixed a number of instances in the Django web development framework where methods had mutable defaults arguments such as lists or dictionaries. (#7253)
• Made a large number of improvements to travis.debian.net, my hosted service for projects that host their Debian packaging on GitHub to use the Travis CI continuous integration platform to test builds on every update:
  • Worked with Evgeni Golov to run autopkgtest and autodep8 tests after builds. (#23, #24 & #25)
  • Ensured that all remote branches are created locally so that packages that specify options such as pristine_tar=True in debian/gbp.conf work as expected. (commit)
  • Fixed an issue where checking out other branches did not reliably not work due to Travis cloning the repository with --depth=50. (#21)
  • Updated the documentation after prompting from Valerie Young. (db7238 & 470d24)
• Improved my Chrome extension for the FastMail web interface to collapse whitespace when appending to the subject. (#9)
• Submitted a pull request for the Handbrake video transcoder to make the build reproducible. (#320)
• Updated the configuration for my OpenWRT-based router (a device I use as a range extender and to save tedious reconfiguration of all my wifi devices in new locales) to enter a "fallback" mode if it cannot connect to the client network. This works around a longstanding "wontfix" upstream issue. (diff)
• Updated django-agpl, my reusable Django application to assist in releasing projects under the GNU Affero General Public License:
  • Merged support from defivelo to support Django 1.8. (#1)
  • Improved the code quality & testability throughout the package. (diff)
• Filed in issue in Mailvelope (a browser extension for OpenPGP encryption) to support composing/viewing messages in a fixed-width font. (#422)
• Blogged about how to write your first Lintian check as well as on the progress bar I added to Diffoscope.

---

Previously: v4.4. Some things I found interesting in the Linux kernel v4.5: CONFIG_IO_STRICT_DEVMEM The CONFIG_STRICT_DEVMEM setting that has existed for a long time already protects system RAM from being accessible through the /dev/mem device node to root in user-space. Dan Williams added CONFIG_IO_STRICT_DEVMEM to extend this so that if a kernel driver has reserved a device memory region for use, it will become unavailable to /dev/mem also. The reservation in the kernel was to keep other kernel things from using the memory, so this is just common sense to make sure user-space can t stomp on it either. Everyone should have this enabled. (And if you have a system where you discover you need IO memory access from userspace, you can boot with iomem=relaxed to disable this at runtime.) If you re looking to create a very bright line between user-space having access to device memory, it s worth noting that if a device driver is a module, a malicious root user can just unload the module (freeing the kernel memory reservation), fiddle with the device memory, and then reload the driver module. So either just leave out /dev/mem entirely (not currently possible with upstream), build a monolithic kernel (no modules), or otherwise block (un)loading of modules (/proc/sys/kernel/modules_disabled). ptrace fsuid checking Jann Horn fixed some corner-cases in how ptrace access checks were handled on special files in /proc. For example, prior to this fix, if a setuid process temporarily dropped privileges to perform actions as a regular user, the ptrace checks would not notice the reduced privilege, possibly allowing a regular user to trick a privileged process into disclosing things out of /proc (ASLR offsets, restricted directories, etc) that they normally would be restricted from seeing. ASLR entropy sysctl Daniel Cashman standardized the way architectures declare their maximum user-space ASLR entropy (CONFIG_ARCH_MMAP_RND_BITS_MAX) and then created a sysctl (/proc/sys/vm/mmap_rnd_bits) so that system owners could crank up entropy. For example, the default entropy on 32-bit ARM was 8 bits, but the maximum could be as much as 16. If your 64-bit kernel is built with CONFIG_COMPAT, there s a compat version of the sysctl as well, for controlling the ASLR entropy of 32-bit processes: /proc/sys/vm/mmap_rnd_compat_bits. Here s how to crank your entropy to the max, without regard to what architecture you re on:

for i in "" "compat_"; do f=/proc/sys/vm/mmap_rnd_$ i bits; n=$(cat $f); while echo $n > $f ; do n=$(( n + 1 )); done; done

strict sysctl writes Two years ago I added a sysctl for treating sysctl writes more like regular files (i.e. what s written first is what appears at the start), rather than like a ring-buffer (what s written last is what appears first). At the time it wasn t clear what might break if this was enabled, so a WARN was added to the kernel. Since only one such string showed up in searches over the last two years, the strict writing mode was made the default. The setting remains available as /proc/sys/kernel/sysctl_writes_strict. seccomp UM support Micka l Sala n added seccomp support (and selftests) for user-mode Linux. Moar architectures! seccomp NNP vs TSYNC fix Jann Horn noticed and fixed a problem where if a seccomp filter was already in place on a process (after being installed by a privileged process like systemd, a container launcher, etc) then the setting of the no new privs flag could be bypassed when adding filters with the SECCOMP_FILTER_FLAG_TSYNC flag set. Bypassing NNP meant it might be possible to trick a buggy setuid program into doing things as root after a seccomp filter forced a privilege drop to fail (generally referred to as the sendmail setuid flaw ). With NNP set, a setuid program can t be run in the first place. That s it! Next I ll cover v4.6 Edit: Added notes about iomem=

2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Categories:

• Debian-Blog
• Tools

Keywords:

• Laptop Mode Tools
• power saving

Like:

The Background Story A year ago, or so, I took some time to search the internet for Free Software that can be used for controlling model railways via a computer. I was happy to find Rocrail [1] being one of only a few applications available on the market. And even more, I was very happy when I saw that it had been licensed under a Free Software license: GPL-3(+). A month ago, or so, I collected my old M rklin (Digital) stuff from my parents' place and started looking into it again after +15 years, together with my little son. Some weeks ago, I remembered Rocrail and thought... Hey, this software was GPLed code and absolutely suitable for uploading to Debian and/or Ubuntu. I searched for the Rocrail source code and figured out that it got hidden from the web some time in 2015 and that the license obviously has been changed to some non-free license (I could not figure out what license, though). This made me very sad! I thought I had found a piece of software that might be interesting for testing with my model railway. Whenever I stumble over some nice piece of Free Software that I plan to use (or even only play with), I upload this to Debian as one of the first steps. However, I highly attempt to stay away from non-free sofware, so Rocrail has become a no-option for me back in 2015. I should have moved on from here on... Instead... Proactively, I signed up with the Rocrail forum and asked the author(s) if they see any chance of re-licensing the Rocrail code under GPL (or any other FLOSS license) again [2]? When I encounter situations like this, I normally offer my expertise and help with such licensing stuff for free. My impression until here already was that something strange must have happened in the past, so that software developers choose GPL and later on stepped back from that decision and from then on have been hiding the source code from the web entirely. Going deeper... The Rocrail project's wiki states that anyone can request GitBlit access via the forum and obtain the source code via Git for local build purposes only. Nice! So, I asked for access to the project's Git repository, which I had been granted. Thanks for that. Trivial Source Code Investigation... So far so good. I investigated the source code (well, only the license meta stuff shipped with the source code...) and found that the main COPYING files (found at various locations in the source tree, containing a full version of the GPL-3 license) had been replaced by this text:

Copyright (c) 2002 Robert Jan Versluis, Rocrail.net
All rights reserved.
Commercial usage needs permission.

The replacement happened with these Git commits:

commit cfee35f3ae5973e97a3d4b178f20eb69a916203e
Author: Rob Versluis <r.j.versluis@rocrail.net>
Date:   Fri Jul 17 16:09:45 2015 +0200
    update copyrights
commit df399d9d4be05799d4ae27984746c8b600adb20b
Author: Rob Versluis <r.j.versluis@rocrail.net>
Date:   Wed Jul 8 14:49:12 2015 +0200
    update licence
commit 0daffa4b8d3dc13df95ef47e0bdd52e1c2c58443
Author: Rob Versluis <r.j.versluis@rocrail.net>
Date:   Wed Jul 8 10:17:13 2015 +0200
    update

Getting in touch again, still being really interested and wanting to help... As I consider such a non-license as really dangerous when distributing any sort of software, be it Free or non-free Software, I posted the below text on the Rocrail forum:

Hi Rob,
I just stumbled over this post [3] [link reference adapted for this
blog post), which probably is the one you have referred to above.
It seems that Rocrail contains features that require a key or such
for permanent activation.  Basically, this is allowed and possible
even with the GPL-3+ (although Free Software activists will  not
appreciate that). As the GPL states that people can share the source
code, programmers can  easily deactivate license key checks (and
such) in the code and re-distribute that patchset as they  like.
Furthermore, the current COPYING file is really non-protective at
all. It does not really protect   you as copyright holder of the
code. Meaning, if people crash their trains with your software, you  
could actually be legally prosecuted for that. In theory. Or in the
U.S. ( ;-) ). Main reason for  having a long long license text is to
protect you as the author in case your software causes t trouble to
other people. You do not have any warranty disclaimer in your COPYING
file or elsewhere. Really not a good idea.
In that referenced post above, someone also writes about the nuisance
of license discussions in  this forum. I have seen various cases
where people produced software and did not really care for 
licensing. Some ended with a letter from a lawyer, some with some BIG
company using their code  under their copyright holdership and their
own commercial licensing scheme. This is not paranoia,  this is what
happens in the Free Software world from time to time.
A model that might be much more appropriate (and more protective to
you as the author), maybe, is a  dual release scheme for the code. A
possible approach could be to split Rocrail into two editions:  
Community Edition and Professional/Commercial Edition. The Community
Edition must be licensed in a  way that it allows re-using the code
in a closed-source, non-free version of Rocrail (e.g.   MIT/Expat
License or Apache2.0 License). Thus, the code base belonging to the
community edition  would be licensed, say..., as Apache-2.0 and for
the extra features in the Commercial Edition, you  may use any
non-free license you want (but please not that COPYING file you have
now, it really  does not protect your copyright holdership).
The reason for releasing (a reduced set of features of a) software as
Free Software is to extend  the user base. The honey jar effect, as
practise by many huge FLOSS projects (e.g. Owncloud,  GitLab, etc.).
If people could install Rocrail from the Debian / Ubuntu archives
directly, I am  sure that the user base of Rocrail will increase.
There may also be developers popping up showing  an interest in
Rocrail (e.g. like me). However, I know many FLOSS developers (e.g.
like me) that  won't waste their free time on working for a non-free
piece of software (without being paid).
If you follow (or want to follow) a business model with Rocrail, then
keep some interesting  features in the Commercial Edition and don't
ship that source code. People with deep interest may  opt for that.
Furthermore, another option could be dual licensing the code. As the
copyright holder of Rocrail  you are free to juggle with licenses and
apply any license to a release you want. For example, this  can be
interesing for a free-again Rocrail being shipped via Apple's iStore. 
Last but not least, as you ship the complete source code with all
previous changes as a Git project  to those who request GitBlit
access, it is possible to obtain all earlier versions of Rocrail. In 
the mail I received with my GitBlit credentials, there was some text
that  prohibits publishing the  code. Fine. But: (in theory) it is
not forbidden to share the code with a friend, for local usage.  This
friend finds the COPYING file, frowns and rewinds back to 2015 where
the license was still  GPL-3+. GPL-3+ code can be shared with anyone
and also published, so this friend could upload the  2015-version of
Rocrail to Github or such and start to work on a free fork. You also
may not want  this.
Thanks for working on this piece of software! It is highly
interesing, and I am still sad, that it  does not come with a free
license anymore. I won't continue this discussion and move on, unless
you  are interested in any of the above information and ask for more
expertise. Ping me here or directly  via mail, if needed. If the
expertise leads to parts of Rocrail becoming Free Software again, the 
expertise is offered free of charge ;-).
light+love
Mike

Wow, the first time I got moderated somewhere... What an experience! This experience now was really new. My post got immediately removed from the forum by the main author of Rocrail (with the forum's moderator's hat on). The new experience was: I got really angry when I discovererd having been moderated. Wow! Really a powerful emotion. No harassment in my words, no secrets disclosed, and still... my free speech got suppressed by someone. That feels intense! And it only occurred in the virtual realm, not face to face. Wow!!! I did not expect such intensity... The reason for wiping my post without any other communication was given as below and quite a statement to frown upon (this post has also been "moderately" removed from the forum thread [2] a bit later today):

Mike,
I think its not a good idea to point out a way to get the sources back to the GPL periode.
Therefore I deleted your posting.

(The phpBB forum software also allows moderators to edit posts, so the critical passage could have been removed instead, but immediately wiping the full message, well...). Also, just wiping my post and not replying otherwise with some apology to suppress my words, really is a no-go. And the reason for wiping the rest of the text... Any Git user can easily figure out how to get a FLOSS version of Rocrail and continue to work on that from then on. Really. Now the political part of this blog post... Fortunately, I still live in an area of the world where the right of free speech is still present. I found out: I really don't like being moderated!!! Esp. if what I share / propose is really noooo secret at all. Anyone who knows how to use Git can come to the same conclusion as I have come to this morning. [Off-topic, not at all related to Rocrail: The last votes here in Germany indicate that some really stupid folks here yearn for another this time highly idiotic wind of change, where free speech may end up as a precious good.] To other (Debian) Package Maintainers and Railroad Enthusiasts... With this blog post I probably close the last option for Rocrail going FLOSS again. Personally, I think that gate was already closed before I got in touch. Now really moving on... Probably the best approach for my new train conductor hobby (as already recommended by the woman at my side some weeks back) is to leave the laptop lid closed when switching on the train control units. I should have listened to her much earlier. I have finally removed the Rocrail source code from my computer again without building and testing the application. I neither have shared the source code with anyone. Neither have I shared the Git URL with anyone. I really think that FLOSS enthusiasts should stay away from this software for now. For my part, I have lost my interest in this completely... References

• [1] http://wiki.rocrail.net/doku.php
• [2] http://forum.rocrail.net/viewtopic.php?t=12400&f=31#p125938
• [3] http://forum.rocrail.net/viewtopic.php?f=44&t=9848&p=93248&hilit=Lizenz#...

light+love,
Mike

What happened in the Reproducible Builds effort between Sunday September 4 and Saturday September 10 2016: Reproducible work in other projects Python 3.6's dictonary type now retains the insertion order. Thanks to themill for the report. In coreboot, Alexander Couzens committed a change to make their release archives reproducible. Patches submitted

• #836609 filed against nostalgy by Chris Lamb.
• #836605 filed against torque by Chris Lamb.
• #836968 filed against erlang-p1-oauth2 by Chris Lamb.
• #836970 filed against erlang-p1-sqlite3 by Chris Lamb.
• #836817 filed against tj3 by Chris Lamb.
• #836969 filed against erlang-p1-xmlrpc by Chris Lamb.

Reviews of unreproducible packages We've been adding to our knowledge about identified issues. 3 issue types have been added:

• random_id_in_pdf_generated_by_dblatex
• captures_execution_time
• captures_home_dir

1 issue type has been updated:

• Expand comment for random_id_in_pdf_generated_by_dblatex

16 have been have updated:

• Add patch for nostalgy
• Add patch for torque
• Expand comment for babl.
• Tag pbuilder with random_id_in_pdf_generated_by_dblatex
• Tag uclibc with users_and_groups_in_tarball
• Tag realmd with different_encoding_in_html_by_docbook_xsl
• Tag mrmpi with timestamps_in_documentation_generated_by_htmldoc
• Tag dynare with leaks_path_environment_variable
• Tag sdlgfx with timestamps_in_tarball
• Tag pantomime1.2 with plist_weirdness
• Tag blockattack with different_due_to_umask
• Tag expeyes with different_pot_creation_date_in_gettext_mo_files
• Tag android-platform-frameworks-data-binding with random_ordering_in_pom
• Tag krunner with users_and_groups_in_tarball
• Tag libevocosm with leaks_path_environment_variable
• Tag gdbm with random_order_in_md5sums

13 have been removed, not including removed packages:

• htp fixed in/since 1.19-2
• Remove openni-sensor-pointclouds and openni-sensor-primesense; fixed by __DATE__ & __TIME__
• hsqldb fixed in/since 2.3.3+dfsg2-1
• linux-tools RM
• ksnapshot RM
• cobalt-panel-utils RM
• strigi RM
• libkdeedu RM
• erc RM
• ttf-atarismall RM
• gnupg-doc RM
• remove RMed django-localflavor
• easymp3gain RM

100s of packages have been tagged with the more generic captures_build_path, and many with captures_kernel_version, user_hostname_manually_added_requiring_further_investigation, user_hostname_manually_added_requiring_further_investigation, captures_shell_variable_in_autofoo_script, etc. Particular thanks to Emanuel Bronshtein for his work here. Weekly QA work FTBFS bugs have been reported by:

• Aaron M. Ucko (1)
• Chris Lamb (7)

diffoscope development

• Mattia Rizzolo:
  • Force LC_ALL=C.UTF-8 in basic-command-list autopkgtest so that diffoscope can always output something
• Ximin Luo:
  • html-dir: use 4 * the given max-diff-block-lines
  • difference: Don't truncate diff output by default, and use a separate flag when doing so
  • html-dir: In html-dir output, split large diffs across several child pages
  • Rename no-max-limits to no-default-limits, a more accurate name
  • Increase default max_diff_input_lines, should be OK based on what we've seen
  • Fix behaviour for max-diff-block-limit=1 and don't report when 0 lines are removed
  • Set limits to inf when parsing args, instead of checking for "> 0" everywhere
  • Suppress decimal line numbers for xxd output

strip-nondeterminism development

• Chris Lamb:
  • handlers/jar.pm: Reintroduce subroutine prototype on _jar_filename_cmp to fix ordering regression in .jar files.
  • bin/strip-nondeterminism: die if file does not exist (Closes: #800159)
  • t/fixtures/jar/*: Add a testcase for jar file ordering and normalisation.
  • t/fixtures.t:
    • Check that output matches expected before comparing attributes to make it less confusing on failure.
    • Don't test whether inode number has changed either.
    • Add a lookup table for descriptions of stat(1) indices.
    • Re-order @fixtures setup for global->specific ordering.
    • Re-add top-level "plan" call dropped in previous commit.
    • Align size check with atime, etc.
    • Make it clearer that we are checking for attributes
    • Add comment why we use a per-fixture temporary directory.
  • Drop all calls to unlink_on_destroy now that we copy the file. (Closes: #836670)
  • Extend testsuite to ensure no extra files are leftover again.

tests.reproducible-builds.org:

• F-Droid:
  • Hans-Christoph Steiner found after extensive debugging that for kvm-on-kvm, vagrant from stretch is needed (or a backport, but that seems harder than setting up a new VM).
• FreeBSD:
  • Holger updated the VM for testing FreeBSD to FreeBSD 10.3.

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

What happened in the Reproducible Builds effort between Sunday August 28 and Saturday September 3 2016: Media coverage Antonio Terceiro blogged about testing build reprodubility with debrepro . GSoC and Outreachy updates The next round is being planned now: see their page with a timeline and participating organizations listing. Maybe you want to participate this time? Then please reach out to us as soon as possible! Packages reviewed and fixed, and bugs filed The following packages have addressed reproducibility issues in other packages:

• ruby-ronn/0.7.3-5 by Antonio Terceiro, original patch by Chris Lamb.

The following updated packages have become reproducible in our current test setup after being fixed:

• check-all-the-things/2016.09.03 by Paul Wise, original patch by Chris Lamb.
• e2fsprogs/1.43.2-2 by Theodore Y. Ts'o.
• gnupg1/1.4.21-1 by Daniel Kahn Gillmor, #834755 by Chris Lamb.
• gnupg2/2.1.15-2 by Daniel Kahn Gillmor.
• inform6-compiler/6.33-2 by Ben Finney.
• libhat-trie/0.0~git25f9e946-2 by Sascha Steinbiss.
• mrd6/0.9.6-13 by Thomas Preud'homme, original patch by Reiner Herrmann.
• safecat/1.13-3 by Teemu Hukkanen, original patch by Reiner Herrmann.
• shibboleth-sp2/2.6.0+dfsg1-1 by Ferenc W gner.
• sweethome3d-furniture-editor/1.15-2 by Markus Koschany, original patch by Reiner Herrmann.
• traceroute/1:2.1.0-2 by Laszlo Boszormenyi, original patch by Reiner Herrmann.
• wise/2.4.1-19 by Sascha Steinbiss.
• xmltooling/1.6.0-2 by Ferenc W gner.

The following updated packages appear to be reproducible now, for reasons we were not able to figure out yet. (Relevant changelogs did not mention reproducible builds.)

• comitup/0.5-1 by David Steele.
• dita-ot/1.5.3-2 by Mathieu Malaterre.
• dput/0.10.2 by Ben Finney.
• gnome-settings-daemon/3.21.90-2 by Michael Biebl.
• libkf5kipi/4:16.08.0-1 by Pino Toscano.
• libmpc/2:0.1~r475-2 by James Cowgill.
• taurus/4.0.1+dfsg-1 by Picca Fr d ric-Emmanuel.
• tcpwatch-httpproxy/1.3.1-2 by Toni Mueller.

The following 4 packages were not changed, but have become reproducible due to changes in their build-dependencies:

• djangorestframework
• roarplaylistd
• zope-maildrophost
• zope-replacesupport

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

• amanda/1:3.3.9-1 by Jose M Calhariz.
• dispcalgui/3.1.6.0-2 by Christian Marillat, original patch by Chris Lamb.
• fastqtl/2.184+dfsg-4 by Dylan A ssi.
• grass/7.0.5~rc1-1~exp1 by Bas Couwenberg.
• kdevplatform/5.0-1 by Pino Toscano, original patch by Scarlett Clark.
• leveldb/1.19-1 by Alessio Treglia.
• libdevel-cover-perl/1.23-2 by gregor herrmann, original patch by Chris Lamb.
• linux/4.7.2-1 by Ben Hutchings, #830268 by Reiner Herrmann.
• lmms/1.1.3-4 by Javier Serrano.
• mayavi2/4.4.3-2.2 by Anton Gladky.
• opensaml2/2.6.0-2 by Ferenc W gner.
• perl/5.22.2-4 by Dominic Hargreaves, original patch and original patch by Chris Lamb.
• radare2/0.10.5+dfsg-1 by Sebastian Reichel, original patch by Chris Lamb.
• splint/3.1.2.dfsg1-3 by Rapha l Hertzog, original patch by Chris Lamb.

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

• #835673 filed against dacs by Chris Lamb.
• #835805 filed against dh-python by Chris Lamb.
• #835985 filed against nmh by Chris Lamb.
• #836609 filed against nostalgy by Chris Lamb.
• #835807 filed against pygtksourceview by Chris Lamb.
• #836004 filed against python-gflags by Chris Lamb.
• #835816 filed against rt-extension-customfieldsonupdate by Chris Lamb.
• #835834 filed against ruby-compass by Chris Lamb.
• #836605 filed against torque by Chris Lamb.
• #833176 filed against trafficserver by Reiner Herrmann.

Reviews of unreproducible packages 706 package reviews have been added, 22 have been updated and 16 have been removed in this week, adding to our knowledge about identified issues. 5 issue types have been added:

• timestamps_in_documentation_generated_by_ocamldoc
• timestamp_in_enc_files_added_by_texlive_fontinst
• cython_captures_build_path
• timestamps_in_perllocal_pod_manpages_generated_by_perl_extutils_mm_unix
• uname_output_in_python_debugging_symbols_caused_by_sysconfig_getplatform

1 issue type has been updated:

• timestamp_in_enc_files_added_by_texlive_fontinst

Weekly QA work FTBFS bugs have been reported by:

• Chris Lamb (8)
• Lucas Nussbaum (3)

diffoscope development diffoscope development on the next version (60) continued in git, taking in contributions from:

• Mattia Rizzolo:
  • Better and more thorough testing
  • Improvements to packaging
  • Improvements to the ppu comparator

strip-nondeterminism development Mattia Rizzolo uploaded strip-nondeterminism 0.023-2~bpo8+1 to jessie-backports. A new version of strip-nondeterminism 0.024-1 was uploaded to unstable by Chris Lamb. It included contributions from:

• Chris Lamb:
  • Improve code quality of zip, jar, ar, png processors
• AYANOKOUZI, Ryuunosuke:
  • Preserve file attribute information of target file (#836075)

Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches. disorderfs development Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches. tests.reproducible-builds.org Debian: We now vary the GECOS records of the two build users. Thanks to Paul Wise for providing the patch. Misc. This week's edition was written by Ximin Luo, Holger Levsen & Chris Lamb and reviewed by a bunch of Reproducible Builds folks on IRC.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. This months is rather light since I was away in vacation for two weeks. Kali related work The new pkg-security team is working full steam and I reviewed/sponsored many packages during the month: polenum, accheck, braa, t50, ncrack, websploit. I filed bug #834515 against sbuild since sbuild-createchroot was no longer usable for kali-rolling due to the embedded dash. That misfeature has been reverted and implemented through an explicit option. I brought the attention of ftpmasters on #832163 since we had unexpected packages in the standard section (they have been discovered in the Kali live ISO while we did not want them). I uploaded two fontconfig NMU to finally push to Debian a somewhat cleaner fix for the problem of various captions being displayed as squares after a font upgrade (see #828037 and #835142). I tested (twice) a live-build patch from Adrian Gibanel Lopez implementing EFI boot with grub and merged it into the official git repository (see #731709). I filed bug #835983 on python-pypdf2 since it has an invalid dependency forbidding co-installation with python-pypdf. I orphaned splint since its maintainer was missing in action (MIA) and immediately made a QA upload to fix the RC bug which kicked it out of testing (this package is a build dependency of a Kali package). django-jsonfield I wrote a patch to make python-django-jsonfield compatible with Django 1.10 (#828668) and I committed that patch in the upstream repository. Distro Tracker I made some changes to make the codebase compatible with Django 1.10 (and added Django 1.10 to the tox test matrix). I added a Debian Maintainer Dashboard link next to people s name on request of Lucas Nussbaum (#830548). I made a preliminary review of Paul Wise s patch to add multiarch hints (#833623) and improved the handling of the mailbot when it gets MIME Headers referencing an unknown charset (like cp-850 , Python only knows of cp850 ) I also helped Peter Palfrader to enabled a .onion address for tracker.debian.org, see onion.debian.org for the full list of services available over Tor. Misc stuff I updated my letsencrypt.sh salt formula to work with the latest version of letsencrypt.sh (0.2.0) I merged updated translations for the Debian Administrator s Handbook from weblate.org and uploaded a new version to Debian. Thanks See you next month for a new summary of my activities.

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

The seventh update in the 0.12.* series of Rcpp just arrived on the CRAN network for GNU R as well as in Debian. This 0.12.7 release follows the 0.12.0 release from late July, the 0.12.1 release in September, the 0.12.2 release in November, the 0.12.3 release in January, the 0.12.4 release in March, the 0.12.5 release in May, and the 0.12.6 release in July --- making it the eleventh release at the steady bi-montly release frequency. Keeping with the established pattern, this is again more of a maintenance release which addresses small bugs, nuisances or documentation issues without adding any major new features. One issue that got to a few people was our casual use of NORET in the definition of Rcpp::stop(). We had (ahem) overlooked that NORET is only defined by R 3.2.0 or later, and several folks trying to build on older releases of R (why?) got bitten. Well, at least we have a new record for most frequently reported bug ... Kidding aside, this is now fixed. Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 759 packages on CRAN depend on Rcpp for making analytical code go faster and further. That is up by well over fifty packages since the last release in mid-July! We are once again fortunate to have a number of pull request, from first-timers to regulars. James "coatless" Balamuta in particular relentlessly pushed for better documentation and cleanup of numerous dangling issue tickets. Artem Klevtsov also contributed again. Qiang, Kevin and I also got some changes in for the Rcpp Core team. More details are again below.

Changes in Rcpp version 0.12.7 (2016-09-04)

• Changes in Rcpp API:
  • The NORET macro is now defined if it was not already defined by R itself (Kevin fixing issue #512).
  • Environment functions get() & find() now accept a Symbol (James Balamuta in #513 addressing issue #326).
  • Several uses of Rf_eval were replaced by the preferred Rcpp::Rcpp_eval (Qiang in PR #523 closing #498).
  • Improved Autogeneration Warning for RcppExports (James Balamuta in #528 addressing issue #526).
  • Fixed invalid C++ prefix identifiers in auto-generated code (James Balamuta in #528 and #531 addressing issue #387; Simon Dirmeier in #548).
  • String constructors now set default UTF-8 encoding (Qiang Kou in #529 fixing #263).
  • Add variadic variants of the RCPP_RETURN_VECTOR and RCPP_RETURN_MATRIX macro when C++11 compiler used (Artem Klevtsov in #537 fixing #38).
• Changes in Rcpp build system
  • Travis CI is now driven via run.sh from our fork, and deploys all packages as .deb binaries using our PPA where needed (Dirk in #540 addressing issue #517).
• Changes in Rcpp unit tests
  • New unit tests for random number generators the R namespace which call the standalone Rmath library. (James Balamuta in #514 addressing issue #28).
• Changes in Rcpp Examples:
  • Examples that used cxxfunction() from the inline package have been rewritten to use either sourceCpp() or cppFunction() (James Balamuta in #541, #535, #534, and #532 addressing issue #56).

Thanks to CRANberries, you can also look at a diff to the previous release. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Some time ago, I built a static program that I wanted to run on an Android tablet. What was my surprise when I saw a message saying "FATAL: kernel too old". After some investigation, it turns out that GNU libc may assume some Linux features are present during build time. This means that given a minimum Linux version, that built libc might only work on that version or newer. Since 2014, GNU libc itself requires 2.6.32 as the minimum. Previously, it was 2.6.16, changed in 2012. Debian, as of 2015, builds it with a required minimum Linux version of 3.2. To give an idea about the history of these kernel releases, we have:

• December 2009, Linus releases Linux 2.6.32.
• November 2010, Red Hat releases RHEL 6.0, Linux 2.6.32.
• February 2011, Debian 6.0 Squeeze, Linux 2.6.32.
• January 2012, Linus releases Linux 3.2.
• April 2014, GNU Libc requires Linux 2.6.32.
• December 2015, Debian GNU Libc uploaded to unstable requires Linux 3.2.

So, at least for GNU libc upstream, it would appear that not many devices would stop being supported, though the situation would not be as good for binary versions of Debian. However, I have a small list of devices that might show otherwise.

• Nokia N900 shipped with Linux 2.6.28.
• Android emulator, a platform called Goldfish, uses Linux 2.6.29.
• The Wii port most widely tested is based on Linux 2.6.32.

Many Android devices have been shipped with Linux 3.4, but I encountered at least one using Linux 3.0. So, even though many new devices ship with newer versions of Linux, it's still possible to find some new and older devices using versions older than 3.2, and even versions older than 2.6.32 may be found. Another interesting note is that, without a few patches, it's not possible to build Linux 2.6.32 with GCC 5 and newer. For that and many other reasons, it's important that we update. For bug fixes, and so we can make progress and use better software are some of the other reasons. So, it's imperative that we have devices support upstream. Otherwise, the task of doing updates with forward porting becomes daunting. And that's the current state for many devices, which is why I have been trying to use new software with older versions of Linux. But as time passes, I realize how hard a task this is, as most new software these days, even a building block like GNU libc, requires ever new versions of Linux. For now, most gadgets I have support Linux 3.4 or newer. But not long ahead, that support will be dropped as well. And that means there will be no more updates for those devices. It's a consequence of both targeting time-to-market and programmed obsolescence as business practices. Upstream support is no priority, and maintenance is only that required until the next model is available on the stores. This is one more reason why we need to have more operating systems available for those devices. Systems that are designed to last more than a couple of years. As I said, upstream support is imperative, but as a step forward, I still believe we can provide the GNU experience to lots of devices out there.

Here is my monthly update covering what I have been doing in the free software world (previously):

• Worked on nsntrace, a userspace tool to perform network traces on processes using kernel namespaces:
  • Overhauled error handling to ensure the return code of the wrapped process is returned to the surrounding environment. (#10).
  • Permit the -u argument to also accept uids as well as usernames. (#16).
  • Always kill the (hard-looping) udp_send utility, even on test failures. (#13).
  • Updated configure.ac to look for iptables in /sbin & /usr/sbin (#11) and to raise an error if pcap.h is missing (#15).
  • Drop bashisms in #!/bin/sh script (#14) and ignore the generated manpage in the Git repository (#12).
• Independently discovered an regression in the Django web development framework where field__isnull=False filters were not working with some foreign keys, resulting in extending the testsuite and release documentation. (#7104).
• Proposed a change to django-enumfield (a custom field for type-safe constants) to ensure passing a string type to Enum.get returned None on error to match the documentation. (#36).
• Fixed an issue in the Mopidy music player's podcast extension where the testsuite was failing tests in extreme timezones. (#40).
• Proposed changes to make various upstream's reproducible:
  • botan, a crypto/TLS library for C++11. (#587).
  • cookiecutter, a project template generator, removing nondeterministic keyword arguments from appearing in the documentation. (#800).
  • pyicu, a Python wraper for the IBM Unicode library. (#27).
• Integrated a number of issues raised by @piotr1212 to python-fadvise, my Python interface to posix_fadvise(2), where the API was not being applied to open file descriptors (#1) and moving the .so to a module directory (#2).
• Various improvements to try.diffoscope.org, a hosted version of the diffoscope in-depth and content-aware diff utility, including introducing an HTTP API (#21), updating the SSL certificate and correcting a logic issue where errors in diffoscope itself were not being detected correctly (b0ff49). Continued thanks to Bytemark for sponsoring the hardware.
• Fixed a bug in django-slack, my library to easily post messages to the Slack group-messaging utility, correcting an EncodeError exception under Python 3 (#53) and updated the minimum required version of Django to 1.7 (#54).
• Various updates to tickle-me-email, my Getting Things Done-inspired email toolbox, to also match / in IMAP's LIST separators (#6) and to encode the folder list as UTF-7 (#7). Thanks to @resiak.
• Clarified the documentation for travis.debian.net my hosted script to easily test and build Debian packages on the Travis CI continuous integration platform regarding how to integrate with Github (#20).

---

Quite on schedule (just one day later), Weblate 2.7 is out today. This release brings Subversion support or improved zen mode. Full list of changes:

• Documentation improvements.
• Translations.
• Updated bundled javascript libraries.
• Added list_translators management command.
• Django 1.8 is no longer supported.
• Fixed compatibility with Django 1.10.
• Added Subversion support.
• Separated XML validity check from XML mismatched tags.
• Fixed API to honor HIDE_REPO_CREDENTIALS settings.
• Show source change in zen mode.
• Alt+PageUp/PageDown/Home/End now works in zen mode as well.
• Add tooltip showing exact time of changes.
• Add option to select filters and search from translation page.
• Added UI for translation removal.
• Improved behavior when inserting placeables.
• Fixed auto locking issues in zen mode.

If you are upgrading from older version, please follow our upgrading instructions. You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Aptoide, FreedomBox, Weblate itself and many other projects. Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English Gammu phpMyAdmin SUSE Weblate 0 comments

What happened in the Reproducible Builds effort between Sunday August 14 and Saturday August 20 2016: Fasten your seatbelts Important note: we enabled build path variation for unstable now, so your package(s) might become unreproducible, while previously it was said to be reproducible given a specific build path it probably still is reproducible but read on for the details below in the tests.reproducible-builds.org section! As said many times: this is still research and we are working to make it reality. Media coverage Daniel Stender blogged about python packaging and explained some caveats regarding reproducible builds. Toolchain developments Thomas Schmitt uploaded xorriso which now obeys SOURCE_DATE_EPOCH. As stated in its man pages:

ENVIRONMENT
[...]
SOURCE_DATE_EPOCH  belongs to the specs of reproducible-builds.org.  It
is supposed to be either undefined or to contain a decimal number which
tells the seconds since january 1st 1970. If it contains a number, then
it is used as time value to set the  default  of  --modification-date=,
--gpt_disk_guid,  and  --set_all_file_dates.  Startup files and program
options can override the effect of SOURCE_DATE_EPOCH.

Packages reviewed and fixed, and bugs filed The following packages have become reproducible after being fixed:

• cadencii/3.3.9+svn20110818.r1732-5 by Ying-Chun Liu, original patch by Chris Lamb.
• cfengine3/3.7.4-3 by Antonio Radici.
• findbugs/3.1.0~preview2-1 by Emmanuel Bourg.
• gcpegg/5.1-14 by Bdale Garbee, original patch by Chris Lamb.
• gnunet-gtk/0.10.1-4 by Bertrand Marc, original patch by Chris Lamb.
• konwert/1.8-12 by Yann Dirson, original patch by Chris Lamb.
• link-grammar/5.3.8-2 by Jeremy Bicha, original patch by Chris Lamb.
• metastudent-data/2.0.1-1 by Sascha Steinbiss.
• pixmap/2.6pl4-20 by Paul Slootman, original patch by Chris Lamb Maria Valentina Marin a.k.a. Akira.
• python-afl/0.5.4-2 by Daniel Stender.
• tf5/5.0beta8-6 by Russ Allbery, original patch by Chris Lamb.
• triplane/1.0.8-2 by Markus Koschanyover, original patch by Chris Lamb.
• vips/8.3.3-1 by Laszlo Boszormenyi, original patch by Chris Lamb.
• xzgv/0.9.1-4 by Theodore Y. Ts'o, original patch by Chris Lamb.

The following updated packages appear to be reproducible now, for reasons we were not able to figure out. (Relevant changelogs did not mention reproducible builds.)

• vulkan/1.0.21.0+dfsg1-1 by Timo Aaltonen.

The following 2 packages were not changed, but have become reproducible due to changes in their build-dependencies: tagsoup tclx8.4. Some uploads have addressed some reproducibility issues, but not all of them:

• cappuccino/0.5.1-4 by Breno Leitao, original patch by Chris Lamb.
• darkice/1.3-0.1 by Nicolas Bouleng.
• flask-restful/0.3.5-1 by Ond ej Nov , original patch by Chris Lamb.
• kodi/16.1+dfsg1-2 by Balint Reczey, original patch by Lukas Rechberger.
• libaws/3.3.2-3 by Nicolas Bouleng.
• liblog4ada/1.3-1 by Nicolas Bouleng.
• libxmlezout/1.06.1-8 by Nicolas Bouleng.
• ruby-rmagick/2.15.4+dfsg-2 by Antonio Terceir, original patch from Chris Lamb.
• taggrepper/0.05-2 by Kumar Appaiah, original patch and original patch from Maria Valentina Marin.
• xotcl/1.6.8-2 by Stefan Sobernig, original patch by Chris Lamb.

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

• #834755 against apt-cacher-ng by Chris Lamb.
• #834976 against auto-apt-proxy by Chris Lamb.
• #834549 against botan1.10 by Chris Lamb.
• #834861 against cookiecutter by Chris Lamb.
• #834779 against dicom3tools by Chris Lamb.
• #834859 against echoping by Chris Lamb.
• #834983 against eyed3 by Chris Lamb.
• #834735 against filepp by Chris Lamb.
• #834957 against flashrom by Chris Lamb.
• #834773 against gkrellm by Chris Lamb.
• #834292 against gr-radar by Chris Lamb.
• #834956 against ircd-irc2 by Chris Lamb.
• #834897 against jpy by Chris Lamb.
• #834452 against libdc0 by Chris Lamb.
• #834324 against libnss-ldap by Reiner Herrmann.
• #834945 against libquvi by Chris Lamb.
• #834534 against librep by Chris Lamb.
• #834537 against mozvoikko by Chris Lamb.
• #834857 against nagios-nrpe by Chris Lamb.
• #834316 against openocd by Reiner Herrmann.
• #834993 against oss4 by Reiner Herrmann.
• #834302 against pd-flite by Reiner Herrmann.
• #834754 against phpab by Chris Lamb.
• #834279 against phpldapadmin by Chris Lamb.
• #834277 against pybit by Chris Lamb.
• #834553 against pyicu by Chris Lamb.
• #834541 against ruby-pg by Chris Lamb.
• #835051 against sheepdog by Chris Lamb.
• #834896 against ttf-tiresias by Chris Lamb.
• #834780 against tuxpaint-config by Chris Lamb.
• #834988 against twitter-bootstrap3 by Chris Lamb.
• #834776 against uhub by Chris Lamb.
• #835061 against varnish by Chris Lamb.

Bug tracker house keeping:

• Chris Lamb pinged 164 bugs he filed more than 90 days ago which have a patch and had no maintainer reaction.

Reviews of unreproducible packages 55 package reviews have been added, 161 have been updated and 136 have been removed in this week, adding to our knowledge about identified issues. 2 issue types have been updated:

• Added user_in_documentation_generated_by_gsdoc
• Added locale_differences_in_pom

Weekly QA work FTBFS bugs have been reported by:

• Chris Lamb (16)
• Santiago Vila (2)

diffoscope development Chris Lamb, Holger Levsen and Mattia Rizzolo worked on diffoscope this week. Improvements were made to SquashFS and JSON comparison, the https://try.diffoscope.org/ web service, documentation, packaging, and general code quality. diffoscope 57, 58, and 59 were uploaded to unstable by Chris Lamb. Versions 57 and 58 were both broken, so Holger set up a job on jenkins.debian.net to test diffoscope on each git commit. He also wrote a CONTRIBUTING document to help prevent this from happening in future. From these efforts, we were also able to learn that diffoscope is now reproducible even when built across multiple architectures:

< h01ger>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope.html shows these packages were built on amd64:
< h01ger>    bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb
< h01ger>    366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb
< h01ger>   and on i386:
< h01ger>    bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb
< h01ger>    366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb
< h01ger>   and on armhf:
< h01ger>    bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb
< h01ger>    366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb

And those also match the binaries uploaded by Chris in his diffoscope 59 binary upload to ftp.debian.org, yay! Eating our own dogfood and enjoying it! tests.reproducible-builds.org Debian related:

• show percentage of results in the last 24/48h (h01ger)
• switch python database backend to SQLAlchemy (Valerie)
• vary build path varitation for unstable and experimental for all architectures. (h01ger)

The last change probably will have an impact you will see: your package might become unreproducible in unstable and this will be shown on tracker.debian.org, while it will still be reproducible in testing. We've done this, because we think reproducible builds are possible with arbitrary build paths. But: we don't think those are a realistic goal for stretch, where we still recommend to use .buildinfo to record the build patch and then do rebuilds using that path. We are doing this, because besides doing theoretical groundwork we also have a practical goal: enable users to independently verify builds. And if they only can do this with a fixed path, so be it. For now To be clear: for Stretch we recommend that reproducible builds are done in the same build path as the "original" build. Finally, and just for our future references, when we enabled build path variation on Saturday, August 20th 2016, the numbers for unstable were:

suite	all	reproducible	unreproducible	ftbfs	depwait	not for this arch	blacklisted
unstable/amd64	24693	21794 (88.2%)	1753 (7.1%)	972 (3.9%)	65 (0.2%)	95 (0.3%)	10 (0.0%)
unstable/i386	24693	21182 (85.7%)	2349 (9.5%)	972 (3.9%)	76 (0.3%)	103 (0.4%)	10 (0.0%)
unstable/armhf	24693	20889 (84.6%)	2050 (8.3%)	1126 (4.5%)	199 (0.8%)	296 (1.1%)	129 (0.5%)

Misc. Ximin Luo updated our git setup scripts to make it easier for people to write proper descriptions for our repositories. This week's edition was written by Ximin Luo and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

I gave a talk about the early days of Linux at the jubilee symposium arranged by the University of Helsinki CS department. Below is an outline of what I meant to speak about, but the actual talk didn't follow it exactly. You can compare these to the video once it comes online.

• Linus and I met at uni, the only 2 Swedish speaking new students that year, so we naturally migrated towards each other.
• After a year away for military service, got back in touch, summer of
  1. .
• C & Unix course fall of 1990; Minix.
• Linus didn't think atime updates in real time were plausible, but I showed him; funnily enough, atime updates have been an issue in Linux until fairly recently, since they slow things down (without being particularly useful)
• Jan 5, 1991 bought his first PC (i386 + i387 + 4 MiB RAM and a small hard disk); he had a Sinclair QL before that.
• Played Prince of Persia for a couple of months.
• Then wanted to learn i386 assembly and multitasking.
• A/B threading demo.
• Terminal emulation, Usenet access from home.
• Hard disk driver, mistaking hard disk for a modem.
• More ambition, announced Linux to the world for the first time
• first ever Linux installation.
• Upload to ftp.funet.fi, directory name by Ari Lemmke.
• Originally not free software, licence changed early 1992.
• First mailing list was created and introduced me to a flood of email (managed with VAX/VMS MAIL and later mush on Unix).
• I talked a lot with Linus about design at this time, but never really participated in the kernel work (partly because disagreeing with Linus is a high-stress thing).
• However, I did write the first sprintf for the kernel, since Linus hadn't learnt about varargs functions in C; he then ruined it and added the comment "Wirzenius wrote this portably..." (add google hit count for wirzenius+fucked).
• During 1992 Linux grew fast, and distros happened, and a lot of packaging and porting of software; porting was easier because Linus was happy to add/change things in the kernel to accomodate software
• A lot of new users during 1992 as well.
• End of 1992 I and a few others founded the Linux Documentation Project to help all the new users, some of who didn't come from a Unix background.
• In fact, things progressed so fast in 1992 that Linus thought he'd release 1.0 very soon, resulting in a silly sequence of version numbers: 0.12, 0.95, 0.96, 0.96b, 0.96c, 0.96c++2.
• X server ported to Linux; almost immediate prediction of the year of the Linux desktop never happening unless ALL the graphics cards were supported immediately.
• Linus was of the opinion that you needed one process (not thread) per window in X; I taught him event driven programming.
• Bug in network code, resulting in ban on uni network.
• Pranks in the shared office room.
• We released 1.0 in an event at the CS dept in March, 1994; this included some talks and a ritual compilation of the release version during the event.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. DebConf 16 I was in South Africa for the whole week of DebConf 16 and gave 3 talks/BoF. You can find the slides and the videos in the links of their corresponding page:

• Kali Linux s Experience of a Derivative Tracking Debian Testing
• 2 Years of Work of Paid Contributors in the Debian LTS Project
• Using Debian Money to Fund Debian Projects

I was a bit nervous about the third BoF (on using Debian money to fund Debian projects) but discussed with many persons during the week and it looks like the project evolved quite a bit in the last 10 years and while it s still a sensitive topic (and rightfully so given the possible impacts) people are willing to discuss the issues and to experiment. You can have a look at the gobby notes that resulted from the live discussion. I spent most of the time discussing with people and I did not do much technical work besides trying (and failing) to fix accessibility issues with tracker.debian.org (help from knowledgeable people is welcome, see #830213). Debian Packaging I uploaded a new version of zim to fix a reproducibility issue (and forwarded the patch upstream). I uploaded Django 1.8.14 to jessie-backports and had to fix a failing test (pull request). I uploaded python-django-jsonfield 1.0.1 a new upstream version integrating the patches I prepared in June. I managed the (small) ftplib library transition. I prepared the new version in experimental, ensured reverse build dependencies do still build and coordinated the transition with the release team. This was all triggered by a reproducible build bug that I got and that made me look at the package last time upstream had disappeared (upstream URL was even gone) but it looks like he became active again and he pushed a new release. I filed wishlist bug #832053 to request a new deblog command in devscripts. It should make it easier to display current and former build logs. Kali related Debian work I worked on many issues that were affecting Kali (and Debian Testing) users:

• I made an open-vm-tools NMU to get the package back into testing.
• I filed #830795 on nautilus and #831737 on pbnj to forward Kali bugs to Debian.
• I wrote a fontconfig patch to make it ignore .dpkg-tmp files. I also forwarded that patch upstream and filed a related bug in gnome-settings-daemon which is actually causing the problem by running fc-cache at the wrong times.
• I started a discussion to see how we could fix the synaptics touchpad problem in GNOME 3.20. In the end, we have a new version of xserver-xorg-input-all which only depends on xserver-xorg-input-libinput and not on xserver-xorg-input-synaptics (no longer supported by GNOME). This is after upstream refused to reintroduce synaptics support.
• I filed #831730 on desktop-base because KDE s plasma-desktop is no longer using the Debian background by default. I had to seek upstream help to find out a possible solution (deployed in Kali only for now).
• I filed #832503 because the way dpkg and APT manages foo:any dependencies when foo is not marked Multi-Arch: allowed is counter-productive I discovered this while trying to use a firefox-esr:any dependency. And I filed #832501 to get the desired Multi-Arch: allowed marker on firefox-esr.

Thanks See you next month for a new summary of my activities.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. Debian Android

• I improved apktool s wrapper script and replaced 1.apk with a symlink to the already existing framework-res.apk file. (#827646)
• For Kai-Chung I sponsored new upstream releases of android-platform-external-jsilver, android-platform-frameworks-data-binding and android-platform-libcore.
• I fixed two FTBFS bugs in android-platform-tools-base which were caused by a new upstream version of libhttpcore-java and a behavioral change in Gradle.
• I packaged a new upstream release of libsmali-java.

Debian Games

• This month GCC-6 bugs became release critical. I fixed and triaged those kind of bugs in games like supertransball2, berusky2, freeorion, bloboats, armagetronad and megaglest.
• I packaged new upstream releases of scorched3d, bzflag, spring, springlobby, freeorion, freeciv and extremetuxracer.
• Freeciv, one of the best strategy games ever by the way, also got a new binary package freeciv-client-gtk3. This package will eventually become the new default client to play the game in the future. You are welcome to test it.
• I packaged a new upstream release of adonthell and adonthell-data. This game is built with Python 3 and SDL 2 now and also uses the latest version of swig to generate its sources. We will probably see only one other future upstream release of adonthell because the main developer has decided to move on after more than 15 years of development.
• I fixed another RC bug in minetest, updated whichwayisup for this release cycle and moved the package to Git.

Debian Java

• My work in the Java Team this month was basically divided into two parts. I started with fixing RC bugs in httpcomponents-asyncclient, httpcomponents-client, libnb-platform18-java, jackrabbit, openjpa, libphonenumber (another GCC-6 RC-bug), osgi-compendium, commons-javaflow, apache-curator, assertj-core and avro-java.
• The second part revolved around jflex, a lexical analyzer generator for Java. Due to my work with gradle-jflex-plugin and libsmali-java, jflex got my attention and since it hasn t been updated in the last seven years, I felt that I had to do it now because it s always good being up-to-date. As usual in the Java world if you touch one package then you are almost always doomed to work on several follow up patches and updates. Of course the new upstream release of jflex broke several packages, so I fixed FTBFS bugs in gradle-jflex-plugin, libsmali-java, qdox, qdox2, cup and jhighlight.
• Rather relaxing was updating libcodesize-java for this release cycle and packaging a new upstream release of activemq.
• I sponsored jacoco for Kai-Chung.

Debian LTS This was my sixth month as a paid contributor and I have been paid to work 14,7 hours on Debian LTS. In that time I did the following:

• DLA-554-1. I spent most of the time this month on completing my work on libarchive. I issued DLA-554-1 and fixed 18 CVE plus another issue which was later assigned CVE-2016-6250.
• DLA-555-1. Issued a security update for python-django fixing 1 CVE.
• DLA-561-1. Issued a security update for uclibc fixing 3 CVE.
• DLA-562-1. Issued a security update for gosa fixing 1 CVE. I could triage another open CVE as not-affected after confirming that the issue had already been fixed two years ago.
• DLA-568-1. Issued a security update for wordpress fixing 6 CVE. I decided to go ahead with this update because I could not find any regressions. Unfortunately this wasn t true for my intended fix for CVE-2015-8834. The database upgrade did not succeed hence I decided to postpone the fix for CVE-2015-8834 until we can narrow down the issue.
• DLA-576-1. Issued a security update for libdbd-mysql-perl fixing 2 CVE.
• From 04. July to 10. July I was in charge of our LTS frontdesk. I triaged CVEs in librsvg, bind9, trn, pdns and drupal7 and answered questions on the debian-lts mailing list.

Misc and QA

• I fixed another GCC-6 bug in wbar, a light and fast launch bar.
• Childsplay and gvrng were orphaned last month. I updated both of them, fixed the RC-bug in childsplay (non-free font) and moved the packages to the Debian QA Group.

A while ago, it occurred to me that querying Debian Code Search seemed slow, which surprised me because I previously spent quite some effort on making it faster, see Debian Code Search Instant and Taming the latency tail for the most recent substantial architecture overhaul and related optimizations. Upon taking a closer look, I realized that while performing the search query on the server side was pretty fast, the perceived slowness was due to the client side being slow. By being slow , I mean that it took a long time until something was drawn on the screen (high latency) and that what was happening on the screen was janky (stuttering, not smooth). Part of that slowness was due to historical reasons: the client-side architecture was optimized for the use-case where users open Debian Code Search s index page and then submit a search query, but I was using Chrome s address bar to send a search query (type codesearch , then hit the TAB key). Further, we only added a non-JavaScript version after we launched the JavaScript version. Hence, the redirects and progressive enhancements we implemented are more of a kludge than a well thought out design. After this bit of original investigation, I opened GitHub issue #69 to track the work on making Debian Code Search faster. In that issue, I captured how Chrome s network inspector visualizes the work necessary to render the page: A couple of quick wins There are a couple of little fixes and improvements on which I m not going to spend too much time on, but which I list for completeness anyway just in case they come in handy for a similar project of yours:

• Remove css @import, unnecessary because we minify the two stylesheets together already.
• Compress assets using the gzip-compatible Z pfli algorithm (saves 3KB).
• Run SVG files through the svgo optimizer (saves 8KB).
• Use highly compressed/post-processed woff/woff2 webfont versions (gains such as 57KB 14KB for Roboto-Bold).
• Enabled HTTP/2 in nginx not a win by itself, but avoids further round trips in combination with the EventSource API (see below).

Bigger changes The URL pattern has changed. Previously, we had 2 areas of the website, one for JavaScript-compatible clients and one for the rest. When you hit the wrong one, you were redirected. In some areas, we couldn t tell which area is the correct one for you, so you would always incur a redirect: one example for this is the search bar. With the new URL pattern, we deliver both versions under the same URL: the elements only used by the JavaScript code are hidden using CSS by default, then made visible by JavaScript code. The elements only used by the non-JavaScript code are wrapped in a <noscript> tag. All CSS which is required for the initial page rendering is now inlined in the responses, allowing the browser to immediately render a response without requiring any additional round trips. All non-essential CSS has been moved into a separate CSS file which is loaded asynchronously. This is done using a pattern like <link rel="preload" href="foo.css" as="style" onload="this.rel='stylesheet'">, see also filamentgroup/loadCSS. We switched from WebSockets to the EventSource API because the former is not compatible with HTTP/2, whereas the latter is. This removes a round trip and some custom code for WebSocket reconnecting, because EventSource does that for you. The progress bar animation used to animate the background-position property. It turns out that browsers can only animate the position, scale, rotation and opacity properties smoothly, because such animations can be off-loaded to the GPU. Hence, we have re-implemented the progress bar animation using the position property. The biggest win for improving client-side latency from the Chrome address bar was introducing Service Workers (see commit 7f31aef402cb782056e290a797f224171f4af270). Our Service Worker caches static assets and a placeholder results page. The placeholder page is presented immediately when you start a search (e.g. from the address bar), making the first response immediate, i.e. rendered within 100ms. Having assets and the result page out of the way, the first round trip is used for actually doing the search, removing all unnecessary overhead. With all of these improvements in place, rendering latency goes down from half a second to well under 100 ms, and this is what the Chrome network inspector looks like:

One year ago (tomorrow) drat 0.1.0 was released. It held up rather well, but a number of small fixes and enhancements piled up, along with somewhat-finished to still-raw additions to the examples/ sections. With that, we are happy to announce drat release 0.1.1 which arrived on CRAN earlier today. drat stands for drat R Archive Template, and helps with easy-to-create and easy-to-use repositories for R packages. Since its inception in early 2015 it has found reasonably widespread adoption among R users because repositories is what we use. In other words, friends don't let friends use install_github(). Just kidding. Maybe. Or not. This version 0.1.1 builds on the previous release from one year ago. Several users sent in nicely focused pull request, and I added a bit of spit and polish here and there. The NEWS file (added belatedly in this release) summarises the release as follows:

Changes in drat version 0.1.1 (2016-08-07)

• Changes in drat functionality
  • Use dir.exists, leading to versioned Depends on R (>= 3.2.0)
  • Optionally pull remote before insert (Mark in PR #38)
  • Fix support for dots (Jan G. in PR #40)
  • Accept dots in package names (Antonio in PR #48)
  • Switch to htpps URLs at GitHub (Colin in PR #50)
  • Support additional fields in PACKAGE file (Jan G. in PR #54)
• Changes in drat documentation
  • Further improvements and clarifications to vignettes
  • Travis script switched to run.sh from our fork
  • This NEWS file was (belatedly) added

Courtesy of CRANberries, there is a comparison to the previous release. More detailed information is on the drat page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.