On Sat, May 02 2026, Richard Purdie <[email protected]> wrote:

> On Fri, 2026-05-01 at 20:36 +0200, Rasmus Villemoes via 
> lists.openembedded.org wrote:
> From: Rasmus Villemoes <[email protected]>
>
> This is _not_ meant to be applied, but merely acts as a place to start
> a discussion.
>
>> In our CI setup (which is gitlab-based, but I'm not sure that's too
>> relevant), we sometimes see spurious errors like
>>
>>   touch: setting times of '[...]/rootfs/usr/share/common-
>> licenses/go2rtc/COPYING.MIT': Operation not permitted
>>
>>
>> I do understand that using hard links is quite valuable for saving
>> time and space (I see GPL-2.0-only having 135 links, so that alone is
>> a few MB), which is why I don't think this should be applied as-is.
>>
>> Could we do something like create a $TMPDIR/license-pool/, and
>> whenever encountering a src not inside TMPDIR, copy that file to
>> $TMPDIR/license-pool/<basename>-<sha256 of source> [if it doesn't
>> already exist], and then use the latter as src in the subsequent "can
>> we hardlink" logic? That would then also improve the case where the
>> meta-layers are (bind)mounted R/O, and we thus always end up copying.
>
> I agree it does look like there is a potential issue here.
>
> I'm not sure we have ever claimed isolation between the build metadata
> and the builds, I know that for example patch files are linked in, so
> that when you update patches, it updates the metadata more easily. I
> can see why you might want that, equally, the ability to update patches
> that way is a nice usability feature.
>
> Did you track down where the utime of the files was being changed? From
> the link, it looks like:
>
>     find  ${IMAGE_ROOTFS} -print0 | xargs -0 touch -h  
> --date=@$REPRODUCIBLE_TIMESTAMP_ROOTFS
>
> in reproducible_final_image_task in image.bbclass

Yes, it it precisely that command/function where it triggers.

> I think that function could be changed to clamp to anything newer than
> REPRODUCIBLE_TIMESTAMP_ROOTFS rather than changing all files, and that
> might actually avoid the issue.

I don't see how. First, how would that then serve the purpose of
producing something reproducible? It seems that the timestamps would or
could then depend on when the meta-data repo was cloned. Second, if the
mtime is still going to be changed sometimes under some conditions, the
problem is not really gone. And third, I think it would make the
implementation much more complicated, if one would need to make a
decision for each file for whether to touch it or not (i.e. the simple
find|xargs would no longer suffice).

Rasmus
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#236437): 
https://lists.openembedded.org/g/openembedded-core/message/236437
Mute This Topic: https://lists.openembedded.org/mt/119105040/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to