Package Details: google-cloud-cli 502.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.36
First Submitted: 2023-03-08 09:33 (UTC)
Last Updated: 2024-11-20 07:51 (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 .. 31 Next › Last »

tengel commented on 2017-04-21 00:18 (UTC)

@Ekaradon - sounds like something is amiss with your python environment; the file api.py in that directory is where uritemplate.api is, it should get put into sys.path automatically. Have you messed with PYTHONPATH or some other environment variable? Do you see anything weird (strange directories or content) when you run this? python2 -c 'import sys; print(sys.path)' Set up a VM with Arch and try a clean build there - I just built 152.0.0 to release and it seems fine as usual; took a moment to look at this section of their code, nothing seems weird but I'm not a python master or anything.

Ekaradon commented on 2017-04-19 10:01 (UTC)

Hello, When trying to upgrade, I am facing this issue: ``` ==> Starting package()... -> Copying core SDK components -> Running bootstrapping script and adding kubectl, app-engine-python Traceback (most recent call last): File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/install.py", line 15, in <module> from googlecloudsdk.calliope import actions File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/calliope/actions.py", line 23, in <module> from googlecloudsdk.calliope import markdown File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/calliope/markdown.py", line 23, in <module> from googlecloudsdk.calliope import base File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/calliope/base.py", line 23, in <module> from googlecloudsdk.calliope import display File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/calliope/display.py", line 32, in <module> from googlecloudsdk.calliope import display_taps File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/calliope/display_taps.py", line 39, in <module> from googlecloudsdk.core import remote_completion File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/core/remote_completion.py", line 29, in <module> from googlecloudsdk.core import resources File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/core/resources.py", line 36, in <module> import uritemplate File "~/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/third_party/uritemplate/__init__.py", line 22, in <module> from uritemplate.api import ( ImportError: No module named api ==> ERROR: A failure occurred in package(). Aborting... ``` Is there anyone else having this issue? I have found a lot of similar issues related to the python2/3 installation... But nothing directly to this error.

tengel commented on 2017-04-13 00:11 (UTC)

@bastelfreak - the build depends was removed just now with the commit for 151.0.0-1 release.

tengel commented on 2017-04-09 15:08 (UTC)

@bastelfreak - sure, it'll go out in the next normal update. don't want to trigger a new build for everyone for that alone, but I edited it locally.

bastelfreak commented on 2017-04-09 15:06 (UTC)

Hi troyengel, you make remove python2 from the makedepends because it is also a normal dependency. No need to declare it twice.

tengel commented on 2017-04-09 13:01 (UTC)

@shanipribaldi - bingo thanks! that's been there forever (over a year and a half, to when I picked it up as an orphan and we moved to AUR4 git), odd how it's never broken before now. fixed that up to use -I in the grep! @moscar - kubectl-bin moved out of replaces() into provides() for you. The others in replaces() were intentional (see below) to replace the older packages at the request of the maintainer.

shanipribadi commented on 2017-04-09 02:59 (UTC)

Binary from google is fine, the issue is the msg2 "Fixing python references for python2" grep -rl 'python' "$pkgdir/opt/$pkgname" | \ xargs sed -i 's|#!.*python\b|#!/usr/bin/env python2|g' find "$pkgdir/opt/$pkgname/bin/" -maxdepth 1 -type f -exec \ sed -i 's/CLOUDSDK_PYTHON=python\b/CLOUDSDK_PYTHON=python2/g' {} \; which works on all files, even those that are not python scripts (e.g. kubectl) using grep -Irl for the first substitution to ignore binary file fixes this.

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!

tengel 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?

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

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