Freexian Collaborators: Tryton 7.0 LTS reaches Debian trixie (by Mathias Behrle, Rapha l Hertzog and Anupa Ann Joseph)

apt install sbuild mmdebstrap uidmap
#!/bin/bash for arch in arm64 armhf armel; do HOME=/tmp mmdebstrap --quiet --arch=$arch --include=ca-certificates --variant=buildd unstable \ ~/.cache/sbuild/unstable-$arch.tar http://127.0.0.1:3142/debian done
mmdebstrap
with --quiet
because I don t want to get
any output on succesful execution. The script is running in cron with email
notifications, and I only want to get a message if something goes south. I m
setting HOME=/tmp
for a similar reason: the unshare user does not have access
to my actual home directory, and by default dpkg tries to use $HOME/.dpkg.cfg
as the configuration file. By overriding HOME
I avoid the following message
to standard error:
dpkg: warning: failed to open configuration file '/home/ema/.dpkg.cfg' for reading: Permission denied
~/.sbuildrc
):
$chroot_mode = 'unshare'; $unshare_tmpdir_template = '/dev/shm/tmp.sbuild.XXXXXXXXXX';
unshare_tmpdir_template
is needed on Bookworm to ensure that the build process
runs in memory rather than on disk for performance reasons. Starting with
Trixie, /tmp
is by default a tmpfs so the setting won t be needed anymore.
# Tarball used: ~/.cache/sbuild/unstable-arm64.tar $ sbuild --dist=unstable hello # Tarball used: ~/.cache/sbuild/unstable-armhf.tar $ sbuild --dist=unstable --arch=armhf hello
git push prod main
.
I ll talk more about that some other day.
Today is about the release process for everything else I maintain Rust / Ruby libraries, standalone programs, and so forth.
To release those, I use the following, extremely intricate process:
git release
in the repository.
git tag -a tagname
will open up an editor window where you can enter your annotation, and git tag -a -m "some annotation" tagname
will create the tag with the annotation some annotation .
Retrieving the annotation for a tag is straightforward, too: git show tagname
will display the annotation along with all the other tag-related information.
Now that we know all about annotated tags, let s talk about how to use them to make software releases freaking awesome.
-a
(or --annotate
, if you enjoy typing) to your git tag
command, and WHAM! annotation achieved.
Releases, though, typically have unique and ever-increasing version numbers, which we want to encode in the tag name.
Rather than having to look at the existing tags and figure out the next version number ourselves, we can have software do the hard work for us.
Enter: git-version-bump
.
This straightforward program takes one mandatory argument: major
, minor
, or patch
, and bumps the corresponding version number component in line with Semantic Versioning principles.
If you pass it -n
, it opens an editor for you to enter the release notes, and when you save out, the tag is automagically created with the appropriate name.
Because the program is called git-version-bump
, you can call it as a git
command: git version-bump
.
Also, because version-bump
is long and unwieldy, I have it aliased to vb
, with the following entry in my ~/.gitconfig
:
[alias] vb = version-bump -nOf course, you don t have to use
git-version-bump
if you don t want to (although why wouldn t you?).
The important thing is that the only step you take to go from here is our current codebase in main
to everything as of this commit is version X.Y.Z of this software , is the creation of an annotated tag that records the version number being released, and the metadata that goes along with that release.
git release
As I said earlier, I ve been using this release process for over a decade now.
So long, in fact, that when I started, GitHub Actions didn t exist, and so a lot of the things you d delegate to a CI runner these days had to be done locally, or in a more ad-hoc manner on a server somewhere.
This is why step 2 in the release process is run git release
.
It s because historically, you can t do everything in a CI run.
Nowadays, most of my repositories have this in the .git/config
:
[alias] release = push --tagsOlder repositories which, for one reason or another, haven t been updated to the new hawtness, have various other aliases defined, which run more specialised scripts (usually just
rake release
, for Ruby libraries), but they re slowly dying out.
The reason why I still have this alias, though, is that it standardises the release process.
Whether it s a Ruby gem, a Rust crate, a bunch of protobuf definitions, or whatever else, I run the same command to trigger a release going out.
It means I don t have to think about how I do it for this project, because every project does it exactly the same way.
It wasn t the button that was the problem. It was the miles of wiring, the hundreds of miles of cables, the circuits, the relays, the machinery. The engine was a massive, sprawling, complex, mind-bending nightmare of levers and dials and buttons and switches. You couldn t just slap a button on the wall and expect it to work. But there should be a button. A big, fat button that you could press and everything would be fine again. Just press it, and everything would be back to normal.Once you ve accepted that your release process should be as simple as creating an annotated tag and running one command, you do need to consider what happens afterwards. These days, with the near-universal availability of CI runners that can do anything you need in an isolated, reproducible environment, the work required to go from annotated tag to release artifacts can be scripted up and left to do its thing. What that looks like, of course, will probably vary greatly depending on what you re releasing. I can t really give universally-applicable guidance, since I don t know your situation. All I can do is provide some of my open source work as inspirational examples. For starters, let s look at a simple Rust crate I ve written, called
- Red Dwarf: Better Than Life
strong-box
.
It s a straightforward crate, that provides ergonomic and secure cryptographic functionality inspired by the likes of NaCl.
As it s just a crate, its release script is very straightforward.
Most of the complexity is working around Cargo s inelegant mandate that crate version numbers are specified in a TOML file.
Apart from that, it s just a matter of building and uploading the crate.
Easy!
Slightly more complicated is action-validator
.
This is a Rust CLI tool which validates GitHub Actions and Workflows (how very meta) against a published JSON schema, to make sure you haven t got any syntax or structural errors.
As not everyone has a Rust toolchain on their local box, the release process helpfully build binaries for several common OSes and CPU architectures that people can download if they choose.
The release process in this case is somewhat larger, but not particularly complicated.
Almost half of it is actually scaffolding to build an experimental WASM/NPM build of the code, because someone seemed rather keen on that.
Moving away from Rust, and stepping up the meta another notch, we can take a look at the release process for git-version-bump
itself, my Ruby library and associated CLI tool which started me down the Just Tag It Already rabbit hole many years ago.
In this case, since gemspecs are very amenable to programmatic definition, the release process is practically trivial.
Remove the boilerplate and workarounds for GitHub Actions bugs, and you re left with about three lines of actual commands.
These approaches can certainly scale to larger, more complicated processes.
I ve recently implemented annotated-tag-based releases in a proprietary software product, that produces Debian/Ubuntu, RedHat, and Windows packages, as well as Docker images, and it takes all of the information it needs from the annotated tag.
I m confident that this approach will successfully serve them as they expand out to build AMIs, GCP machine images, and whatever else they need in their release processes in the future.
main
becomes practically trivial.
This is mostly due to another fantastic and underused Git command: git describe
.
How git describe
works is, basically, that it finds the most recent commit that has an associated annotated tag, and then generates a string that contains that tag s name, plus the number of commits between that tag and the current commit, with the current commit s hash included, as a bonus.
That is, imagine that three commits ago, you created an annotated release tag named v4.2.0
.
If you run git describe
now, it will print out v4.2.0-3-g04f5a6f
(assuming that the current commit s SHA starts with 04f5a6f
).
You might be starting to see where this is going.
With a bit of light massaging (essentially, removing the leading v
and replacing the -
s with .
s), that string can be converted into a version number which, in most sane environments, is considered newer than the official 4.2.0
release, but will be superceded by the next actual release (say, 4.2.1
or 4.3.0
).
If you re already injecting version numbers into the release build process, injecting a slightly different version number is no work at all.
Then, you can easily build release artifacts for every commit to main
, and make them available somewhere they won t get in the way of the official releases.
For example, in the proprietary product I mentioned previously, this involves uploading the Debian packages to a separate component (prerelease
instead of main
), so that users that want to opt-in to the prerelease channel simply modify their sources.list
to change main
to prerelease
.
Management have been extremely pleased with the easy availability of pre-release packages; they ve been gleefully installing them willy-nilly for testing purposes since I rolled them out.
In fact, even while I ve been writing this article, I was asked to add some debug logging to help track down a particularly pernicious bug.
I added the few lines of code, committed, pushed, and went back to writing.
A few minutes later (next week s job is to cut that in-process time by at least half), the person who asked for the extra logging ran apt update; apt upgrade
, which installed the newly-built package, and was able to progress in their debugging adventure.
Continuous Delivery: It s Not Just For Hipsters.
Series: | Bright Falls #1 |
Publisher: | Jove |
Copyright: | February 2022 |
ISBN: | 0-593-33641-0 |
Format: | Kindle |
Pages: | 374 |
Series: | Class 5 #2 |
Publisher: | Eclipse |
Copyright: | January 2016 |
ISBN: | 0-6454658-4-4 |
Format: | Kindle |
Pages: | 340 |
#thoughtleadership
believe that an AWS hosted EKS k8s
cluster running
images built by CI talking to an AWS hosted PostgreSQL RDS is not complex.
They re right. Mostly right. This is less complex less complex for them.
It s not, however, without complexity and its own tradeoffs it s just
complexity that they do not have to deal with. Now they don t have to
maintain machines that have pesky operating systems or hard drive failures.
They don t have to deal with updating the version of k8s
, nor ensuring the
backups work. No one has to push some artifact to prod manually. Deployments
happen unattended. You click a button and get a cluster.
On the other hand, developers outside the ops function need to deal with
troubleshooting CI, debugging access control rules encoded in turing complete
YAML, permissions issues inside the cluster due to whatever the fuck a service
mesh is, everyone needs to learn how to use some k8s
tools they only actually
use during a bad day, likely while doing some x.509
troubleshooting to
connect to the cluster (an internal only endpoint; just port forward it) not
to mention all sorts of rules to route packets to their project (a single
repo s binary being run in 3 containers on a single vm host).
Beyond that, there s the invisible complexity complexity on the interior of
a service you depend on. I think about the dozens of teams maintaining the EKS
service (which is either run on EC2 instances, or alternately, EC2 instances in
a trench coat, moustache and even more shell scripts), the RDS service (also
EC2 and shell scripts, but this time accounting for redundancy, backups,
availability zones), scores of hypervisors pulled off the shelf (xen
, kvm
)
smashed together with the ones built in-house (firecracker
, nitro
, etc)
running on hardware that has to be refreshed and maintained continuously. Every
request processed by network ACL rules, AWS IAM rules, security group rules,
using IP space announced to the internet wired through IXPs directly into ISPs.
I don t even want to begin to think about the complexity inherent in how those
switches are designed. Shitloads of complexity to solve problems you may or
may not have, or even know you had.
What s more complex? An app running in an in-house 4u server racked in the
office s telco closet in the back running off the office Verizon line, or an
app running four hypervisors deep in an AWS datacenter? Which is more complex
to you? What about to your organization? In total? Which is more prone to
failure? Which is more secure? Is the complexity good or bad? What type of
Complexity can you manage effectively? Which threaten the system? Which
threaten your users?
The availability of multiple binaries built from the same sources creates new challenges and opportunities, and raises questions such as: Does build A confirm the integrity of build B? or Can build A reveal a compromised build B? . To answer such questions requires a notion of equivalence between binaries. We demonstrate that the obvious approach based on bitwise equality has significant shortcomings in practice, and that there is value in opting for alternative notions. We conceptualise this by introducing levels of equivalence, inspired by clone detection types.A PDF of the paper is freely available.
[ ] delves into how two project[s] approaches fundamental security features through Reproducible Builds, Bootstrappable Builds, code auditability, etc. to improve trustworthiness, allowing independent verification; trustworthy projects require little to no trust. Exploring the challenges that each project faces due to very different technical architectures, but also contextually relevant social structure, adoption patterns, and organizational history should provide a good backdrop to understand how different approaches to security might evolve, with real-world merits and downsides.
the D8 Java to DEX compiler (part of the Android toolchain) eliminated a redundant field load if running the class s static initialiser was known to be free of side effects, which ended up accidentally depending on the sharding of the input, which is dependent on the number of CPU cores used during the build.To make it easier to understand the bug and the patch, Fay also made a small example to illustrate when and why the optimisation involved is valid.
CONFIG_MODULE_SIG
and the unreproducible Linux Kernel to add: I wonder whether it would be possible to use the Linux kernel s Integrity Policy Enforcement to deploy a policy that would prevent loading of anything except a set of expected kernel modules. [ ]
279
, 280
, 281
and 282
to Debian:
.ar
archives (#1085257
). [ ]systemd-ukify
in the Debian stable distribution. [ ]Depends
on the deprecated python3-pkg-resources
(#1083362
). [ ]devscripts
version 2.24.2, including many changes to the debootsnap
, debrebuild
and reproducible-check
scripts. This is the first time that debrebuild
actually works (using sbuild
s unshare
backend). As part of this, Holger also fixed an issue in the reproducible-check
script where a typo in the code led to incorrect results [ ]
The new server has no problems keeping up with importing the full archives on every update, as each run finishes comfortably in time before it s time to run again. [While] the new server is the one doing all the importing of updated archives, the HTTP interface is being served by both the new server and one of the VM s at LeaseWeb.The entry list a number of specific updates surrounding the API endpoints and rate limiting.
hulkoba
README
page for building the website under NixOS. [ ][ ][ ][ ][ ]index.html
for rebuilderd
. [ ]nginx.conf
configuration file for rebuilderd
. [ ]riscv64
architecture. [ ]rebuilderd
-related TODO. [ ]inos5
node [ ] and Vagrant Cascadian brought 4 virt
nodes back online [ ].
apache-ivy
(.zip
modification time)ccache
(build failure)colord
(CPU)efivar
(CPU/march=native)gsl
(no check)libcamera
(date/copyright year)libreoffice
(possible rpm/build toolchain corruption bug)moto
(.gz
modification time)openssl-1_1
(date-related issue)python-pygraphviz
(benchmark)sphinx/python-pygraphviz
(benchmark)python-panel
(package.lock
has random port)python-propcache
(random temporary path)python314
(.gz
-related modification time)rusty_v8
(random .o
files)scapy
(date)wine
(parallelism)ibmtss
(FTBFS-2026)pymol
(date)pandas
(ASLR)linutil
(drop date)lsof
(also filed in openSUSE: uname -r
in LSOF_VSTR
)schily
(also filed in openSUSE: uname -r
)superlu
(nocheck)util
(random test failure)ceph
(year-2038 variation from embedded boost)distro-info
.calibre
(two sort issues) [ ][ ]#reproducible-builds
on irc.oftc.net
.
rb-general@lists.reproducible-builds.org
libpng1.6
would fail to cross build on musl
architectures whereas it would succeed on other ones failing to locate zlib
. Adding --debug-find
to the cmake
invocation eventually revealed that it would fail to search in /usr/lib/<triplet>
, which is the default library path. This turned out to be a bug in cmake assuming that all linux systems use glibc. libpng1.6
also gained a baseline violation for powerpc
and ppc64
by enabling the use of AltiVec there.
The newt
package would fail to cross build for many 32-bit architectures whereas it would succeed for armel
and armhf
due to -Wincompatible-pointer-types
. It turns out that this flag was turned into -Werror
and it was compiling with a warning earlier. The actual problem is a difference in signedness between wchar_t
and FriBidChar
(aka uint32_t
) and actually affects native building on i386
.
mkdocs-macros-plugin
, which required packaging a new Python package for Debian, python-super-collections (now in NEW review).Publisher: | Mark Lawrence |
Copyright: | June 2023 |
Copyright: | February 2024 |
ASIN: | B0C9N51M6Y |
ASIN: | B0CTYNQGBX |
Format: | Kindle |
Pages: | 99 |
gputools
. As
hinted in the previous paragraph, it was once on CRAN but is not right now so we
adjusted our reference.
CRANberries
also provides a diffstat report for
the latest release.
If you like this or other open-source work I do, you can sponsor me at
GitHub.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
->
has become
, and \
is now
.
Another option is perhaps the newest, the LaTeX package minted, which
leverages the Python Pygments program. Here's the same code again. It
defaults to monospace (the choice of font seems a lot clearer to me than the
default for listings
), no symbolic substitution, and liberal use of colour:
An informal survey of the samples so far showed that the minted output was
the most popular.
All of these packages can be configured to varying degrees. Here are some
examples of what I've achieved with a bit of tweaking
All of this has got me wondering whether there are straightforward empirical
answers to some of these questions of style.
Firstly, I'm pretty convinced that symbolic substitution is valuable. When
writing Haskell, we write ->
, \
, /=
etc. not because it's most legible,
but because it's most practical to type those symbols on the most widely
available keyboards and popular keyboard layouts.1 Of the three
options listed here, symbolic substitution is possible with listings and
lhs2tex, but I haven't figured out if minted can do it (which is really
the question: can pygments do it?)
I'm unsure about proportional versus monospaced fonts. We typically use
monospaced fonts for editing computer code, but that's at least partly for
historical reasons. Vertical alignment is often very important in source code,
and it can be easily achieved with monospaced text; it's also sometimes
important to have individual characters (.
, etc.) not be de-emphasised by being
smaller than any other character.
lhs2tex, at least, addresses vertical alignment whilst using proportional
fonts. I guess the importance of identifying individual significant characters
is just as true in a code sample within a larger document as it is within
plain source code.
From a (brief) scan of research on this topic, it seems that proportional
fonts result in marginally quicker reading times for regular prose. It's
not clear whether those results carry over into reading computer code in
particular, and the margin is slim in any case. The drawbacks of monospaced
text mostly apply when the volume of text is large, which is not the case
for the short code snippets I am working with.
I still have a few open questions:
instead of elem
,
instead of /=
. Sadly, it's not possible
to replace the denotation for an anonymous function, \
, with
this
way. libglib2.0-dev
such that it would absorb more functionality and in particular provide tools for working with .gir
files. Those tools practically require being run for their host architecture (practically this means running under qemu-user
) which is at odds with the requirements of architecture cross bootstrap. The qemu
requirement was expressed in package dependencies and also made people unhappy attempting to use libglib2.0-dev
for i386
on amd64
without resorting to qemu
. The use of qemu
in architecture bootstrap is particularly problematic as it tends to not be ready at the time bootstrapping is needed.
As a result, Simon proposed and implemented the introduction of a libgio-2.0-dev
package providing a subset of libglib2.0-dev
that does not require qemu
. Packages should continue to use libglib2.0-dev
in their Build-Depends
unless involved in architecture bootstrap. Helmut reviewed and tested the implementation and integrated the necessary changes into rebootstrap. He also prepared a patch for libverto to use the new package and proposed adding forward compatibility to glib2.0.
Helmut continued working on adding cross-exe-wrapper to architecture-properties and implemented autopkgtests later improved by Simon. The cross-exe-wrapper
package now provides a generic mechanism to a program on a different architecture by using qemu
when needed only. For instance, a dependency on cross-exe-wrapper:i386
provides a i686-linux-gnu-cross-exe-wrapper
program that can be used to wrap an ELF executable for the i386
architecture. When installed on amd64
or i386
it will skip installing or running qemu
, but for other architectures qemu
will be used automatically. This facility can be used to support cross building with targeted use of qemu
in cases where running host code is unavoidable as is the case for GObject introspection.
This concludes the joint work with Simon and Niels Thykier on glib2.0
and architecture-properties
resolving known architecture bootstrap regressions arising from the glib2.0
refactoring earlier this year.
dpkg
, the question arises how this affects existing packages. The dedup.debian.net infrastructure provides an easy playground to answer such questions, so Helmut gathered file metadata from all binary packages in unstable and performed an explorative analysis. Some results include:
/usr
-merge is not the only cause for aliasing problems in Debian.
dpkg
can enforce.
setup.py test
. This month, Stefano did some more rebuilds, starting with experimental versions of dh-python
.
During the Python 3.12 transition, we had added a dependency on python3-setuptools to dh-python, to ease the transition. Python 3.12 removed distutils from the stdlib, but many packages were expecting it to still be available. Setuptools contains a version of distutils, and dh-python was a convenient place to depend on setuptools for most package builds. This dependency was never meant to be permanent. A rebuild without it resulted in mass-filing about 340 bugs (and around 80 more by mistake).
A new feature in Python 3.12, was to have unittest s test runner exit with a non-zero return code, if no tests were run. We added this feature, to be able to detect tests that are not being discovered, by mistake. We are ignoring this failure, as we wouldn t want to suddenly cause hundreds of packages to fail to build, if they have no tests. Stefano did a rebuild to see how many packages were affected, and found that around 1000 were. The Debian Python community has not come to a conclusion on how to move forward with this.
As soon as Python 3.13 release candidate 2 was available, Stefano did a rebuild of the Python packages in the archive against it. This was a more complex rebuild than the others, as it had to be done in stages. Many packages need other Python packages at build time, typically to run tests. So transitions like this involve some manual bootstrapping, followed by several rounds of builds. Not all packages could be tested, as not all their dependencies support 3.13 yet. The result was around 100 bugs in packages that need work to support Python 3.13. Many other packages will need additional work to properly support Python 3.13, but being able to build (and run tests) is an important first step.
setup.py test
, backported a large upstream patch set to make buildbot work with SQLAlchemy 2.0, and upgraded 25 other Python packages to new upstream versions.
sbuild
reviewing and improving a MR for refactoring the unshare backend.
gcc-defaults
.
/usr
-move. With more and more key packages such as libvirt
or fuse3
fixed. We re moving into the boring long-tail of the transition.
glib2.0
above, rebootstrap moves a lot further, but still fails for any architecture.
libcupsfilter
to fix the autopkgtest and a dependency problem of this package. After package splix
was abandoned by upstream and OpenPrinting.org adopted its maintenance, Thorsten uploaded their first release.
binsider
tool to analyse ELF binaries
README
page:
Binsider can perform static and dynamic analysis, inspect strings, examine linked libraries, and perform hexdumps, all within a user-friendly terminal user interface!More information about Binsider s features and how it works can be found within Binsider s documentation pages.
95% fixed by [merge request] !12680 when -fobject-determinism
is enabled. [ ]
The linked merge request has since been merged, and Rodrigo goes on to say that:
After that patch is merged, there are some rarer bugs in both interface file determinism (eg.#25170
) and in object determinism (eg.#25269
) that need to be taken care of, but the great majority of the work needed to get there should have been merged already. When merged, I think we should close this one in favour of the more specific determinism issues like the two linked above.
zlib
/deflate
compression in .zip
and .apk
files and later followed up with the results of her subsequent investigation.
CONFIG_MODULE_SIG
flag. [ ]
zlib
to zlib-ng
as reproducibility requires identical compressed data streams. [ ]
maven-lockfile
that is designed aid building Maven projects with integrity . [ ]
This is a report of Part 1 of my journey: building 100% bit-reproducible packages for every package that makes up [openSUSE s] minimalVM
image. This target was chosen as the smallest useful result/artifact. The larger package-sets get, the more disk-space and build-power is required to build/verify all of them.
This work was sponsored by NLnet s NGI Zero fund.
A hermetic build system manages its own build dependencies, isolated from the host file system, thereby securing the build process. Although, in recent years, new artifact-based build technologies like Bazel offer build hermeticity as a core functionality, no empirical study has evaluated how effectively these new build technologies achieve build hermeticity. This paper studies 2,439 non-hermetic build dependency packages of 70 Bazel-using open-source projects by analyzing 150 million Linux system file calls collected in their build processes. We found that none of the studied projects has a completely hermetic build process, largely due to the use of non-hermetic top-level toolchains. [ ]
debrebuild
component of the devscripts suite of tools. In particular:
#1081047
: Fails to download .dsc
file.#1081048
: Does not work with a proxy.#1081050
: Fails to create a debrebuild.tar
.#1081839
: Fails with E: mmdebstrap failed to run
error.build_path
variation. Holger Levsen provided a rationale for this change in the issue, which has already been made to the tests being performed by tests.reproducible-builds.org. This month, this issue was closed by Santiago R. R., nicely explaining that build path variation is no longer the default, and, if desired, how developers may enable it again.
278
to Debian:
python3-setuptools
dependency. (#1080825)Standards-Version
to 4.7.0. [ ]0.5.11-4
was uploaded to Debian unstable by Holger Levsen making the following changes:
pkg-config
package with one on pkgconf
, following a Lintian check. [ ]Standards-Version
field to 4.7.0, with no related changes needed. [ ]0.7.28
was uploaded to Debian unstable by Holger Levsen including a change by Jelle van der Waa to move away from the pipes
Python module to shlex
, as the former will be removed in Python version 3.13 [ ].
classes.dex
file (and thus a different .apk
) depending on the number of cores available during the build, thereby breaking Reproducible Builds:
We ve rebuilt [tagv3.6.1
] multiple times (each time in a fresh container): with 2, 4, 6, 8, and 16 cores available, respectively:
- With 2 and 4 cores we always get an unsigned APK with SHA-256
14763d682c9286ef
.- With 6, 8, and 16 cores we get an unsigned APK with SHA-256
35324ba4c492760
instead.
reproducibility settings [being] applied to some of Gradle s built-in tasks that should really be the default. Compatible with Java 8 and Gradle 8.3 or later.
ext4
, erofs
and FAT
filesystems can now be made reproducible . [ ]
agama-integration-tests
(random)contrast
(FTBFS-nocheck)cpython
(FTBFS-2038)crash
(parallelism, race)ghostscript
(toolchain date)glycin-loaders
(FTBFS -j1
)gstreamer-plugins-rs
(date, other)kernel-doc/Sphinx
(toolchain bug, parallelism/race)kernel
(parallelism in BTF)libcamera
(random key)libgtop
(uname -r
)libsamplerate
(random temporary directory)lua-luarepl
(FTBFS)meson
(toolchain)netty
(modification time in .a
)nvidia-persistenced
(date)nvidia-xconfig
(date-related issue)obs-build
(build-tooling corruption)perl
(Perl records kernel version)pinentry
(make efl droppable)python-PyGithub
(FTBFS 2024-11-25)python-Sphinx
(parallelism/race)python-chroma-hnswlib
(CPU)python-libcst
python-pygraphviz
(random timing)python312
(.pyc
embeds modification time)python312
(drop .pyc
from documentation time)scap-security-guide
(date)seahorse
(parallelism)subversion
(minor Java .jar
modification times)xen/acpica
(date-related issue in toolchain)xmvn
(random)magic-wormhole-transit-relay
.python-sphobjinv
.lomiri-content-hub
.python-mt-940
.tree-puzzle
.muon-meson
.osuosl4
node to Debian trixie in anticipation of running debrebuild
and rebuilderd
there. [ ][ ][ ]osuosl4
node as offline due to ongoing xfs_repair
filesystem maintenance. [ ][ ]risc64
architecture to the multiarch version skew tests for Debian trixie and sid. [ ][ ][ ]virt 32,64 b
nodes as down. [ ]virt32b
and virt64b
nodes [ ], performed some maintenance of the cbxi4a
node [ ][ ] and marked most armhf
architecture systems as being back online.
#reproducible-builds
on irc.oftc.net
.
rb-general@lists.reproducible-builds.org
Next.