Message ID | cover.1726500347.git.code@greghogan.com |
---|---|
Headers | show |
Series | Update aws-sdk-cpp. | expand |
Greg Hogan <code@greghogan.com> skribis: > gnu: s2n: Update to 1.5.1. > gnu: aws-lc: Update to 1.34.2. > gnu: aws-c-common: Update to 0.9.27. > gnu: aws-checksums: Update to 0.1.18. > gnu: aws-c-cal: Update to 0.7.4. > gnu: aws-c-io: Update to 0.14.18. > gnu: aws-c-event-stream: Update to 0.4.3. > gnu: aws-c-sdkutils: Update to 0.1.19. > gnu: aws-c-compression: Update to 0.2.19. > gnu: aws-c-http: Update to 0.8.8. > gnu: aws-c-auth: Update to 0.7.26. > gnu: aws-c-s3: Update to 0.6.4. > gnu: aws-c-mqtt: Update to 0.10.4. > gnu: aws-crt-cpp: Update to 0.28.2. > gnu: aws-sdk-cpp: Update to 1.11.402. Applied, thanks! > This update also removes the workaround for a certificate expiration > test error. Should we update the offending test suite to run under ‘datefudge’ or similar, so the expiration issue doesn’t lead to a test failure going forward? Thanks, Ludo’.
Hi, Greg Hogan <code@greghogan.com> skribis: > I tested 10 years in the future and submitted a bug report upstream: > https://github.com/aws/aws-lc/issues/1889 > > It's a strange error, not a simple time bomb. The build fails > somewhere between six and seven years in the future. > > So in the case where this bug is resolved and the current package > definition successfully builds in the future should we still wrap with > datefudge or libfaketime? Add a comment to run a future test build > when updating? I prefer the comment since overridden phases are > unsightly and simply mask the problem. Generally speaking we should ensure packages can be built regardless of the value of the system clock, so people can eventually time-machine and rebuild packages. When we’re aware of time-dependent behavior, we should patch it or use libfaketime/datefudge. Thanks, Ludo’.
Hi, Greg Hogan <code@greghogan.com> skribis: > I tested 10 years in the future and submitted a bug report upstream: > https://github.com/aws/aws-lc/issues/1889 > > It's a strange error, not a simple time bomb. The build fails > somewhere between six and seven years in the future. > > So in the case where this bug is resolved and the current package > definition successfully builds in the future should we still wrap with > datefudge or libfaketime? Add a comment to run a future test build > when updating? I prefer the comment since overridden phases are > unsightly and simply mask the problem. Generally speaking we should ensure packages can be built regardless of the value of the system clock, so people can eventually time-machine and rebuild packages. When we’re aware of time-dependent behavior, we should patch it or use libfaketime/datefudge. Thanks, Ludo’.