Re: [isar 0/1] Fix non-reproducible issue due to localepurge

[Jan Kiszka <jan.kiszka@siemens.com>]

On 11.04.22 12:53, Henning Schild wrote:
> Am Sun, 10 Apr 2022 22:32:28 +0530
> schrieb venkata.pyla@toshiba-tsip.com:
> 
>> From: venkata pyla <venkata.pyla@toshiba-tsip.com>
>>
>> Hello all,
>>
>> Replying to this mail conversation,
>> (https://groups.google.com/g/isar-users/c/JCgpWU_pFJU/m/IwlYTmzQBQAJ)
>>
>> For the problem "debconf cache non-reproducible", I figured out a
>> solution in isar system itself.
> 
> Generating configuration items and placing them before a package gets
> installed is very common. It is not only done by Isar but very likely
> by many packages in debian that cater for other packages.
> 
> What you are suggesting is not a generic solution to "debconf cache"
> being non-reproducible. It is just a quirk to hide the problem in that
> one case for that one package.
> 
> Maybe the cache just needs to be excluded from the image, or cleaned or
> whatever.
> 
> And i guess we should have some infrastructure in Isar to find
> "non-reproducible" build issues also available for any layers. Because
> layers is where the real complexity is, not those relatively boring
> example images you find in isar.
> 

Just ran into a more complex scenario where non-reproducibility of the
image bites:

isar-cip-core [1] in secure boot mode generates dm-verity images and a
corresponding initramfs which carries the rootfs hash. As we are not
able to re-generate the very same rootfs from the same task(-hashes),
bitbake will not rebuild the initramfs, and image and initramfs will no
longer match.

Jan

[1] https://gitlab.com/cip-project/cip-core/isar-cip-core

-- 
Siemens AG, Technology
Competence Center Embedded Linux