Package Details: google-cloud-cli 474.0.0-1

Git Clone URL: https://aur.archlinux.org/google-cloud-cli.git (read-only, click to copy)
Package Base: google-cloud-cli
Description: A set of command-line tools for the Google Cloud Platform. Includes gcloud (with beta and alpha commands), gsutil, and bq.
Upstream URL: https://cloud.google.com/cli/
Keywords: cloud gcloud gcp google sdk
Licenses: Apache-2.0
Conflicts: google-cloud-sdk
Provides: google-cloud-sdk
Replaces: google-cloud-sdk
Submitter: PolarianDev
Maintainer: jvybihal
Last Packager: jvybihal
Votes: 188
Popularity: 0.92
First Submitted: 2023-03-08 09:33 (UTC)
Last Updated: 2024-05-01 09:55 (UTC)

Dependencies (2)

Required by (15)

Sources (3)

Pinned Comments

Latest Comments

« First ‹ Previous 1 .. 21 22 23 24 25 26 27 28 29 30 Next › Last »

tuxfusion commented on 2015-12-16 15:18 (UTC)

I have the same python problem. /etc/profile.d/google-cloud-sdk.sh points to "python2" which doesn't exist on my system or the repo. Manually exporting "python2.7" instead works if it's installed. executing the .sh or restarting the terminal won't help here, I suppose.

troyengel commented on 2015-12-13 13:58 (UTC)

@vendion - did you log out and back in (the terminal or desktop, depending on your setup) after installing it? That's Google's code, if the variable CLOUDSDK_PYTHON is null or doesn't equal python2 that strange logic of theirs is triggered. The AUR package adds /etc/profile.d/google-cloud-sdk.sh which is sourced when you log in to set up the basic envvars which set that var to python2.

vendion commented on 2015-12-13 03:15 (UTC)

Links against the wrong Python: /usr/bin/gcloud: line 119: python22: command not found That should probably be python2 or python2.7

troyengel commented on 2015-12-12 01:02 (UTC)

Quick note - Google changed the release numbering scheme with the release 90.0.0 that I just pushed up, see RELEASE_NOTES for details on the change.

troyengel commented on 2015-11-07 17:06 (UTC)

@ogarcia - roger that, try now with the new 0.9.85-4 release. This was one of the new files in the new tarball we're using, I added a line to remove this symlink during build and leave it for google-appengine-python where it fits better.

ogarcia commented on 2015-11-07 16:51 (UTC)

This have conflicts with "google-appengine-python" cause /usr/bin/dev_appserver.py exist in both.

troyengel commented on 2015-11-06 17:20 (UTC)

OK we should be all set -- the changes are very large to the PKGBUILD, so y'all report if anything is still broken (it took me 3 tries to fix the man page permissions, sorry). I've also added 'kubectl' component during build which isn't included in the core SDK tarball but seems safe and useful. I've also added the prepare() function that will try and alert that the upstream source has a newer release. :) $ gcloud info Google Cloud SDK [0.9.85] Platform: [Linux, x86_64] Python Version: [2.7.10 (default, Sep 7 2015, 13:51:49) [GCC 5.2.0]] Site Packages: [Disabled] Installation Root: [/opt/google-cloud-sdk] Installed Components: core: [2015.10.30] core-nix: [2015.10.30] kubectl: [] app: [2015.10.30] gcloud: [2015.10.30] gsutil-nix: [4.15] gsutil: [4.15] bq: [2.0.18] kubectl-linux-x86_64: [1.0.6] bq-nix: [2.0.18] ...

troyengel commented on 2015-11-06 15:35 (UTC)

I've also figured out what's wrong with our package for the "SDK_ROOT" that's causing the errors; the python code (lib/googlecloudsdk/core/config.py) is looking for a $CLOUDSDK_ROOT_DIR/.install/ subdirectory with the manifests and JSON files, which are in the tarball with a version -- I'm going to copy this .install over to the root in PKGBUILD, it seems to fix that whole issue when I do it manually.

troyengel commented on 2015-11-06 14:16 (UTC)

Heya guys, UI have the morning off and I'm figuring something out -- I found the openSUSE Factory RPM SPEC file which provided a critical clue, this magic file: https://dl.google.com/dl/cloudsdk/release/sha1.txt ...and sure enough, we can download numbered releases (including the older ones, they're in the downloads/ subdirectory if you wget them by hand). The file downloads/google-cloud-sdk-0.9.85-linux-x86_64.tar.gz has a layout slightly different (with more things too) than the one we're using, but this is good -- it contains the man pages again! Here's a quick diff from the basic download and the numbered one above: $ diff -qr google-cloud-sdk.1 google-cloud-sdk.2 Only in google-cloud-sdk.2/.install: app.manifest Only in google-cloud-sdk.2/.install: app.snapshot.json Only in google-cloud-sdk.2/.install: bq-nix.manifest Only in google-cloud-sdk.2/.install: bq-nix.snapshot.json Only in google-cloud-sdk.2/.install: bq.manifest Only in google-cloud-sdk.2/.install: bq.snapshot.json Only in google-cloud-sdk.2/.install: core-nix.manifest Only in google-cloud-sdk.2/.install: core-nix.snapshot.json Only in google-cloud-sdk.2/.install: gcloud.manifest Only in google-cloud-sdk.2/.install: gcloud.snapshot.json Only in google-cloud-sdk.2/.install: gsutil-nix.manifest Only in google-cloud-sdk.2/.install: gsutil-nix.snapshot.json Only in google-cloud-sdk.2/.install: gsutil.manifest Only in google-cloud-sdk.2/.install: gsutil.snapshot.json Files google-cloud-sdk.1/bin/bootstrapping/.default_components and google-cloud-sdk.2/bin/bootstrapping/.default_components differ Only in google-cloud-sdk.2/bin/bootstrapping: bq.py Only in google-cloud-sdk.2/bin/bootstrapping: gsutil.py Only in google-cloud-sdk.2/bin: bq Only in google-cloud-sdk.2/bin: dev_appserver.py Only in google-cloud-sdk.2/bin: gcloud Only in google-cloud-sdk.2/bin: git-credential-gcloud.sh Only in google-cloud-sdk.2/bin: gsutil Only in google-cloud-sdk.2: help Only in google-cloud-sdk.2/lib/googlecloudsdk: appengine Only in google-cloud-sdk.2/lib/googlecloudsdk: compute Only in google-cloud-sdk.2: platform Only in google-cloud-sdk.2: properties So we can sort this out now, I'm just working through the differences and trying to sort out a sane, logical way to make sure we don't break anything moving over to the other file. I was thinking of even adding a wget of the file above and alerting "new version detected, alert AUR maintainer!" during the build cycle or something...

justin8 commented on 2015-11-06 14:11 (UTC)

You can set the hash to 'SKIP' and it won't be checked. but it really should be google who are rather terrible at not updating versioned packages of this tool.