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. Kind Regards, Tinu
Attachment:
signature.asc
Description: PGP signature