make build of cpio reproduceable #323
Conversation
| @@ -16,7 +16,7 @@ rootfs: | |||
| done | |||
|
|
|||
| capability.cpio: rootfs | |||
| cd rootfs/; find . | cpio -o -H newc -F ../capability.cpio | |||
| cd rootfs/; find . | xargs touch -d @1690848000 ; find . | sort | cpio -o -H newc -F ../capability.cpio | |||
There was a problem hiding this comment.
Why are you changing the timestamp on everything to Aug 1, 2023 12:00am ?
There was a problem hiding this comment.
@jmstover Presumably so two given builds will both have the same timestamps and thus result in the same byte for byte cpio... assuming of course that the contents are the same as well.
It's too bad cpio or bsdcpio itself doesn't have a way todo this.
There was a problem hiding this comment.
Yeah, I understand that. But we aren't going for byte for byte identical here... I mean, I've created different capabilities for a single set of servers than other servers on the same cluster... It's the functionality a capability does that's the important thing (IMO). So, I'm just trying to figure out why ... ;)
There was a problem hiding this comment.
To expand... I don't see an overall issue with it. I don't think changing the date across the board should break anything in the bootstraps ... I'd just like to know why a given change is being done for my peace of mind. =)
There was a problem hiding this comment.
This is for reproducible builds as @bsallen-argonne guessed it right. Distributions like openSUSE like the idea, that the same sources lead to the same binaries.
I should have mentioned this in the PR.
There was a problem hiding this comment.
anyone know of a better way to set all 3 timestamps and/or get cpio to set it?
There was a problem hiding this comment.
I don't think with touch you can (unless you run it without the -d option, then it changes all 3). Running touch -t [...] only changes Access and Modify times. I know cpio can reset the access time, so you don't know the file has been read... but I don't think there's a way to set the timestamp to something specific.
As ugly as it would be, the only way I can see us doing this would be to take Greg's cpio code from wwvnfs, and modify it to see if we can set atime and ctime ... I know it sets mtime, but don't think anything else .... :/
There was a problem hiding this comment.
From looking around a bit more, it looks like ctime is supposed to be extremely difficult to arbitrarily change. One way to do it is to use debugfs on a unmounted filesystem... But, beyond that POSIX says atime/mtime are user-setable ... but ctime the system must tack unerringly.
There was a problem hiding this comment.
@mslacken Ohhhhh.... I just noticed this was on master branch. Can you rebase it to development?
There was a problem hiding this comment.
Bit this pr goes to the master branch, so the PR should also go to the development branch instead?
bensallen
dismissed stale reviews from jmstover and themself
The base branch was changed.
Signed-off-by: Christian Goll <cgoll@suse.com>
|
Unfortunately, there are more places which require adjustments: there are 8 sub-directories which contribute to this cpio file and there is at least one other cpio file. All of these need to be included. I'm investigating. |
I've looked into this: Using |
No description provided.