[Reproducible-builds] [pkg-wml] Bug#833437: mp4h: please make the build reproducible

[Axel Beckert]

Control: tag -1 -patch +confirmed

Hi Chris,

Chris Lamb wrote:
> Whilst working on the "reproducible builds" effort [0], we noticed
> that mp4h could not be built reproducibly.

Yeah, that's well known -- at least to me. :-)

> Patch attached.

Thanks. Despite hours of work I haven't managed to get it building
completely reproducibly yet.

> -@@ -1958,7 +1958,7 @@
> +@@ -1958,7 +1958,7 @@ This is similar to using the &m4; undive

I'd really appreciate if unnecessary clutter like this would not be
part of submitted patches. Had to remove many of them to get to the
essence of your patch.

> --- a/doc/mp4h.mp4h	2016-08-04 09:30:01.438012891 +0100
> --- b/doc/mp4h.mp4h	2016-08-04 09:37:42.517347692 +0100
> @@ -2260,13 +2260,6 @@
>  is the number of clock ticks, and so is dependent of your CPU.
>  </para>
>  
> -<example>
> -<timer/>
> -The number of clock ticks since the beginning of the parsing of
> -this example by &mp4h; is:
> -<timer/>
> -</example>
> -
>  <tag:description mp4h-l10n>
>  <var name />=<var value />
>  </tag:description>

This hunk did not apply:

→ GET https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=833437\;filename\=mp4h.diff.txt\;msg\=5 | patch -p1
patching file debian/patches/reproducible-build.diff
patching file doc/mp4h.mp4h
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file doc/mp4h.mp4h.rej

It seems that's a leftover of what you've added to
debian/patches/reproducible-build.diff, namely the essence of your
patch.

So your whole patch is to just remove one code example from the
documentation?!?

That's cheating! :-(

If I would have gone that way I wouldn't have needed that many
iterations to get as far as I am now with making mp4h building
reproducibly.

Actually I'm fully aware of that <timer/> is the last reason (or at
least one of the last reasons) why mp4h doesn't build reproducibly.
But so far I didn't have an idea how to make that value reproducible.

Just removing the example is IMHO definitely _not_ how reproducible
builds should work, so I refuse to apply your patch.

I'd rather hack something that <timer/> generates a reproducible value
if $SOURCE_DATE_EPOCH is set. Like the last two digits of it or so.

(So your bug report at least triggered an idea on how to be able to
get <timer/> to reproducibly return the same value. :-)

Note to myself: A nice test which often different values is this:

$ perl -E 'say "<timer/>"x150000' | nice -n 20 mp4h | tail -3

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE