>> 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