Re: [PATCH] image.bbclass: fix non-reproducible file time-stamps inside rootfs image

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 3 Jan 2023 09:05:53 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 02.01.23 17:44, Henning Schild wrote:
> > Am Mon,  2 Jan 2023 20:28:28 +0530
> > schrieb venkata.pyla@toshiba-tsip.com:
> >   
> >> From: venkata pyla <venkata.pyla@toshiba-tsip.com>
> >>
> >> As part of reproducible-build work, the rootfs images generated on
> >> same source should be identical between two builds.
> >>
> >> In this commit it tries to solve one of the non-reproducible
> >> problem i.e. the rootfs file time-stamps generated during build
> >> time are not reproducible, it uses one of the solution provided in
> >> the debian live-build image project (refer [1]), it fixes by
> >> finding all the files/folders that are gernerated newly and set
> >> the time-stamp provided by `SOURCE_DATE_EPOCH` environment
> >> variable.
> >>
> >> [1]
> >> https://salsa.debian.org/live-team/live-build/-/merge_requests/218
> >>
> >> Signed-off-by: venkata pyla <venkata.pyla@toshiba-tsip.com>
> >> ---
> >>  meta/classes/image.bbclass | 9 +++++++++
> >>  1 file changed, 9 insertions(+)
> >>
> >> diff --git a/meta/classes/image.bbclass
> >> b/meta/classes/image.bbclass index 813e1f3..f592a12 100644
> >> --- a/meta/classes/image.bbclass
> >> +++ b/meta/classes/image.bbclass
> >> @@ -430,6 +430,15 @@ do_rootfs_finalize() {
> >>              "${ROOTFSDIR}/etc/apt/sources.list.d/bootstrap.list"
> >>  
> >>          rm -f "${ROOTFSDIR}/etc/apt/sources-list"
> >> +
> >> +        # Set same time-stamps to the newly generated file/folders
> >> in the
> >> +        # rootfs image for the purpose of reproducible builds.
> >> +        test ! -z "${SOURCE_DATE_EPOCH}" && \
> >> +            find ${ROOTFSDIR} -newermt \
> >> +                "$(date -d@${SOURCE_DATE_EPOCH} '+%Y-%m-%d
> >> %H:%M:%S')" \
> >> +                -printf "%y %p\n" \
> >> +                -exec touch '{}' -h -d@${SOURCE_DATE_EPOCH} ';'
> >> +  
> > 
> > This looks like i have seen it before. For me that is _way_ too
> > generic and something that is not a package touches files all over
> > the place. If some package now wants to intentionally bring a file
> > that is from a far away future?  
> 
> Then debian-live would have the same problem - I don't think following
> that pattern is a bad idea as we are not alone.

debian-live is a closed quality thing with likely very little hacks that
do not come from packages. So ... kind of ... is isar core. But in the
layers we do not really know what people do.

Note that this code should somehow be colocated with
do_rootfs_quality_check where we already check how people messed around
in postproc based on time of files.

And i still vote that we bring it as bbwarn only, telling people that a
file is causing issues with repro build. And maybe a list of files that
people have to append to to have them touched ... not touch everything
we find by default.

Henning

> Jan
>