make build of cpio reproduceable

[mslacken]

No description provided.

[jmstover]

Why are you changing the timestamp on everything to Aug 1, 2023 12:00am ?

[bsallen-argonne]

@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.

[jmstover]

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 ... ;)

[jmstover]

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. =)

[mslacken]

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.

[bensallen]

anyone know of a better way to set all 3 timestamps and/or get cpio to set it?

[jmstover]

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 .... :/

[jmstover]

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.

[jmstover]

@mslacken Ohhhhh.... I just noticed this was on master branch. Can you rebase it to development?

[mslacken]

Bit this pr goes to the master branch, so the PR should also go to the development branch instead?

[jmstover]

Attempt at reproducible build seems fine. I don't think the change should interfere with the bootstrap at all.

The base branch was changed.

[e4t]

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.

[e4t]

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 touch to set the access and modification time of a files to a fixed value is sufficient to make cpio archives reproducible - if cpio is called with --reproducible. We have verified this here.
However, the changes required to make this work across the all of warewulf3 are more extensive than what's been submitted.
I will create a separate pull request with the full set of changes.