| 9 Feb 2022 |
 @rnhmjoj:maxwell.ydns.eu | stupid question: does the fact that uname -v include a timestamp mean the kernel is not reproducibile? | 08:35:41 |
 raboof | In reply to @rnhmjoj:maxwell.ydns.eu
stupid question: does the fact that uname -v include a timestamp mean the kernel is not reproducibile? AFAIK the kernel is reproducible, so that suggests it's ok - presumably it takes the date from a 'stable' source like commit or filesystem timestamps instead of from the clock | 08:51:07 |
 j-k | https://reproducible-builds.org/docs/source-date-epoch/
git log -1 --pretty=%ct
or if you want something more human readable
git log --date=format:'%Y-%m-%dT%H:%M:%SZ' -1 --pretty=%ad
| 08:56:30 |
| j-k | not sure what the kernel builds actually use for date tho | 08:56:46 |
 tomberek | In reply to @tpw_rules:matrix.org
i mean i hope this is not using HFS+ on linux It’s on BTRFS. | 12:17:24 |
 tpw_rules | oh, that's the problem: https://linux-btrfs.vger.kernel.narkive.com/oAoDX89D/btrfs-st-nlink-for-directories#post3 | 17:41:19 |
| tpw_rules | btrfs always answers 1 for st_nlink, allegedly (have not yet tested personally) | 17:41:43 |
| tpw_rules | i feel like this is cpio's problem, because the file format states that st_nlink is always at least 2 | 17:52:23 |
| tpw_rules | should we use tar in cpio mode? | 17:57:24 |
| tomberek | hrm... i was going to shift my builder to ZFS. I guess it's a good thing to have diversity of testing for reproducibility | 18:14:06 |
