On Mon, 2026-05-04 at 11:58 +0200, Rasmus Villemoes wrote:
> On Mon, May 04 2026, Richard Purdie <[email protected]>
> wrote:
>
> > 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.
>
> OK, but then that still wouldn't solve the problem we see, where the
> build has decided that it can create a hard link, but then later it
> fails to perform the futimensat syscall because the user running bitbake
> is not (apparently) the user owning the inode.
>
> As I said, I don't really understand how that actually sometimes happens
> and most of the time doesn't, perhaps it is some weird interaction
> between how gitlab starts docker containers and perhaps with some pseudo
> in the mix.
I'm forgetting that git doesn't give consistent timestamps upon
checkout. If it did, my suggestion would work however it does not.
I still don't think we should be changing every timestamp in an image
as most timestamps should already be consistent. Where we copy data
from source control into the image, we are going to need to do
something though.
To hit the error, you're probably using license_image.bbclass and
hitting the:
oe.path.copyhardlink(pkg_license, rootfs_license)
codepath by having COPY_LIC_MANIFEST set?
Perhaps the answer is just not to hardlink the files into the image in
license_image.bbclass? I think the other usages are safe...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#236463):
https://lists.openembedded.org/g/openembedded-core/message/236463
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]]
-=-=-=-=-=-=-=-=-=-=-=-
