Arch Linux User Repository

IMPORTANT NOTE!

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.

I've gone ahead and pushed the update - as @sudoforge mentions, please use the link in the upper right "Flag package out-of-date" for AUR packages.

@deace Flagging a package as out-of-date is the proper way to inform the author of an update.

update, please.

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: https://docs.python.org/2/library/compileall.html

@troyengel ah, you mean:

https://dl.google.com/dl/cloudsdk/release/sha1.txt

and

https://dl.google.com/dl/cloudsdk/release/sha256.txt

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?

@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...

@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.

@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: https://www.apt-browse.org/browse/debian/jessie/main/amd64/xss-lock/0.3.0-1/ (edit: and confirm now the Arch package does the same - https://www.archlinux.org/packages/community/x86_64/xss-lock/ )

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...

@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 completion.zsh.inc 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.