Re: Using 'libfaketime' for reproducible builds

[Werner LEMBERG]

>> Before investing more time into it I wonder whether the use of
>> 'libfaketime' would be a valid solution for creating reproducible
>> builds.
> 
> My 2 cents: The widely accepted solution is SOURCE_DATE_EPOCH and if
> there is anything in LilyPond itself that inserts unreproducible data
> (into PostScript code), that should be fixed.

AFAICS, my last MR is the last missing bit to achieve that from the
binary side – as mentioned, there is still some randomness in the
build infrastructure.

However, conversion to PDF using ghostscript can't be controlled
sufficiently from the LilyPond side w.r.t. reproducibility.

> Intercepting syscalls (or whatever the library does, I didn't check)

Yes.

> doesn't sound like the right approach outside of testing
> reproducibility.

Why?  It's even less intrusive than the `SOURCE_DATE_EPOCH` solution.

> The larger "issue" with this topic seems to be LilyPond's
> dependencies, in particular Ghostscript.  A contribution to add
> support for above variable was closed as WONTFIX:
> https://bugs.ghostscript.com/show_bug.cgi?id=696765

Exactly.  In particular it means that we had to use the patched Debian
version of ghostscript for reproducibility if we go the
`SOURCE_DATE_EPOCH` route – and check which other distributions
provide something similar.  I consider this as a very hacky solution.
On the other hand, intercepting the time syscalls is a completely
transparent and clean solution.

BTW, the next version 'libfaketime' will allow to intercept
`getrandom`, which means that we probably can 'fix' the `/ID` issue in
PDF files generated by gs, too.

> I think that's a pity, but nothing we can change as a "consumer" of
> library functions.

Exactly.  As long as we don't change LilyPond to produce PDFs by
itself – which is a huge undertaking that I certainly won't start – I
think we have no other choice than using something like 'libfaketime'
or a patched gs version.  I definitely prefer the former.


     Werner