Debian Contributions: 2026-01 Contributing to Debian is part of Freexian s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

cross building, by Helmut Grohne In version 1.10.1, Meson merged a patch to make it call the correct g-ir-scanner by default thanks to Eli Schwarz. This problem affected more than 130 source packages. Helmut retried building them all and filed 69 patches as a result. A significant portion of those packages require another Meson change to call the correct vapigen. Another notable change is converting gnu-efi to multiarch, which ended up requiring changes to a number of other packages. Since Aurelien dropped the libcrypt-dev dependency from libc6-dev, this transition now is mostly complete and has resulted in most of the Perl ecosystem correctly expressing perl-xs-dev dependencies needed for cross building. It is these infrastructure changes affecting several client packages that this work targets. As a result of this continued work, about 66% of Debian s source packages now have satisfiable cross Build-Depends in unstable and about 10000 (55%) actually can be cross built. There are now more than 500 open bug reports affecting more than 2000 packages most of which carry patches.

rebootstrap, by Helmut Grohne Maintaining architecture cross-bootstrap requires continued effort for adapting to archive changes such as glib2.0 dropping a build profile or an e2fsprogs FTBFS. Beyond those generic problems, architecture-specific problems with e.g. musl-linux-any or sparc may arise. While all these changes move things forward on the surface, the bootstrap tooling has become a growing pile of patches. Helmut managed to upstream two changes to glibc for reducing its Build-Depends in the stage2 build profile and thanks Aurelien Jarno.

Refresh of the patch tagging guidelines, by Rapha l Hertzog Debian Enhancement Proposal #3 (DEP-3) is named Patch Tagging Guidelines and standardizes meta-information that Debian contributors can put in patches included in Debian source packages. With the feedback received over the years, and with the change in the package management landscape, the need to refresh those guidelines became evident. As the initial driver of that DEP, I spent a good day reviewing all the feedback (that I kept in a folder) and producing a new version of the document. The changes aim to give more weight to the syntax that is compatible with git format-patch s output, and also to clarify the expected uses and meanings of a couple of fields, including some algorithm that parsers should follow to define the state of the patch. After the announcement of the new draft on debian-devel, the revised DEP-3 received a significant number of comments that I still have to process.

Miscellaneous contributions

• Helmut uploaded debvm making it work with unstable as a target distribution again.
• Helmut modernized the code base backing dedup.debian.net significantly expanding the support for type checking.
• Helmut fixed the multiarch hinter once more given feedback from Fabian Gr nbichler.
• Helmut worked on migrating the rocblas package to forky.
• Rapha l fixed RC bug #1111812 in publican and did some maintenance for tracker.debian.org.
• Carles added support in the festival Debian package for systemd socket activation and systemd service and socket units. Adapted the patch for upstream and created a merge request (also fixed a MacOS X building system error while working on it). Updated Orca Wiki documentation regarding festival. Discussed a 2007 bug/feature in festival which allowed having a local shell and that the new systemd socket activation has the same code path.
• Carles using po-debconf-manager worked on Catalan translations: 7 reviewed and sent; 5 follow ups, 5 deleted packages.
• Carles made some po-debconf-manager changes: now it attaches the translation file on follow ups, fixed bullseye compatibility issues.
• Carles reviewed a new Catalan apt translation.
• Carles investigated and reported a lxhotkey bug and sent a patch for the abcde package.
• Carles made minor updates for Debian Wiki for different pages (lxde for dead keys, Ripping with abcde troubleshooting, VirtualBox troubleshooting).
• Stefano renamed build-details.json in Python 3.14 to fix multiarch coinstallability.
• Stefano audited the tooling and ignore lists for checking the contents of the python3.X-minimal packages, finding and fixing some issues in the process.
• Stefano made a few uploads of python3-defaults and dh-python in support of Python 3.14-as-default in Ubuntu. Also investigated the risk of ignoring byte-compilation failures by default, and started down the road of implementing this.
• Stefano did some sysadmin work on debian.social infrastructure.
• Stefano and Santiago worked on preparations for DebConf 26. Especially to help the local team on opening the registration, and reviewing the budget to be presented for approval.
• Stefano uploaded routine updates of python-virtualenv and python-flexmock.
• Antonio collaborated with DSA on enabling a new proxy for salsa to prevent scrapers from taking the service down.
• Antonio did miscellaneous salsa administrative tasks.
• Antonio fixed a few Ruby packages towards the Ruby 3.4 transition.
• Antonio started work on planned improvements to the DebConf registration system.
• Santiago prepared unstable updates for the latest upstream versions of knot-dns and knot-resolver. The authoritative DNS server and DNS resolver software developed by CZ.NIC. It is worth highlighting that, given the separation of functionality compared to other implementations, knot-dns and knot-resolver are also less complex software, which results in advantages in terms of security: only three CVEs have been reported for knot-dns since 2011).
• Santiago made some routine reviews of merge requests proposed for the Salsa CI s pipeline. E.g. a proposal to fix how sbuild chooses the chroot when building a package for experimental.
• Colin fixed lots of Python packages to handle Python 3.14 and to avoid using the deprecated pkg_resources module.
• Colin added forky support to the images used in Salsa CI pipelines.
• Colin began working on getting a release candidate of groff 1.24.0 (the first upstream release since mid-2023, so a very large set of changes) into experimental.
• Lucas kept working on the preparation for Ruby 3.4 transition. Some packages fixed (support build against Ruby 3.3 and 3.4): ruby-rbpdf, jekyll, origami-pdf, ruby-kdl, ruby-twitter, ruby-twitter-text, ruby-globalid.
• Lucas supported some potential mentors in the Google Summer of Code 26 program to submit their projects.
• Anupa worked on the point release announcements for Debian 12.13 and 13.3 from the Debian publicity team side.
• Anupa attended the publicity team meeting to discuss the team activities and to plan an online sprint in February.
• Anupa attended meetings with the Debian India team to plan and coordinate the MinDebConf Kanpur and sent out related Micronews.
• Emilio coordinated various transitions and helped get rid of llvm-toolchain-17 from sid.

The following contributors got their Debian Developer accounts in the last two months:

• Patrick Winnertz (winnie)
• Fabian Gruenbichler (fabiang)

The following contributors were added as Debian Maintainers in the last two months:

• Juri Grabowski
• Tobias Heider
• Jean Charles Del pine
• Guilherme Puida Moreira
• Antoine Le Gonidec
• Arthur Barbosa Diniz

Congratulations!

Introduction In 2020 I first setup a Matrix [1] server. Matrix is a full featured instant messaging protocol which requires a less stringent definition of instant , messages being delayed for minutes aren t that uncommon in my experience. Matrix is a federated service where the servers all store copies of the room data, so when you connect your client to it s home server it gets all the messages that were published while you were offline, it is widely regarded as being IRC but without a need to be connected all the time. One of it s noteworthy features is support for end to end encryption (so the server can t access cleartext messages from users) as a core feature. Matrix was designed for bridging with other protocols, the most well known of which is IRC. The most common Matrix server software is Synapse which is written in Python and uses a PostgreSQL database as it s backend [2]. My tests have shown that a lightly loaded Synapse server with less than a dozen users and only one or two active users will have noticeable performance problems if the PostgreSQL database is stored on SATA hard drives. This seems like the type of software that wouldn t have been developed before SSDs became commonly affordable. The matrix-synapse is in Debian/Unstable and the backports repositories for Bullseye and Buster. As Matrix is still being very actively developed you want to have a recent version of all related software so Debian/Buster isn t a good platform for running it, Bullseye or Bookworm are the preferred platforms. Configuring Synapse isn t really hard, but there are some postential problems. The first thing to do is to choose the DNS name, you can never change it without dropping the database (fresh install of all software and no documented way of keeping user configuration) so you don t want to get it wrong. Generally you will want the Matrix addresses at the top level of the domain you choose. When setting up a Matrix server for my local LUG I chose the top level of their domain luv.asn.au as the DNS name for the server. If you don t want to run a server then there are many open servers offering free account. Server Configuration Part of doing this configuration required creating the URL https://luv.asn.au/.well-known/matrix/client with the following contents so clients know where to connect. Note that you should not setup Jitsi sections without first discussing it with the people who run the Jitsi server in question.

 
  "m.homeserver":  
    "base_url": "https://luv.asn.au"
   
  "jitsi":  
    "preferredDomain": "jitsi.perthchat.org"
   
  "im.vector.riot.jitsi":  
    "preferredDomain": "jitsi.perthchat.org"
   
 

Also the URL https://luv.asn.au/.well-known/matrix/server for other servers to know where to connect:

 
  "m.server": "luv.asn.au:8448"
 

If the base_url or the m.server points to a name that isn t configured then you need to add it to the web server configuration. See section 3.1 of the documentation about well known Matrix client fields [3]. The SE Linux specific parts of the configuration are to run the following commands as Bookworm and Bullseye SE Linux policy have support for Synapse:

setsebool -P httpd_setrlimit 1
setsebool -P httpd_can_network_relay 1
setsebool -P matrix_postgresql_connect 1

To configure apache you have to enable proxy mode and SSL with the command a2enmod proxy ssl proxy_http and add the line Listen 8443 to /etc/apache2/ports.conf and restart Apache. The command chmod 700 /etc/matrix-synapse should probably be run to improve security, there s no reason for less restrictive permissions on that directory. In the /etc/matrix-synapse/homeserver.yaml file the macaroon_secret_key is a random key for generating tokens. To use the matrix.org server as a trusted key server and not receive warnings put the following line in the config file:

suppress_key_server_warning: true

A line like the following is needed to configure the baseurl:

public_baseurl: https://luv.asn.au:8448/

To have Synapse directly accept port 8448 connections you have to change bind_addresses in the first section of listeners to the global listen IPv6 and IPv4 addresses. The registration_shared_secret is a password for adding users. When you have set that you can write a shell script to add new users such as:

#!/bin/bash
# usage: matrix_new_user USER PASS
synapse_register_new_matrix_user -u $1 -p $2 -a -k THEPASSWORD

You need to set tls_certificate_path and tls_private_key_path to appropriate values, usually something like the following:

tls_certificate_path: "/etc/letsencrypt/live/www.luv.asn.au-0001/fullchain.pem"
tls_private_key_path: "/etc/letsencrypt/live/www.luv.asn.au-0001/privkey.pem"

For the database section you need something like the following which matches your PostgreSQL setup:

  name: "psycopg2"
  args:
    user: WWWWWW
    password: XXXXXXX
    database: YYYYYYY
    host: ZZZZZZ
    cp_min: 5
    cp_max: 10

You need to run psql commands like the following to set it up:

create role WWWWWW login password 'XXXXXXX';
create database YYYYYYY with owner WWWWWW ENCODING 'UTF8' LOCALE 'C' TEMPLATE 'template0';

For the Apache configuration you need something like the following for the port 8448 web server:

<VirtualHost *:8448>
  SSLEngine on
...
  ServerName luv.asn.au;
  AllowEncodedSlashes NoDecode
  ProxyPass /_matrix http://127.0.0.1:8008/_matrix nocanon
  ProxyPassReverse /_matrix http://127.0.0.1:8008/_matrix
  AllowEncodedSlashes NoDecode
  ProxyPass /_matrix http://127.0.0.1:8008/_matrix nocanon
  ProxyPassReverse /_matrix http://127.0.0.1:8008/_matrix
</VirtualHost>

Also you must add the ProxyPass section to the port 443 configuration (the server that is probably doing other more directly user visible things) for most (all?) end-user clients:

  ProxyPass /_matrix http://127.0.0.1:8008/_matrix nocanon

This web page can be used to test listing rooms via federation without logging in [4]. If it gives the error Can t find this server or its room list then you must set allow_public_rooms_without_auth and allow_public_rooms_over_federation to true in /etc/matrix-synapse/homeserver.yaml. The Matrix Federation Tester site [5] is good for testing new servers and for tests after network changes. Clients The Element (formerly known as Riot) client is the most common [6]. The following APT repository will allow you to install Element via apt install element-desktop on Debian/Buster.

deb https://packages.riot.im/debian/ default main

The Debian backports repository for Buster has the latest version of Quaternion, apt install quaternion should install that for you. Quaternion doesn t support end to end encryption (E2EE) and also doesn t seem to have good support for some other features like being invited to a room. My current favourite client is Schildi Chat on Android [7], which has a notification message 24*7 to reduce the incidence of Android killing it. Eventually I want to go to PinePhone or Librem 5 for all my phone use so I need to find a full featured Linux client that works on a small screen. Comparing to Jabber I plan to keep using Jabber for alerts because it really does instant messaging, it can reliably get the message to me within a matter of seconds. Also there are a selection of command-line clients for Jabber to allow sending messages from servers. When I first investigated Matrix there was no program suitable for sending messages from a script and the libraries for the protocol made it unreasonably difficult to write one. Now there is a Matrix client written in shell script [8] which might do that. But the delay in receiving messages is still a problem. Also the Matrix clients I ve tried so far have UIs that are more suited to serious chat than to quickly reading a notification message. Bridges Here is a list of bridges between Matrix and other protocols [9]. You can run bridges yourself for many different messaging protocols including Slack, Discord, and Messenger. There are also bridges run for public use for most IRC channels. Here is a list of integrations with other services [10], this is for interacting with things other than IM systems such as RSS feeds, polls, and other things. This also has some frameworks for writing bots. More Information The Debian wiki page about Matrix is good [11]. The view.matrix.org site allows searching for public rooms [12].

• [1] https://en.wikipedia.org/wiki/Matrix_(protocol)
• [2] https://tinyurl.com/2ddl5nvw
• [3] https://matrix.org/docs/spec/client_server/latest
• [4] https://app.element.io/#/welcome
• [5] https://federationtester.matrix.org/
• [6] https://element.io/get-started
• [7] https://schildi.chat/
• [8] https://github.com/fabianonline/matrix.sh
• [9] https://matrix.org/ecosystem/bridges/
• [10] https://matrix.org/ecosystem/integrations/
• [11] https://wiki.debian.org/Matrix
• [12] https://view.matrix.org/

This post serves as a report from my attendance to Kubecon and CloudNativeCon 2023 Europe that took place in Amsterdam in April 2023. It was my second time physically attending this conference, the first one was in Austin, Texas (USA) in 2017. I also attended once in a virtual fashion. The content here is mostly generated for the sake of my own recollection and learnings, and is written from the notes I took during the event. The very first session was the opening keynote, which reunited the whole crowd to bootstrap the event and share the excitement about the days ahead. Some astonishing numbers were announced: there were more than 10.000 people attending, and apparently it could confidently be said that it was the largest open source technology conference taking place in Europe in recent times. It was also communicated that the next couple iteration of the event will be run in China in September 2023 and Paris in March 2024. More numbers, the CNCF was hosting about 159 projects, involving 1300 maintainers and about 200.000 contributors. The cloud-native community is ever-increasing, and there seems to be a strong trend in the industry for cloud-native technology adoption and all-things related to PaaS and IaaS. The event program had different tracks, and in each one there was an interesting mix of low-level and higher level talks for a variety of audience. On many occasions I found that reading the talk title alone was not enough to know in advance if a talk was a 101 kind of thing or for experienced engineers. But unlike in previous editions, I didn t have the feeling that the purpose of the conference was to try selling me anything. Obviously, speakers would make sure to mention, or highlight in a subtle way, the involvement of a given company in a given solution or piece of the ecosystem. But it was non-invasive and fair enough for me. On a different note, I found the breakout rooms to be often small. I think there were only a couple of rooms that could accommodate more than 500 people, which is a fairly small allowance for 10k attendees. I realized with frustration that the more interesting talks were immediately fully booked, with people waiting in line some 45 minutes before the session time. Because of this, I missed a few important sessions that I ll hopefully watch online later. Finally, on a more technical side, I ve learned many things, that instead of grouping by session I ll group by topic, given how some subjects were mentioned in several talks. On gitops and CI/CD pipelines Most of the mentions went to FluxCD and ArgoCD. At that point there were no doubts that gitops was a mature approach and both flux and argoCD could do an excellent job. ArgoCD seemed a bit more over-engineered to be a more general purpose CD pipeline, and flux felt a bit more tailored for simpler gitops setups. I discovered that both have nice web user interfaces that I wasn t previously familiar with. However, in two different talks I got the impression that the initial setup of them was simple, but migrating your current workflow to gitops could result in a bumpy ride. This is, the challenge is not deploying flux/argo itself, but moving everything into a state that both humans and flux/argo can understand. I also saw some curious mentions to the config drifts that can happen in some cases, even if the goal of gitops is precisely for that to never happen. Such mentions were usually accompanied by some hints on how to operate the situation by hand. Worth mentioning, I missed any practical information about one of the key pieces to this whole gitops story: building container images. Most of the showcased scenarios were using pre-built container images, so in that sense they were simple. Building and pushing to an image registry is one of the two key points we would need to solve in Toolforge Kubernetes if adopting gitops. In general, even if gitops were already in our radar for Toolforge Kubernetes, I think it climbed a few steps in my priority list after the conference. Another learning was this site: https://opengitops.dev/. On etcd, performance and resource management I attended a talk focused on etcd performance tuning that was very encouraging. They were basically talking about the exact same problems we have had in Toolforge Kubernetes, like api-server and etcd failure modes, and how sensitive etcd is to disk latency, IO pressure and network throughput. Even though Toolforge Kubernetes scale is small compared to other Kubernetes deployments out there, I found it very interesting to see other s approaches to the same set of challenges. I learned how most Kubernetes components and apps can overload the api-server. Because even the api-server talks to itself. Simple things like kubectl may have a completely different impact on the API depending on usage, for example when listing the whole list of objects (very expensive) vs a single object. The conclusion was to try avoiding hitting the api-server with LIST calls, and use ResourceVersion which avoids full-dumps from etcd (which, by the way, is the default when using bare kubectl get calls). I already knew some of this, and for example the jobs-framework-emailer was already making use of this ResourceVersion functionality. There have been a lot of improvements in the performance side of Kubernetes in recent times, or more specifically, in how resources are managed and used by the system. I saw a review of resource management from the perspective of the container runtime and kubelet, and plans to support fancy things like topology-aware scheduling decisions and dynamic resource claims (changing the pod resource claims without re-defining/re-starting the pods). On cluster management, bootstrapping and multi-tenancy I attended a couple of talks that mentioned kubeadm, and one in particular was from the maintainers themselves. This was of interest to me because as of today we use it for Toolforge. They shared all the latest developments and improvements, and the plans and roadmap for the future, with a special mention to something they called kubeadm operator , apparently capable of auto-upgrading the cluster, auto-renewing certificates and such. I also saw a comparison between the different cluster bootstrappers, which to me confirmed that kubeadm was the best, from the point of view of being a well established and well-known workflow, plus having a very active contributor base. The kubeadm developers invited the audience to submit feature requests, so I did. The different talks confirmed that the basic unit for multi-tenancy in kubernetes is the namespace. Any serious multi-tenant usage should leverage this. There were some ongoing conversations, in official sessions and in the hallway, about the right tool to implement K8s-whitin-K8s, and vcluster was mentioned enough times for me to be convinced it was the right candidate. This was despite of my impression that multiclusters / multicloud are regarded as hard topics in the general community. I definitely would like to play with it sometime down the road. On networking I attended a couple of basic sessions that served really well to understand how Kubernetes instrumented the network to achieve its goal. The conference program had sessions to cover topics ranging from network debugging recommendations, CNI implementations, to IPv6 support. Also, one of the keynote sessions had a reference to how kube-proxy is not able to perform NAT for SIP connections, which is interesting because I believe Netfilter Conntrack could do it if properly configured. One of the conclusions on the CNI front was that Calico has a massive community adoption (in Netfilter mode), which is reassuring, especially considering it is the one we use for Toolforge Kubernetes. On jobs I attended a couple of talks that were related to HPC/grid-like usages of Kubernetes. I was truly impressed by some folks out there who were using Kubernetes Jobs on massive scales, such as to train machine learning models and other fancy AI projects. It is acknowledged in the community that the early implementation of things like Jobs and CronJobs had some limitations that are now gone, or at least greatly improved. Some new functionalities have been added as well. Indexed Jobs, for example, enables each Job to have a number (index) and process a chunk of a larger batch of data based on that index. It would allow for full grid-like features like sequential (or again, indexed) processing, coordination between Job and more graceful Job restarts. My first reaction was: Is that something we would like to enable in Toolforge Jobs Framework? On policy and security A surprisingly good amount of sessions covered interesting topics related to policy and security. It was nice to learn two realities:

1. kubernetes is capable of doing pretty much anything security-wise and create greatly secured environments.
2. it does not by default. The defaults are not security-strict on purpose.

It kind of made sense to me: Kubernetes was used for a wide range of use cases, and developers didn t know beforehand to which particular setup they should accommodate the default security levels. One session in particular covered the most basic security features that should be enabled for any Kubernetes system that would get exposed to random end users. In my opinion, the Toolforge Kubernetes setup was already doing a good job in that regard. To my joy, some sessions referred to the Pod Security Admission mechanism, which is one of the key security features we re about to adopt (when migrating away from Pod Security Policy). I also learned a bit more about Secret resources, their current implementation and how to leverage a combo of CSI and RBAC for a more secure usage of external secrets. Finally, one of the major takeaways from the conference was learning about kyverno and kubeaudit. I was previously aware of the OPA Gatekeeper. From the several demos I saw, it was to me that kyverno should help us make Toolforge Kubernetes more sustainable by replacing all of our custom admission controllers with it. I already opened a ticket to track this idea, which I ll be proposing to my team soon. Final notes In general, I believe I learned many things, and perhaps even more importantly I re-learned some stuff I had forgotten because of lack of daily exposure. I m really happy that the cloud native way of thinking was reinforced in me, which I still need because most of my muscle memory to approach systems architecture and engineering is from the old pre-cloud days. List of sessions I attended on the first day:

• Keynote
• Node Resource Management: The Big Picture - Sascha Grunert & Swati Sehgal, Red Hat; Alexander Kanevskiy, Intel; Evan Lezar, NVIDIA; David Porter, Google.
• How We Securely Scaled Multi-Tenancy with VCluster, Crossplane, and Argo CD - Ilia Medvedev & Kostis Kapelonis, Codefresh. (Couldn t really attend, room full)
• Flux Beyond Git: Harnessing the Power of OCI - Stefan Prodan & Hidde Beydals, Weaveworks. (Couldn t really attend, room full)
• Tutorial: Measure Twice, Cut Once: Dive Into Network Foundations the Right Way! - Marino Wijay & Jason Skrzypek, Solo.io
• Argo CD Core - A Pure GitOps Agent for Kubernetes - Alexander Matyushentsev, Akuity & Leonardo Luz Almeida, Intuit
• Kubeadm Deep Dive - Rohit Anand, NEC & Paco Xu, Dao
• Cloud Operate Multi-Tenancy Service Mesh with ArgoCD in Production - Lin Sun, Solo.io & Faseela K, Ericsson Software Technology

List of sessions I attended on the second day:

• Keynote
• Setting up Etcd with Kubernetes to Host Clusters with Thousands of Nodes - Marcel Zi ba, Isovalent & Laurent Bernaille, Datadog
• Container Is the New VM: The Paradigm Change No One Explained to You - Marga Manterola, Isovalent & Rodrigo Campos Catelin, Microsoft
• Ephemeral Clusters as a Service with ClusterAPI and GitOps - Alessandro Vozza, Solo.io & Joaquin Rodriguez, Microsoft
• Automating Configuration and Permissions Testing for GitOps with OPA Conftest - Eve Ben Ezra & Michael Hume, The New York Times
• Across Kubernetes Namespace Boundaries: Your Volumes Can Be Shared Now! - Masaki Kimura & Takafumi Takahashi, Hitachi

List of sessions I attended on third day:

• Keynote
• Prevent Embarrassing Cluster Takeovers with This One Simple Trick! - Daniele de Araujo dos Santos & Shane Lawrence, Shopify
• Hacking and Defending Kubernetes Clusters: We ll Do It LIVE!!! - Fabian Kammel & James Cleverley-Prance, ControlPlane
• Painless Multi-Cloud to the Edge Powered by NATS & Kubernetes - Tomasz Pietrek & David Gee, Synadia
• Demystifing IPv6 Kubernetes - Antonio Jose Ojea Garcia, Google & Fernando Gont, Yalo
• Open Policy Agent. (OPA) Intro & Deep Dive - Charlie Egan, Styra, Inc. (Couldn t really attend, room full)
• Practical Challenges with Pod Security Admission - V K rbes & Christian Schlotter, VMware
• Enabling HPC and ML Workloads with the Latest Kubernetes Job Features - Micha Wo niak, Google & Vanessa Sochat, Lawrence Livermore National Laboratory
• Can You Keep a Secret? on Secret Management in Kubernetes - Liav Yona & Gal Cohen, Firefly

The videos have been published on Youtube.

Welcome to the first report for 2023 from the Reproducible Builds project! In these reports we try and outline the most important things that we have been up to over the past month, as well as the most important things in/around the community. As a quick recap, the motivation behind the reproducible builds effort is to ensure no malicious flaws can be deliberately introduced during compilation and distribution of the software that we run on our devices. As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.

---

News In a curious turn of events, GitHub first announced this month that the checksums of various Git archives may be subject to change, specifically that because:

the default compression for Git archives has recently changed. As result, archives downloaded from GitHub may have different checksums even though the contents are completely unchanged.

This change (which was brought up on our mailing list last October) would have had quite wide-ranging implications for anyone wishing to validate and verify downloaded archives using cryptographic signatures. However, GitHub reversed this decision, updating their original announcement with a message that We are reverting this change for now. More details to follow. It appears that this was informed in part by an in-depth discussion in the GitHub Community issue tracker.
The Bundesamt f r Sicherheit in der Informationstechnik (BSI) (trans: The Federal Office for Information Security ) is the agency in charge of managing computer and communication security for the German federal government. They recently produced a report that touches on attacks on software supply-chains (Supply-Chain-Angriff). (German PDF)
Contributor Seb35 updated our website to fix broken links to Tails Git repository [ ][ ], and Holger updated a large number of pages around our recent summit in Venice [ ][ ][ ][ ].
Noak J nsson has written an interesting paper entitled The State of Software Diversity in the Software Supply Chain of Ethereum Clients. As the paper outlines:

In this report, the software supply chains of the most popular Ethereum clients are cataloged and analyzed. The dependency graphs of Ethereum clients developed in Go, Rust, and Java, are studied. These client are Geth, Prysm, OpenEthereum, Lighthouse, Besu, and Teku. To do so, their dependency graphs are transformed into a unified format. Quantitative metrics are used to depict the software supply chain of the blockchain. The results show a clear difference in the size of the software supply chain required for the execution layer and consensus layer of Ethereum.

Yongkui Han posted to our mailing list discussing making reproducible builds & GitBOM work together without gitBOM-ID embedding. GitBOM (now renamed to OmniBOR) is a project to enable automatic, verifiable artifact resolution across today s diverse software supply-chains [ ]. In addition, Fabian Keil wrote to us asking whether anyone in the community would be at Chemnitz Linux Days 2023, which is due to take place on 11th and 12th March (event info). Separate to this, Akihiro Suda posted to our mailing list just after the end of the month with a status report of bit-for-bit reproducible Docker/OCI images. As Akihiro mentions in their post, they will be giving a talk at FOSDEM in the Containers devroom titled Bit-for-bit reproducible builds with Dockerfile and that my talk will also mention how to pin the apt/dnf/apk/pacman packages with my repro-get tool.
The extremely popular Signal messenger app added upstream support for the SOURCE_DATE_EPOCH environment variable this month. This means that release tarballs of the Signal desktop client do not embed nondeterministic release information. [ ][ ]

---

Distribution work

F-Droid & Android There was a very large number of changes in the F-Droid and wider Android ecosystem this month: On January 15th, a blog post entitled Towards a reproducible F-Droid was published on the F-Droid website, outlining the reasons why F-Droid signs published APKs with its own keys and how reproducible builds allow using upstream developers keys instead. In particular:

In response to [ ] criticisms, we started encouraging new apps to enable reproducible builds. It turns out that reproducible builds are not so difficult to achieve for many apps. In the past few months we ve gotten many more reproducible apps in F-Droid than before. Currently we can t highlight which apps are reproducible in the client, so maybe you haven t noticed that there are many new apps signed with upstream developers keys.

(There was a discussion about this post on Hacker News.) In addition:

• F-Droid added 13 apps published with reproducible builds this month. [ ]
• FC Stegerman outlined a bug where baseline.profm files are nondeterministic, developed a workaround, and provided all the details required for a fix. As they note, this issue has now been fixed but the fix is not yet part of an official Android Gradle plugin release.
• GitLab user Parwor discovered that the number of CPU cores can affect the reproducibility of .dex files. [ ]
• FC Stegerman also announced the 0.2.0 and 0.2.1 releases of reproducible-apk-tools, a suite of tools to help make .apk files reproducible. Several new subcommands and scripts were added, and a number of bugs were fixed as well [ ][ ]. They also updated the F-Droid website to improve the reproducibility-related documentation. [ ][ ]
• On the F-Droid issue tracker, FC Stegerman discussed reproducible builds with one of the developers of the Threema messenger app and reported that Android SDK build-tools 31.0.0 and 32.0.0 (unlike earlier and later versions) have a zipalign command that produces incorrect padding.
• A number of bugs related to reproducibility were discovered in Android itself. Firstly, the non-deterministic order of .zip entries in .apk files [ ] and then newline differences between building on Windows versus Linux that can make builds not reproducible as well. [ ] (Note that these links may require a Google account to view.)
• And just before the end of the month, FC Stegerman started a thread on our mailing list on the topic of hiding data/code in APK embedded signatures which has been made possible by the Android APK Signature Scheme v2/v3. As part of this, they made an Android app that reads the APK Signing block of its own APK and extracts a payload in order to alter its behaviour called sigblock-code-poc.

Debian As mentioned in last month s report, Vagrant Cascadian has been organising a series of online sprints in order to clear the huge backlog of reproducible builds patches submitted by performing NMUs (Non-Maintainer Uploads). During January, a sprint took place on the 10th, resulting in the following uploads:

• Chris Lamb:
  • critcl (#963600)
  • log4cpp (#1020662)
  • logapp (#1010845)
  • nanomsg (#1001853)
• Holger Levsen:
  • netkit-rsh (#1020798)
  • wcwidth (#1005408)
• Vagrant Cascadian:
  • mc (#828683)
  • gtk-sharp3 (#989965 & #989966)

During this sprint, Holger Levsen filed Debian bug #1028615 to request that the tracker.debian.org service display results of reproducible rebuilds, not just reproducible CI results. Elsewhere in Debian, strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. This month, version 1.13.1-1 was uploaded to Debian unstable by Holger Levsen, including a fix by FC Stegerman (obfusk) to update a regular expression for the latest version of file(1) [ ]. (#1028892) Lastly, 65 reviews of Debian packages were added, 21 were updated and 35 were removed this month adding to our knowledge about identified issues.

Other distributions In other distributions:

• Bernhard M. Wiedemann published another monthly report for reproducibility within openSUSE, as well as a belated report for December 2022.
• It was announced that Fedora Rawhide now clamps file modification types to SOURCE_DATE_EPOCH. [ ]
• Finally, an existing tool called rpmreproduce was (re-)discovered this month, which claims that given a buildinfo file from a RPM package, [it can] generate instructions for attempting to reproduce the binary packages built from the associated source and build information.

---

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb made the following changes to diffoscope, including preparing and uploading versions 231, 232, 233 and 234 to Debian:

• No need for from __future__ import print_function import anymore. [ ]
• Comment and tidy the extras_require.json handling. [ ]
• Split inline Python code to generate test Recommends into a separate Python script. [ ]
• Update debian/tests/control after merging support for PyPDF support. [ ]
• Correctly catch segfaulting cd-iccdump binary. [ ]
• Drop some old debugging code. [ ]
• Allow ICC tests to (temporarily) fail. [ ]

In addition, FC Stegerman (obfusk) made a number of changes, including:

• Updating the test_text_proper_indentation test to support the latest version(s) of file(1). [ ]
• Use an extras_require.json file to store some build/release metadata, instead of accessing the internet. [ ]
• Updating an APK-related file(1) regular expression. [ ]
• On the diffoscope.org website, de-duplicate contributors by e-mail. [ ]

Lastly, Sam James added support for PyPDF version 3 [ ] and Vagrant Cascadian updated a handful of tool references for GNU Guix. [ ][ ]

---

Upstream patches The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • argparse (date-related issue)
  • asciimatics (build failure)
  • asyncpg (fails to build in 2032)
  • cpython (fails to build in 2038)
  • django (fails to build in 2038)
  • grandorgue (.zip-related issue)
  • libarchive (fails to build in 2038)
  • libarchive (fails to build in 2038)
  • librcc (date)
  • mbedtls (fails to build in 2023)
  • mozilla-nss (fails to build in 2023)
  • ocaml-rpm-macros (fix fallout from an RPM-related change)
  • perl HTTP::Cookies (fails to build in 2038)
  • python-aiosmtplib/python-trustme (fails to build in 2038 due to SSL certificate)
  • python-bmap (fails to build in 2024)
  • python-compileall2 (fails to build in 2038)
  • taskwarrior (python-tasklib fails to build in 2038)
  • taskwarrior (fix fails to build in 2038)
  • wrk (hash ordering issue)
  • xemacs (fails to build in 2038 stuck)
• Chris Lamb:
  • #1027988 filed against click.
  • #1027992 filed against towncrier.
  • #1028051 filed against unifrac-tools.
  • #1028310 filed against hamster-time-tracker.
  • #1028515 filed against accel-config.
  • #1029295 filed against python-miio.
  • #1029297 filed against python-graphviz.
• Vagrant Cascadian:
  • #1029227 filed against ectrans.
  • #1029303 filed against fiat-ecmwf.
  • #1029307 filed against node-katex.
  • #1029800 filed against aribas.
  • #1029801 filed against tbox.
  • #1029807 filed against borgbackup2.
  • #1029809 filed against dnf-plugins-core.
  • #1030057 filed against refpolicy.
• FC Stegerman:
  • Several patches for file(1) (which is used by reproducible builds tools like diffoscope and strip-nondeterminism) that improve detection of various file formats are now included in the Debian packaging. [ ]

---

Testing framework The Reproducible Builds project operates a comprehensive testing framework at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In January, the following changes were made by Holger Levsen:

• Node changes:
  • Add three new nodes hosted at the Oregon State University Open Source Lab including integrating them into the DNS, maintenance and monitoring systems. [ ][ ][ ][ ][ ]
• Debian-related changes:
  • Only keep diffoscope s HTML output (ie. no .json or .txt) for LTS suites and older in order to save diskspace on the Jenkins host. [ ]
  • Re-create pbuilder base less frequently for the stretch, bookworm and experimental suites. [ ]
• OpenWrt-related changes:
  • Add gcc-multilib to OPENWRT_HOST_PACKAGES and install it on the nodes that need it. [ ]
  • Detect more problems in the health check when failing to build OpenWrt. [ ]
• Misc changes:
  • Update the chroot-run script to correctly manage /dev and /dev/pts. [ ][ ][ ]
  • Update the Jenkins shell monitor script to collect disk stats less frequently [ ] and to include various directory stats. [ ][ ]
  • Update the real year in the configuration in order to be able to detect whether a node is running in the future or not. [ ]
  • Bump copyright years in the default page footer. [ ]

In addition, Christian Marangi submitted a patch to build OpenWrt packages with the V=s flag to enable debugging. [ ]

---

If you are interested in contributing to the Reproducible Builds project, please visit the Contribute page on our website. You can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Mastodon: @reproducible_builds@fosstodon.org
• Mailing list: rb-general@lists.reproducible-builds.org

The following contributors got their Debian Developer accounts in the last two months:

• Dennis Braun (snd)
• Ra l Benencia (rul)

The following contributors were added as Debian Maintainers in the last two months:

• Gioele Barabucci
• Agathe Porte
• Braulio Henrique Marques Souto
• Matthias Geiger
• Alper Nebi Yasak
• Fabian Gr nbichler
• Lance Lin

Congratulations!

From November 2nd to 4th, 2022, the 19th edition of Latinoware - Latin American Congress of Free Software and Open Technologies took place in Foz do Igua u. After 2 years happening online due to the COVID-19 pandemic, the event was back in person and we felt Debian Brasil community should be there. Out last time at Latinoware was in 2016 The Latinoware organization provided the Debian Brazil community with a booth so that we could have contact with people visiting the open exhibition area and thus publicize the Debian project. During the 3 days of the event, the booth was organized by me (Paulo Henrique Santana) as Debian Developer, and by Leonardo Rodrigues as Debian contributor. Unfortunately Daniel Lenharo had an issue and could not travel to Foz do Igua u (we miss you there!). A huge number of people visited the booth, and the beginners (mainly students) who didn't know Debian, asked what our group was about and we explained various concepts such as what Free Software is, GNU/Linux distribution and Debian itself. We also received people from the Brazilian Free Software community and from other Latin American countries who were already using a GNU/Linux distribution and, of course, many people who were already using Debian. We had some special visitors as Jon maddog Hall, Debian Developer Emeritus Ot vio Salvador, Debian Developer Eriberto Mota, and Debian Maintainers Guilherme de Paula Segundo and Paulo Kretcheu. Photo from left to right: Leonardo, Paulo, Eriberto and Ot vio. Photo from left to right: Paulo, Fabian (Argentina) and Leonardo. In addition to talking a lot, we distributed Debian stickers that were produced a few months ago with Debian's sponsorship to be distributed at DebConf22 (and that were left over), and we sold several Debian t-shirts) produced by Curitiba Livre community). We also had 3 talks included in Latinoware official schedule. I) talked about: "how to become a Debian contributor by doing translations" and "how the SysAdmins of a global company use Debian". And Leonardo) talked about: "advantages of Open Source telephony in companies". Photo Paulo in his talk. Many thanks to Latinoware organization for once again welcoming the Debian community and kindly providing spaces for our participation, and we congratulate all the people involved in the organization for the success of this important event for our community. We hope to be present again in 2023. We also thank Jonathan Carter for approving financial support from Debian for our participation at Latinoware. Portuguese version

De 2 a 4 de novembro de 2022 aconteceu a 19 edi o do Latinoware - Congresso Latino-americano de Software Livre e Tecnologias Abertas, em Foz do Igua u. Ap s 2 anos acontecendo de forma online devido a pandemia do COVID-19, o evento voltou a ser presencial e sentimos que a comunidade Debian Brasil deveria estar presente. Nossa ltima participa o no Latinoware foi em 2016 A organiza o do Latinoware cedeu para a comunidade Debian Brasil um estande para que pud ssemos ter contato com as pessoas que visitavam a rea aberta de exposi es e assim divulgarmos o projeto Debian. Durante os 3 dias do evento, o estande foi organizado por mim (Paulo Henrique Santana) como Desenvolvedor Debian, e pelo Leonardo Rodrigues como contribuidor Debian. Infelizmente o Daniel Lenharo teve um imprevisto de ltima hora e n o pode ir para Foz do Igua u (sentimos sua falta l !). V rias pessoas visitaram o estande e aquelas mais iniciantes (principalmente estudantes) que n o conheciam o Debian, perguntavam do que se tratava o nosso grupo e a gente explicava v rios conceitos como o que Software Livre, distribui o GNU/Linux e o Debian propriamente dito. Tamb m recebemos pessoas da comunidade de Software Livre brasileira e de outros pa ses da Am rica Latina que j utilizavam uma distribui o GNU/Linux e claro, muitas pessoas que j utilizavam Debian. Tivemos algumas visitas especiais como do Jon maddog Hall, do Desenvolvedor Debian Emeritus Ot vio Salvador, do Desenvolvedor Debian Eriberto Mota, e dos Mantenedores Debian Guilherme de Paula Segundo e Paulo Kretcheu. Foto da esquerda pra direita: Leonardo, Paulo, Eriberto e Ot vio. Foto da esquerda pra direita: Paulo, Fabian (Argentina) e Leonardo. Al m de conversarmos bastante, distribu mos adesivos do Debian que foram produzidos alguns meses atr s com o patroc nio do Debian para serem distribu dos na DebConf22(e que haviam sobrado), e vendemos v rias camisetas do Debian produzidas pela comunidade Curitiba Livre. Tamb m tivemos 3 palestras inseridas na programa o oficial do Latinoware. Eu fiz as palestras: como tornar um(a) contribuidor(a) do Debian fazendo tradu es e como os SysAdmins de uma empresa global usam Debian . E o Leonardo fez a palestra: vantagens da telefonia Open Source nas empresas . Foto Paulo na palestra. Agradecemos a organiza o do Latinoware por receber mais uma vez a comunidade Debian e gentilmente ceder os espa os para a nossa participa o, e parabenizamos a todas as pessoas envolvidas na organiza o pelo sucesso desse importante evento para a nossa comunidade. Esperamos estar presentes novamente em 2023. Agracemos tamb m ao Jonathan Carter por aprovar o suporte financeiro do Debian para a nossa participa o no Latinoware. Vers o em ingl s

De 2 a 4 de novembro de 2022 aconteceu a 19 edi o do Latinoware - Congresso Latino-americano de Software Livre e Tecnologias Abertas, em Foz do Igua u. Ap s 2 anos acontecendo de forma online devido a pandemia do COVID-19, o evento voltou a ser presencial e sentimos que a comunidade Debian Brasil deveria estar presente. Nossa ltima participa o no Latinoware foi em 2016 A organiza o do Latinoware cedeu para a comunidade Debian Brasil um estande para que pud ssemos ter contato com as pessoas que visitavam a rea aberta de exposi es e assim divulgarmos o projeto Debian. Durante os 3 dias do evento, o estande foi organizado por mim (Paulo Henrique Santana) como Desenvolvedor Debian, e pelo Leonardo Rodrigues como contribuidor Debian. Infelizmente o Daniel Lenharo teve um imprevisto de ltima hora e n o pode ir para Foz do Igua u (sentimos sua falta l !). V rias pessoas visitaram o estande e aquelas mais iniciantes (principalmente estudantes) que n o conheciam o Debian, perguntavam do que se tratava o nosso grupo e a gente explicava v rios conceitos como o que Software Livre, distribui o GNU/Linux e o Debian propriamente dito. Tamb m recebemos pessoas da comunidade de Software Livre brasileira e de outros pa ses da Am rica Latina que j utilizavam uma distribui o GNU/Linux e claro, muitas pessoas que j utilizavam Debian. Tivemos algumas visitas especiais como do Jon maddog Hall, do Desenvolvedor Debian Emeritus Ot vio Salvador, do Desenvolvedor Debian Eriberto Mota, e dos Mantenedores Debian Guilherme de Paula Segundo e Paulo Kretcheu. Foto da esquerda pra direita: Leonardo, Paulo, Eriberto e Ot vio. Foto da esquerda pra direita: Paulo, Fabian (Argentina) e Leonardo. Al m de conversarmos bastante, distribu mos adesivos do Debian que foram produzidos alguns meses atr s com o patroc nio do Debian para serem distribu dos na DebConf22(e que haviam sobrado), e vendemos v rias camisetas do Debian produzidas pela comunidade Curitiba Livre. Tamb m tivemos 3 palestras inseridas na programa o oficial do Latinoware. Eu fiz as palestras: como tornar um(a) contribuidor(a) do Debian fazendo tradu es e como os SysAdmins de uma empresa global usam Debian . E o Leonardo fez a palestra: vantagens da telefonia Open Source nas empresas . Foto Paulo na palestra. Agradecemos a organiza o do Latinoware por receber mais uma vez a comunidade Debian e gentilmente ceder os espa os para a nossa participa o, e parabenizamos a todas as pessoas envolvidas na organiza o pelo sucesso desse importante evento para a nossa comunidade. Esperamos estar presentes novamente em 2023. Agracemos tamb m ao Jonathan Carter por aprovar o suporte financeiro do Debian para a nossa participa o no Latinoware. Vers o em ingl s

From November 2nd to 4th, 2022, the 19th edition of Latinoware - Latin American Congress of Free Software and Open Technologies took place in Foz do Igua u. After 2 years happening online due to the COVID-19 pandemic, the event was back in person and we felt Debian Brasil community should be there. Out last time at Latinoware was in 2016 The Latinoware organization provided the Debian Brazil community with a booth so that we could have contact with people visiting the open exhibition area and thus publicize the Debian project. During the 3 days of the event, the booth was organized by me (Paulo Henrique Santana) as Debian Developer, and by Leonardo Rodrigues as Debian contributor. Unfortunately Daniel Lenharo had an issue and could not travel to Foz do Igua u (we miss you there!). A huge number of people visited the booth, and the beginners (mainly students) who didn't know Debian, asked what our group was about and we explained various concepts such as what Free Software is, GNU/Linux distribution and Debian itself. We also received people from the Brazilian Free Software community and from other Latin American countries who were already using a GNU/Linux distribution and, of course, many people who were already using Debian. We had some special visitors as Jon maddog Hall, Debian Developer Emeritus Ot vio Salvador, Debian Developer Eriberto Mota, and Debian Maintainers Guilherme de Paula Segundo and Paulo Kretcheu. Photo from left to right: Leonardo, Paulo, Eriberto and Ot vio. Photo from left to right: Paulo, Fabian (Argentina) and Leonardo. In addition to talking a lot, we distributed Debian stickers that were produced a few months ago with Debian's sponsorship to be distributed at DebConf22 (and that were left over), and we sold several Debian t-shirts) produced by Curitiba Livre community). We also had 3 talks included in Latinoware official schedule. I) talked about: "how to become a Debian contributor by doing translations" and "how the SysAdmins of a global company use Debian". And Leonardo) talked about: "advantages of Open Source telephony in companies". Photo Paulo in his talk. Many thanks to Latinoware organization for once again welcoming the Debian community and kindly providing spaces for our participation, and we congratulate all the people involved in the organization for the success of this important event for our community. We hope to be present again in 2023. We also thank Jonathan Carter for approving financial support from Debian for our participation at Latinoware. Portuguese version

Welcome to the December 2021 report from the Reproducible Builds project! In these reports, we try and summarise what we have been up to over the past month, as well as what else has been occurring in the world of software supply-chain security. As a quick recap of what reproducible builds is trying to address, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. As always, if you would like to contribute to the project, please get in touch with us directly or visit the Contribute page on our website.
Early in December, Julien Voisin blogged about setting up a rebuilderd instance in order to reproduce Tails images. Working on previous work from 2018, Julien has now set up a public-facing instance which is providing build attestations. As Julien dryly notes in his post, Currently, this isn t really super-useful to anyone, except maybe some Tails developers who want to check that the release manager didn t backdoor the released image. Naturally, we would contend sincerely that this is indeed useful.
The secure/anonymous Tor browser now supports reproducible source releases. According to the project s changelog, version 0.4.7.3-alpha of Tor can now build reproducible tarballs via the make dist-reprod command. This issue was tracked via Tor issue #26299.
Fabian Keil posted a question to our mailing list this month asking how they might analyse differences in images produced with the FreeBSD and ElectroBSD s mkimg and makefs commands:

After rebasing ElectroBSD from FreeBSD stable/11 to stable/12
I recently noticed that the "memstick" images are unfortunately
still not 100% reproducible.

Fabian s original post generated a short back-and-forth with Chris Lamb regarding how diffoscope might be able to support the particular format of images generated by this command set.

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb prepared and uploading versions 195, 196, 197 and 198 to Debian, as well as made the following changes:

• Support showing Ordering differences only within .dsc field values. [ ]
• Add support for XMLb files. [ ]
• Also add, for example, /usr/lib/x86_64-linux-gnu to our local binary search path. [ ]
• Support OCaml versions 4.11, 4.12 and 4.13. [ ]
• Drop some unnecessary has_same_content_as logging calls. [ ]
• Replace token variable with an anonymously-named variable instead to remove extra lines. [ ]
• Don t use the runtime platform s native endianness when unpacking .pyc files. This fixes test failures on big-endian machines. [ ]

Mattia Rizzolo also made a number of changes to diffoscope this month as well, such as:

• Also recognize GnuCash files as XML. [ ]
• Support the pgpdump PGP packet visualiser version 0.34. [ ]
• Ignore the new Lintian tag binary-with-bad-dynamic-table. [ ]
• Fix the Enhances field in debian/control. [ ]

Finally, Brent Spillner fixed the version detection for Black uncompromising code formatter [ ], Jelle van der Waa added an external tool reference for Arch Linux [ ] and Roland Clobus added support for reporting when the GNU_BUILD_ID field has been modified [ ]. Thank you for your contributions!

Distribution work In Debian this month, 70 reviews of packages were added, 27 were updated and 41 were removed, adding to our database of knowledge about specific issues. A number of issue types were created as well, including:

• build_path_identifiers_in_documentation_generated_by_doxygen
• non_deterministic_doc_base_file_for_javadoc
• nondeterministic_ordering_in_guile_binaries

strip-nondeterminism version 1.13.0-1 was uploaded to Debian unstable by Holger Levsen. It included contributions already covered in previous months as well as new ones from Mattia Rizzolo, particularly that the dh_strip_nondeterminism Debian integration interface uses the new get_non_binnmu_date_epoch() utility when available: this is important to ensure that strip-nondeterminism does not break some kinds of binNMUs.
In the world of openSUSE, however, Bernhard M. Wiedemann posted his monthly reproducible builds status report.
In NixOS, work towards the longer-term goal of making the graphical installation image reproducible is ongoing. For example, Artturin made the gnome-desktop package reproducible.

Upstream patches The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. In December, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • g++7/rsync (randomness in output)
  • python-eventlet (build fails in the future)
  • python-PyQRCode (incorporates copyright year)
• Chris Lamb:
  • #1001227 filed against locust.
  • #1001277 filed against cwltool.
  • #1001553 filed against mate-submodules.
• Simon McVittie:
  • #1001210 filed against ksh93u+m.
  • #1001223 filed against dx.
• Vagrant Cascadian:
  • #1000944 filed against apbs.
  • #1000945 filed against binutils-riscv64-unknown-elf.
  • #1000946 filed against gcc-riscv64-unknown-elf.
  • #1001850 filed against userbindmount.
  • #1001853 filed against nanomsg.
  • #1001854 filed against freediameter.
  • #1001856 filed against gr-satellites.
  • #1001859 filed against kjs.
  • #1001860 filed against xeus-python.
  • #1001866 filed against libime.
  • #1001867 filed against fcitx5-gtk.
  • #1001868 filed against fcitx.
  • #1001869 filed against libpodofo.
  • #1001870 filed against meshlab.
  • #1001872 filed against eiskaltdcpp.
  • #1001873 filed against editorconfig-core.
  • #1002671 filed against python-parse-type.
  • #1002673 filed against sphinx-copybutton.
  • #1002674 filed against fcitx5-qt.
• Roland Clobus:
  • libxmlb#110 filed upstream against libxmlb, fixed by Richard Hughes. Waiting for an upstream release.

Testing framework The Reproducible Builds project runs a significant testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, the following changes were made:

• Holger Levsen:
  • Run the Debian scheduler less often. [ ]
  • Fix the name of the Debian testing suite name. [ ]
  • Detect builds that are rescheduling due to problems with the diffoscope container. [ ]
  • No longer special-case particular machines having a different /boot partition size. [ ]
  • Automatically fix failed apt-daily and apt-daily-upgrade services [ ], failed e2scrub_all.service & user@ systemd units [ ][ ] as well as generic build failures [ ].
  • Simplify a script to powercycle arm64 architecture nodes hosted at/by codethink.co.uk. [ ]
  • Detect if the udd-mirror.debian.net service is down. [ ]
  • Various miscellaneous node maintenance. [ ][ ]
• Roland Clobus (Debian live image generation):
  • If the latest snapshot is not complete yet, try to use the previous snapshot instead. [ ]
  • Minor: whitespace correction + comment correction. [ ]
  • Use unique folders and reports for each Debian version. [ ]
  • Turn off debugging. [ ]
  • Add a better error description for incorrect/missing arguments. [ ]
  • Report non-reproducible issues in Debian sid images. [ ]

Lastly, Mattia Rizzolo updated the automatic logfile parsing rules in a number of ways (eg. to ignore a warning about the Python setuptools deprecation) [ ][ ] and Vagrant Cascadian adjusted the config for the Squid caching proxy on a node. [ ]

---

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• Mailing list: rb-general@lists.reproducible-builds.org
• IRC: #reproducible-builds on irc.oftc.net.
• Mastodon: @reproducible_builds@fosstodon.org

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.

I'm currently trying to make sense of some still image coding (more details to come at a much later stage!), and for a variety of reasons, I've chosen to use rANS as the entropy coder. However, there's an interesting little detail that I haven't actually seen covered anywhere; maybe it's just because I've missed something, or maybe because it's too blindingly obvious, but I thought I would document what I ended up with anyway. (I had hoped for something even more elegant, but I guess the obvious would have to do.) For those that don't know rANS coding, let me try to handwave it as much as possible. Your state is typically a single word (in my case, a 32-bit word), which is refilled from the input stream as needed. The encoder and decoder works in reverse order; let's just talk about the decoder. Basically it works by looking at the lowest 12 (or whatever) bits of the decoder state, mapping each of those 2^12 slots to a decoded symbol. More common symbols are given more slots, proportionally to the frequency. Let me just write a tiny, tiny example with 2 bits and three symbols instead, giving four slots:

Lowest bits	Symbol
00	0
01	0
10	1
11	2

Note that the zero coefficient here maps to one out of two slots (ie., a range); you don't choose which one yourself, the encoder stashes some information in there (which is used to recover the next control word once you know which symbol there is). Now for the actual problem: When storing DCT coefficients, we typically want to also store a sign (ie., not just 1 or 2, but also -1/+1 and -2/+2). The statistical distribution is symmetrical, so the sign bit is incompressible (except that of course there's no sign bit needed for 0). We could have done this by introducing new symbols -1 and -2 in addition to our three other ones, but this means we'll need more bits of precision, and accordingly larger look-up tables (which is negative for performance). So let's find something better. We could also simply store it separately somehow; if the coefficient is non-zero, store the bits in some separate repository. Perhaps more elegantly, you can encode a second symbol in the rANS stream with probability 1/2, but this is more expensive computationally. But both of these have the problem that they're divergent in terms of control flow; nonzero coefficients potentially need to do a lot of extra computation and even loads. This isn't nice for SIMD, and it's not nice for GPU. It's generally not really nice. The solution I ended up with was simulating a larger table with a smaller one. Simply rotate the table so that the zero symbol has the top slots instead of the bottom slots, and then replicate the rest of the table. For instance, take this new table:

Lowest bits	Symbol
000	1
001	2
010	0
011	0
100	0
101	0
110	-1
111	-2

(The observant reader will note that this doesn't describe the exact same distribution as last time zero has twice the relative frequency as in the other table but ignore that for the time being.) In this case, the bottom half of the table doesn't actually need to be stored! We know that if the three bottom bits are >= 110 (6 in decimal), we have a negative value, can subtract 6, and then continue decoding. If we are go past the end of our 2-bit table despite that, we know we are decoding a zero coefficient (which doesn't have a sign), so we can just clamp the read; or for a GPU, reads out-of-bounds on a texture will typically return 0 anyway. So it all works nicely, and the divergent I/O is gone. If this pickled your interest, you probably want to read up on rANS in general; Fabian Giesen (aka ryg) has some notes that work as a good starting point, but beware; some of this is pretty confusing. :-)

The following contributors got their Debian Developer accounts in the last two months:

• Ross Gammon (rossgammon)
• Balasankar C (balasankarc)
• Roland Fehrenbacher (rfehren)
• Jonathan Cristopher Carter (jcc)

The following contributors were added as Debian Maintainers in the last two months:

• Jos Guti rrez de la Concha
• Paolo Greppi
• Ming-ting Yao Wei
• Boyuan Yang
• Paul Hardy
• Fabian Wolff
• Moritz Schlarb
• Shengjing Zhu

Congratulations!

People I Met and will Remember

• Angela, my wife, I met daily on Jabber. Thanks for letting me go to this great DebConf17 conference and keeping our family up and running
• Andreas asking people to either impersonate his wife or adoptive daughter for a photo shooting. You gave such a touching talk on Friday, together with Minh from Vietnam.
• Holger for nagging us about stone age bugs in the Debian Blends package and the outdated software list in Debian Edu (Kernel 2.6.32 package are finally not mentioned anymore)
• Vagrant, Foetini and Alkis for there efforts on LTSP and their success in Greece with bringing Debian into Greek schools
• Tiago, Jerome and all the others from the local team, providing us with such great food and support. THANKS folks!!!
• Enrico who showed my his 20 liner version of nodm aka lightdm-autologin-greeter (and also made me curious on staticsite)
• Jonas Smedegaard for teaching me the solarized theme and loads of other things
• Siri for being around and really having a stand for making Debian look more like a product
• Dimitri John Ledkov for chiming in on Ayatana Indicators as next Indicators upstream for Ubuntu 18.04 LTS
• Chrys for chiming on .desktop file proxying, meet you back in #arctica on Freenode
• Sean for asking me daily, if my luggage had arrived (see below), as he shared the same fate during DebCamp
• the owner of that nice shop where I bought loads of clothes while waiting for my luggage still stuck in Hamburg
• Steven for looking into gcc compiler macros with me for nx-libs autotools conversion, also probably - luggage wise - the lightest traveller among us
• Fabian for sharing is sadness and pain about the FLOSS non-situation in schools all over Quebec
• Mario from New Zealand and Jos from the Netherlands chiming in on FLOSS and education on IRC after having watch my talk about Debian Edu / Skolelinux. Mario, we will soon ask you for opensourcing your teacher screen over WiFi solution...
• Lior who thinks about bringing Debian Edu / Skolelinux to Israel. (That would be awesome!)
• Rhonda for having time for my Debian Backports woes and probably having been quite forgiving ;-)
• Bobby who is a font engineer during the week and (used to be) a cave explorer and mapper in his spare time
• Ximin for providing deep insight in the key signing workflow and the caff approach to it
• Daniel for sharing work experiences and nudging me to go with Remote Desktop stuff (out of pure personal interest *g*, of course, but still)
• Tzfarir and Gunnar for a nice chat on the last night of DebConf

Topics I have worked on

• Finding my luggage
  • After I had arrived at Montreal Airport, I found out that my luggage stayed in Hamburg
  • So the first 4.5 days, I was continuously busy with calling Lufthansa for package item tracking...
  • Go shopping twice, to update my plastic bag of fresh clothes...
• MATE 1.18 in Debian
  • Finalize package builds of MATE 1.18 in Debian unstable (because of some GLib2.0 regression, thanks to Iain Lane for the prompt fix and upload)
• Debian Edu
  • clear up src:package debian-edu regarding the task files related to Debian Pure Blends
  • this work is still in progress...
• Debian Blends (esp. the blends-dev part of the blends src:package)
  • You can now have empty Depends: / Recommends: / Suggests: fields with the list of packages then starting in the next line.
  • It is now possible to have real Depends: fields in task files that become Depends: fields in debian/control. Packages targetting Depends: that are not in unstable get de-promoted to the Suggests: field in debian/control.
  • Tested with most available Debian Pure Blends meta-packages
  • I also pointed Daniel Pocock with his new GnuPG clean-room project towards Debian Pure Blends
• Ring: A 'new' distributed video chat tool without mediating servers. Good concept, however, we could not get it to work on the DebConf campus.
• Debian Design Team (which I am now a member of, I guess)
  • Dive into and out of the vision of a Debian Uniform set of packages, turning the collection of software in Debian into one thing.
  • Run my terminal applications now with the Base16 profile 'solarized-universal'. However, Debian Design will be much more than 16 colors in a console terminal.
  • Let's turn Debian into something like a potential product!
• Debian Policy:
  • I even helped with a Debian Policy bug...
• Skolab Groupware: Forking Kolab (v2) as a new project, named the Skolab Groupware. Instead of migrating my own mail server away from Kolab (v2), I chose continuing maintenance for it, at least for the core compoents:
  • https://github.com/Skolab-Groupware
  • Targetting small to medium sized installations with little administration effort.
  • I mainly ported Kolab's kolab-webadmin PHP project to a recent status so that it can run under Debian testing/unstable: https://github.com/Skolab-Groupware/skolab-webadmin
  • Big thanks to Siri Reiter for consulting me on artwork and for helping me putting together a simple logo for the project.
• nx-libs: Work on several PRs:
  • https://github.com/ArcticaProject/nx-libs/pull/496 (review + merge)
  • https://github.com/ArcticaProject/nx-libs/pull/498 (code)
  • https://github.com/ArcticaProject/nx-libs/pull/499 (code)
  • https://github.com/ArcticaProject/nx-libs/pull/501 (review + merge)
  • Play with KDE5 and nx-libs: IT WORKS!
• Weblate:
  • Become hosted by hosted Weblate for...
  • Ayatana Indicators
  • Arctica Project
  • Skolab Groupware
  Thanks to Michal iha for providing this fine translation service

Talks and BoFs

• Talk: Supporting Debian Edu / Skolelinux as a Product: Lessons Learned
  • Schedule: https://debconf17.debconf.org/talks/169
  • Video: http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/su...
  • Outcome: https://sunweavers.net/blog/node/59
• Talk: Ayatana Indicators
  • Schedule: https://debconf17.debconf.org/talks/168
  • Video: http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/ay...
  • Outcome: https://sunweavers.net/blog/node/60
• Ad-hoc BoF: Bits from the Debian+Ubuntu MATE Packaging Team
  • Schedule: https://debconf17.debconf.org/talks/223
  • Outcome: still to be published...
• Ad-hoc BoF: Debian for Remote Desktop Computing
  • Schedule: https://debconf17.debconf.org/talks/60
  • Outcome: still to be published...

Packages Uploaded to Debian unstable

• mate-settings-daemon
• mate-dock-applet
• brisk-menu
• mate-optimus
• caja-actions
• mate-common
• mate-tweak
• plank
• freerdp (2x)
• freerdp2
• gosa-plugin-mailaddress

Packages Uploaded to Debian NEW

• python-wither
• lightdm-autologin-greeter
• caja-rename

I also looked into lightdm-webkit2-greeter, but upstream is in the middle of a transition from Gtk3 to Qt5, so this has been suspended for now. Packages Uploaded to oldstable-/stable-proposed-updates or -security

• freerdp (1.1) (actually twice, one of them a security upload)
• gosa-plugin-mailaddress
• mate-themes

Other Package related Stuff

• Prepare upload of caja-admin by asking for release tags upstream
• Talk Clint Byrums into a fresh upload of the long not touch undistract-me package
• Breed on different desktop layouts for Debian MATE (like in Ubuntu MATE)
• Do quite a bit of GnuPG key signing
• Update my consent with NM to pick up my work on collab-maint request processing again

Thanks to Everyone Making This Event Possible A big thanks to everyone who made it possible for me to attend this event!!!

What happened in the Reproducible Builds effort between June 19th and June 25th 2016. Media coverage

• Holger Levsen gave a talk at openSUSE Conference 2016 explaining the general idea and status of Reproducible Builds. This talk is available as video recording.
• This was followed by Bernhard Wiedemannn, detailing his work on Reproducible Builds for openSUSE which is also available as video recording:
  • openSUSE uses SOURCE_DATE_EPOCH now too
  • How to create bit-for-bit identical RPMs
  • How strip-nondeterminism is Python and thus unsuitable for the openSUSE base system
• Mozilla awarded $77k to work on reproducible builds for Tails. The goal is to enable anyone (given sufficient technical skills and hardware resources) to rebuild from source a given Tails release, in order to independently verify that it matches the ISO image that was published. A substantial part of this work will be done in Debian: for example, to make the side-effects of some packages' post-installation scripts deterministic. On the longer term, this work should benefit other projects that want to make their own builds reproducible (e.g. operating system images for the cloud and embedded systems, operating system installation media, other Live systems).

GSoC and Outreachy updates

• Valerie Young published a report detailing what she did the last week regarding improving tests.reproducible-builds.org/debian.
• Ceridwen announced reprotest's arrival in the NEW queue and discussed autopkgtest's layout.

Toolchain fixes

• Anton Gladky uploaded an NMU of python-setuptools, which sorts entries in native_libs.txt files (#825857).

Other upstream fixes Emil Velikov searched on IRC for hints on how to guarantee unique values during build to invalidate shader caches in Mesa, when also no VCS information is available. A possible solution is a timestamp, which is unique enough for local builds, but can still be reproducible by allowing it to be overwritten with SOURCE_DATE_EPOCH. Packages fixed The following 9 packages have become reproducible due to changes in their build dependencies: cclib librun-parts-perl llvm-toolchain-snapshot python-crypto python-openid r-bioc-shortread r-bioc-variantannotation ruby-hdfeos5 sqlparse The following packages have become reproducible after being fixed:

• allegro4.4/2:4.4.2-9 by Tobias Hansen, original patch by Reiner Herrmann.
• atomicparsley/0.9.6-1 by Jonas Smedegaard.
• dwarfutils/20160613-1 by Fabian Wolff, original patch by Reiner Herrmann.
• dwm/6.1-3 by Hugo Lefeuvre, original patch by Reiner Herrmann.
• funtools/1.4.6+git150811-3 by Ole Streicher, original patch by Alexis Bienven e.
• golang-github-appc-spec/0.8.4+dfsg-1 by Dmitry Smirnov.
• golang-github-appc-docker2aci/0.11.1+dfsg-1 Dmitry Smirnov.
• hdf-eos5/5.1.15.dfsg.1-7 by Alastair McKinstry.
• hmmer2/2.3.2-11 by Sascha Steinbiss, original patch by Chris Lamb.
• jpy/0.8-2 by Alastair McKinstry.
• lazarus/1.6+dfsg-4 by Paul Gevers.
• pgbackrest/1.02-2 by Adrian Vondendriesch.
• siege/4.0.2-1 by Josue Abarca.
• starlink-pal/0.5.0-4 by Ole Streicher, original patch by Chris Lamb.
• stylish-haskell/0.5.17.0-2 by Sean Whitton.
• xprobe/0.3-3 by Sophie Brun, original patch by Reiner Herrmann.

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

• hdfeos4/2.19v1.00+dfsg.1-5 by Alastair McKinstry.
• icu4j/57.1-2 by Tony Mancill, original patch by Chris Lamb.
• pari/2.7.6-1 by Bill Allombert,

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

• #827684 against cgoban by Chris Lamb: set SHELL to static value.
• #827731 against tin by Alexis Bienven e: drop patch which overwrites __DATE__/__TIME__ macros, since gcc can handle it now
• #827863 against swedish by Alexis Bienven e: use C locale for sorting.
• #827987 against glances by Chris Lamb: Use SOURCE_DATE_EPOCH for embedded timestamp.
• #827994 against cmtk by Chris Lamb: use C locale for sorting.
• #828008 against aghermann by Chris Lamb: honour SOURCE_DATE_EPOCH for timestamps embedded into manpages.
• #828012 against bind9 by Chris Lamb: honour SOURCE_DATE_EPOCH for embedded timestamp.
• #828017 against frog by Chris Lamb: don't include pyc/pyo files in the package.
• #828021 against extra-cmake-modules by Scarlett Clark: normalize permission and file order in tarballs.
• #828060 against libffado by Chris Lamb: exclude file with test output from package.
• #828066 against gsmlib by Chris Lamb: honour SOURCE_DATE_EPOCH for timestamps embedded into manpages.
• #828067 against grib-api by Chris Lamb: exclude pyc files from package.
• #828122 against libxmlbird by Chris Lamb: sort list of globbed files.
• #828123 against magnum by Chris Lamb: use static value for embedded hostname.
• #828131 against pyjwt by Chris Lamb: exclude coverage data from package.
• #828145 against mkdocs by Chris Lamb: honour SOURCE_DATE_EPOCH for embedded timestamp.
• #828164 against zeal by Chris Lamb: use UTC for embedded timestamp.
• #828168 against x42-plugins by Daniel Shahaf: use printf instead of non-portable echo.

Package reviews 139 reviews have been added, 20 have been updated and 21 have been removed in this week. New issues found:

• timestamps_in_pdf_generated_by_reportlab
• r_base_appends_built_header_to_description_files
• timestamps_in_documentation_generated_by_mkdocs

53 FTBFS bugs have been reported by Chris Lamb, Santiago Vila and Mateusz ukasik. diffoscope development

• Satyam Zode added argument completion.
• Chris Lamb made the confusing "No differences found inside, yet data differs" message less confusing.

Quote of the week "My builds are so reproducible, they fail exactly every second time." Johannes Ziemke (@discordianfish) Misc. This week's edition was written by Chris Lamb (lamby), Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

What happened in the Reproducible Builds effort between June 5th and June 11th 2016: Media coverage Ed Maste gave a talk at BSDCan 2016 on reproducible builds (slides, video). GSoC and Outreachy updates Weekly reports by our participants:

• Scarlett Clark worked on making some packages reproducible, focusing on KDE backend and utility programs.
• Ceridwen published an initial design for the interface for reprotest, including a discussion on different types of build variations and the difficulties of specifying certain types of variations.
• Valerie Young improved documentation for building our tests website, began migrating Debian-specific pages into a new namespace, and planned future work around its navigation.

Documentation update - Ximin Luo proposed a modification to our SOURCE_DATE_EPOCH spec explaining FORCE_SOURCE_DATE. Some upstream build tools (e.g. TeX, see below) have expressed a desire to control which cases of embedded timestamps should obey SOURCE_DATE_EPOCH. They were not convinced by our arguments on why this is a bad idea, so we agreed on an environment variable FORCE_SOURCE_DATE for them to implement their desired behaviour - named generically, so that at least we can set it centrally. For more details, see the text just linked. However, we strongly urge most build tools not to use this, and instead obey SOURCE_DATE_EPOCH unconditionally in all cases. Toolchain fixes

• TeX Live 2016 released with SOURCE_DATE_EPOCH support for all engines except LuaTeX and original TeX.
• Continued discussion (alternative archive) with TeX upstream, about SOURCE_DATE_EPOCH corner cases, eventually resulting in the FORCE_SOURCE_DATE proposal from above.
• gcc-5/5.4.0-4 by Matthias Klose now avoids storing -fdebug-prefix-map in DW_AT_producer, thanks to original patch by Daniel Kahn Gillmor.
• sphinx/1.4.3-1 by Dmitry Shachnev now drops Debian-specific patches relating to SOURCE_DATE_EPOCH applied upstream, original patch by Alexis Bienven e.
• asciidoctor/1.5.4-2 by C dric Boutillier now supports SOURCE_DATE_EPOCH, thanks to original patch by Alexis Bienven e.
• dh-python/1.5.4-2 by Piotr O arowski now behaves better in some cases, thanks to original patch by Chris Lamb.

Packages fixed The following 16 packages have become reproducible due to changes in their build-dependencies: apertium-dan-nor apertium-swe-nor asterisk-prompt-fr-armelle blktrace canl-c code-saturne coinor-symphony dsc-statistics frobby libphp-jpgraph paje.app proxycheck pybit spip tircd xbs The following 5 packages are new in Debian and appear to be reproducible so far: golang-github-bowery-prompt golang-github-pkg-errors golang-gopkg-dancannon-gorethink.v2 libtask-kensho-perl sspace The following packages had older versions which were reproducible, and their latest versions are now reproducible again after being fixed:

• excellent-bifurcation/0.0.20071015-8 by Vincent Cheng, original patch by Reiner Herrmann.
• gnurobbo/0.68+dfsg-2 by Stephen Kitt, original patch by Reiner Herrmann.

The following packages have become reproducible after being fixed:

• gdbm/1.8.3-14 by Matthias Klose, original patch by J r my Bobbio.
• miceamaze/4.2.1-3 by Sarah COUDERT, original patch by Reiner Herrmann.
• netcdf/1:4.4.1~rc2-1~exp3 by Bas Couwenberg.
• osmo-bts/0.4.0-2 by Ruben Undheim.
• pd-hcs/0.1-3 by IOhannes m zm lnig.
• pd-hid/0.7-2 by IOhannes m zm lnig.
• python-certbot/0.8.0-1 by Harlan Lieberman-Berg, original patch by Chris Lamb.
• python-csb/1.2.3+dfsg-3 by Sascha Steinbiss.
• python-osprofiler/1.3.0-2 by Thomas Goirand.
• usb-modeswitch-data/20160112-3 by Didier Raboud, original patch by intrigeri.

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

• bzr/2.7.0-7 by Jelmer Vernoo .
• clanlib/1.0~svn3827-5 by Stephen Kitt, original patch by Chris Lamb.
• dwarfutils/20160507+git20160523.9086738-1 by Fabian Wolff.
• fakeroot/1.20.2-2 by Clint Adams, original patch.
• fastqtl/2.184+dfsg-2 by Dylan A ssi, original patch by Chris Lamb.
• gnuplot/5.0.3+dfsg3-3 by Anton Gladky.
• lazarus/1.6+dfsg-3 by Paul Gevers.
• python-pygit2/0.24.0-3 by Ond ej Nov .

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

• #806331 against xz-utils by Ximin Luo: make the selected POSIX shell stable accross build environments
• #806494 against gnupg by intrigeri: Make man pages not embed a build-time dependent timestamp
• #806945 against bash by Reiner Herrmann and Ximin Luo: Use the system man2html, and set PGRP_PIPE unconditionally.
• #825857 against python-setuptools by Anton Gladky: sort libs in native_libs.txt
• #826408 against brainparty by Reiner Herrmann: Sort object files for deterministic linking order
• #826416 against blockout2 by Reiner Herrmann: Sort the list of source files
• #826418 against xgalaga++ by Reiner Herrmann: Sort source files to get a deterministic linking order
• #826423 against kraptor by Reiner Herrmann: Sort source files for deterministic linking order
• #826431 against traceroute by Reiner Herrmann: Sort lists of libraries/source/object files
• #826544 against doc-debian by intrigeri: make the created files stable regardless of the locale
• #826676 against python-openstackclient by Chris Lamb: make the build reproducible
• #826677 against cadencii by Chris Lamb: make the build reproducible
• #826760 against dctrl-tools by Reiner Herrmann: Sort object files for deterministic linking order
• #826951 against slicot by Alexis Bienven e: please make the build reproducible (fileordering)
• #826982 against hoichess by Reiner Herrmann: Sort object files for deterministic linking order

Package reviews 68 reviews have been added, 19 have been updated and 28 have been removed in this week. New and updated issues:

• cryptographic_signature
• timestamps_in_maven_version_files
• ftbfs_build-indep_not_build_on_some_archs
• timestamps_added_by_xbean_spring
• timestamps_in_maven_metadata_local_xml_files
• timestamps_in_documentation_generated_by_asciidoctor

26 FTBFS bugs have been reported by Chris Lamb, 1 by Santiago Vila and 1 by Sascha Steinbiss. diffoscope development

• Mattia Rizzolo uploaded diffoscope/54 to jessie-backports.

strip-nondeterminism development

• Mattia uploaded strip-nondeterminism/0.018-1 to jessie-backports, to support a debhelper backport.
• Andrew Ayer uploaded strip-nondeterminism/0.018-2 fixing #826700, a packaging improvement for Multi-Arch to ease cross-build situations.
• 2 days later Andrew released strip-nondeterminism/0.019; now strip-nondeterminism is able to:
  • recursively normalize JAR files embedded within JAR files (#823917)
  • clamp the timestamp, the same way tar >=1.28-2.2 can (for now available only for gzip archives)

disorderfs development

• Andrew Ayer released disorderfs/0.4.3, fixing a issue with umask handling (#826891)

tests.reproducible-builds.org

• Valerie Young namespaced the Debian-specific pages to /debian/ namespace, with redirects to for the previous URLs.
• Holger Levsen improved the reliability of build jobs: the availability of both build nodes (for a given build) is now being tested when a build job is started, to better cope when one of the 25 build nodes go down for some reason.
• Ximin Luo improved the index of identified issues to include the total popcon scores of each issue, which is now also used for sorting that page.

Misc. Steven Chamberlain submitted a patch to FreeBSD's makefs to allow reproducible builds of the kfreebsd installer. Ed Maste committed a patch to FreeBSD's binutils to enable determinstic archives by default in GNU ar. Helmut Grohne experimented with cross+native reproductions of dash with some success, using rebootstrap. This week's edition was written by Ximin Luo, Chris Lamb, Holger Levsen, Mattia Rizzolo and reviewed by a bunch of Reproducible builds folks on IRC.

What happened in the Reproducible Builds effort between May 22nd and May 28th 2016: Media coverage

• Holger Levsen was invited to RIPE72 to talk about Reproducible Builds and a hope for a more secure future (Video, 25min and slides) in the cooperative workgroup.
• Scarlett Clark blogged about her first week of Outreachy work trying to make packages build reproducible, describing her efforts with kapptemplate, choqok and kdevplatform.

Documentation update

• The wiki page TimestampsProposal has been extended to cover more usage examples and to list more softwares supporting SOURCE_DATE_EPOCH. (Axel Beckert, Dhole and Ximin Luo)
• h01ger started a reference card for tools and information about reproducible builds but hasn't progressed much yet. Help with it is much welcome, this is also a good opportunity to learn about this project The idea is simply to have one coherent place with pointers to all the stuff we have and provide, without repeating nor replacing other documentation.

Toolchain fixes

• Alexis Bienven e submitted a patch (#824050) against emacs24 for SOURCE_DATE_EPOCH support in autoloads files, but upstream already disabled timestamps by default some time before.
• proj/4.9.2-3 uploaded by Bas Couwenberg (original patch by Alexis Bienven ) properly initializes memory with zero to prevent the nad2bin tool from leaking random memory content into output artefacts.
• Reiner Herrmann submitted a patch (#825569, upstream) against Ruby to sort object files in generated Makefiles, which are used to compile C sources that are part of Ruby projects.

Packages fixed The following 18 packages have become reproducible due to changes in their build dependencies: canl-c configshell dbus-java dune-common frobby frown installation-guide jexcelapi libjsyntaxpane-java malaga octave-ocs paje.app pd-boids pfstools r-cran-rniftilib scscp-imcce snort vim-addon-manager The following packages have become reproducible after being fixed:

• apngasm/2.7-2 by Manuel A. Fernandez Montecelo, original patch by Reiner Herrmann.
• apngdis/2.5-2 by Manuel A. Fernandez Montecelo, original patch by Reiner Herrmann.
• apngopt/1.2-2 by Manuel A. Fernandez Montecelo, original patch by Reiner Herrmann.
• asio/1:1.10.6-4 by Markus Wanner.
• bowtie/1.1.2-4 by Sascha Steinbiss.
• bowtie2/2.2.9-2 by Sascha Steinbiss.
• breeze/4:5.6.4-1 by Maximiliano Curia, original patch by Eduard Sanou.
• cain/1.10+dfsg-2 by Sascha Steinbiss.
• cdist/4.0.0-2 by Dmitry Bogatov, original patch by Chris Lamb.
• crossroads/2.81-1 by Reiner Herrmann.
• elasticsearch/1.7.5-1 by Emmanuel Bourg.
• gdal/2.1.0+dfsg-3 by Bas Couwenberg, original patch by Alexis Bienven e.
• grass/7.0.4-2 by Bas Couwenberg, original patch by Alexis Bienven e.
• jaligner/1.0+dfsg-3 by Michael R. Crusoe.
• khmer/2.0+dfsg-7 by Michael R. Crusoe.
• libhdf4/4.2.11-2 by Bas Couwenberg.
• libjspeex-java/0.9.7-4 by Emmanuel Bourg.
• libmialm/1.0.9-1 by Gert Wollny.
• libtheora/1.1.1+dfsg.1-10 by Petter Reinholdtsen.
• odil/0.6.0-2 by Julien Lamy.
• pacemaker/1.1.15~rc3-1 by Ferenc W gner.
• pvm/3.4.6-1 by James Clarke.
• rna-star/2.5.2a+dfsg-2 by Sascha Steinbiss.
• smalt/0.7.6-6 by Sascha Steinbiss.
• soapdenovo2/240+dfsg-3 by Sascha Steinbiss.
• svtplay-dl/1.1-1 by Olof Johansson.
• t-coffee/11.00.8cbe486-3 by Sascha Steinbiss.
• toppred/1.10-3 by Sascha Steinbiss.
• transdecoder/3.0.0+dfsg-2 by Michael R. Crusoe.
• vpim/0.695-1.4 by Herbert Parentes Fortes Neto.
• vtk-dicom/0.7.7-2 by Gert Wollny.
• xplc/0.3.13-6 by Reiner Herrmann.

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

• codeblocks/16.01+dfsg-1 by Vincent Cheng, original patch by Fabian Wolff.
• gmt/5.2.1+dfsg-6 by Bas Couwenberg, original patch by Alexis Bienven .

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

• #803547 against bbswitch (reopened) by Reiner Herrmann: sort members of tar archive
• #806945 against bash (follow-up) by Reiner Herrmann: use system man2html instead of embedded copy
• #825122 against kapptemplate by Scarlett Clark: set owner/group of members in tarball to root
• #825138 against console-setup by Reiner Herrmann: fix umask issue; sort entries in shell script; sort fontsets/charmaps locale-independently
• #825285 against kodi by Lukas Rechberger: replace build timestamps with version numbers
• #825322 against choqok by Scarlett Clark: force UTF-8 locale so kconfig_compiler behaves correctly
• #825544 against wavemon by Reiner Herrmann: sort list of object files
• #825545 against dwm by Reiner Herrmann: sort list of header files
• #825547 against tennix by Reiner Herrmann: sort list of data files being archived
• #825584 against ffmpeg2theora by Reiner Herrmann: sort list of source files
• #825588 against kball by Reiner Herrmann: sort list of source files
• #825634 against miceamaze by Reiner Herrmann: sort list of object files
• #825643 against dash by Reiner Herrmann: fix sorting of struct members in generated source file
• #825655 against libselinux by Reiner Herrmann: sort list of source files
• #825656 against libsepol by Reiner Herrmann: sort list of source files
• #825674 against libsemanage by Reiner Herrmann: sort list of source files

Package reviews 123 reviews have been added, 57 have been updated and 135 have been removed in this week.

• 5 new issues have been identified:
  • timestamps_in_pdf_generated_by_imagemagick
  • ruby_mkmf_makefile_unsorted_objects
  • timestamps_from_timestamp_macro
  • scons_doesnt_pass_environment_to_build_tools
  • timestamps_from_cpp_macros_in_d

21 FTBFS bugs have been reported by Chris Lamb and Santiago Vila. strip-nondeterminism development

• strip-nondeterminsim development: treat *.htb as Zip files (by Sascha Steinbiss).
• strip-nondeterminism 0.017-1 uploaded by h01ger.

tests.reproducible-builds.org

• The kde pkg set was extended, though the change ain't visible yet, as there are currently non-installable packages in it (and so the set can't be computed). (h01ger)

Misc.

• Mattia improved misc.git/reports (=the tools to help writing the weekly statistics for this blog) some more.

This week's edition was written by Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

What happened in the Reproducible Builds effort between May 8th and May 14th 2016: Documentation updates

• Ximin Luo spent some work on improving and updating our documentation:
  • updated the SOURCE_DATE_EPOCH adoption page at wiki.debian.org/ReproducibleBuilds/TimestampsProposal with a compilation of our reasonings versus common arguments encountered with package maintainers and upstream developers.
  • updated wiki.debian.org/ReproducibleBuilds/Howto
  • and also moved resolved issues to wiki.debian.org/ReproducibleBuilds/OldIssues.
• https://anonscm.debian.org/git/reproducible/ has been cleaned up by Ximin, including the removal of the link from diffoscope.git to debbindiff.git.

Toolchain fixes

• dpkg 1.18.7 has been uploaded to unstable, after which Mattia Rizzolo took care of rebasing our patched version.
  • this prompted h01ger to restart the discussion about reproducible dpkg for sid and stretch
  • to which Guillem replied with a status update.
• gcc-5 and gcc-6 migrated to testing with the patch to honour SOURCE_DATE_EPOCH
• Ximin Luo started an upstream discussion with the Ghostscript developers.
• Norbert Preining has uploaded a new version of texlive-bin with these changes relevant to us:
  • imported Upstream version 2016.20160512.41045 support for suppressing timestamps (SOURCE_DATE_EPOCH) (Closes: #792202)
  • add support for SOURCE_DATE_EPOCH also to luatex
• cdbs 0.4.131 has been uploaded to unstable by Jonas Smedegaard, fixing these issues relevant to us:
  • #794241: export SOURCE_DATE_EPOCH. Original patch by akira
  • #764478: call dh_strip_nondeterminism if available. Original patch by Holger Levsen
• libxslt 1.1.28-3 has been uploaded to unstable by Mattia Rizzolo, fixing the following toolchain issues:
  • #823857: backport patch from upstream to provide stable IDs in the genrated documents.
  • #791815: Honour SOURCE_DATE_EPOCH when embedding timestamps in docs. Patch by Eduard Sanou.

Packages fixed The following 28 packages have become newly reproducible due to changes in their build dependencies: actor-framework ask asterisk-prompt-fr-armelle asterisk-prompt-fr-proformatique coccinelle cwebx d-itg device-tree-compiler flann fortunes-es idlastro jabref konclude latexdiff libint minlog modplugtools mummer mwrap mxallowd mysql-mmm ocaml-atd ocamlviz postbooks pycorrfit pyscanfcs python-pcs weka The following 9 packages had older versions which were reproducible, and their latest versions are now reproducible again due to changes in their build dependencies: csync2 dune-common dune-localfunctions libcommons-jxpath-java libcommons-logging-java libstax-java libyanfs-java python-daemon yacas The following packages have become newly reproducible after being fixed:

• asymptote/2.38-1 by Norbert Preining, original patch by Alexis Bienven e.
• bnd/2.4.1-4 by Emmanuel Bourg.
• cgal/4.8-4 by Joachim Reichel.
• courier/0.76.1-2 by Ond ej Sur , original patch by Alexis Bienven e.
• dict-foldoc/20160505-1 by Iustin Pop, original patch by Reiner Herrmann.
• emoslib/2:4.4.1-2 by Alastair McKinstry, original patch by boyska.
• libksba/1.3.4-3 by Andreas Metzler.
• mp4h/1.3.1-15 by Axel Beckert.
• stk/4.5.2+dfsg-2 by Felipe Sateler, original patch by Alexis Bienven e.
• sympow/1.023-7 by Jerome Benoit.
• x11proto-input/2.3.2-1 by Julien Cristau, original patch by Eduard Sanou.

The following packages had older versions which were reproducible, and their latest versions are now reproducible again after being fixed:

• klibc/2.0.4-9 by Ben Hutchings.

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

• allegro4.4/2:4.4.2-8 by Andreas R nnquist, original patch by Daniel Shahaf.
• gearmand/1.0.6-7 by Alexandre Mestiashvili, original patch by Chris Lamb.
• mame/0.172-1 by Jordi Mallach.
• python-babel/1.3+dfsg.1-7 by Jean-Michel Vourg re, original patch by Val Lorentz.
• openttd/1.6.0-1 by Matthijs Kooijman.
• blender/2.77.a+dfsg0-4 by Matteo F. Vescovi, original patch by Campbell Burton.
• unburden-home-dir/0.4 by Axel Beckert.
• refpolicy/2:2.20140421-10 by Laurent Bigonville, original patch by Chris Lamb.
• kdiff3/0.9.98-3 by Eike Sauer.

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

• #787424 against emacs24 by Alexis Bienven e: order hashes when generating .el files
• #823764 against sen by Daniel Shahaf: render the build timestamp in a consistent timezone
• #823797 against openclonk by Alexis Bienven e: honour SOURCE_DATE_EPOCH
• #823961 against herbstluftwm by Fabian Wolff: honour SOURCE_DATE_EPOCH
• #824049 against emacs24 by Alexis Bienven e: make start value of gensym-counter reproducible
• #824050 against emacs24 by Alexis Bienven e: make autoloads files reproducible
• #824182 against codeblocks by Fabian Wolff: honour SOURCE_DATE_EPOCH
• #824263 against cmake by Reiner Herrmann: sort file lists from file(GLOB ...)

Package reviews 344 reviews have been added, 125 have been updated and 20 have been removed in this week. 14 FTBFS bugs have been reported by Chris Lamb. tests.reproducible-builds.org

• bpi0 has been reinstalled with a new ssd. (vagrant/h01ger)
• A new navigation menu for the Debian pages at https://tests.reproducible-builds.org/ has been implemented. (h01ger)

Misc. Dan Kegel sent a mail to report about his experiments with a reproducible dpkg PPA for Ubuntu. According to him sudo add-apt-repository ppa:dank/dpkg && sudo apt-get update && sudo apt-get install dpkg should be enough to get reproducible builds on Ubuntu 16.04. This week's edition was written by Ximin Luo and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

This month I've worked on the following things for Debian: To begin with that, I've set up a Debhelper sequencer script for dh-buildinfo¹, this add-on now can be used with dh $@ --with buildinfo in deb/rules instead of having to explicitly call it somewhere in an override. Debops I've set up initial Debian packages of Debops², a collection of fine crafted Ansible roles and playbooks especially for Debian servers, shipped with a couple of convenience and wrapper scripts in Python³. There are two binary packages, one for the toolset (debops), and the other for the playbooks and roles of the project (debops-playbooks). The application is easy to use, just initialize a new project with debops-init foo and add your server(s) to foo/ansible/inventory/hosts belonging to groups representing services and things you want to employ on them. Like the group [debops_gitlab] automatically installs a complete running Gitlab setup on one or a multitude of servers in the same run with the debops command⁴. Use other groups like [debops_mariadb_server] accordingly in the same host inventory. Ansible runs agent less, so you don't have to prepare freshly setup servers with nothing special to use that tool randomly (like on localhost). The list of things you could deploy with Debops is quite amazing and you've got dozens of services at your hand. The new packages are currently in experimental because they need some more fine tuning, like there are a couple of minor error messages which recently occur using it, but it works well. The (early staged) documentation unfortunately couldn't be packaged because of the scattered resp. collective nature of the project (all parts have their own Github repositories)⁵, and also how to generate the upstream tarball remains a bit of a challenge (currently, it's the outcome of debops-init)⁶. I'll have this package in unstable soon. More info on Debops is coming up, then. Hashicorp's Packer I'm very glad to announce that Packer⁷ is ready being available in unstable, and the two year old RFP bug could be finally closed⁸. It's another great and much convenient devops tool which does a lot of different things in an automated fashion using only a single "one-argument" CLI tool in combination with a couple of lines in a configuration script (thanks to Yaroslav Halchenko for the tip). Packer helps creating machine images for different platforms. This is like when you use e.g. Debian installations in a Qemu box for testing or development purposes. Instead of setting up a new virtual machine manually like installing Debian on another computer this process could be automated with Packer, like I've written about in this blog entry here⁹. You just need a template containing instructions for the included Qemu-builder and a preseeding script for the Debian installer, and there you go drinking your coffee while Packer does all the work for you: downloading the installation ISO image, creating the new virtual harddrive, booting the emulator, running the whole installation process automatically like answering questions, selecting things, rebooting without ISO image to complete the installation etc. A couple of minutes and you have a new pre-baked virtual machine image like from a vendoring machine, a fresh one everytime you need it. Packer¹⁰ supports a number of builders for different target platforms (desktop virtualization solutions as much as public cloud providers and private cloud software), can build in parallel, and also the full range of common provisioners can be employed in the process to equip the newly installed OSs. Vagrant boxes could be generated by one of the included postprocessors. I'll write more on Packer here on this blog, soon. There were more then two dozens of packages missing to complete Packer¹¹, which is the achievement of combined forces within the pkg-go group. Much thanks esp. to Alexandre Viau who have worked on the most of the needed new packages. Thanks also to the FTP-masters which were always very quick in reviewing the Go packages, so that it could be proceeded to build and package the sub dependent new ones always consecutively. Squirrel3 I've didn't had the most work with it and just sponsored this for Fabian Wolff, but want to highlight here that there's a new package of Squirrel¹² now available in Debian¹³. Squirrel is a lightweight scripting language, somewhat comparable to Lua. It's fully object-oriented and highly embeddable, it's used in a lot of commerical computer games under the hood for implementing intelligence for bots next to other things¹⁴, but also for the Internet of Things (it's embedded in hardware from Electric Imp). Squirrel functions could be called from C++¹⁵. I've filed an ITP bug for Squirrel already in 2011 (#651195), but always something else got in the way, and it ended up being an RFP. I'm really glad that it got picked up and completed. misc There were a couple of uploads on updated upstream tarballs and for fixing bugs, namely afl/2.10b-1 and 2.11b-1, python-afl/0.5.3-1, pyutilib/5.3.2-1, pyomo/4.3.11327-1, libvigraimpex/1.10.0+git20160211.167be93dfsg-2 (fix of #820429, thanks for Tobias Frost), and gamera/3.4.2+svn1454-1. For the pkg-go group, I've set up a new package of github-mitchellh-ioprogress (which is needed by the official DigitalOcean CLI tool doctl, now RFP #807956 instead of ITP due to the lack of time - again facing a lot of missing packages), and provided a little patch for dh-make-golang updating some standards¹⁶. For Packer I've also updated azure-go-autorest and azure-sdk as team upload (#821938, #821832), but it came out that the project which is currently under heavy development towards a new official release broke a lot in the past weeks (and no Git branching have been used), so that Packer as a matter of fact needed a vendored snapshot, although there have been only a couple of commits in between. Docker-registry hat the same problem with the new package of azure-sdk/2.1.1~beta1, so that it needed to be fixed, too (#822146). By the way, the tool ratt¹⁷ comes very handy for automatically test building down all reverse dependencies, not only for Go packages (thanks to Tianon Gravi for the tip). Finally, I've posted the needed reverse depencies as RFP bugs for Terraform¹⁸ (again quite a lot), Vuls¹⁹, and cve-dictionary²⁰, which is needed for Vuls. I'll let them rest a while waiting to get picked up before working anything down.