AUR (en) - aws-cli-v2

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: aws-cli-v2 2.22.21-1

Package Actions

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:	29
Popularity:	2.88
First Submitted:	2024-04-21 11:04 (UTC)
Last Updated:	2024-12-20 03:52 (UTC)

Dependencies (20)

python (python37^AUR, python311^AUR, python310^AUR)
python-awscrt
python-certifi
python-colorama (python-colorama-git^AUR)
python-cryptography
python-dateutil
python-distro
python-docutils
python-jmespath
python-prompt_toolkit
python-ruamel-yaml (python-ruamel-yaml-hg^AUR)
python-urllib3
python-build (make)
python-flit-core (make)
python-installer (python-installer-git^AUR) (make)
python-wheel (make)
procps-ng (procps-ng-git^AUR, busybox-coreutils^AUR) (check)
python-jsonschema (check)
python-pytest (check)
python-pytest-xdist (check)

Required by (19)

arkade-bin (requires aws-cli) (optional)
aurbuilder-git
awj-git (requires aws-cli)
aws-credential-1password (requires aws-cli) (optional)
aws-session-manager-plugin (requires aws-cli)
aws2-wrap (requires aws-cli)
curam-git (requires aws-cli)
datomic-cli (requires aws-cli)
git-remote-codecommit (requires aws-cli)
k3sup-bin (requires aws-cli) (optional)
lambroll-bin (requires aws-cli) (optional)
liquidprompt (requires aws-cli) (optional)
porter-bin (requires aws-cli) (optional)
python-awscli-plugin-endpoint (requires aws-cli)
python-pdf2video (requires aws-cli)
rattlesnakeos-stack-bin (requires aws-cli) (optional)
scwrypts (optional)
statsite (requires aws-cli) (optional)
stsauth (requires aws-cli) (make)

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 »

alexdandrea commented on 2024-05-02 08:04 (UTC) (edited on 2024-05-02 12:54 (UTC) by alexdandrea)

These tests are there for the developers of aws-cli to ensure features built are actually working and no regressions are introduced from version to version; they're not really meant as target platform integration tests.

So, when a test failure would occur, there wouldn't be a new release since that would've been caught on upstream side already. As such you could argue it is not really necessary to run them on package build.

However, the package does patch quite some stuff, so after all it is justified a bit. It seems, though, that these tests do pick up the environment and user-specific configuration that exists in the context where these tests are run. For the package it means it uses all env vars and $HOME/.aws/{credentials,config} and that really is a problem since many of us might have real credentials there...

These tests should have some kind of jail and a separate user where they're run (eg. for me the test suite finally breaks with an assertion that 'eu-central-1' != 'us-mars-2' - where eu-central-1 is the region configured in my $HOME/.aws/credentials).

PS: Thank you for providing this package!

UPDATE: Found out that you can build packages in a chroot, with paru's --chroot option and this solves everything. I will enable this option in /etc/paru.conf for all the builds.

bamboo commented on 2024-05-01 15:36 (UTC) (edited on 2024-05-02 16:01 (UTC) by bamboo)

@asday I understand your concern but this is relevant for people with exotic architectures or configuration. They should be able to opt-in for tests. In my case it is classic amd64. I believe that python is bad enough to misbehave but the probability in real world is low when you are using "classic amd64 environment".

Opt-in for tests is good for some users but so is opt-out. Users need to decide themselves. I did so I turned off tests. Yes it can break but so my whole system can break with every kernel update. Do you run tests for kernel?

Do you run tests in Docker? I believe that most production use of aws cli is in Docker environment.

duongdominhchau commented on 2024-04-30 13:36 (UTC) (edited on 2024-04-30 13:39 (UTC) by duongdominhchau)

The build process hangs for a long time then crashes with too many arguments error when I use Python managed by pyenv or rye (I don't remember which one caused it). You may want to run the build with PATH=/bin instead to make sure system Python is being used directly. This happened a few days ago and I haven't tried to reproduce this on latest PKGBUILD yet, not sure if it is still there as I saw many fixes pushed to AUR within the past few days.

haug1 commented on 2024-04-29 20:01 (UTC) (edited on 2024-04-29 20:05 (UTC) by haug1)

Every day there's an update and it takes an hour to install. And I actually need this application for work. What a horrible experience.

Considering alternative(less convenient) methods of maintaining this app on my system.

asday commented on 2024-04-29 15:13 (UTC)

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

I see this sentiment a lot and it bothers me, so if I could please be tolerated to leave my opinion here and then say no more, that would be lovely.

If the software package provides tests, they should all be passing, or marked as skipped. If they do not pass, then it stands to reason that the software package is FAULTY and should not be installed on user machines.

If an individual user decides the risk is worth it, or knows it's not a risk, they can disable the tests themselves (--mflags --nocheck in yay, --nocheck with makepkg or paru, etc), or if they're particularly invested and skilled - fixing the tests.

EVERY user should not have presumably faulty software shoved on them because the tests fail in some environments.

Relatedly but unrelatedly, I am a Python programmer. Tests failing depending on user environment variables or production config is entirely incorrect behaviour and is a bug that should be reported upstream. If upstream doesn't think it's a bug, a fork is in order.

Tests using anything from the environment at all that wasn't passed directly to the test runner or residing in test-specific configuration files are in my opinion broken.

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.