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

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

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux