Dear Mattia, > > TIL. However, as these generated files do not appear in the binary > > debian-installer package it is likely that that our testing framework > > will (after the mooted networking exception is made) entirely- > > correctly report that the src:debian-installer package is reproducible > > as its declared artifects contain only documentation. This will be > > somewhat misleading about the true reproducibility status of our installer. > > It doesn't contain only documentation. > src:debian-installer also builds a > debian-installer-images_$(VERSION)_$(ARCH).tar.gz that does contain > binary stuff, including the initrd, kernel image, mini.iso, etc etc.
Whilst it may build indeed these files they do not appear in the binary package: $ find | head . ./usr ./usr/share ./usr/share/doc ./usr/share/doc/debian-installer ./usr/share/doc/debian-installer/talks ./usr/share/doc/debian-installer/talks/fosdem07 ./usr/share/doc/debian-installer/talks/fosdem07/README ./usr/share/doc/debian-installer/talks/fosdem07/fosdem1.tgz ./usr/share/doc/debian-installer/talks/d-i_debconf7 $ find | grep images $ Thus, they cannot affect the reproducibility status of the debian- installer source package. This prompted my paragraph regarding at least including these files' hashes, etc. > Right, to cover this we would need to do a full build of the cd image. > I have no idea whatsoever how that's done (and, as others said, it's > outside of the debian-boot office, it's within debian-cd). I see I've been conflating the -boot and -cd work here, sorry. Well, if full debian-cd rebuilds are out of scope for now (!) we should at-least cover any "debian-boot" related stuff. Now, I am certain I am missing something but would this latter approach just (!) involve adding another Jenkins job that tracks the HEAD of debian- installer.git (ooh, another advantage; time) which calls "make -C build release" in two environments? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-