[arch-general] Participation of Arch in Google Summer of Code.

[Tinu Weber]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190219/68836904/attachment.sig>