Package Details: google-cloud-sdk 267.0.0-1

Git Clone URL: (read-only)
Package Base: google-cloud-sdk
Description: A set of command-line tools for the Google Cloud Platform. Includes gcloud (with beta and alpha commands), gsutil, and bq.
Upstream URL:
Keywords: cloud gcloud gcp google sdk
Licenses: Apache
Submitter: barnybug
Maintainer: sudoforge (sudoforge-bot)
Last Packager: sudoforge
Votes: 127
Popularity: 1.907942
First Submitted: 2014-06-03 08:10
Last Updated: 2019-10-15 21:20

Dependencies (2)

Required by (6)

Sources (2)

Pinned Comments

sudoforge commented on 2018-09-10 15:11

To report issues or request features, please use:

sudoforge commented on 2018-08-21 22:09


Commit e01da1e449882ad8e4fe590b01cd09624b58143a removes the appengine components from this package. These components, along with all of the others, will be made available as independent packages in the future.

If you need any of the additional components for your day-to-day workflow, set "disable_updater": false in /opt/google-cloud-sdk/lib/googlecloudsdk/core/config.json and manage components using gcloud components <command>.

Be sure to install any dependencies for the additional components that you may need.

Latest Comments

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

deace commented on 2018-07-13 10:00

update, please.

troyengel commented on 2018-06-16 18:01

The newest pacman exposed that the use of python2 -m compileall embeds the source directory of the packaging process into the resulting *.pyc files as strings. I've added a -d /opt/google-cloud-sdk to the compileall PKGBUILD step for this new 205.0.0 release and it seems to do the trick (checked it with strings), please holler if this breaks something though. I tested a quick gcloud and gsutil and they're functional. Ref:

sudoforge commented on 2018-06-02 03:07

@troyengel ah, you mean:


Cool. Thanks! I should have noticed that in the prepare() step. It looks like the sha1.txt file was obsoleted as of v148.0.1 of the SDK.

If you have a moment, hit me up on IRC (freenode) as sudoforge or via email. I'm planning some big changes, namely:

  • Slimming the google-cloud-sdk AUR package to only include alpha and beta components
  • Adding AUR packages for each individual component

This will make the available AUR packages match Google's DEB and RPM releases. Most importantly, I think (once I complete the above refactoring) we should submit a request to merge this package into google-cloud-sdk. After that, I'd be happy to add you as a co-maintainer to it and whatever other packages you'd like to support. What are your thoughts on this?

troyengel commented on 2018-05-31 23:04

@sudoforge I used to maintain the larger package you now do (google-cloud-sdk) for a few years (2015-07-18 to 2017-06-14 in git, no logs from AUR3 pre-git). I looked in the comments, on 2017-01-13 when I was preparing 139.0.0 I wrote 'Heya all, as I was preparing 139.0.0 for release just now I notice in the sha1.txt a number of new downloads appeared that has "for packagers" in the directory name' (back then it was sha1.txt).

So I'd have to say that between 138.0.0 and 139.0.0 I saw it first appear in the hash checksum file, not that I'd read about it on their docs or saw a blog post or anything like that... doesn't really help you with your goal, I know - sorry. But does give you a date when it seemed to first have happened, which might be a clue somehow to help. Here's the commit where I first "found" sha1.txt (I don't remember how) and implemented it in the PKGBUILD we both use today as sha256.txt: (edit: I can't get this comment to stop butchering the link, look in the Changes for 0.9.84 -> 0.9.85 dated 2015-11-06 )

Hope some of this helps! Good luck tracking those archives down...

sudoforge commented on 2018-05-31 01:09

@troyengel where did you find the "for packagers" archive? i'm trying to find archives for the different components in order to create packages for them, and i'm not able to find current archives for anything.

troyengel commented on 2018-05-18 21:11

@sudoforge - thanks! Following your hint, I see various google hits and was able to locate a random package on Debian that shows it in use, so we can follow their pattern: (edit: and confirm now the Arch package does the same - )

If y'all can work out the file changes needed, I can integrate here as a patch as well etc. Thanks for the heads up that just copying it won't work, will wait on a solution. @MaddyBoo has never returned to pick on this conversation...

sudoforge commented on 2018-05-18 16:45

@troyengel (RE: zsh completions):

The zsh package owns /usr/share/zsh/site-functions, which is a good location to put completion files. This is where the zsh-completions package puts its completion files, and is (from my experience) included in the default $FPATH.

It's true that there isn't a well defined convention for where completion files should live, but this seems like a pretty sane choice to me.

It should be noted, however, that the file will not work in its current form. It cannot simply be copied to /usr/share/zsh/site-functions/_gcloud. Google intends for the user to source this file in their shell, and I suspect this has something to do with it.

I haven't spent time debugging this, but there will need to be modifications to the file in order for it to... well, work. I'm a co-maintainer of the google-cloud-sdk package, so it's on my list of things to check out, but isn't a high priority.

arbano commented on 2018-05-10 05:59

Thanks for the update!

arbano commented on 2018-05-10 03:46

Hi @oxplot I would also like to help maintaining this package. How can I help you?

sudoforge commented on 2018-05-08 20:49

@oxplot any chance this can be updated at some point in the near future? I'd be happy to co-maintain this and help with updates.