On Wed, Feb 03, 2021 at 10:41:30PM -0500, Neal Gompa wrote: > On Wed, Feb 3, 2021 at 4:51 PM Frédéric Pierret > <frederic.pier...@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/rpmbuildinfo > > or > > https://raw.githubusercontent.com/fepitre/rpmreproduce/master/scripts/rpmbuildinfo > > (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.
Isn't it going to be an issue that the initial SRPM can't possibly have
this info? Buildinfo generally is a product of a build, similar to build
log, just more structured, which can be used as a build input in some
cases too (reproducing particular binary rpm). Copying from Debian wiki:
The .buildinfo file has several goals which are related to each other:
* It records information about the system environment used during a
particular build -- packages installed (toolchain, etc), system
architecture, etc. This can be useful for forensics/debugging.
* It can also be used to try to recreate (partially or in full) the
system environment when trying to reproduce a particular build.
It makes a perfect sense to take a single SRPM and build in two
different environments (for example for f33 and f34) - resulting in two
different sets of binary RPMs and two buildinfo files (wherever they
will be).
So, if including in an RPM, I'd say it is more logical to include in a
binary RPM - a build output. In fact, Archlinux does exactly that (in
their package format). If it would be in an SRPM, then you'd need to
rebuild/modify SRPM _after_ building binary RPMs, which feels wrong...
Does it make sense?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
