On 2/19/19 11:26 AM, Tinu Weber wrote:
On Tue, Feb 19, 2019 at 10:22:34 -0500, Eli Schwartz via arch-general wrote:
On 2/19/19 10:19 AM, Tinu Weber wrote:
On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.
In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)
(that being said, I'm obviously open for discussing suggestions)
I see no problem and nothing to fix here. reproducible rebuilding a .pkg.tar.xz created by remakepkg, which has as its whole purpose, surgery upon a package, seems fundamentally unreproducible to me, moreover why would you want to reproduce it -- a reproducible rebuild of remakepkg packages should have as its only input, the original .pkg.tar.xz
I was thinking more of: "If I run remakepkg twice on the same package, with the same rules, do I get the same output package?".
I just checked, and I do indeed modify the timestamp of a file when patching it (both the file itself and its MTREE entry), and I don't respect SOURCE_DATE_EPOCH, so I would conclude that remakepkg does not produce reproducible .pkg.tar.xz files.
That's a fair point. If you wanted to have remakepkg be a program that supported reproducible builds, it would need to respect some form of SOURCE_DATE_EPOCH -- I suggest using the builddate that the original .pkg.tar.xz used. As well, provide some mechanism for https://reproducible-builds.org/docs/recording/ the input (the .pkg.tar.xz and the deviations that have been declared). The difference is that it is hardly an issue if remakepkg invalidates the makepkg .BUILDINFO spec, since remakepkg is not makepkg and isn't expected to produce the same output as makepkg anyway -- it is only meant to produce output that *pacman/libalpm* can consume. -- Eli Schwartz Bug Wrangler and Trusted User