Bug#894476: rcc: please honour SOURCE_DATE_EPOCH (was Re: RCC: provide option to encode EPOCH timestamp)

[Thorsten Glaser <t.glaser@tarent.de>]

affects 894476 src:musescore
retitle 894476 rcc: please honour SOURCE_DATE_EPOCH
thanks

Hi *,

I just got bitten by this in an FTBR of src:musescore which I tracked
down to this bug.

On Tue, 3 Apr 2018, Sune Vuorela wrote:

> If S_D_E gets used, rather than the data.xml modified date in the
> source, this will end up using the wrong file if S_D_E is newer than
> the system copy of the file.

AIUI, S_D_E is used as a *delimiter*, not as a timestamp *all* files
are to be set to.

So, basically, instead of

	encode(dst, sb.st_mtime);

you do

	encode(dst, MIN(sb.st_mtime, s_d_e_as_time_t_value));

and not

	encode(dst, s_d_e_as_time_t_value);

which would indeed break things the way you described.


Chris/H01ger, please correct me if I’m wrong, but this is
how I understood S_D_E to work.


I don’t know cmake magic enough to be able to do the same
patch to lrelease et al. as Thomas did, so I unfortunately
will have to live with the FTBR in src:musescore until this
issue is fixed.

Thanks,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
	-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel