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

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

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?

Which files are we talking about here? It can basically only be
metadata and other little places where we violate our "everything comes
from a package" rule.

Has this ever been tested against a complex layer, has any of the repro
work ever looked at something bigger than the very artificial isar
base image?

I think a better start would be to bbwarn and only much later move to
"-exec touch".

We recently added CI tests for reproducible building. Would be nice to
the two patches. p1 writes a test-case that goes red, p2 (this one)
makes it go green

Henning

>  EOSUDO
>  }
>  addtask rootfs_finalize before do_rootfs after do_rootfs_postprocess