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.pierret@xxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
