On 1/14/19 12:42 PM, Mattia Rizzolo wrote:
I personally still prefer to _also_ push for single fixes, dropping any
source of possible unreproducibilities.
After all, the build date is totally meaningless in pretty much all
cases I can think of, so getting rid of it completely is only good, and
t
On Tue, Dec 25, 2018 at 08:31:42PM +, Bernhard M. Wiedemann wrote:
> regarding https://github.com/uoaerg/wavemon/pull/59
>
> I thought, we do not need to do this kind of patch anymore since gcc
> natively supports SOURCE_DATE_EPOCH to override __DATE__ and __TIME__
> and everyone interested in
On 12/26/18 1:34 PM, Daniel Shahaf wrote:
> Eli Schwartz wrote on Tue, 25 Dec 2018 15:52 -0500:
>> Eh, it's hardly harmful either way. I don't believe there was any
>> explicit desire to avoid relying on toolchain fixes though. Especially
>> since the patch is definitely in Arch Linux's toolchain (
Eli Schwartz wrote on Tue, 25 Dec 2018 15:52 -0500:
> Eh, it's hardly harmful either way. I don't believe there was any
> explicit desire to avoid relying on toolchain fixes though. Especially
> since the patch is definitely in Arch Linux's toolchain (we have gcc 8)
> so in the ordinary way of thin
On 12/25/18 3:31 PM, Bernhard M. Wiedemann wrote:
> regarding https://github.com/uoaerg/wavemon/pull/59
>
> I thought, we do not need to do this kind of patch anymore since gcc
> natively supports SOURCE_DATE_EPOCH to override __DATE__ and __TIME__
> and everyone interested in reproducible builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
regarding https://github.com/uoaerg/wavemon/pull/59
I thought, we do not need to do this kind of patch anymore since gcc
natively supports SOURCE_DATE_EPOCH to override __DATE__ and __TIME__
and everyone interested in reproducible builds sets this var
