mbox series

[bug#73323,00/15] Update aws-sdk-cpp.

Message ID cover.1726500347.git.code@greghogan.com
Headers show
Series Update aws-sdk-cpp. | expand

Message

Greg Hogan Sept. 17, 2024, 8:15 p.m. UTC
This patchset successfully builds with the updated version of gcc from
the core-updates merge (an issue caused by the packages' default use of
-Werror). This update also removes the workaround for a certificate
expiration test error.

Greg Hogan (15):
  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.

 gnu/packages/c.scm   | 55 ++++++++++++++++++++++----------------------
 gnu/packages/cpp.scm |  8 +++----
 gnu/packages/tls.scm | 31 ++++++-------------------
 3 files changed, 38 insertions(+), 56 deletions(-)


base-commit: 034eb1b0b624ccd14ed846f402ce7670e6e3f317

Comments

Ludovic Courtès Sept. 27, 2024, 10:18 p.m. UTC | #1
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’.
Ludovic Courtès Oct. 1, 2024, 3:29 p.m. UTC | #2
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’.
Ludovic Courtès Oct. 1, 2024, 3:30 p.m. UTC | #3
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’.