| 17 Aug 2021 |
 @grahamc:nixos.org | hrm, can an IAM policy not restrict which buckets you can create invalidation for? | 17:52:15 |
| @grahamc:nixos.org | * hrm, can an IAM policy not restrict which buckets you can create invalidations for? | 17:52:17 |
 baloo | I believe you can restrict with the URN | 17:52:45 |
| baloo | arn:aws:cloudfront::223448837225:distribution/E2JKFLGW8FADQD | 17:52:50 |
| baloo | that | 17:52:51 |
| baloo | something like: https://gist.github.com/baloo/8435c1dd0a1c510848f0dd85c619eef7 | 17:56:23 |
| @grahamc:nixos.org | https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudfront.html "If the column includes a resource type, then you can specify an ARN of that type in a statement with that action." | 17:58:32 |
| @grahamc:nixos.org | so no subpaths but yes ARN | 17:58:35 |
| @grahamc:nixos.org | baloo: merged & applied the changes w/ terraform to grant the privileges to do that | 18:01:14 |
| baloo | ha right | 18:04:03 |
|  chreekat changed their display name from bryan to chreekat. | 19:59:06 |
| 18 Aug 2021 |
| baloo | An error occurred (AccessDenied) when calling the CreateInvalidation operation: User: arn:aws:iam::223448837225:user/vault-token-r13y-publish-1629245456-7999 is not authorized to perform: cloudfront:CreateInvalidation on resource: arn:aws:cloudfront::223448837225:distribution/E2JKFLGW8FADQD | 03:58:14 |
| baloo | oh | 03:58:15 |
| baloo | https://buildkite.com/grahamc/r13y-dot-com/builds/855#54ff268f-62e5-4ec6-9f80-e8273655eeae/51-60 | 03:58:38 |
|  siraben changed their display name from siraben to siraben (he/him). | 19:36:31 |
| 19 Aug 2021 |
 nrdxp | I was trying to get a better understand on how nix manages the time for reproducible behavior, and it seems to me that time passes normally in a derivation sandbox and is then timestamped to the unix epoch after the build completes.
However, I was wondering if there might be a mechanism to freeze the time during a build and I came across datefudge, which takes a static flag -s which freezes the time to whatever you set, for example:
❯ n run datefudge -- -s "$(date)" ./foo.sh
Thu Aug 19 10:36:43 AM MDT 2021
Thu Aug 19 10:36:43 AM MDT 2021
where foo.sh is:
#!/usr/bin/env bash
date
sleep 10
date
| 16:49:22 |
| nrdxp | Would this add any meaningful improvement to reproducible behavior? Seems like it should be simply enough to replicate this behavior if we wanted. | 16:50:14 |
| nrdxp | * Would this add any meaningful improvement to reproducible behavior? Seems like it should be simply enough to replicate if we wanted. | 16:52:20 |
| nrdxp | * Would this add any meaningful improvement to reproducible behavior (seems like it would, naively)? It should be simply enough to replicate if we wanted. | 16:54:38 |
 andi- | It would but it shouldn't. Packages should have a build system that doesn't care about specific times. There is already a somewhat standard env var to signal the time that should be used in e.g. binaries to display build time. | 16:59:14 |
| andi- | If we start changing the sandbox it is a quick win and it is nice to find impurities but really the builds need to be fixed. | 16:59:45 |
| nrdxp | Maybe we could use datefudge to help find impure builds then at least | 17:02:02 |
| chreekat | Y not both 🙂 | 17:02:11 |
| nrdxp | I agree with you andi-, but I also feel like trying to change the world is always an uphill and losing battle. So if upstream builders won't do anything maybe we should take the initiative? | 17:06:53 |
| andi- | Have we ever actually had an upstream that rejected non-nix specific reproducibility patches? | 17:14:18 |
| andi- | Given that Debian is leading this I don't see much of a battle | 17:14:33 |
| chreekat | I mean, there are approximately 20 hojillion software packages present and future that are yet to be made reproducible | 17:18:14 |
| andi- | Isn't it mostly about the build system anyway? | 17:29:47 |
| nrdxp | It's great to submit patches upstream, I certainly wouldn't argue against that. I just think it'd be nice behavior to have by default, since there will always be some build system somewhere that doesn't act the way we'd like. And even if we patched them all someday. Then a new one would come out shortly after and break everything again 😅 | 17:42:49 |
| nrdxp | * It's great to submit patches upstream, I certainly wouldn't argue against that. I just think it'd be nice behavior to have by default, since there will always be some build system somewhere that doesn't act the way we'd like. And even if we patched them all someday, Then a new one would come out shortly after and break everything again 😅 | 17:43:10 |
