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 .. 18 19 20 21 22 23 24 25 26 27 28 .. 30 Next › Last »

moscar commented on 2017-04-08 17:14 (UTC)

Could you please change replaces to provides? Because of the kubectl issue I wanted to install kubectl-bin instead for the time being, but since I put AUR packages in my own repository pacman keeps asking me if I want to replace kubectl-bin with google-cloud-sdk. :) It's suggested to only use conflicts/provides for AUR packages: https://wiki.archlinux.org/index.php/PKGBUILD#replaces Thanks!

troyengel commented on 2017-04-07 23:46 (UTC)

I got nowhere trying to understand why it segfaults (it crashes after one instruction) using gdb and the core file (and strace); however, I was able to find a backup download URL if you're in a bind: https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/kubectl This file is exactly one byte smaller than the one downloaded from Google during the build process in PKGBUILD; the file downloaded by the build is 70704508 bytes, the above URL is 70704507 bytes. So I took a different tactic - which byte is wrong? It turns out to be a space character before a double linefeed (0a) near a copyright. Deleting that errant byte with a binary editor makes it work as expected. $ cp /opt/google-cloud-sdk/bin/kubectl kubectl.bad $ hexdump -v -e '/1 "%02x\n"' kubectl.bad > bad.txt $ hexdump -v -e '/1 "%02x\n"' kubectl-1.6.0 > good.txt $ $ diff -uN bad.txt good.txt --- bad.txt 2017-04-07 18:25:56.719722980 -0500 +++ good.txt 2017-04-07 18:26:12.366656743 -0500 @@ -40218707,7 +40218707,6 @@ 68 6f 6e -32 0a 0a 23 There she be, the errant 32. So I like 'bvi' myself, been using it forever - I did this: $ bvi -s 40218707 kubectl.bad ...cursored over two to the right (the line starts with '6F 6E 32 0A 0A') to where the '32' is (you can then visually see the text on the right, a Copyright of some sort) and did a ":set memmove" and 'x' to delete it, ZZ to save (so your hex string should say "6F 6E 0A 0A". It then works: $ ./kubectl.bad version Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Here's the download URL above: $ ./kubectl-1.6.0 version Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Same git commit ID and exact same build time. Something hinky is going wrong with the download from Google during the PKGBUILD, it's inserting that extra space somewhere that's causing the pain. It's not us, we just run the "download kubectl please" part of their bootstrap stuff (see the build() function in PKGBUILD). I'd say for now, just manually download that above binary and overwrite the one the package makes. Does anyone have an upstream contact at Google to feed this information to?

troyengel commented on 2017-04-07 11:34 (UTC)

Another user reported the same to me in email, I just checked and it segfaults now for me too. :( Should we roll back to 149.0.0? Wait for a new release? Google usually releases new SDKs very fast (almost every week, sometimes faster), I think if a lot of people report it to them they will fix it fast...?

tanordheim commented on 2017-04-07 07:44 (UTC)

'kubectl' is segfaulting for me (even when running just 'kubectl' without any arguments) after updating to 150.0.0-1. I downgraded to 149.0.0 (which uses kubectl 1.5.4 instead of 1.6.0), and that works fine. Removing google-cloud-sdk and installing kubectl 1.6.0 manually works just fine. Anyone else experiencing this?

vgivanovic commented on 2017-01-23 06:16 (UTC)

I haven't been able to upgrade since 135. I see now that this package also includes 'kubectl-bin' 'google-appengine-python-php' 'google-appengine-python' 'google-appengine-php', and failures in installing those are preventing me installing this package. A couple of comments: 1. I was mislead by this package being called "google-cloud-sdk" because it includes more than what's in the Google download of "google-cloud-sdk-$pkgver-linux-x86_64.tar.gz". Links from the webpage https://cloud.google.com/sdk/ don't mention anything other than "google-cloud-sdk-$pkgver-linux-x86_64.tar.gz" (but 'yaourt -Si google-cloud-sdk' does mention the additions.) 2. I can install using 'yaourt' the package 'kubectl-bin', but not 'google-appengine-python-php' 'google-appengine-python' 'google-appengine-php' because they aren't available as AUR packages. 3. As a user of 'google-cloud-sdk', I have no need for 'google-appengine-python-php' 'google-appengine-python' 'google-appengine-php', although other people may. So, I'd like to suggest splitting 'kubectl-bin' 'google-appengine-python-php' 'google-appengine-python' 'google-appengine-php' out from 'google-cloud-sdk' and to create new packages for 'google-appengine-python-php' 'google-appengine-python' 'google-appengine-php' ('kubectl-bin' already exists). If the combination of the new 'google-cloud-sdk' plus 'kubectl-bin' 'google-appengine-python-php' 'google-appengine-python' 'google-appengine-php' makes sense, then perhaps those four could be bundled together as 'google-cloud-sdk-extras' with the new 'google-cloud-sdk' as a dependency. The thing I feel most strongly about is 'google-cloud-sdk' only containing what's in "google-cloud-sdk-$pkgver-linux-x86_64.tar.gz".

troyengel commented on 2017-01-13 00:46 (UTC)

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: https://dl.google.com/dl/cloudsdk/release/sha1.txt I did not change anything in this build, it uses the same download and such - but if anyone has an idea if we should be changing something, holler. I do not investigate this software with Google at all, I'm just a casual user of a few tools.

troyengel commented on 2016-12-19 23:13 (UTC)

@vgivanovic has to be something with the server you're hitting? I just now ran my upgrade to 138.0.0 and it downloaded and installed fine. The error message you're getting appears to be reaching the Google server during build; it appears to be one of these three URLs (but there may be more): https://storage.cloud.google.com/ https://storage.googleapis.com/ https://cloud.google.com/appengine/downloads If you look in the updater code for your error string, that specific message is the final 'else' clause in the URL fetch error class used when it doesn't know exactly what's wrong, other than it can't reach a URL and wants to fail gracefully.

vgivanovic commented on 2016-12-19 04:27 (UTC)

@troyengel Same, no change. How should I help debug?

vgivanovic commented on 2016-12-19 04:17 (UTC)

@troyengel I will try your 138.0.0 version. (I just `gcloud components update' from 137.0.1 to 138.0.0.)

troyengel commented on 2016-12-18 17:33 (UTC)

@vgivanovic - looks like Google deleted the actual archives upstream for 137.0.1, they've released an updated 138.0.0 that builds. I just uploaded a fresh PKGBUILD for it, resync and try again - thanks for reporting.

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