| 17 Aug 2021 |
 @grahamc:nixos.org | and only files that would change (ie: the files never change, just the user-facing report root) | 17:43:00 |
| @grahamc:nixos.org | * and only files that would change (ie: the diffoscope files never change, just the user-facing report root) | 17:43:07 |
 baloo | https://github.com/grahamc/r13y.com/pull/33 | 17:45:27 |
| @grahamc:nixos.org | dang | 17:45:41 |
| baloo | 1sec | 17:45:57 |
| @grahamc:nixos.org | I didn't expect it to be so fast :P | 17:46:09 |
| * @grahamc:nixos.org goes to update the vault policy | 17:46:21 |
| baloo | https://github.com/grahamc/r13y.com/pull/33/files | 17:47:16 |
| baloo | better that way | 17:47:20 |
| baloo | well, it's easy with the documentation :D | 17:48:12 |
| @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 (he/him) 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 |
