On Wed, Feb 3, 2021 at 4:51 PM Frédéric Pierret
<frederic.pierret(a)qubes-os.org> wrote:
Hi,
As discussed few weeks ago, I'm working on reproducible builds for Fedora. I've
submitted a request for review for new packages:
https://bugzilla.redhat.com/show_bug.cgi?id=1924918. Notably, reprotest is a striking tool
to test reproduciblity by changing multiples build factors (time, user, lang, etc.) and
highlight differences (if exists) with diffoscope (see
https://salsa.debian.org/reproducible-builds/reprotest).
On the same topic, I'm developing rpmreproduce (see
https://github.com/fepitre/rpmreproduce) which is very much work in progress. This tool
allows to rebuild a RPM with the same environment, packages versions etc. This is in the
continuity of a previous attempt
https://github.com/kholia/ReproducibleBuilds. Currently,
it uses a "buildinfo" file as input (see
https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles) but there is not such file in
Fedora (yet?). In Qubes OS, we use an original implementation for RPM done at the occasion
of Reproducible Builds summit:
https://github.com/QubesOS/qubes-builder-rpm/blob/master/scripts/rpmbuild... or
https://raw.githubusercontent.com/fepitre/rpmreproduce/master/scripts/rpm... (latest
dev/test version). This tool is in charge to download exact version dependencies as
specified in the buildinfo, create a local repository, download the corresponding source
RPM and then, rebuild it with mock and only this locally created repository that reflects
the original build environment.
I take this opportunity to invite RPM devs to discuss about a possible upstream
implementation of buildinfo file format. For example, we could think about having a
buildinfo file automatically generated by rpmbuild as dpkg is doing similarly in Debian. I
would be happy to do the work for that.
The Koji build system already records buildinfo data in a slightly
different form, where build IDs are linked to all the inputs that
constructed the build environment as recorded by Koji itself. This
implicitly includes a definition of all the RPM macros that are inputs
for a build, too.
I would generally expect that information like this at the rpmbuild
level should probably be stored in the Source RPM. Since a Source RPM
is an atomic unit containing a build description and the inputs needed
to make the build work, it would make sense that more comprehensive
build environment data would go there. Source RPMs already contain
some rudimentary stuff, like the compiler build flags set in the build
environment during the package build time. It would make sense to
expand this to cover all inputs traditionally covered by the buildinfo
file in Debian.
--
真実はいつも一つ!/ Always, there's only one truth!