Nearly reproducible Bookworm 12.6 live images

Roland Clobus rclobus at rclobus.nl
Tue Jul 16 07:58:12 UTC 2024


-debian-cd (As this thread is only about reproducibility)

Hello James,

On 16/07/2024 00:21, James Addison wrote:
> This sounds great - I have one specific question / concern:

> Limiting the timestamp to a maximum of SOURCE_DATE_EPOCH makes sense so that
> the modification-time is consistent for equivalent rebuilds.
> 
> However: if the contents of the txt file / other content in the git repository
> change, would that prevent an independent rebuilder from recreating the
> identical CD image as output?

First the rebuild script determines the latest modification date of the 
archive (as found in InRelease) and sets SOURCE_DATE_EPOCH accordingly.
Then the rebuild script uses the git repository of live-build and finds 
the commit that matches SOURCE_DATE_EPOCH. Thus it ensures that for the 
Debian point releases you get exactly what was configured at that time.
During this 'git checkout HASH' command, the timestamps of the modified 
files will be updated to 'now', which is the intended behaviour, as the 
final ISO image will have all dates truncated to SOURCE_DATE_EPOCH.

So an independent rebuilder should call the rebuild.sh script without 
setting S_D_E and will get identical output.

> (note: given that the package archive is regularly updated, I think that there
> are other reasons why an identical point-in-time rebuild may require sharing
> of some build-time/archive metadata -- the reason I'm asking is that I'd like
> to check whether this git repo could require similar co-ordination during
> rebuilds.  fixed commit ID / signed tag, or other mechanism for example)

I'm using the timestamp from InRelease, which was confirmed to be 'the' 
timestamp of the archive [1]. Therefore I don't need tags.

With kind regards,
Roland Clobus

[1] https://lists.debian.org/debian-devel/2022/09/msg00199.html
     https://lists.debian.org/debian-devel/2022/09/msg00249.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20240716/cad3b0ec/attachment.sig>


More information about the rb-general mailing list