Package Details: aws-cli-v2 2.25.6-1

Git Clone URL: https://aur.archlinux.org/aws-cli-v2.git (read-only, click to copy)
Package Base: aws-cli-v2
Description: Unified command line interface for Amazon Web Services (version 2)
Upstream URL: https://github.com/aws/aws-cli/tree/v2
Licenses: Apache-2.0
Conflicts: aws-cli
Provides: aws-cli
Submitter: jelly
Maintainer: kstolp
Last Packager: kstolp
Votes: 38
Popularity: 5.77
First Submitted: 2024-04-21 11:04 (UTC)
Last Updated: 2025-03-30 00:52 (UTC)

Required by (20)

Sources (9)

Pinned Comments

kstolp commented on 2024-10-23 05:14 (UTC)

If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.

==> ERROR: One or more PGP signatures could not be verified!

You have two options:

1) Import the key into your keyring. ArchWiki article. The key is available in this repo, which is copied from the AWS documentation. e.g. gpg --import keys/pgp/FB5DB77FD5C118B80511ADA8A6310ACC4672475C.asc. (recommended)

2) Alternatively, you can skip this verification by passing the --skippgpcheck argument to makepkg when building. (not recommended)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

bamboo commented on 2024-04-29 14:48 (UTC) (edited on 2024-04-29 14:51 (UTC) by bamboo)

Is it really necessary to run tests?

a. I don't feel confortable when it runs tests when access to my production account is configured.

b. It takes about 5 minutes

EDIT: Ok my bad. Solved by !check in makepkg.conf

trevordf commented on 2024-04-29 13:20 (UTC)

It looks like the failing tests related to the us-mars-2 region assertion were removed in the latest version, 2.15.42. After updating to this version the failing tests at the end should be resolved.

Example of failed test:

FAILED tests/functional/test_clidriver.py::TestSession::test_imds_region_is_used_as_fallback_with_v2_support - AssertionError: 'us-west-1' != 'us-mars-2'

aquilinux commented on 2024-04-29 10:20 (UTC)

renaming ~/.aws/credentials works if you have profiles configured

j0ni commented on 2024-04-28 21:38 (UTC)

Thank you @kino_t, version 2.15.40-5 installed cleanly for me.

The best solution would be for upstream to unset all env vars supported by the CLI before starting any tests - I would hope that env var handling is in the tests, but it's a python project so who knows? Even getting the same dependencies consistently is pretty challenging.

I did see a bug related to this upstream. I might throw in 2c.

VLegacy commented on 2024-04-28 19:32 (UTC)

@kino_t Thank you! The latest version works for me, so unsetting that env var did the trick.

@asday Good suggestion, though I may not make time for that test unless I hit further related problems. Whatever the ultimate source, it does seem super weird that the test suite is set up in such a way that env vars on any random consumer's system can make it fail.

j0ni commented on 2024-04-28 12:00 (UTC)

Can you please unset AWS_PROFILE as well (or instead)?

It's documented here:

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles

I'm not sure where AWS_DEFAULT_PROFILE comes from - I've seen AWS_DEFAULT_REGION documented but not the first one.

I guess it must do something if it works for people. It make my pedantic brain explode a bit since it exists to override the default region, and makes no sense in any context where there isn't an existing profile configured via ~/.aws/config. Maybe it's possible to have that file exist without a [default] section, that would make sense. AWS authentication and authorization models are a many layered rotting onion.

Anyway, thanks for coming to my ted talk.

asday commented on 2024-04-28 01:17 (UTC)

@kino_t Thank you, I'm glad for you, but I was directing my comment to whom I was quoting - @VLegacy.

It has been established that tests sometimes fail based on the environment, first with my issues with DST, and then with VLegacy's issues with his environment variables. It's expected that they might pass in other people's environments.

kino_t commented on 2024-04-28 01:14 (UTC)

@asday All tests passed on my machine.

asday commented on 2024-04-28 01:06 (UTC)

The checks still fail unless I unset the AWS_DEFAULT_PROFILE environment variable in my shell prior to running the update.

That sounds like an upstream bug to me - do they still fail in the same manner and are they fixable in the same manner with a clean checkout not involving the AUR? If so, I'd recommend opening an issue on the github.

VLegacy commented on 2024-04-28 00:24 (UTC)

The latest package update to reduce the number of parallel workers used by pytest in the checks is a huge improvement to the system load problem. Thank you!

The checks still fail unless I unset the AWS_DEFAULT_PROFILE environment variable in my shell prior to running the update. I see that the setup for the checks set AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID to fake values prior to running the tests. Perhaps it could also unset AWS_DEFAULT_PROFILE to avoid the user's environment variable from being used in the tests and causing issues?