Bug#900918: debian-installer: Please make the generated images reproducible

Chris Lamb lamby at debian.org
Mon Jan 21 12:25:31 GMT 2019


Dear Cyril,

Thank you for your review and timely merge.

> That's looking good but I'm seeing new warnings because of gzip's being
> unhappy about the GZIP environment variable.

Interesting. However when you say "new" warnings I don't believe my
patch set actually added/changed this; indeed, it has not changed
since:

   https://salsa.debian.org/lamby/debian-installer/commit/28b863340cc5fd73fbaac85a3fb89e72e842b15c

… so I'm just checking what you are requesting to be done here.

§

> All gtk files have fontconfig-related cache/uuid changes…
[…]
> FWIW, dropping all fontconfig-related bits (see attached patch)

This is #864082 in src:fontconfig — I've been playing whack-a-mole
with fontconfig over the past 18 months or so and this was a
fairly recent regression.

Are you planning on applying this patch to debian-installer.git?
Naturally, I would prefer if #864082 was applied and in buster, or
otherwise closed again.

§

> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg?

Possibly. Let me try and reproduce and reload all of that into my
brain and get back to you on this; IIRC there was some pushback
against making it change behaviour only on SOURFE_DATE_EPOCH being
present so — as you imply — a command-line change might be required.

§

> (Including lintian runtime, using pigz on a 8-way machine cuts real time
> from 8m8s to 4m23s.)

TIL pigz; thanks.

> Checking what happens [it] seems successive builds with pigz lead to the
> same results. But those aren't the same as the results generated with
> gzip. I don't suppose this is going to be a particularly huge problem
> though?

Alas, it is a problem in thatfrom the outside nobody will know
whether one built with pigz or gzip and thus it will be unclear how
to reproduce the bit-for-bit identical binary. In other words, there
is currently no ".buildinfo" equivalent here that specifies "I used
Arch^Wpigz, btw" and got a SHA of $foo.

One easy solution would be if that, if SOURCE_DATE_EPOCH is present,
then we force the use of one tool. Although that would regrettably
mean the lowest common denominator (ie. gzip)  which probably isn't
the ideal due to the aforementioned performance gain for using pigz.
Alternatively, we could make pigz a strict build requirement but
that sounds a little antisocial.

Perhaps we need to record the environment after all; again, I will
reload all of this into my head anyway due to mini.iso (^) so this
will be top-of-stack again.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org 🍥 chris-lamb.co.uk
       `-



More information about the Reproducible-builds mailing list