Re: Using 'libfaketime' for reproducible builds

[Werner LEMBERG]

>> What 'new shiny syscall' shall influence the creation of PDFs,
>> specified by international standards?  I think this is a straw man
>> argument.
> 
> For example a new syscall to get the current time.  While
> improbable, just look at things like the new statx call, it happens
> from time to time that very fundamental interfaces are introduced
> and eventually used.

If this unlikely scenario really happens, 'libfaketime' will be
updated accordingly, I guess.

>> This is what I've started with, see the attached experimental stuff.
> 
> This is not what I had in mind here, that is more towards my
> option 2).  With "strip" I really mean removing emitted fields from
> the generated PDF.

Ah, ok, I misunderstood.

> The format is very readable, a simple search-and-replace is easily
> able to deal with all instances discussed so far.

Let's assume that the various time-related fields in output PDFs are
fixed.  At least problems still remain.

(1) The various `essay.pdf` files include, among others, the images
    `bwv861-breitkopf.png` and `bwv861-gessellschaft.png`.  For some
    unknown reasons yet, this leads to different PDF files.  This
    might be a bug in `xdvipdfmx` (the PDF driver of `xetex`) of
    TeXLive 2020.

(2) `musicxml2ly` doesn't produce reproducible output; see issue
    #6076.

>> ... there is one additional field called `/ID` in (some) PDF output
>> files that is apparently a random-based value.  I've contacted some
>> gs people to get more info on that.
> 
> If you look into the GS code, it is based upon a) the current time
> (addressed by libfaketime) and b) the output file name that recent
> LilyPond sets to a random string for atomically moving the generated
> PDF.

Thanks for investigating this!


    Werner