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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
