On Mon, 2026-05-04 at 10:30 +0200, Rasmus Villemoes wrote: > 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).
Pretty much all the rest of the system works like this for reproducibility. Whether you make everything REPRODUCIBLE_TIMESTAMP_ROOTFS or just clamp to a max value of REPRODUCIBLE_TIMESTAMP_ROOTFS doesn't really matter since you're using that value regardless. Basically anything touched as part of the build process (newer than the timestamp) would be reset, everything else (older than that) should be deterministic. The value of the actual timestamp used is a different discussion but we're not changing that. Having thought about this a bit, I do think that is the right solution, and it does match how we handle timestamps elsewhere like the packages. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236438): https://lists.openembedded.org/g/openembedded-core/message/236438 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]] -=-=-=-=-=-=-=-=-=-=-=-
