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 <a...@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 _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds