Welcome to the December 2024 report from the Reproducible Builds project! Our monthly reports outline what we ve been up to over the past month and highlight items of news from elsewhere in the world of software supply-chain security when relevant. As ever, however, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. Table of contents:

1. reproduce.debian.net
2. debian-repro-status
3. On our mailing list
4. Enhancing the Security of Software Supply Chains
5. diffoscope
6. Supply-chain attack in the Solana ecosystem
7. Website updates
8. Debian changes
9. Other development news
10. Upstream patches
11. Reproducibility testing framework

---

reproduce.debian.net Last month saw the introduction of reproduce.debian.net. Announced at the recent Debian MiniDebConf in Toulouse, reproduce.debian.net is an instance of rebuilderd operated by the Reproducible Builds project. rebuilderd is our server designed monitor the official package repositories of Linux distributions and attempts to reproduce the observed results there. This month, however, we are pleased to announce that not only does the service now produce graphs, the reproduce.debian.net homepage itself has become a start page of sorts, and the amd64.reproduce.debian.net and i386.reproduce.debian.net pages have emerged. The first of these rebuilds the amd64 architecture, naturally, but it also is building Debian packages that are marked with the no architecture label, all. The second builder is, however, only rebuilding the i386 architecture. Both of these services were also switched to reproduce the Debian trixie distribution instead of unstable, which started with 43% of the archive rebuild with 79.3% reproduced successfully. This is very much a work in progress, and we ll start reproducing Debian unstable soon. Our i386 hosts are very kindly sponsored by Infomaniak whilst the amd64 node is sponsored by OSUOSL thank you! Indeed, we are looking for more workers for more Debian architectures; please contact us if you are able to help.

debian-repro-status Reproducible builds developer kpcyrd has published a client program for reproduce.debian.net (see above) that queries the status of the locally installed packages and rates the system with a percentage score. This tool works analogously to arch-repro-status for the Arch Linux Reproducible Builds setup. The tool was packaged for Debian and is currently available in Debian trixie: it can be installed with apt install debian-repro-status.

On our mailing list On our mailing list this month:

• Bernhard M. Wiedemann wrote a detailed post on his long journey towards a bit-reproducible Emacs package. In his interesting message, Bernhard goes into depth about the tools that they used and the lower-level technical details of, for instance, compatibility with the version for glibc within openSUSE.
• Shivanand Kunijadar posed a question pertaining to the reproducibility issues with encrypted images. Shivanand explains that they must use a random IV for encryption with AES CBC. The resulting artifact is not reproducible due to the random IV used. The message resulted in a handful of replies, hopefully helpful!
• User Danilo posted an in interesting question related to their attempts in trying to achieve reproducible builds for Threema Desktop 2.0. The question resulted in a number of replies attempting to find the right combination of compiler and linker flags (for example).
• Longstanding contributor David A. Wheeler wrote to our list announcing the release of the Census III of Free and Open Source Software: Application Libraries report written by Frank Nagle, Kate Powell, Richie Zitomer and David himself. As David writes in his message, the report attempts to answer the question what is the most popular Free and Open Source Software (FOSS)? .
• Lastly, kpcyrd followed-up to a post from September 2024 which mentioned their desire for someone to implement a hashset of allowed module hashes that is generated during the kernel build and then embedded in the kernel image , thus enabling a deterministic and reproducible build. However, they are now reporting that somebody implemented the hash-based allow list feature and submitted it to the Linux kernel mailing list . Like kpcyrd, we hope it gets merged.

Enhancing the Security of Software Supply Chains: Methods and Practices Mehdi Keshani of the Delft University of Technology in the Netherlands has published their thesis on Enhancing the Security of Software Supply Chains: Methods and Practices . Their introductory summary first begins with an outline of software supply chains and the importance of the Maven ecosystem before outlining the issues that it faces that threaten its security and effectiveness . To address these:

First, we propose an automated approach for library reproducibility to enhance library security during the deployment phase. We then develop a scalable call graph generation technique to support various use cases, such as method-level vulnerability analysis and change impact analysis, which help mitigate security challenges within the ecosystem. Utilizing the generated call graphs, we explore the impact of libraries on their users. Finally, through empirical research and mining techniques, we investigate the current state of the Maven ecosystem, identify harmful practices, and propose recommendations to address them.

A PDF of Mehdi s entire thesis is available to download.

diffoscope diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 283 and 284 to Debian:

• Update copyright years. [ ]
• Update tests to support file 5.46. [ ][ ]
• Simplify tests_quines.py::test_ differences,differences_deb to simply use assert_diff and not mangle the test fixture. [ ]

Supply-chain attack in the Solana ecosystem A significant supply-chain attack impacted Solana, an ecosystem for decentralised applications running on a blockchain. Hackers targeted the @solana/web3.js JavaScript library and embedded malicious code that extracted private keys and drained funds from cryptocurrency wallets. According to some reports, about $160,000 worth of assets were stolen, not including SOL tokens and other crypto assets.

Website updates Similar to last month, there was a large number of changes made to our website this month, including:

• Chris Lamb:
  • Make the landing page hero look nicer when the vertical height component of the viewport is restricted, not just the horizontal width.
  • Rename the Buy-in page to Why Reproducible Builds? [ ]
  • Removing the top black border. [ ][ ]
• Holger Levsen:
  • Fixed a number of issues on the 2024 Summit page, including fixing the path to a sponsor logo [ ] but also added the event documentation from Aspiration [ ].
  • Check and cleanup a presentation formerly linked from the About page on the Debian wiki. [ ]
  • Link to reproduce.debian.net on the Involved Projects page. [ ]
  • Fix a number of links on the Talks & Resources page. [ ][ ][ ][ ]
• hulkoba:
  • Remove the sidebar-type layout and move to a static navigation element. [ ][ ][ ][ ]
  • Create and merge a new Success stories page, which highlights the success stories of Reproducible Builds, showcasing real-world examples of projects shipping with verifiable, reproducible builds. These stories aim to enhance the technical resilience of the initiative by encouraging community involvement and inspiring new contributions. . [ ]
  • Further changes to the homepage. [ ]
  • Remove the translation icon from the navigation bar. [ ]
  • Remove unused CSS styles pertaining to the sidebar. [ ]
  • Add sponsors to the global footer. [ ]
  • Add extra space on large screens on the Who page. [ ]
  • Hide the side navigation on small screens on the Documentation pages. [ ]

Debian changes There were a significant number of reproducibility-related changes within Debian this month, including:

• Santiago Vila uploaded version 0.11+nmu4 of the dh-buildinfo package. In this release, the dh_buildinfo becomes a no-op ie. it no longer does anything beyond warning the developer that the dh-buildinfo package is now obsolete. In his upload, Santiago wrote that We still want packages to drop their [dependency] on dh-buildinfo, but now they will immediately benefit from this change after a simple rebuild.
• Holger Levsen filed Debian bug #1091550 requesting a rebuild of a number of packages that were built with a very old version of dpkg.
• Fay Stegerman contributed to an extensive thread on the debian-devel development mailing list on the topic of Supporting alternative zlib implementations . In particular, Fay wrote about her results experimenting whether zlib-ng produces identical results or not.
• kpcyrd uploaded a new rust-rebuilderd-worker, rust-derp, rust-in-toto and debian-repro-status to Debian, which passed successfully through the so-called NEW queue.
• Gioele Barabucci filed a number of bugs against the debrebuild component/script of the devscripts package, including:
  • #1089087: Address a spurious extra subdirectory in the build path.
  • #1089201: Extra zero bytes added to .dynstr when rebuilding CMake projects.
  • #1089088: Some binNMUs have a 1-second offset in some timestamps.
• Gioele Barabucci also filed a bug against the dh-r package to report that the Recommends and Suggests fields are missing from rebuilt R packages. At the time of writing, this bug has no patch and needs some help to make over 350 binary packages reproducible.
• Lastly, 8 reviews of Debian packages were added, 11 were updated and 11 were removed this month adding to our knowledge about identified issues.

Other development news In other ecosystem and distribution news:

• Jan-Benedict Glaw published the 6th NetBSD Reproducibility Report and reported on our mailing list as well.
• Developer unmush wrote a long post on the GNU Guix blog on the topic of Adding a fully-bootstrapped Mono to the distribution.
• The Glasgow Haskell Compiler (GHC) has released a new version of their compiler. This release introduces a new experimental flag, -fobject-determinism, which enables deterministic object code generation .
• The IzzyOnDroid Android APK repository published an extensive Review of 2024 and Outlook for 2025 which includes statistics and future plans related to reproducible builds (including having passed the 30% mark this month).
• The historic Arch Linux reproducibility tests that were hosted at tests.reproducible-builds.org/archlinux now redirect to reproducible.archlinux.org instead. In fact, everything Arch-related has now been removed from the jenkins.debian.net.git repository, as those continuous integration tests have been disabled for some time.
• reprotest version 0.7.29 was uploaded to Debian unstable by Vagrant Cascadian. It included contributions already covered in previous months as well as new ones from Rebecca N. Palmer, such as:
  • Stop using pkg_resources. [ ][ ]
  • The as_file attribute is not a method. [ ]
  • Use a non-constant object to test memory address capture. [ ]
• rebuilderd was updated as follows by kpcyrd:
  • Migrate diesel dependency from 1.x to 2.x. [ ]
  • Migrate clap dependency from 2 to 4. [ ]
  • Refactor reqwest code, and the replace openssl dependency with the memory-safe rustls. [ ][ ]

• Lastly, in openSUSE, Bernhard M. Wiedemann published another report for the distribution. There, Bernhard reports about the success of building R-B-OS , a partial fork of openSUSE with only 100% bit-reproducible packages. This effort was sponsored by the NLNet NGI0 initiative.

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann: cargo-packaging/rusty_v8, cockpit, collectd, deepin-daemon, deepin-file-manager, esbuild, grpc, hyperkitty, icedtea-web, java-atk-wrapper, kdenetwork-filesharing, kicad, kompare, librespeed-cli, lincity-ng, mraa, ollama, opa-fmgui, opencryptoki, opencryptoki, openmpi4:gnu-hpc, openwsman, patterns-microos, portmidi, presage, procps, sad, scons/nst, sendmail, static-initrd, suse-hpc, swtpm, tiny, vtk, xdg-desktop-portal and yast.
• Chris Lamb:
  • #1089011 filed against pyorbital.
  • #1089095 filed against python-pbcore.
• Gioele Barabucci:
  • #1089088 filed against sbuild.
• James Addison:
  • #1090395 filed against binutils.
• Johannes Schauer Marin Rodrigues:
  • #1089092 filed against hurd.
• Moritz Schlarb:
  • #1090078 filed against firehol.
• Roland Clobus:
  • #1090981 filed against dictionaries-common.

Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In November, a number of changes were made by Holger Levsen, including:

• reproduce.debian.net-related:
  • Add a new i386.reproduce.debian.net rebuilder. [ ][ ][ ][ ][ ][ ]
  • Make a number of updates to the documentation. [ ][ ][ ][ ][ ]
  • Run i386.reproduce.debian.net run on a public port to allow external workers. [ ]
  • Add a link to the /api/v0/pkgs/list endpoint. [ ]
  • Add support for a statistics page. [ ][ ][ ][ ][ ][ ]
  • Limit build logs to 20 MiB and diffoscope output to 10 MiB. [ ]
  • Improve the frontpage. [ ][ ]
  • Explain that we re testing arch:any and arch:all on the amd64 architecture, but only arch:any on i386. [ ]
• Misc:
  • Remove code for testing Arch Linux, which has moved to reproduce.archlinux.org. [ ][ ]
  • Don t install dstat on Jenkins nodes anymore as its been removed from Debian trixie. [ ]
  • Prepare the infom08-i386 node to become another rebuilder. [ ]
  • Add debug date output for benchmarking the reproducible_pool_buildinfos.sh script. [ ]
  • Install installation-birthday everywhere. [ ]
  • Temporarily disable automatic updates of pool links on buildinfos.debian.net. [ ]
  • Install Recommends by default on Jenkins nodes. [ ]
  • Rename rebuilder_stats.py to rebuilderd_stats.py. [ ]
  • r.d.n/stats: minor formatting changes. [ ]
  • Install files under /etc/cron.d/ with the correct permissions. [ ]

and Jochen Sprickerhof made the following changes:

• Always prefer official .buildinfo on buildinfos.debian.net files. [ ][ ][ ]
• Add a rebuilder_stats.py scripts. [ ]

Lastly, Gioele Barabucci also classified packages affected by 1-second offset issue filed as Debian bug #1089088 [ ][ ][ ][ ], Chris Hofstaedtler updated the URL for Grml s dpkg.selections file [ ], Roland Clobus updated the Jenkins log parser to parse warnings from diffoscope [ ] and Mattia Rizzolo banned a number of bots and crawlers from the service [ ][ ].
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:

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

Welcome to the July 2024 report from the Reproducible Builds project! In our reports, we outline what we ve been up to over the past month and highlight news items in software supply-chain security more broadly. As always, if you are interested in contributing to the project, please visit our Contribute page on our website. Table of contents:

1. Reproducible Builds Summit 2024
2. Pulling Linux up by its bootstraps
3. Towards Idempotent Rebuilds?
4. AROMA: Automatic Reproduction of Maven Artifacts
5. Community updates
6. Android Reproducible Builds at IzzyOnDroid with rbtlog
7. Extending the Scalability, Flexibility and Responsiveness of Secure Software Update Systems
8. Development news
9. Website updates
10. Upstream patches
11. Reproducibility testing framework

---

Reproducible Builds Summit 2024 Last month, we were very pleased to announce the upcoming Reproducible Builds Summit, set to take place from September 17th 19th 2024 in Hamburg, Germany. We are thrilled to host the seventh edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin and Athens. Our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving. If you re interesting in joining us this year, please make sure to read the event page, which has more details about the event and location. We are very much looking forward to seeing many readers of these reports there.

Pulling Linux up by its bootstraps (LWN) In a recent edition of Linux Weekly News, Daroc Alden has written an article on bootstrappable builds. Starting with a brief introduction that

a bootstrappable build is one that builds existing software from scratch for example, building GCC without relying on an existing copy of GCC. In 2023, the Guix project announced that the project had reduced the size of the binary bootstrap seed needed to build its operating system to just 357-bytes not counting the Linux kernel required to run the build process.

The article goes onto to describe that now, the live-bootstrap project has gone a step further and removed the need for an existing kernel at all. and concludes:

The real benefit of bootstrappable builds comes from a few things. Like reproducible builds, they can make users more confident that the binary packages downloaded from a package mirror really do correspond to the open-source project whose source code they can inspect. Bootstrappable builds have also had positive effects on the complexity of building a Linux distribution from scratch [ ]. But most of all, bootstrappable builds are a boon to the longevity of our software ecosystem. It s easy for old software to become unbuildable. By having a well-known, self-contained chain of software that can build itself from a small seed, in a variety of environments, bootstrappable builds can help ensure that today s software is not lost, no matter where the open-source community goes from here

Towards Idempotent Rebuilds? Trisquel developer Simon Josefsson wrote an interesting blog post comparing the output of the .deb files from our tests.reproducible-builds.org testing framework and the ones in the official Debian archive. Following up from a previous post on the reproducibility of Trisquel, Simon notes that typically [the] rebuilds do not match the official packages, even when they say the package is reproducible , Simon correctly identifies that the purpose of [these] rebuilds are not to say anything about the official binary build, instead the purpose is to offer a QA service to maintainers by performing two builds of a package and declaring success if both builds match. However, Simon s post swiftly moves on to announce a new tool called debdistrebuild that performs rebuilds of the difference between two distributions in a GitLab pipeline and displays diffoscope output for further analysis.

AROMA: Automatic Reproduction of Maven Artifacts Mehdi Keshani, Tudor-Gabriel Velican, Gideon Bot and Sebastian Proksch of the Delft University of Technology, Netherlands, have published a new paper in the ACM Software Engineering on a new tool to automatically reproduce Apache Maven artifacts:

Reproducible Central is an initiative that curates a list of reproducible Maven libraries, but the list is limited and challenging to maintain due to manual efforts. [We] investigate the feasibility of automatically finding the source code of a library from its Maven release and recovering information about the original release environment. Our tool, AROMA, can obtain this critical information from the artifact and the source repository through several heuristics and we use the results for reproduction attempts of Maven packages. Overall, our approach achieves an accuracy of up to 99.5% when compared field-by-field to the existing manual approach [and] we reveal that automatic reproducibility is feasible for 23.4% of the Maven packages using AROMA, and 8% of these packages are fully reproducible.

Community updates On our mailing list this month:

• Nichita Morcotilo reached out to the community, first to share their efforts to build reproducible packages cross-platform with a new build tool called rattler-build, noting that as you can imagine, building packages reproducibly on Windows is the hardest challenge (so far!) . Nichita goes onto mention that the Apple ecosystem appears to be using ZERO_AR_DATE over SOURCE_DATE_EPOCH. [ ]
• Roland Clobus announced that the Debian bookworm 12.6 live images are nearly reproducible , with more detail in the post itself and input in the thread from other contributors.
• As reported in last month s report, Pol Dellaiera completed his master thesis on Reproducibility in Software Engineering at the University of Mons, Belgium. This month, Pol announced this on the list with more background info. Since the master thesis sources have been available, it has received some feedback and contributions. As a result, an updated version of the thesis has been published containing those community fixes.
• Daniel Gr ber asked for help in getting the Yosys documentation to build reproducibly, citing issues in inter alia the PDF generation causing differing CreationDate metadata values.
• James Addison continued his long journey towards getting the Sphinx documentation generator to build reproducible documentation. In this thread, James concerns himself with the problem that even when SOURCE_DATE_EPOCH is configured, Sphinx projects that have configured their copyright notices using dynamic elements can produce nonsensical output under some circumstances. James query ended up generating a number of replies.
• Allen gunner Gunner posted a brief update on the progress the core team is making towards introducing a Code of Conduct (CoC) such that it is in place in time for the RB Summit in Hamburg in September . In particular, gunner asks if you are interested in helping with CoC design and development in the weeks ahead, simply email rb-core@lists.reproducible-builds.org and let us know . [ ]

Android Reproducible Builds at IzzyOnDroid with rbtlog On our mailing list, Fay Stegerman announced a new Reproducible Builds collaboration in the Android ecosystem:

We are pleased to announce Reproducible Builds, special client support and more in our repo : a collaboration between various independent interoperable projects: the IzzyOnDroid team, 3rd-party clients Droid-ify & Neo Store, and rbtlog (part of my collection of tools for Android Reproducible Builds) to bring Reproducible Builds to IzzyOnDroid and the wider Android ecosystem.

Extending the Scalability, Flexibility and Responsiveness of Secure Software Update Systems Congratulations to Marina Moore of the New York Tandon School of Engineering who has submitted her PhD thesis on Extending the Scalability, Flexibility and Responsiveness of Secure Software Update Systems. The introduction outlines its contributions to the field:

[S]oftware repositories are a vital component of software development and release, with packages downloaded both for direct use and to use as dependencies for other software. Further, when software is updated due to patched vulnerabilities or new features, it is vital that users are able to see and install this patched version of the software. However, this process of updating software can also be the source of attack. To address these attacks, secure software update systems have been proposed. However, these secure software update systems have seen barriers to widespread adoption. The Update Framework (TUF) was introduced in 2010 to address several attacks on software update systems including repository compromise, rollback attacks, and arbitrary software installation. Despite this, compromises continue to occur, with millions of users impacted by such compromises. My work has addressed substantial challenges to adoption of secure software update systems grounded in an understanding of practical concerns. Work with industry and academic communities provided opportunities to discover challenges, expand adoption, and raise awareness about secure software updates. [ ]

Development news In Debian this month, 12 reviews of Debian packages were added, 13 were updated and 6 were removed this month adding to our knowledge about identified issues. A new toolchain issue type was identified as well, specifically ordering_differences_in_pkg_info.
Colin Percival filed a bug against the LLVM compiler noting that building i386 binaries on the i386 architecture is different when building i386 binaries under amd64. The fix was narrowed down to x87 excess precision, which can result in slightly different register choices when the compiler is hosted on x86_64 or i386 and a fix committed. [ ]
Fay Stegerman performed some in-depth research surrounding her apksigcopier tool, after some Android .apk files signed with the latest apksigner could no longer be verified as reproducible. Fay identified the issue as follows:

Since build-tools >= 35.0.0-rc1, backwards-incompatible changes to apksigner break apksigcopier as it now by default forcibly replaces existing alignment padding and changed the default page alignment from 4k to 16k (same as Android Gradle Plugin >= 8.3, so the latter is only an issue when using older AGP). [ ]

She documented multiple available workarounds and filed a bug in Google s issue tracker.
Lastly, diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb uploaded version 272 and Mattia Rizzolo uploaded version 273 to Debian, and the following changes were made as well:

• Chris Lamb:
  • Ensure that the convert utility is from ImageMagick version 6.x. The command-line interface has seemingly changed with the 7.x series of ImageMagick. [ ]
  • Factor out version detection in test_jpeg_image. [ ]
  • Correct the import of the identify_version method after a refactoring change in a previous commit. [ ]
  • Move away from using DSA OpenSSH keys in tests as support has been deprecated and removed in OpenSSH version 9.8p1. [ ]
  • Move to assert_diff in the test_openssh_pub_key package. [ ]
  • Update copyright years. [ ]
• Mattia Rizzolo:
  • Add support for ffmpeg version 7.x which adds some extra context to the diff. [ ]
  • Rework the handling of OpenSSH testing of DSA keys if OpenSSH is strictly 9.7, and add an OpenSSH key test with a ed25519-format key [ ][ ][ ]
  • Temporarily disable a few packages that are not available in Debian testing. [ ][ ]
  • Stop ignoring the results of Debian testing in the continuous integration system. [ ]
  • Adjust options in debian/source to make sure not to pack the Python sdist directory into the binary Debian package. [ ]
  • Adjust Lintian overrides. [ ]

Website updates There were a number of improvements made to our website this month, including:

• Bernhard M. Wiedemann updated the SOURCE_DATE_EPOCH page to include instructions on how to create reproducible .zip files from within Python using the zipfile module. [ ]
• Chris Lamb fixed a potential duplicate heading on the Projects page. [ ]
• Fay Stegerman added rbtlog to the Tools page [ ] and IzzyOnDroid to the Projects page [ ], also ensuring that the latter page was always sorted regardless of the ordering within the input data files. [ ]
• Holger Levsen added Linus Nordberg to our global list of contributors [ ] as well as made a number of changes to the page for the upcoming Reproducible Builds summit later this year [ ][ ][ ][ ].
• Mattia Rizzolo updated the Civil Infrastructure Platform logo [ ] and also updated the 2024 summit page [ ][ ].
• Nichita Morcotilo added rattler-build to the Projects page. [ ][ ][ ]
• Pol Dellaiera updated the Academic Publications page, adding two publications. [ ][ ]

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • armagetron (date)
  • blaspp (hostname)
  • cligen (GnuTLSs date)
  • cloudflared (date)
  • dpdk (Sphinx doctrees)
  • fonttosfnt/xorg-x11-fonts (toolchain, date)
  • gegl (build machine details)
  • gettext-runtime (jar mtime)
  • kf6-kirigami+kf6-qqc2-desktop-style (race-condition)
  • kubernetes1.26 (backport upstream fix for random path)
  • lapackpp (hostname)
  • latex2html (nochecks)
  • libdb-4_8 (.jar modification time)
  • librcc (already merged upstream)
  • libreoffice (strip .jar mtimes + clucene-core toolchain)
  • maliit-keyboard (nocheck)
  • nautilus (date)
  • openblas (CPU type, fixed)
  • openssl-3 (random-related issue)
  • python-ruff (ASLR)
  • python3 (date, parallelism/race)
  • reproducible-faketools (0.5.2)
  • sphinx (GZip modification time)
  • sphinxcontrib (gzip mtime)
• Chris Lamb:
  • #1076368 filed against nautilus.
  • #1076507 filed against mccode.
  • #1076806 filed against meson-python.
  • #1077479 filed against debcraft.
  • #1077485 filed against pytest.
  • #1077601 filed against setuptools.
• Fridrich Strba:
  • javapackages-tools
  • ant
  • java-21-openjdk
• Evangelos Ribeiro Tzaras:
  • buffybox

Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In July, a number of changes were made by Holger Levsen, including:

• Grant bremner access to the ionos7 node. [ ][ ]
• Perform a dummy change to force update of all jobs. [ ][ ]

In addition, Vagrant Cascadian performed some necessary node maintenance of the underlying build hosts. [ ]

---

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:

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

It has been close to a year now that I've incorporated my new company, Mergify. I've been busy, and I barely wrote anything about it so far. Now is an excellent time to take a break and reflect a bit on what happened during those last 12 months.

What problem does Mergify solve?Mergify is a powerful automation engine for GitHub pull requests. It allows you to automate everything and especially merging. You write rules, and it handles the rest.

Example of rule matching returned in GitHub checks

For example, let's say you want your pull request to be merged, e.g., once your CI passes and the pull request has been approved. You just write such a rule, and our engine merges the pull request as soon as it's ready.We also deal with more advanced use cases. For instance, we provide a merge queue so your pull requests are merged serially and tested by your CI one after another avoiding any regression in your code.Our goal is to make pull request management and automation easy. You can use your bot to trigger a rebase of your pull requests, or a backport to a different branch, just with a single comment.

Some people like to make bots talk to each other.

A New AdventureMergify is the first company that I ever started. I did run some personal businesses before, created non-profit organizations, built FOSS projects but I never created a company from scratch, even less with an associate.Indeed, I've chosen to build the company with my old friend Mehdi. We've known each others for 7 years now, and have worked together all that time on different open-source projects. Having worked with each other for so long has probably been a critical factor in the success of our venture so far.I had little experience sharing the founding seats with someone, and tons of reading seemed to indicate that it would be a tough ride. Picking the right business partner(s) can be a hard task. Luckily, after working so much time together, Mehdi and I both know our strengths and weaknesses well enough to be able to circumvent them. On the other hand, we both have similar backgrounds as software engineers. That does not help to cover all the hats you need to wear when building a company. Over time, we found arrangements to cover most of those equally between us.We don't have any magical advice to give on this. As in every relationship, communication is the key, and the #1 factor of success.

Getting UsersI don't know if we got lucky, but we got users and customers pretty early. We used a few cooperative projects as guinea pigs first, and they were brave enough to try our service and give us feedback. No repository has been harmed during this first phase!Then, as soon as we managed to get our application on the GitHub Marketplace, we saw a steady number of users coming to us.This has been fantastic as it allowed us to get feedback rapidly. We set up a form asking users for feedback after they used Mergify for a couple of weeks. What we hear is that users were happy, that the documentation was confusing and that some features were buggy or missing. We planned all of those ideas as our future work in our roadmap, using the principles we described a few months ago.

How we handle our roadmap for Mergify

Whatever you re building a company, a product, or a house a time comes where you need planning. Pushing random buttons to move forward does not work anymore. You need to take a step back to

Julien DanjouMergify

If you're curious, you can read this article.

We tried various strategies to get new users, but so far, organic growth has been our #1 way of onboarding new users. Like many small startups out there, we're not that good at marketing and executing strategies.We provide our service for free for open-source projects We are now powering many organizations, such as Mozilla, Amazon Web Services, Ceph and Fedora.

Working with GitHubWorking with GitHub has been complicated. When you build an application for a marketplace, your business is entirely dependent on the platform you develop for both in terms of features and quality of service.In our case, we hit quite many bugs with GitHub. Their support has mostly been fast to answer, but some significant issues are still opened months later. The truth is that the GitHub API could deserve more love and care from GitHub. For example, their GraphQL API is a work in progress for years and miss out many essential features.

GitHub service status is not always green.

We dealt and still deal with all those issues. It obviously impacts our operations and decreases our overall velocity. We regularly have to find new ways to sidestep GitHub limitations.You have no idea how we wished for GitHub to be open-source. The idea of not having access to their code and understand how it works is so frustrating that we publish our engine as an open-source project. That allows all of our users to see how it works and even propose enhancements.

Automate all the wayWe're a tiny startup, and we decided to bootstrap our company. We never took any funding. From the beginning, it has been clear to us that we had to think and act like we had no resources. We're built around a scarcity mindset. Every decision we make is based on the assumption that we basically are very limited in terms of money and time.We basically act like any wrong choice we do could (virtually) kill the company. We only do what is essential, we ship fast, and we automate everything.For example, we have built our whole operation about CI/CD systems, and pushing any new fix or feature in production is done in a matter of minutes. It's not uncommon for us to push a fix from our phone, just by reviewing some code or editing a file.

GrowthWe're extremely happy with our steady growth and more users using our service. We now manage close to 30k repositories and merge 15k pull requests per month for our users.That's a lot of mouse clicks saved!If you want to try Mergify yourself, it's a single click log-in using your GitHub account. Check it out!

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

• I was elected Debian Project Leader for 2017. I'd like to sincerely thank everyone who voted for me as well as everyone who took part in the election in general especially Mehdi Dogguy for being a worthy opponent. The result was covered on LWN, Phoronix, DistroWatch, iTWire, etc.
• Added support for the Monzo banking API in social-core, a Python library to allow web applications to authenticate using third-parties. (#68)
• Fixed a HTML injection attack in a demo of Russell Keith-Magee's BeeWare presentation library. (#3)
• Updated systemd's documentation to explain why we suggest explicitly calling make all despite the Makefile's "check" target calling it. (#5830)
• Updated the documentation of a breadth-first version of find(1) called bfs to refer to the newly-uploaded Debian package. (#23)
• Updated the configuration for the ticketbot IRC bot (zwiebelbot on OFTC) to identify #reproducible-builds as a Debian-related channel. This is so that bug Debian bug numbers are automatically expanded by the bot. (#7)

---

The Debian Project Leader elections finished yesterday and the winner is Chris Lamb! Of a total of 1062 developers, 322 developers voted using the Condorcet method. More information about the result is available in the Debian Project Leader Elections 2017 page. The current Debian Project Leader, Mehdi Dogguy, congratulated Chris Lamb in his Final bits from the (outgoing) DPL message. Thanks, Mehdi, for the service as DPL during this last twelve months! The new term for the project leader starts on April 17th and expires on April 16th 2018.

I'd like to thank the entire Debian community for choosing me to represent them as the next Debian Project Leader. I would also like to thank Mehdi for his tireless service and wish him all the best for the future. It is an honour to be elected as the DPL and I am humbled that you would place your faith and trust in me. You can read my platform here.

• Official results
• LWN article
• Phoronix
• DistroWatch
• iTWire

It's that time of year again for the Debian Project: the elections of its Project Leader! The Project Leader position is described in the Debian Constitution. Two Debian Developers run this year to become Project Leader: Mehdi Dogguy, who has held the office for the last year, and Chris Lamb. We are in the middle of the campaigning period that will last until the end of April 1st. The candidates and Debian contributors are already engaging in debates and discussions on the debian-vote mailing list. The voting period starts on April 2nd, and during the following two weeks, Debian Developers can vote to choose the person that will fit that role for one year. The results will be published on April 16th with the term for new the project leader starting the following day.

Many of you are big fans of S.W.O.T analysis, I am sure of that! :-) Technical competence is our strongest suit, but we have reached a size and sphere of influence which requires an increase in organisation.

We all love our project and want to make sure Debian still shines in the next decades (and centuries!). One way to secure that goal is to identify elements/events/things which could put that goal at risk. To this end, we've organized a short S.W.O.T analysis session at DebConf16. Minutes of the meeting can be found here. I believe it is an interesting read and is useful for Debian old-timers as well as newcomers. It helps to convey a better understanding of the project's status. For each item, we've tried to identify an action.

Here are a few things we've worked on:

• Identify new potential contributors by attending and speaking at conferences where Free and Open Sources software are still not very well-known, or where we have too few contributors.
  
  Each Debian developer is encouraged to identify events where we can promote FOSS and Debian. As DPL, I'd be happy to cover expenses to attend such events.
• Our average age is also growing over the years. It is true that we could attract more new contributors than we already do.
  
  We can organize short internships. We should not wait for students to come to us. We can get in touch with universities and engineering schools and work together on a list of topics. It is easy and will give us the opportunity to reach out to more students.
  
  It is true that we have tried in the past to do that. We may organize a sprint with interested people and share our experience on trying to do internships on Debian-related subjects. If you have successfully done that in the past and managed to attract new contributors that way, please share your experience with us!
  
  If you see other ways to attract new contributors, please get in touch so that we can discuss!
• Not easy to get started in the project.
  
  It could be argued that all the information is available, but rather than being easily findable from on starting point, it is scattered over several places (documentation on our website, wiki, metadata on bug reports, etc ).
  
  Fedora and Mozilla both worked on this subject and did build a nice web application to make this easier and nicer. The result of this is asknot-ng.
  
  A whatcanidofor.debian.org would be wonderful! Any takers? We can help by providing a virtual machine to build this. Being a DD is not mandatory. Everyone is welcome!
• Cloud images for Debian.
  
  This is a very important point since cloud providers are now major distributions consumers. We have to ensure that Debian is correctly integrated in the cloud, without making compromises on our values and philosophy.
  
  I believe this item has been worked on during the last Debian Cloud sprint. I am looking forward to seeing the positive effects of this sprint in the long term. I believe it does help us to build a stronger relationship with cloud providers and gives us a nice opportunity to work with them on a shared set of goals!

During next DebConf, we can review the progress that has been made on each item and discuss new ones. In addition to this session acting as a health check, I see it as a way for the DPL to discuss, openly and publicly, about the important changes that should be implemented in the project and imagine together a better future.

In the meantime, everyone should feel free to pick one item from the list and work on it. :-)

The process leading to acceptation of new Debian Maintainers is mainly administrative today and is handled by the Newmaint team. In order to simplify this process further, the team wants to integrate their workflow into nm.debian.org's interface so that prospective maintainers can send their application online and the Newmaint team review it from within the website.

We need your help to implement the missing pieces into nm.debian.org. It is written in Python and using Django. If you have some experience with that, you should definitely join the newmaint-site mailing list and ask for the details. Enrico or someone else in the list will do their best to share their vision and explain the needed work in order to get this properly implemented!

It doesn't matter if you're already a Debian Developer to be able to contribute to this project. Anyone can step up and help!

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS I handled a new LTS sponsor that wanted to see wheezy keep supporting armel and armhf. This was not part of our initial plans (set during last Debconf) and I thus mailed all teams that were impacted if we were to collectively decide that it was OK to support those architectures. While I was hoping to get a clear answer rather quickly, it turns out that we never managed to get an answer to the question from all parties. Instead the discussion drifted on the more general topic of how we handle sponsorship/funding in the LTS project. Fortunately, the buildd maintainers said they were OK with this and the ftpmasters had no objections, and they both implicitly enacted the decision: Ansgar Burchardt kept the armel/armhf architectures in the wheezy/updates suite when he handled the switch to the LTS team, and Aur lien Jarno also configured wanna-build to keep building armel/armhf for the suite. The DSA team did not confirm that this change was not interfering with one of their plans to decommission some hardware. Build daemons are a shared resource anyway and a single server is likely to handle builds for multiple releases. DebConf 16 This month I registered for DebConf 16 and submitted multiple talk/BoF proposals:

• Kali Linux s Experience of a Debian Derivative Based on Testing (Talk)
• 2 Years of Work of Paid Contributors in the Debian LTS Project (Talk)
• Using Debian Money to Fund Debian Projects (BoF)

I want to share the setup we use in Kali as it can be useful for other derivatives and also for Debian itself to help smooth the relationship with derivatives. I also want to open again the debate on the usage of money within Debian. It s a hard topic but we should really strive to take some official position on what s possible and what s not possible. With Debian LTS and its sponsorship we have seen that we can use money to some extent without hurting the Debian project as a whole. Can this be transposed to other teams or projects? What are the limits? Can we define a framework and clear rules? I expect the discussion to be very interesting in the BoF. Mehdi Dogguy has agreed to handle this BoF with me. Packaging Django. I uploaded 1.8.12 to jessie-backports and 1.9.5 to unstable. I filed two upstream bugs (26473 and 26474) for two problems spotted by lintian. Unfortunately, when I wanted to upload it to unstable, the test suite did not ran. I pinned this down to a sqlite regression. Chris Lamb filed #820225 and I contacted the SQLite and Django upstream developers by email to point them to this issue. I helped the SQLite upstream author (Richard Hipp) to reproduce the issue and he was quick to provide a patch which landed in 3.12.1. Later in the month I made another upload to fix an upgrade bug (#821789). GNOME 3.20. As for each new version, I updated gnome-shell-timer to ensure it works with the new GNOME. This time I spent a bit more time to fix a regression (805347) that dates back to a while and that would never be fixed otherwise since the upstream author orphaned this extension (as he no longer uses GNOME). I have also been bitten by display problems where accented characters would be displayed below the character that follows. With the help of members of the GNOME team, we found out that this was a problem specific to the cantarell font and was only triggered with Harfbuzz 1.2. This is tracked in Debian with #822682 on harfbuzz and #822762 in fonts-cantarell. There s a new upstream release (with the fix) ready to be packaged but unfortunately it is blocked by the lack of a recent fontforge in Debian. I thus mailed debian-mentors in the hope to find volunteers to help the pkg-fonts team to package a newer version Misc Debian/Kali work Distro Tracker. I started to mentor Vladimir Likic who contacted me because he wants to contribute to Distro Tracker. I helped him to setup his development environment and we fixed a few issues in the process. Bug reports. I filed many bug reports, most of them due to my work on Kali:

• #820288: a request to keep the wordpress package installable in older releases (due to renaming of many php packages)
• #820660: request support of by-hash indices in reprepro
• #820867: possibility to apply overrides on already installed packages in reprepro
• #821070: jessie to stretch upgrade problem with samba-vfs-modules
• #822157: python-future hides and breaks python-configparser
• #822669: dh_installinit inserts useless autoscript for System V init script when package doesn t contain any
• #822670: dh-systemd should be merged into debhelper, we have systemd by default and debhelper should have proper support for it by default

I also investigated #819958 that was affecting testing since it has been reported to Kali as well. And I made an NMU of dh-make-golang to fix #819472 that I reported earlier. Thanks See you next month for a new summary of my activities.

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

The Debian Project Leader elections finished yesterday and the winner is Mehdi Dogguy! Of a total of 1023 developers, 282 developers voted using the Condorcet method. More information about the result is available in the Debian Project Leader Elections 2016 page. The new term for the project leader starts today April 17th and expire on April 17th 2017.

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

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

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

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

It's that time of year again for the Debian Project: the elections of its Project Leader! Neil McGovern who has held the office for the last year will not be seeking reelection. Debian Developers will have to choose between voting for the only candidate running Mehdi Dogguy or None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. Mehdi Dogguy was a candidate for the DPL position last year, finishing second with a close amount of votes to the winner Neil McGovern. We are in the middle of the campaigning period that will last until April 2nd. The candidate and Debian contributors are expected to engage in debates and discussions on the debian-vote mailing list. The voting period starts on April 3rd, and during the following two weeks, Debian Developers will vote to choose the person who will guide the project for one year. The results will be published on April 17th with the term for new the project leader starting immediately that same day.

A little more than 3 months after our latest minor release, here is the new major version of Gnocchi, stamped 2.0.0. It contains a lot of new and exciting features, and I'd like to talk about some of them to celebrate! You may notice that this release happens in the middle of the OpenStack release cycle. Indeed, Gnocchi does not follow that 6-months cycle, and we release whenever our code is ready. That forces us to have a more iterative approach, less disruptive for other projects and allow us to achieve a higher velocity. Applying the good old mantra release early, release often. Documentation This version features a large documentation update. Gnocchi is still the only OpenStack server project that implements a "no doc, no merge" policy, meaning any code must come with the documentation addition or change included in the patch. The full documentation is included in the source code and available online at gnocchi.xyz. Data split & compression I've already covered this change extensively in my last blog about timeseries compression. Long story short, Gnocchi now splits timeseries archives in small chunks that are compressed, increasing speed and decreasing data size. Measures batching support Gnocchi now supports batching, which allow submitting several measures for different metric in a single request. This is especially useful in the context where your application tends to cache metrics for a while and is able to send them in a batch. Usage is fully documented for the REST API. Group by support in aggregation One of the most demanded features was the ability to do measure aggregation no resource, using a group by type query. This is now possible using the new groupby parameter to aggregation queries. Ceph backend optimization We improved the Ceph back-end a lot. Mehdi Abaakouk wrote a new Python binding for Ceph, called Cradox, that is going to replace the current Python rados module in the subsequent Ceph releases. Gnocchi makes usage of this new module to speed things up, making the Ceph based driver really, really faster than before. We also implemented asynchronous data deletion, which improves performance a bit. The next step will be to run some new benchmarks like I did a few months ago and compare with the Gnocchi 1.3 series. Stay tuned!

What happened in the reproducible builds effort between December 27th and January 2nd: Infrastructure dak now silently accepts and discards .buildinfo files (commit 1, 2), thanks to Niels Thykier and Ansgar Burchardt. This was later confirmed as working by Mattia Rizzolo. Packages fixed The following packages have become reproducible due to changes in their build dependencies: banshee-community-extensions, javamail, mono-debugger-libs, python-avro. The following packages became reproducible after getting fixed:

• avrdude/6.2-5 by Milan Kupcevic.
• blosxom/2.1.2-2 uploaded by Rhonda D'Vine, original patches (#777292, #793001) by Chris Lamb and akira.
• buzztrax/0.10.2-2 uploaded by Sebastian Dr ge, original patch by Chris Lamb, fixed upstream.
• dx/1:4.4.4-8 by Graham Inggs.
• gap-guava/3.12+ds1-3 by Jerome Benoit.
• goffice/0.10.26-1 uploaded by Dmitry Smirnov, fixed upstream.
• gunroar/0.15.dfsg1-8 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• iceweasel/43.0.2-1 by Mike Hommey.
• ii-esu/1.0a.dfsg1-7 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• jing-trang/20131210+dfsg+1-4 by Samuel Thibault.
• mstflint/4.1.0+1.46.gb1cdaf7-1 by Mehdi Dogguy.
• mu-cade/0.11.dfsg1-9 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• mumble/1.2.12-1 by Christopher Knadle.
• netris/0.52-10 by Rhonda D'Vine, original patches (#778201, #793707) by Chris Lamb and akira.
• onboard/1.1.2-2 uploaded by Mike Gabriel, original patch by Reiner Herrmann.
• parsec47/0.2.dfsg1-7 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• pathological/1.1.3-14 by Markus Koschany.
• projectl/1.001.dfsg1-8 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• re2c/0.15.3-1 by JCF Ploemen.
• s3d/0.2.2-14 by Sven Eckelmann.
• tulip/4.8.0dfsg-2 by Yann Dirson.
• val-and-rick/0.1a.dfsg1-5 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• xterm/321-1 by Sven Joachim.

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

• debian-installer/20160101 uploaded by Cyril Brulebois with several fixes from Steven Chamberlain.
• drbd-utils/8.9.5-1 by Apollon Oikonomopoulos.
• hhvm/3.11.0+dfsg-1 by Faidon Liambotis.
• rkward/0.6.4-1 uploaded by Thomas Friedrichsmeier, original patch by Philip Rinn.
• rsbackup/3.0-2 uploaded by Matthew Vernon, original patches (#777394, #793716) by Chris Lamb and akira.
• tin/1:2.3.2-1 by Marco d'Itri.
• transdecoder/2.0.1+dfsg-2 uploaded by Andreas Tille, original patch by Chris Lamb.
• tumiki-fighters/0.2.dfsg1-7 uploaded by Markus Koschany, original patch by Reiner Herrmann.

Untested changes:

• fltk1.1/1.1.10-20 by Aaron M. Ucko, currently FTBFS.
• fltk1.3/1.3.3-5 by Aaron M. Ucko, currently FTBFS.

reproducible.debian.net The testing distribution (the upcoming stretch) is now tested on armhf. (h01ger) Four new armhf build nodes provided by Vagrant Cascandian were integrated in the infrastructer. This allowed for 9 new armhf builder jobs. (h01ger) The RPM-based build system, koji, is now in unstable and testing. (Marek Marczykowski-G recki, Ximin Luo). Package reviews 131 reviews have been removed, 71 added and 53 updated in the previous week. 58 new FTBFS reports were made by Chris Lamb and Chris West. New issues identified this week: nondeterminstic_ordering_in_gsettings_glib_enums_xml, nondeterminstic_output_in_warnings_generated_by_breathe, qt_translate_noop_nondeterminstic_ordering. Misc. Steven Chamberlain explained in length why reproducible cross-building across architectures mattered, and posted results of his tests comparing a stage1 debootstrapped chroot of linux-i386 once done from official Debian packages, the others cross-built from kfreebsd-amd64.

It is with great sadness that I learned of the passing of Ian Murdock. I have never had the chance to meet him. Several persons testify for his kindness and talent. We will always remember him. His legacy influences our lives everyday!

Looking at his latest blog posts, he seemed a bit nostalgic about Debian and still very proud of it.

Later, he wrote about how he came to find Linux and the importance of telling the story of hackers of his generation. In his memory, I'll reread Stephen Levy s Hackers for the nth time too.

When (if?) his webserver will shut down, you will still be able to read his past blog posts using the archived version of his website or a static mirror that has been set up.

RIP Ian.

This weekend is organized the Aaron Swartz Day across the world. There are events organized in many cities and video streams available. It is important that we remember Aaron's projects and fights. If you want to know more about Aaron Swartz, you may start by watching the excellent documentary The Internet's Own Boy : The Story of Aaron Swartz. His work was very inspirational and should not be forgotten!

Thanks to Mehdi Dogguy, here's a nice hook to generate a source change file at build time (with pbuilder), so one can upload source-only packages to the archive and have buildds rebuild for all the architectures. Put it in .pbuilder/hooks/B10_source-build so it gets called once the builds succeeds

#! /bin/sh
generate_change_file()
 
  local version=$(dpkg-parsechangelog -Sversion)
  local package=$(dpkg-parsechangelog -Ssource)
  echo "Generating source changes file"
  dpkg-genchanges -S > ../$ package _$ version _source.changes
 
cd /tmp/buildd/*/debian/..
generate_change_file

Next time you build a package, you should find, alongside the <package>_<version>_<arch>.changes file, a <package>_<version>_source.changes which you can use with usual tools (lintian, debsign, dput ) to upload it to the Debian archive. Note that if you do that, you have to make sure that your debian/rules support building separately the arch-dependent and arch-independant packages. To check that, you can call pdebuild like this:

pdebuild --debbuildopts -A # binary-only build, limited to arch-independant packages
pdebuild --debbuildopts -B # binary-only build, limited to arch-dependant packages

What happened in the reproducible builds effort this week: Toolchain fixes

• Stefano Rivera uploaded python-cffi/1.3.0-1 which makes the generated code order deterministic for anonymous unions and anonymous structs. Reported by Tristan Seligmann, and fixed uptream.

Mattia Rizzolo created a bug report to continue the discussion on storing cryptographic checksums of the installed .deb in dpkg database. This follows the discussion that happened in June and is a pre-requisite to add checksums to .buildinfo files. Niko Tyni identified why the Vala compiler would generate code in varying order. A better patch than his initial attempt still needs to be written. Packages fixed The following 15 packages became reproducible due to changes in their build dependencies: alt-ergo, approx, bin-prot, caml2html, coinst, dokujclient, libapreq2, mwparserfromhell, ocsigenserver, python-cryptography, python-watchdog, slurm-llnl, tyxml, unison2.40.102, yojson. The following packages became reproducible after getting fixed:

• 389-ds-base/1.3.3.13-1 uploaded by Timo Aaltonen, original patch by Chris Lamb.
• apache2/2.4.17-1 by Stefan Fritsch.
• ben/0.7.3 by Mehdi Dogguy.
• cdo/1.6.9+dfsg.1-3 by Alastair McKinstry.
• epubcheck/4.0.0-2 by Eugene Zhukov.
• grads/2:2.0.2-8 by Alastair McKinstry.
• litl/0.1.7+dfsg-1 uploaded by Samuel Thibault, original patch by Chris Lamb.
• mia/2.2.5-1 by Gert Wollny.
• powerline/2.2-2 by Jerome Charaoui.
• python-oslotest/1:1.11.0-2 by Thomas Goirand.
• tth/4.05+ds-2 uploaded by Jerome Benoit, original patch by Reiner Herrmann.
• xbae/4.60.4-7 uploaded by Nicholas Breen, original patch by Chris Lamb.
• xdmf/2.1.dfsg.1-13 by Alastair McKinstry.

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

• foxeye/0.10.2-1 by Andriy Grytsenko.
• jaxe/3.5-6 by Samuel Thibault.
• ncurses/6.0+20151017-1 by Sven Joachim, original patch by Esa Peuha.
• olap4j/1.2.0-1 by Emmanuel Bourg.
• tomcat8/8.0.28-1 by Emmanuel Bourg.

reproducible.debian.net pbuilder has been updated to version 0.219~bpo8+1 on all eight build nodes. (Mattia Rizzolo, h01ger) Packages that FTBFS but for which no open bugs have been recorded are now tested again after 3 days. Likewise for depwait packages. (h01ger) Out of disk situations will not cause IRC notifications anymore. (h01ger) Documentation update Lunar continued to work on writing documentation for the future reproducible-builds.org website. Package reviews 44 reviews have been removed, 81 added and 48 updated this week. Chris West and Chris Lamb identified 70 fail to build from source issues. Misc. h01ger presented the project in Mexico City at the 3er Congreso de Seguridad de la Informaci n where it became clear that we lack academic papers related to reproducible builds. Bryan has been doing hard work to improve reproducibility for OpenWrt. He wrote a report linking to the patches and test results he published.

What happened in the reproducible builds effort this week: Toolchain fixes

• Niels Thykier uploaded debhelper/9.20151004 which exports SOURCE_DATE_EPOCH when running dh_auto_* (patch by Dhole). dh now also calls dh_strip_nondeterminism during build (patch by Andrew Ayer). The only remaining change regarding reproducibility in the custom debhelper is related to mtimes in data.tar which might be fixed directly in dpkg instead.
• Niels Thykier made another upload of debhelper/9.20151005 the next day to sort Build IDs added by dh_strip in control files.

Scott Kitterman fixed an issue with non-deterministic Depends generated by dh-python identified by Santiago Vila and Chris Lamb. Lunar updated the patch against dpkg which makes the order of files in control.tar.gz deterministic using the new --sort=name option available in GNU Tar 1.28. josch released sbuild version 0.66.0-1 with several fixes and improvements. The most notable one for reproducible builds is the new --build-path option and $build_path configuration variable added by akira which allows to explicitly chose a given build path. Reiner Herrmann wrote a new patch for dh-systemd to sort the list of unit files in the generated maintainer scripts. Packages fixed The following packages became reproducible due to changes in their build dependencies: aoeui, apron, camlmix, cudf, findlib, glpk-java, hawtjni, haxe, java-atk-wrapper, llvm-py, misery, mtasc, ocamldsort, optcomp, spamoracle. The following packages became reproducible after getting fixed:

• classified-ads/0.08-1 uploaded by Antti J rvinen, fix merged upstream, original patch by Reiner Herrmann.
• criu/1.7-3 uploaded by Salvatore Bonaccorso, original patch by Chris Lamb.
• doomsday/1.15.4-1 by Michael Gilbert.
• ejabberd/15.07-1~exp1 by Philipp Huebner.
• libxbean-java/4.4-1 by Emmanuel Bourg.
• markdown/1.0.1-8 uploaded by Matt Kraai, original patches by Chris Lamb (#776925) and akira (#793701).
• nedit/1:5.6a-3 by Paul Gevers.
• nvidia-settings/340.93-1 uploaded by Andreas Beckmann, original patch by Lunar.
• ocaml/4.02.3-2 by St phane Glondu.
• polygen/1.0.6.ds2-14 uploaded by Mehdi Dogguy, original patch by Chris Lamb.
• stsci.distutils/0.3.7-4 by Aurelien Jarno.
• vdr/2.2.0-4 by Tobias Grimm.
• vdr-plugin-xineliboutput/1.1.0+cvs20150907-3 by Tobias Grimm.
• w3c-markup-validator/1.3+dfsg-3 by Santiago Vila.
• xcolorsel/1.1a-19 by Santiago Vila.
• xmoto/0.5.11+dfsg-3 by Stephen Kitt.

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

• ognl/2.7.3-6 by Emmanuel Bourg.
• enblend-enfuse/4.1.4+dfsg-2 by Andreas Metzler.

Untested

• nvidia-xconfig/340.93-1 by Andreas Beckmann.
• nvidia-settings-legacy-304xx/304.128-1 by Andreas Beckmann.

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

• #801212 on unicode-data by Esa Peuha: set TZ=UTC when calling unzip.

reproducible.debian.net ProfitBricks once again increased their support for reproducible builds in Debian and in other free software projects by adding 58 new cores and 138 GiB of RAM to the already existing setup. Two new amd64 build nodes and 16 new amd64 build jobs have been added which doubles the build capacity per day and allows us to spot many kind of problems earlier. The size of the tmpfs where builds are performed has also been increased from 70 to 200 GiB on all amd64 build nodes. Huge thanks! When examining a package, a link now points to a table listing all previous recorded tests for the same package. (Mattia) The menu on the package pages has also been improved. (h01ger) Packages in the depwait state are now rescheduled automatically after five days. (h01ger) Links to documentation and other projects being tested have been made more visible on the landing page. (h01ger) To reduce noise on the team IRC channel five different types of notifications have been turned into mail notifications. The remaining ones have been shortened and the status changes have been limited to unstable and experimental. (h01ger) Maintainer notifications about status changes in a package will only be sent out once per day, and not on each status change. (h01ger) diffoscope development Some more experiments of concurrent processing have been made. None were good and reliable enough to be shared, though. Package reviews 48 reviews have been removed, 189 added and 23 updated this week. 9 FTBFS bugs were reported by Chris Lamb. Misc. h01ger met with Levente Polyak to discuss testing Arch Linux on Debian continuous test system with an easily extensible framework. The idea is to also allow testing of other distributions, and provide a nice package based view like the one for Debian.