>> 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 t
Am Montag, dem 28.12.2020 um 11:40 +0100 schrieb Werner LEMBERG:
> > I definitely consider intercepting various syscalls by means of
> > LD_PRELOADing more intrusive than setting a single environment
> > variable that was invented for the purpose of setting timestamps.
> > Just think of a new shiny
>> I definitely consider intercepting various syscalls by means of
>> LD_PRELOADing more intrusive than setting a single environment
>> variable that was invented for the purpose of setting timestamps.
>> Just think of a new shiny syscall that might add a new source of
>> non-reproducibility.
>
> I definitely consider intercepting various syscalls by means of
> LD_PRELOADing more intrusive than setting a single environment
> variable that was invented for the purpose of setting timestamps.
> Just think of a new shiny syscall that might add a new source of
> non-reproducibility.
What 'ne
Am Montag, dem 28.12.2020 um 10:52 +0100 schrieb Han-Wen Nienhuys:
> On Mon, Dec 28, 2020 at 10:26 AM Jonas Hahnfeld
> wrote:
>
> > This probably leaves the UUIDs (is that the issue you mention
> > above?) which can be overridden using -sDocumentUUID and -
> > sInstanceUUID. Setting a constant ti
On Mon, Dec 28, 2020 at 10:26 AM Jonas Hahnfeld wrote:
> Am Sonntag, dem 27.12.2020 um 22:24 +0100 schrieb Werner LEMBERG:
> > > Intercepting syscalls (or whatever the library does, I didn't
> > > check) doesn't sound like the right approach outside of testing
> > > reproducibility.
> >
> > Why?
Am Sonntag, dem 27.12.2020 um 22:24 +0100 schrieb Werner LEMBERG:
> > Intercepting syscalls (or whatever the library does, I didn't
> > check) doesn't sound like the right approach outside of testing
> > reproducibility.
>
> Why? It's even less intrusive than the `SOURCE_DATE_EPOCH` solution.
I
>> 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
> (int
Am Sonntag, dem 27.12.2020 um 18:02 +0100 schrieb 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
>> The idea is to do the following:
>>
>> export LD_PRELOAD=/usr/local/lib/libfaketime.so.1
>> export FAKETIME="2020-12-24 00:00:00"
>>
>> make all
>> make doc
>>
>> This freezes the current time at a given value.
>
> Isn't that a problem for the operation of Make itself since it
> relie
Werner LEMBERG writes:
> Before investing more time into it I wonder whether the use of
> 'libfaketime' would be a valid solution for creating reproducible
> builds. According to 'pkgs.org' it is available for most GNU/Linux
> distributions; it is also part of both MacPorts and Homebrew.
>
> h
Before investing more time into it I wonder whether the use of
'libfaketime' would be a valid solution for creating reproducible
builds. According to 'pkgs.org' it is available for most GNU/Linux
distributions; it is also part of both MacPorts and Homebrew.
https://github.com/wolfcw/libfaketi
12 matches
Mail list logo
