Age | Commit message (Collapse) | Author | Files | Lines |
|
This change is the companion to the one in dpkg-genchanges that lists
only relevant packages, instead of all the ones listed in debian/control,
but for the .buildinfo file instead of the .changes file.
|
|
This field will contain a list of tainting reason tags, which can denote
that the current build has potentially been broken.
Suggested-by: Alexander E. Patrakov <patrakov@gmail.com>
|
|
The former calls /bin/pwd, while the latter uses the getcwd() syscall
directly.
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
This reverts commit 83272497c5be8c4e703ab179906cf904465fe775.
This commit introduced a regression in the author test suite. And there's
a patch by Johannes 'josch' Schauer <josch@mister-muffin.de> which should
be fixing this and other problems. If this is needed after all, we will
need to refactor the functions first to take a hash instead of a long list
of arguments.
|
|
|
|
This is more extensible and more clear.
|
|
Packages intended to be built in a generic way must never rely on the
currently running kernel on the build system (an exception could be an
optimization rebuild using the current system as the reference baseline).
But to be able to detect when a package might not be reproducible due to
varying kernel information it is still useful to be able to record this
information. Although that information can be very sensitive.
When the builder has explicitly enabled the Build-Kernel-Version field
with the new dpkg-genbuildinfo --always-include-kernel option, it will
get included in the generated .buildinfo file.
Closes: #873937
|
|
This reduces the load chain for several Dpkg modules.
|
|
We should use the binary (instead of the source) version for the
.buildinfo filename, otherwise on binNMUs the filename will be wrong.
Reported-by: Raphaël Hertzog <hertzog@debian.org>
|
|
Our current minimal Perl version contains a new enough List::Util module
implementing none and any, and several other functions.
|
|
We should do something similar to what dpkg-gencontrol is doing, by
preventing duplicated entries for the same file with different versions.
In this case, because the assumption is that there can ever only be one
buildinfo file for a «source» or «all» build, but possibly multiple for
arch-specific builds (from another build driver than dpkg-buildpackage),
we filter based on this.
|
|
All the currently planned changes have been done, let's bump the format
version to denote a stable format, which will not change in incomatible
changes any more without bumping the major version component.
|
|
The dependency traversal code is currently broken, and this mostly
papers over the issue. Properly fixing this involves changes all over
the place, which would be too intrusive for this series.
We should handle this gracefully, instead of letting perl die.
Closes: #849944
|
|
The loop is per package stanza, so we need to parse both fields
separately.
Based-on-patch-by: Johannes Schauer <josch@debian.org>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
This will make it possible to enable or disable specific features that
should be recorded in the .buildinfo file. For now only “all” and “path”
are supported.
Closes: #848705
|
|
|
|
Using undeterministic filenames based on the buildinfo-id produces ugly
looking filenames, which get left behind when rebuilding the same source
multiple times as they vary by date.
There's really no great point in using unique filenames as they will end
up with different contents depending on the builder.
|
|
This records the time the build happened. This might be useful when
there is a need to track down problems caused by external time-based
events not visible from inside the build system. Things like hardware,
software deployment or other such failures.
|
|
|
|
This will allow other projects to use the same whitelist as dpkg does.
Requested-by: Johannes Schauer <josch@debian.org>
|
|
The code is fine, but perlcritic seems to have issues properly parsing
it. Let's help it by using an intermediate variable.
Addresses RegularExpressions::ProhibitUnusedCapture.
Warned-by: perlcritic
|
|
This makes the script slightly more idempotent by filtering the only
file it generates and registers itself.
|
|
If we are doing a binary build, we should expect at least one binary
artifact, and fail otherwise, instead of just always emitting a
warning due to missing binary artifacts.
Reported-by: Sven Joachim <svenjoac@gmx.de>
|
|
If we are doing a source build, we should just expect the source to be
available, and fail otherwise, instead of just emitting a warning.
|
|
The .buildinfo files are a new type of control files, similar to
the .changes files, meant to describe the environment of a build
and its artifacts. They are meant to be added to the Debian archive
to allow independent parties to reproduce a build and verify the
result.
Specifications for .buildinfo are available at:
<https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification>
This patch adds support for .buildinfo files in Dpkg::Control,
adds new .buildinfo fields to Dpkg::Control::Fields, a new
builtin-system-build-paths Dpkg::Vendor hook, and adds a new script
named dpkg-genbuildinfo, that will now be called by dpkg-buildpackage
before generating the .changes file.
[ntyni@debian.org: small changes. ]
Closes: #138409
Based-on-patch-by: Jérémy Bobbio <lunar@debian.org>
Signed-off-by: Guillem Jover <guillem@debian.org>
|