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

[Ben Hutchings]

On Tue, 2019-01-22 at 10:53 +0100, Philipp Kern wrote:
> On 1/22/2019 7:08 AM, Cyril Brulebois wrote:
> > > Alternatively, we could make pigz a strict build requirement but
> > > that sounds a little antisocial.
> > Right.
> In what way do you consider this antisocial and what's speaking
> against
> doing that? If it's about CPU time, then maybe it should obey the
> parallelization setting of the build process.
[...]

The general way to communicate this is by wrapping the build in
"taskset", and pigz will surely follow that.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman




signature.asc
Description: This is a digitally signed message part

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

[Chris Lamb]

Hi Cyril,

> I think I'd prefer closing this very bug report whenever what's in
> git gets uploaded

That would definitely work for me. Indeed, it would probably help
separate discussions/issues correctly as any followups are likely =
to be much more specific.

> half the build time is spent waiting for gzip to finish its work on
> a single core. Reproducibility is very nice but I would definitely
> hate to lose this huge speed-up.

Absolutely, hence my regret at suggesting a fallback to gzip. *nod*

> > Perhaps we need to record the environment after all
[…]
> Ah right, pigz isn't in Build-Depends, so it's not included in the
> .buildinfo file…

"the .buildinfo"? As I understood it we are not recording any
explicit debian-installer build attestation document that records
the environment at the moment. Again, will reload this all into my
head soon and come up with a suggested solution if required in
another bug report.

Thanks again. :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

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

[Chris Lamb]

Philipp,

> > > Alternatively, we could make pigz a strict build requirement but
> > > that sounds a little antisocial.
> >
> > Right.
>
> In what way do you consider this antisocial and what's speaking against
> doing that?

I was using this word in a somewhat romantic sense; fewer
dependencies are "better" in some aesthetic or poetic sense.

Please do not read too much into it. :)

(I had also slightly assumed that pigz was only on some archs, but
I am clearly mistaken there...)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

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

[Philipp Kern]

On 1/22/2019 7:08 AM, Cyril Brulebois wrote:
>> Alternatively, we could make pigz a strict build requirement but
>> that sounds a little antisocial.
> Right.
In what way do you consider this antisocial and what's speaking against
doing that? If it's about CPU time, then maybe it should obey the
parallelization setting of the build process. But then it's already a
build process and if you want that to not be detrimental to your desktop
performance, you nice it. Apart from that thing I really struggle to
find something "antisocial" in that build-dependency.

Kind regards and thanks
Philipp Kern

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

[Cyril Brulebois]

Hi Chris,

Chris Lamb  (2019-01-21):
> > 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

I think I got stuff mixed up (hard to tell now as I deleted the 10+ GB
of build logs and artefacts I accumulated while testing various things
with your patch series and a couple of extra patches on top of it),
maybe because those warnings were moving around by a line or two in the
logs… Maybe that's why I thought they were new.

Putting the confusion aside, I pushed that to avoid the warnings:
  
https://salsa.debian.org/installer-team/debian-installer/commit/0b025d7f485ecf7ed8969068f98e49d3141d77fd

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

All in all, I'm not requesting you to do anything more on the d-i level
(there's been quite a lot of work already); just a mere suggestion to
maybe include an example of direct “gzip -n” specification for tar
invokations on the wiki, so that others don't have to look around how to
do that.


> > 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.

I don't plan to apply that patch; it was only meaning to serve as a
basis to double check there were no other reproducibility issues in the
gtk images.


> > 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.

OK. I think I'd prefer closing this very bug report whenever what's in
git gets uploaded (it's been a long run and thread already), and see
other issues discussed in a fresh bug report; would that work for you?


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

Now less than 4m, after an extra commit:
  
https://salsa.debian.org/installer-team/debian-installer/commit/234058c033ef05c9aab3ced7a7c8cd4917daff9b

> 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.

Ah right, pigz isn't in Build-Depends, so it's not included in the
.buildinfo file…

> 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.

Right, for a development build (meaning without the generation of the
big debian-installer-images tarball), my gut feeling without specific
clocking data is that half the build time is spent waiting for gzip
to finish its work on a single core. Reproducibility is very nice but
I would definitely hate to lose this huge speed-up.

> Alternatively, we could make pigz a strict build requirement but
> that sounds a little antisocial.

Right.

> 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.

Not having looked into the format or tool(s) generating it, would it
be reasonable to have an opt-in mechanism so that a package could
declare “please record the state of this package that might or might not
be installed”. So that pigz could be registered in some way, akin to:
“not-really-in-build-depends-but-oh-look-it-was-present-at-version-X”


Thanks again for your valuable feedback.

Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Chris Lamb]

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
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

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

[Cyril Brulebois]

Control: tag -1 pending

Cyril Brulebois  (2019-01-19):
> 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? (In which case build/config/arm.cfg might need an
> update as well.) Checking all MINIISO occurrences might also make sense
> I suppose?

FWIW, dropping all fontconfig-related bits (see attached patch) makes it
possible to confirm only mini.iso (regular and gtk ones) are showing
differences now:

installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS


I had purged the pigz package during my experiments, just to be sure it
wouldn't interfere:

build/Makefile:gzip = $(shell which pigz >/dev/null 2>&1 && echo "pigz -n 
-T" || echo "gzip -n")

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

Checking what happens, and forgetting about the aforementioned mini.iso
images temporarily, 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?


Anyway, summarizing: likely more work to be done on the xorriso front,
(on the debian-installer side) for the mini.iso images produced for
netbooting; and fontconfig needs to get fixed in some way at some point
(but I know it's been a long run as well…); but all the rest looks good.

Pushing once I have updated the changelog; marking as pending, thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
From b1de326f8e97105e97beaf8b14c4af88894a62f0 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sat, 19 Jan 2019 22:09:23 +
Subject: [PATCH] Remove unreproducible bits due to fontconfig.

---
 build/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/build/Makefile b/build/Makefile
index 22abaac1d..2e6a0c76c 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -634,6 +634,11 @@ endif
 		fc-cache -s -y "$(TREE)"; \
 	fi
 
+	# Clean everything to check reproducibility:
+	@echo "HACK ALERT: fontconfig clean-up"
+	rm -v -rf "$(TREE)/var/cache/fontconfig"
+	find "$(TREE)" -name .uuid -print -delete
+
 	# Remove some unnecessary dpkg files.
 	set -e; \
 	for file in `find $(TREE)/var/lib/dpkg/info -name '*.md5sums' -o \
-- 
2.20.1



signature.asc
Description: PGP signature

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

[Cyril Brulebois]

Cyril Brulebois  (2019-01-19):
> Back to d-i results: I'm seeing small differences in the generated
> -images tarball, that I'll try to investigate. I'll probably push the
> series anyway, as these patches are helping anyway. :)

Here are the differences I'm seeing by building multiple times in the
same sid devel chroot:

installer-amd64/20190119/images/cdrom/gtk/initrd.gz
installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/hd-media/gtk/initrd.gz
installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/debian-installer/amd64/initrd.gz
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/gtk/netboot.tar.gz
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS

*SUMS are no-brainers due to changes in other files.

All gtk files have fontconfig-related cache/uuid changes…

Excluding those, remaining files are:

installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/netboot/mini.iso

The boot.img includes two initrds: initrd.gz and initrdg.gz; the latter
is the one with graphical support, which explains why it's also hit by
the fontconfig cache/uuid problem.

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? (In which case build/config/arm.cfg might need an
update as well.) Checking all MINIISO occurrences might also make sense
I suppose?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
--- d-i-8/extract/installer-amd64/20190119/images/netboot/mini.iso
+++ d-i-9/extract/installer-amd64/20190119/images/netboot/mini.iso
│┄ Format-specific differences are supported for this file format but none were detected (DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 240, 5376 sectors; partition 3 : ID=0x1, start-CHS (0x28,0,1), end-CHS (0x2d,63,32), startsector 81920, 12288 sectors)
@@ -21,25 +21,25 @@
 0140: 04b3 07cd 103c 0a75 f1cd 18f4 ebfd   .<.u
 0150:          
 0160:          
 0170:          
 0180:          
 0190:          
 01a0:          
-01b0: f015    bd2c ea2e  8000  .,..
+01b0: f015    f3a8 811b  8000  
 01c0: 0100 003f 2027   0040 0100 00fe  ...? '.@
 01d0:  effe  f000  0015    
 01e0: 0128 013f 202d 0040 0100 0030    .(.? -.@...0
 01f0:        55aa  ..U.
 0200: 4546 4920 5041 5254  0100 5c00   EFI PART\...
-0210: 6d39 8060   0100     m9.`
+0210: eaae c021   0100     ...!
 0220: ff3f 0100   2200     .?.."...
-0230: de3f 0100   e54d 5a45 8789 8e48  .?...MZE...H
-0240: 94f8 d8a5 4fef 9546 0200     O..F
-0250: 8000  8000  2e4a 6260    .Jb`
+0230: de3f 0100   c3d2 f8ef b4ab 7940  .?y@
+0240: bcb6 4ce6 6ef7 1afc 0200     ..L.n...
+0250: 8000  8000  a705 e2f2    
 0260:          
 0270:          
 0280:          
 0290:          
 02a0:          
 02b0:          
 02c0:          
@@ -59,23 +59,23 @@
 03a0:          
 03b0:          
 03c0:          
 03d0:          
 03e0:          
 03f0:          
 0400: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7  ..3D..h..&..
-0410: 39a0 b199 1b8e 6243 b6c7 10a4 2fa5 da3f  9.bC/..?
+0410: 169b 0fd6 bf07 7441 9901 f113 33d4 9991  ..tA3...
 0420:     473f 0100    G?..
 0430:  

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

[Cyril Brulebois]

Hi Chris,

Chris Lamb  (2019-01-19):
> >  * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
> >ordering only, but that's just the sort part
> 
> I've split this commit and it is much clearer now.

Perfect, thanks.

> >  * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the
> >FAT volume ID; have you checked with people like debian-cd@
> >whether another constant might make more sense?
> 
> Clarified where this comes from in the commmit and in the code
> itself.

Thanks.

> >  * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE,
> >adding a few characters (“:SS”); that ends up in various help
> >screens
> 
> In my tests, this did not break any visual text wrapping, etc.

Perfect.

> >  * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.
> 
> Fixed (use 'results' instead).

(I was genuinely happy to learn about the en_GB version; always
struggling to remember how to spell it in French vs. (American) English,
was happy to discover the British English version. :))

> §
> 
> Thank you again for your review. Let me know if you would require any
> further modifications before merging. :-)

That's looking good but I'm seeing new warnings because of gzip's being
unhappy about the GZIP environment variable. This seems to have been
deprecated in gzip 1.8:

gzip: warning: GZIP environment variable is deprecated; use an alias or 
script

I'm attaching the patch I've deployed locally, and it seems to me that
[1] might want an update.

 1. https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders

An other solution would be to use tar | gzip instead of passing -I to
tar, but I thought I'd learn about that option in the process. :)

Back to d-i results: I'm seeing small differences in the generated
-images tarball, that I'll try to investigate. I'll probably push the
series anyway, as these patches are helping anyway. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Chris Lamb]

[Keeping Kibi in CC as requested off-list, dropping mtools@p.d.o]

Dear Kibi,

First, thank you so much for your review. I believe I have resolve
all of your issues on the corresponding merge request, as well as
rebasing it against the current master:

  https://salsa.debian.org/installer-team/debian-installer/merge_requests/3
  
§

>  * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
>ordering only, but that's just the sort part

I've split this commit and it is much clearer now.

>  * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the FAT
>volume ID; have you checked with people like debian-cd@ whether
>another constant might make more sense?

Clarified where this comes from in the commmit and in the code
itself.

>  * 7c533fa721c3ae89ca81d1336b5928a80ed0d531 thanks for the clarity
>[ also: “becuase” in commit message. ]

Fixed.

>  * c35b8688696b1b4563a45d0feeabc3a0c0f2eccb “determinstic”

Fixed.

>  * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE, adding
>a few characters (“:SS”); that ends up in various help screens

In my tests, this did not break any visual text wrapping, etc.

>  * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.

Fixed (use 'results' instead).

§

Thank you again for your review. Let me know if you would require
any further modifications before merging. :-)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

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

[Cyril Brulebois]

Hello Chris,

First off: Thanks a lot for your work, and for your patience.

Chris Lamb  (2019-01-12):
> I would dearly love to have reproducible installer images for buster
> and indeed this would be a good thing to provide and offer, let alone
> announce in the release notes, etc.
> 
> Now that mtools has been sorted out, could this bug & corresponding
> merge request get a closer look? Thanks in advance.

There's a new alpha coming up and I've just spent some time cleaning up
things in debian-installer.git (debhelper compat, standards-version,
etc.) right after the upload; I've almost merged your patch series as
is, but I'd like to raise a few points first. I'm fine with amending the
patches myself, just wanted to check with you first…

 * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
   ordering only, but that's just the sort part AFAIUI; you're also
   resetting some timestamps with the find | xargs touch loop aren't
   you? I'd be happy to see this documented in the commit message as
   well.
   [ basically the clamp_mtimes function in build/Makefile in later
 commits. ]

 * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the FAT
   volume ID; have you checked with people like debian-cd@ whether
   another constant might make more sense? (cc-edd)
   [ also: “determinstic” in commit message. ]
   [ post-scriptum: ok, now I see we already had that in place
 elsewhere; keeping the cc anyway. ]

 * 7c533fa721c3ae89ca81d1336b5928a80ed0d531 thanks for the clarity, much
   appreciated.
   [ also: “becuase” in commit message. ]

 * c35b8688696b1b4563a45d0feeabc3a0c0f2eccb “determinstic” in commit
   message.

 * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE, adding
   a few characters (“:SS”); that ends up in various help screens
   (hopefully not an issue) but also on some files: version.info,
   disk.lbl, etc.

   Also, coming to think about BUILD_DATE, it's defined with ?= in
   build/config/common but we also set it from debian/rules… I guess
   I'll have to check what happens.

 * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Chris Lamb]

Chris Lamb wrote:

> Whilst working on the Reproducible Builds effort [0], we noticed
> that debian-installer's images were not reproducible.
> 
> I have created merge request #3 [1] on salsa with a patch series
> to address this.
> 
>  [0] https://reproducible-builds.org/
>  [1] https://salsa.debian.org/installer-team/debian-installer/merge_requests/3

Since working on this in June 2018 I have:

 * NMU'd src:mtools to incorporate the required reproducibility
   patches in 4.0.18-2.1.

 * Subsequently salvaged the mtools package and packaged the latest
   upstream version (4.0.23-1).

 * Rebased the corresponding merge request since the recent secure
   boot / EFI changes by Steve.

I would dearly love to have reproducible installer images for
buster and indeed this would be a good thing to provide and
offer, let alone announce in the release notes, etc.

Now that mtools has been sorted out, could this bug & corresponding
merge request get a closer look? Thanks in advance.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

[Vagrant Cascadian]

Control: block 900918 by 900409 900410

This requires fixes to mtools, marked as blocking bugs.


live well,
  vagrant


signature.asc
Description: PGP signature

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

[Chris Lamb]

Package: debian-installer
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that debian-installer's images were not reproducible.

I have created merge request #3 [1] on salsa with a patch series
to address this.

 [0] https://reproducible-builds.org/
 [1] https://salsa.debian.org/installer-team/debian-installer/merge_requests/3


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-