Package Details: google-cloud-sdk 386.0.0-1

Git Clone URL: https://aur.archlinux.org/google-cloud-sdk.git (read-only, click to copy)
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: https://cloud.google.com/sdk/
Keywords: cloud gcloud gcp google sdk
Licenses: Apache
Submitter: barnybug
Maintainer: sudoforge (sudobot)
Last Packager: sudoforge
Votes: 166
Popularity: 3.28
First Submitted: 2014-06-03 08:10 (UTC)
Last Updated: 2022-05-17 15:57 (UTC)

Pinned Comments

sudoforge commented on 2022-04-25 02:14 (UTC) (edited on 2022-04-25 03:08 (UTC) by sudoforge)

There has been a recent influx of users reporting that they are encountering an error related to missing libcrypt.so.1:

error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

If you encounter this error, the issue is that your shell has not imported /etc/profile.d/google-cloud-sdk.sh, causing the CLOUDSDK_PYTHON environment variable (among others) to not be set. This causes the tool to use a bundled python executable with its own library searching logic which fails to find the correct library.

libcrypt is provided by core/libxcrypt, which is required by core/python, which is required by aur/google-cloud-sdk. If you've installed this package, you have the correct library.

This is not a bug with the package; it is a bug with your shell. At the moment, this appears to be limited to users of fish. Please check the wiki for information about the tasks you should perform when setting fish as your default shell to avoid errors like this.

sudoforge commented on 2018-09-10 15:11 (UTC) (edited on 2021-02-09 22:04 (UTC) by sudoforge)

PLEASE NOTE

This PKGBUILD is maintained on GitHub. Please use the following repository to submit patches, ask questions, and raise issues:

https://github.com/sudoforge/pkgbuilds

sudoforge commented on 2018-08-21 22:09 (UTC) (edited on 2019-05-04 12:36 (UTC) by sudoforge)

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.

Latest Comments

Showfom commented on 2022-05-11 12:36 (UTC)

385.0.0-2 works, thanks for update.

sudoforge commented on 2022-05-11 12:02 (UTC)

385.0.0-2 resolved the issue. If you are still experiencing a build failure, you are not building 385.0.0-2.

Showfom commented on 2022-05-11 12:01 (UTC)

Same error here for the latest version:

==> Starting prepare()...
failed to apply patch: 0004-collections-abc.patch
==> ERROR: A failure occurred in prepare().
    Aborting...
 -> error making: google-cloud-sdk

quest commented on 2022-05-11 09:39 (UTC)

Latest version fails to apply the collections patch.

failed to apply patch: 0004-collections-abc.patch
==> ERROR: A failure occurred in prepare().

sudoforge commented on 2022-04-25 02:14 (UTC) (edited on 2022-04-25 03:08 (UTC) by sudoforge)

There has been a recent influx of users reporting that they are encountering an error related to missing libcrypt.so.1:

error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

If you encounter this error, the issue is that your shell has not imported /etc/profile.d/google-cloud-sdk.sh, causing the CLOUDSDK_PYTHON environment variable (among others) to not be set. This causes the tool to use a bundled python executable with its own library searching logic which fails to find the correct library.

libcrypt is provided by core/libxcrypt, which is required by core/python, which is required by aur/google-cloud-sdk. If you've installed this package, you have the correct library.

This is not a bug with the package; it is a bug with your shell. At the moment, this appears to be limited to users of fish. Please check the wiki for information about the tasks you should perform when setting fish as your default shell to avoid errors like this.

sudoforge commented on 2022-03-23 16:22 (UTC)

Note: I overhauled my internal CI process that updates packages and syncs them out to external destinations (like the AUR). Please open an issue using the issue tracker if you encounter any issues.

cameronraysmith commented on 2022-02-25 16:19 (UTC)

@sudoforge @ginjiruu I received the same error in bash and fixed by installing https://archlinux.org/packages/core/x86_64/libxcrypt-compat/ as described here https://bbs.archlinux.org/viewtopic.php?pid=2022246#p2022246 (but now in community rather than aur) due to dropping libcrypt.so.1 from glibc.

mccurdyc commented on 2022-02-20 12:17 (UTC)

@sudoforge export CLOUDSDK_PYTHON=$(which python3) also fixed it for me on zsh. Thanks!

sudoforge commented on 2022-02-15 21:55 (UTC)

To those curious: ginjiruu was using fish, which apparently doesn't source /etc/profile, causing the CLOUDSDK_PYTHON variable to be unset (among other important variables). Specifically, when CLOUDSDK_PYTHON is unset, gcloud uses a vendored python3 executable, which wasn't linked appropriately.

I will likely remove this bundled python in future releases.

sudoforge commented on 2022-02-15 16:32 (UTC)

@ginjiruu Please open an issue using the issue tracker, and I'll follow up with you today to debug this issue specific to your environments.

ginjiruu commented on 2022-02-15 16:07 (UTC)

@sudoforge I don't believe so. Was able to build version 371 just fine with the same shell config. First system tried was a local arch installation and the other was a wsl2 install that also succeeded on version 371 and is also having issues now

sudoforge commented on 2022-02-15 15:54 (UTC) (edited on 2022-02-15 16:03 (UTC) by sudoforge)

@ginjiruu This does not occur in a clean chroot, nor on my local system (outside of a chroot). Are you building this in a python virtual environment, or do you otherwise have a python virtual environment active in the shell session you are attempting to build it in?

Edit: And to be clear, you are encountering this error when building the package on your systems (as opposed to encountering it when running commands), correct?

ginjiruu commented on 2022-02-15 15:38 (UTC) (edited on 2022-02-15 15:40 (UTC) by ginjiruu)

Version 372.0.0-1 is giving me the error

/opt/google-cloud-sdk/platform/bundledpythonunix/bin/python3: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

despite having the various ssl packages installed. Repeated on 2 separate computers.

sudoforge commented on 2022-02-04 15:14 (UTC)

@rsaxena correct, 371.0.0-4 updates the patch to cover a new use of collections.Mapping that was introduced in 370.0.0 and missed (because my pipeline does not test every possible command; although this is something I'm aiming to resolve in the upcoming weeks).

Somewhat hilariously, 370.0.0 actually introduced the removal of a workaround to support the collections -> collections.abc change for newer versions of Python.

➜ diff {369,370}/platform/bq/bigquery_client.py | head -10
--- 369/platform/bq/bigquery_client.py    1980-01-01 01:00:00.000000000 -0700
+++ 370/platform/bq/bigquery_client.py    1980-01-01 01:00:00.000000000 -0700
@@ -58,9 +58,6 @@

 _GCS_SCHEME_PREFIX = 'gs://'

-collections_abc = collections
-if sys.version_info > (3, 8):
-  collections_abc = collections.abc

rsaxena commented on 2022-02-04 09:35 (UTC)

With the new patch (v. 371.0.0-4) it is working for me, Python 3.10.2

ayr-ton commented on 2022-02-03 15:18 (UTC)

The current version is failing with Python 3.10.1:

└─[$] bq
Traceback (most recent call last):
  File "/opt/google-cloud-sdk/platform/bq/bq.py", line 63, in <module>
    import bigquery_client
  File "/opt/google-cloud-sdk/platform/bq/bigquery_client.py", line 6755, in <module>
    class ApiClientHelper(object):
  File "/opt/google-cloud-sdk/platform/bq/bigquery_client.py", line 6761, in ApiClientHelper
    class Reference(collections.Mapping):
AttributeError: module 'collections' has no attribute 'Mapping'
└─[$] python -V
Python 3.10.1

I will investigate more later and provide details if I find the reason.

sudoforge commented on 2022-01-31 18:16 (UTC)

@Jont828, please see the pinned comments.

I'm in the process of finishing the PKGBUILDs for each external component. I'd suggest following the instructions in the pinned comments until they are finalized and published.

Jont828 commented on 2022-01-31 18:10 (UTC)

Is it possible to get gcloud's cloud-build-local package on the AUR? I installed the Google Cloud SDK from here, but this tutorial requires installing cloud-build-local, which I could not find on the AUR. It can be installed through gcloud using gcloud components install cloud-build-local, but that command doesn't work when it's installed through the AUR since gcloud sees a separate package manager.

sudoforge commented on 2022-01-26 06:59 (UTC) (edited on 2022-01-26 07:00 (UTC) by sudoforge)

@akhil: I have no idea what Yay does, but the package most definitely installs the shell inclusion files under /opt. Please file issues related to Yay at its project page.


PLEASE NOTE

This PKGBUILD is maintained on GitHub. Please use the following repository to submit patches, ask questions, and raise issues:

https://github.com/sudoforge/pkgbuilds

sudoforge commented on 2022-01-26 06:57 (UTC) (edited on 2022-01-26 07:01 (UTC) by sudoforge)

@rachejazz: comments from 2022-01-13 are obsolete. The issue was fixed later that day.


PLEASE NOTE

This PKGBUILD is maintained on GitHub. Please use the following repository to submit patches, ask questions, and raise issues:

https://github.com/sudoforge/pkgbuilds

rachejazz commented on 2022-01-26 06:53 (UTC)

@myyc do you mean to say dev-app-server and endpoints-cfg patches needn't be patched since it was already patched?

myyc commented on 2022-01-13 10:59 (UTC) (edited on 2022-01-13 13:08 (UTC) by myyc)

edit: i was lazy and only checked the first two files. as per the comment below this one actually only the first two files had been patched already. deleting the first two files from the diff and changing the checksum works.

original comment:

it seems like the patch that's failing has been applied already, i've checked a couple of the affected files and it seems to be the case.

i am not the maintainer of the package so i don't know the risk in removing it, but doing so installs the sdk.

amiga23 commented on 2022-01-13 09:30 (UTC)

I've removed the >/dev/null and get the following conrete error messages:

==> Starting prepare()...
patching file bin/dev_appserver.py
patching file bin/endpointscfg.py
patching file completion.zsh.inc
patching file lib/googlecloudsdk/api_lib/run/k8s_object.py
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file lib/googlecloudsdk/api_lib/run/k8s_object.py.rej
patching file lib/googlecloudsdk/api_lib/run/traffic.py
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file lib/googlecloudsdk /api_lib/run/traffic.py.rej
patching file lib/third_party/dns/namedict.py
patching file lib/third_party/frozendict/__init__.py
patching file lib/third_party/functools32/functools32.py
patching file lib/third_party/ml_sdk/cloud/ml/prediction/prediction_utils.py
patching file lib/third_party/prompt_toolkit/styles/from_dict.py
patching file platform/gsutil/gslib/vendored/boto/boto/dynamodb/types.py
patching file platform/gsutil/gslib/vendored/boto/boto/mws/connection.py
failed to apply patch: 0004-collections-abc.patch
==> ERROR: A failure occurred in prepare().
    Aborting...

masterberg commented on 2022-01-12 21:39 (UTC) (edited on 2022-01-12 21:39 (UTC) by masterberg)

0004-collections-abc.patch fails to be applied when installing the package.

failed to apply patch: 0004-collections-abc.patch

amrit073 commented on 2022-01-12 14:34 (UTC)

failed to apply patch

marmotz commented on 2022-01-12 11:10 (UTC)

@fabian-ang same here

failed to apply patch: 0004-collections-abc.patch

fabian-ang commented on 2022-01-12 10:34 (UTC)

With the new update it fails building on my machine, it can't apply 0004-collections-abc.patch. Cleaning all build artifatcs etc. did not help

akhil commented on 2021-12-28 11:37 (UTC)

looks like its removing the extracted files after installation

no such file or directory: /home/akhil/.cache/yay/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/completion.zsh.inc
no such file or directory: /home/akhil/.cache/yay/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/path.zsh.inc

cippaciong commented on 2021-12-18 15:37 (UTC) (edited on 2021-12-19 21:19 (UTC) by cippaciong)

EDIT: Should be fixed now

Hey folks, if anyone is getting this error when building the package:

PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.10/site-packages/google_api_core-2.3.2-py3.10.egg-info/PKG-INFO'

Please be aware that the problem is not caused by this package itself, but is related to python-google-api-core and is being tracked in FS#73074

sudoforge commented on 2021-12-15 14:03 (UTC) (edited on 2021-12-15 14:14 (UTC) by sudoforge)

To anyone experiencing an issue with version 367.0.0-3 of this package, please rebuild with 367.0.0-4.


A reminder: Please use sudoforge/pkgbuilds for reporting issues in the future.

Issue tracking via AUR comments is not preferred for various reasons, the least of which is that this repository is essentially just a read-only mirror; no development occurs here.

MigueldeCarvalho commented on 2021-12-15 12:04 (UTC) (edited on 2021-12-15 12:05 (UTC) by MigueldeCarvalho)

Same here

failed to apply patch: 0004-collections-abc.patch
==> ERROR: A failure occurred in prepare().
Aborting...

Fandekasp commented on 2021-12-15 10:00 (UTC) (edited on 2021-12-15 10:11 (UTC) by Fandekasp)

Same here, failed to apply patch: 0004-collections-abc.patch System python is 3.10.1-1

There are changes related to collections.abc.Callable in 3.10 https://docs.python.org/3/whatsnew/3.10.html#changes-in-the-python-api

blackout commented on 2021-12-15 07:24 (UTC)

fails to apply patch

-> Extracting google-cloud-sdk_367.0.0.orig.tar.gz with bsdtar
==> Starting prepare()...
failed to apply patch: 0004-collections-abc.patch
==> ERROR: A failure occurred in prepare().
Aborting...
 -> error making: google-cloud-sdk

sudoforge commented on 2021-09-01 14:02 (UTC)

@frabjous The package is tested before it is uploaded. The URL is correct. Check your internet connection, firewall, and any host-blocking tools you may use (e.g. PiHole).

frabjous commented on 2021-09-01 13:27 (UTC)

I'm getting a 404 error when attempting to download https://dl.google.com/dl/cloudsdk/release/downloads/for_packagers/linux/google-cloud-sdk_355.0.0.orig.tar.gz. Anyone else?

jamesmcm commented on 2021-04-27 09:01 (UTC) (edited on 2021-04-27 09:03 (UTC) by jamesmcm)

Would it be possible to package with the cloud-datastore-emulator component?

EDIT: Nevermind I read the pinned comments.

sudoforge commented on 2020-06-15 03:00 (UTC)

@allsyed component support in individual packages is still under way; only a few packages are currently maintained (check my profile for a complete list). Read the pinned comment(s) for instructions on how to receive support for this package, and how to modify your installation to allow for component management via gcloud components <command>.

allsyed commented on 2020-06-15 02:57 (UTC)

How do I go about installing other components?

Like when I try to install cloud_sql_proxy. I get this message.

ERROR: (gcloud.components.install) You cannot perform this action because this Cloud SDK installation is managed by an external package manager. Please consider using a separate installation of the Cloud SDK created through the default mechanism described at: https://cloud.google.com/sdk/

sudoforge commented on 2020-04-23 19:27 (UTC)

@brody great catch, that was patched in. As a reminder, please use Github to submit patches, ask questions, and raise issues.

brody commented on 2020-04-22 18:37 (UTC)

Please can you adjust the permission of the bash-completion file to 644 (from the least privilege perspective)?

diff --git a/PKGBUILD b/PKGBUILD
index ce029a3..6260b9d 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -66,7 +66,7 @@ package() {
   install -Dm755 "${srcdir}/${source[1]}" \
     "${pkgdir}/etc/profile.d/google-cloud-sdk.sh"

-  install -Dm755 "${pkgdir}/opt/${pkgname}/completion.bash.inc" \
+  install -Dm644 "${pkgdir}/opt/${pkgname}/completion.bash.inc" \
     "${pkgdir}/etc/bash_completion.d/google-cloud-sdk"

   mkdir -p "${pkgdir}/usr/share"

mindrunner commented on 2020-02-18 22:20 (UTC)

Will do, thank you for help and patience! :)

sudoforge commented on 2020-02-18 22:16 (UTC)

Haha, cannot patch PKGUILD because 'patch not found'. reinstalled base-devel group and all good now! :)

I guessed that was going to be the issue, but wanted to make sure we debugged it properly. Glad it's sorted out! As a note, please use the GitHub parent project for reporting issues in the future.

mindrunner commented on 2020-02-18 22:13 (UTC)

Haha, cannot patch PKGUILD because 'patch not found'. reinstalled base-devel group and all good now! :)

Cheers

sudoforge commented on 2020-02-18 21:30 (UTC) (edited on 2020-02-18 21:36 (UTC) by sudoforge)

Super weird. I still encounter this on one computer (a virtual server), however I am able to install the package on my laptop without any problems. Both are set up in pretty much the same way, but differ in the list of installed packages (e.g. laptop has desktop stuff installed). Using yay as the aur-helper on both machines. Tried manually with makepkg, same result. I cannot figure out an easy way to see why patching fails (no verbose option).

After cloning this repository on the failing machine, apply the following patch to the PKGBUILD before running makepkg; this should give us the information we need:

diff -urN a/PKGBUILD b/PKGBUILD
--- a/PKGBUILD  2020-02-18 13:33:09.701671909 -0800
+++ b/PKGBUILD  2020-02-18 13:35:33.254889896 -0800
@@ -36,7 +36,7 @@
   cd "$pkgname"

   for f in ./../*.patch; do
-    patch -p1 -i $f > /dev/null 2>&1 || ( echo "failed to apply patch: $(basename $f)" && exit 1 )
+    patch -p1 --verbose -i $f
   done
 }

I've uploaded the above patch to ix.io. To easily apply this from your virtual server:

$ git clone https://aur.archlinux.org/google-cloud-sdk.git
$ cd google-cloud-sdk
$ patch -p1 < <(wget -qO- http://ix.io/2c5o)
$ makepkg -sr

Edit: I initially made this comment with an invalid patch containing an erroneous s I had added to verify that the patch would print out the error.

mindrunner commented on 2020-02-18 21:07 (UTC)

Super weird. I still encounter this on one computer (a virtual server), however I am able to install the package on my laptop without any problems. Both are set up in pretty much the same way, but differ in the list of installed packages (e.g. laptop has desktop stuff installed). Using yay as the aur-helper on both machines. Tried manually with makepkg, same result. I cannot figure out an easy way to see why patching fails (no verbose option).

sudoforge commented on 2020-02-18 19:54 (UTC) (edited on 2020-02-18 20:01 (UTC) by sudoforge)

==> Extracting sources... -> Extracting google-cloud-sdk_279.0.0.orig.tar.gz with bsdtar ==> Starting prepare()... failed to apply patch: 0001-fix-console-io-syntax-warning.patch ==> ERROR: A failure occurred in prepare().

Since a couple of days now. Any news on this?

I apologize for the delay in responding to you; I'm just now seeing this. This would seem to indicate that there is an error with applying the patch file at commit 3540d93b5a51f9a0cd3a6b54c9491363efcfb4f3 in this repository (d60f3d6bb2808253fd4b51d975b78c47ae6e3080 in the parent).

I'm not able to recreate this at that revision, nor at the latest. For context, commits are only sent to this repository (and the parent) if the google-cloud-sdk package is built successfully in a chroot. I have also taken to testing that various subcommands return expected results without errors or erroneous content spewed out to the console due to recent upstream issues (which I have opened bugs for). These are not automated yet; I build and install the package, and then perform some manual "E2E tests".

That said, I'm surprised to hear that you encountered issues. Are you still experiencing this, @mindrunner? Is anyone else?

mindrunner commented on 2020-02-10 22:24 (UTC)

==> Extracting sources... -> Extracting google-cloud-sdk_279.0.0.orig.tar.gz with bsdtar ==> Starting prepare()... failed to apply patch: 0001-fix-console-io-syntax-warning.patch ==> ERROR: A failure occurred in prepare().

Since a couple of days now. Any news on this?

sudoforge commented on 2020-01-24 04:53 (UTC) (edited on 2020-01-24 04:54 (UTC) by sudoforge)

Hey folks,

277.0.0-2 has been released. This includes 7 new commits, bringing quite a few changes in. Namely:

  • The PKGBUILD now downloads and, well, packages, version 277.0.0
  • The SDK should now run with python 3 instead of python 2
  • The SyntaxWarning brought about by an upstream commit is patched locally
  • Building + packaging should now be a lot more quiet; interpreter-compiled bytecode are removed at packaging time (which will suppress a makepkg warning), and the various echo statements have been removed

As always, please let me know if you run into issues, or have a usability concern. While I do still monitor AUR comments, the proper place to report issues is at the Github repository.

sudoforge commented on 2020-01-16 17:15 (UTC) (edited on 2020-01-17 04:34 (UTC) by sudoforge)

Why is python in both depends a optdepends?

Whoops - good catch, thanks!

Also, CLOUDSDK_PYTHON still defaults to python2, so why exactly does this packages depends on python? Since Python 2 is dead, shouldn't this package change CLOUDSDK_PYTHON to python3 and move python2 from depends to optdepends?

While the core SDK supports Python3, some of the internal tools (dev_appserver and endpointscfg) that are bundled with the SDK do not yet support Python3. Therefore, both Python3 and Python2 are listed as dependencies. I'm still experimenting with setting CLOUDSDK_PYTHON to 3; I have not had time to determine whether or not this breaks the internal tools which depend on 2. I suppose that line could be removed from the script and we could rely on the internal resolution; but note that this would also default to Python2, as seen in the load order described in gcloud topic startup or online at: https://cloud.google.com/sdk/gcloud/reference/topic/startup

the-k commented on 2020-01-15 21:59 (UTC) (edited on 2020-01-15 22:00 (UTC) by the-k)

Why is python in both depends a optdepends? Also, CLOUDSDK_PYTHON still defaults to python2, so why exactly does this packages depends on python? Since Python 2 is dead, shouldn't this package change CLOUDSDK_PYTHON to python3 and move python2 from depends to optdepends?

the-k commented on 2019-12-23 11:48 (UTC)

Version 274.0.0 has been released and it features gcloud GA support for Python 3. See https://cloud.google.com/sdk/docs/quickstart-linux#before-you-begin.

sudoforge commented on 2019-12-13 06:56 (UTC) (edited on 2019-12-13 06:56 (UTC) by sudoforge)

I reverted the package to 272 after the build error was discovered.

The issue preventing me from building 273.0.0 is being tracked here:

https://issuetracker.google.com/issues/146012762

To summarize, there's a missing module: google_type_annotations. This is (supposedly) provided by the python package pytype, however, installing pytype doesn't seem to resolve this error, and I don't really have the time to dedicate digging into this further.

I could remove the step that is compiling the python source files to bytecode and bypass this error to build the package for 273.0.0, however, this would result in a SyntaxError at runtime whenever the particular file (active_peering_zones.py) is invoked, so I'm making the decision to halt upgrades until the issue referenced above is resolved, or until a future version of the SDK builds successfully.

piozylka commented on 2019-12-11 05:01 (UTC)

error in building script after today's update

Installing bash completion script Fixing python references for python2 and compiling *.pyc Compiling /home/pio/.cache/yay/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/api_lib/dns/active_peering_zones.py ... SyntaxError: future feature google_type_annotations is not defined (active_peering_zones.py, line 19)

ewaller commented on 2019-12-11 03:52 (UTC) (edited on 2019-12-11 03:55 (UTC) by ewaller)

Not building after today's system update:

Installing bash completion script Fixing python references for python2 and compiling *.pyc Compiling /home/ewaller/devel/build/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/api_lib/dns/active_peering_zones.py ... SyntaxError: future feature google_type_annotations is not defined (active_peering_zones.py, line 19)

==> ERROR: A failure occurred in package().

sudoforge commented on 2019-11-09 16:40 (UTC)

@chibby0ne, this is very likely an upstream issue, but I've filed it and will be following up on Github:

https://github.com/sudoforge/pkgbuilds/issues/12

chibby0ne commented on 2019-11-08 14:02 (UTC)

I've read the pinned comment from @sudoforge, and the comments from @oskar and @esbdb, but these assume that kubectl is installed.

I've just installed this package which is now in version 270.0.0-3, and it looks like it doesn't bring kubectl anymore but it still shows up as installed in the output of gcloud components list:


Your current Cloud SDK version is: 270.0.0
The latest available version is: 270.0.0

+------------------------------------------------------------------------------------------------------------+
|                                                 Components                                                 |
+---------------+------------------------------------------------------+--------------------------+----------+
|     Status    |                         Name                         |            ID            |   Size   |
+---------------+------------------------------------------------------+--------------------------+----------+
| Not Installed | App Engine Go Extensions                             | app-engine-go            |  4.9 MiB |
| Not Installed | Cloud Bigtable Command Line Tool                     | cbt                      |  7.5 MiB |
| Not Installed | Cloud Bigtable Emulator                              | bigtable                 |  6.6 MiB |
| Not Installed | Cloud Datalab Command Line Tool                      | datalab                  |  < 1 MiB |
| Not Installed | Cloud Datastore Emulator                             | cloud-datastore-emulator | 18.4 MiB |
| Not Installed | Cloud Firestore Emulator                             | cloud-firestore-emulator | 40.0 MiB |
| Not Installed | Cloud Pub/Sub Emulator                               | pubsub-emulator          | 34.9 MiB |
| Not Installed | Cloud SQL Proxy                                      | cloud_sql_proxy          |  3.8 MiB |
| Not Installed | Emulator Reverse Proxy                               | emulator-reverse-proxy   | 14.5 MiB |
| Not Installed | Google Cloud Build Local Builder                     | cloud-build-local        |  6.0 MiB |
| Not Installed | Google Container Registry's Docker credential helper | docker-credential-gcr    |  1.8 MiB |
| Not Installed | Skaffold                                             | skaffold                 | 22.1 MiB |
| Not Installed | gcloud app Java Extensions                           | app-engine-java          | 85.9 MiB |
| Not Installed | gcloud app PHP Extensions                            | app-engine-php           |          |
| Not Installed | gcloud app Python Extensions                         | app-engine-python        |  6.0 MiB |
| Not Installed | gcloud app Python Extensions (Extra Libraries)       | app-engine-python-extras | 27.1 MiB |
| Installed     | BigQuery Command Line Tool                           | bq                       |  < 1 MiB |
| Installed     | Cloud SDK Core Libraries                             | core                     | 12.3 MiB |
| Installed     | Cloud Storage Command Line Tool                      | gsutil                   |  3.6 MiB |
| Installed     | gcloud Alpha Commands                                | alpha                    |  < 1 MiB |
| Installed     | gcloud Beta Commands                                 | beta                     |  < 1 MiB |
| Installed     | kubectl                                              | kubectl                  |  < 1 MiB |
+---------------+------------------------------------------------------+--------------------------+----------+
To install or remove components at your current SDK version [270.0.0], run:
  $ gcloud components install COMPONENT_ID
  $ gcloud components remove COMPONENT_ID

To update your SDK installation to the latest version [270.0.0], run:
  $ gcloud components update

sudoforge commented on 2019-11-06 00:41 (UTC)

@bswartz thanks for catching that; python3 should have been an optdep.

bswartz commented on 2019-11-06 00:27 (UTC) (edited on 2019-11-06 00:28 (UTC) by bswartz)

This package no longer builds. The error message is:

==> Starting package()...
Copying core SDK components
Running bootstrapping script
/home/arch/google-cloud-sdk/PKGBUILD: line 38: python2: command not found
==> ERROR: A failure occurred in package().
    Aborting...

sudoforge commented on 2019-09-18 12:05 (UTC) (edited on 2019-09-18 12:19 (UTC) by sudoforge)

Hey folks,

The PKGBUILD has been updated from 261.0.0 to 263.0.0. I apologize for skipping 262.0.0's release; I was out of town.

I'm in the process of working out how I want to automate these updates, since Google is a trusted source (at least in terms of package integrity). I currently use a mashed up shell script to do this for me, but it still needs to be manually invoked -- after it's completion, I create the commit and handle pushing to Github (the source of truth for the PKGBUILD) and then subtree the google-cloud-sdk directory out to the AUR.

I'll almost certainly have to do two things:

1) Stop signing the Git commits with my PGP key

2) Use a passwordless key to push to the AUR

1 is more or less unimportant, as I doubt anyone has workflows that rely on my key. 2 is more concerning, as it would mean that the machine I'm using to update the AUR package is able to hit the git server with a passwordless RSA key. To limit the attack vector to packages which have a "trusted upstream source" (like this one), I'll be adding a bot user as a co-maintainer. I may eventually remove my personal account from this package if this proves successful.

Let me know if:

  • Your workflow will break if my commits are no longer signed with my PGP key, or
  • Your workflow will break if the package owner changes

sudoforge commented on 2019-05-04 12:37 (UTC)

@Brinox:

I have confirmed this regression and updated the pinned comment.

Brinox commented on 2019-01-27 10:54 (UTC)

The described mechanism of installing additional components by modifying the _additional_components variable does not work. The SDK installer just won't install the given components, because "disable_updater" is set to true. This seems to affect the bootstrap install, too.

sudoforge commented on 2019-01-15 09:03 (UTC)

@esbdb and @oskar - There has been a pinned comment with instructions for managing components since August 2018.

oskar commented on 2019-01-15 08:42 (UTC)

I wasn't able to update kubectl component either due to the following error:

ERROR: (gcloud.components.remove) You cannot perform this action because this Cloud SDK installation is managed by an external package manager. Please consider using a separate installation of the Cloud SDK created through the default mechanism described at: <https://cloud.google.com/sdk/>

I circumvented this by installing kubectl package from AUR (which is up-to-date) and removing /opt/google-cloud-sdk/bin/kubectl.

brendanb commented on 2018-10-30 06:56 (UTC)

How do I actually update installed components? I'm still running kubectl 1.7.2. Even when update gcloud, gcloud components update never gets run.

sudoforge commented on 2018-10-20 15:36 (UTC)

@mathieu.clabaut:

You can follow the very straightforward instructions in the pinned comment to add additional components. No additional components will be added to this PKGBUILD at any time now or in the future.

mathieu.clabaut commented on 2018-10-20 12:23 (UTC)

First, I must thank you for your useful package.

I'd like to ask if it Wouldn't be possible to keep the app engine component in this package until the other package is available ?

sudoforge commented on 2018-09-14 15:14 (UTC)

@tuxsavvy Upon reading the output you posted, that would seem to be an error from the bootstrap script itself - or rather, that yaml cannot be imported from ruamel. Something definitely got borked with your environment, as that's a bundled SDK dependency included in the tarball that this PKGBUILD downloads from Google.

sudoforge commented on 2018-09-10 15:11 (UTC) (edited on 2021-02-09 22:04 (UTC) by sudoforge)

PLEASE NOTE

This PKGBUILD is maintained on GitHub. Please use the following repository to submit patches, ask questions, and raise issues:

https://github.com/sudoforge/pkgbuilds

sudoforge commented on 2018-09-10 15:10 (UTC)

@tuxsavvy

Apart from git diff output as that returns nothing I figured you want me to compare the previous major commit

No, the intent was to make sure you didn't have a dirty working tree (changes from HEAD). I don't need to see the difference between two commits if you've not diverged from origin like you say...

You should try deleting the repository from disk and re-cloning it, and building from that. I don't use aurman, and don't know what it's trying to do under the hood, but I can tell you with absolute certainty that python-ruamel-yaml is not a build dependency.

tuxsavvy commented on 2018-09-10 09:29 (UTC)

@sudoforge Thanks for replying. Apart from git diff output as that returns nothing I figured you want me to compare the previous major commit. Below are requested output.

$ git rev-parse HEAD
929c850f3397f91040c3e23b78d3165d2a6cc3be
$ git diff 929c850f3397f91040c3e23b78d3165d2a6cc3be d7688acc171002029ee9ac1ccd6fa41ca104aee6
diff --git a/.SRCINFO b/.SRCINFO
index 922e193..92bc9e4 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,17 +1,18 @@
 pkgbase = google-cloud-sdk
        pkgdesc = A set of command-line tools for the Google Cloud Platform. Includes gcloud (with beta and alpha commands), gsutil, and bq.
-       pkgver = 214.0.0
+       pkgver = 213.0.0
        pkgrel = 1
        url = https://cloud.google.com/sdk/
        arch = x86_64
        license = Apache
        depends = python2
        optdepends = python2-crcmod: [gsutil] verify the integrity of GCS object contents
+       conflicts = google-cloud-sdk-minimal
        options = !strip
        options = staticlibs
-       source = https://dl.google.com/dl/cloudsdk/release/downloads/for_packagers/linux/google-cloud-sdk_214.0.0.orig.tar.gz
+       source = https://dl.google.com/dl/cloudsdk/release/downloads/for_packagers/linux/google-cloud-sdk_213.0.0.orig.tar.gz
        source = google-cloud-sdk.sh
-       sha256sums = f7c2720792aa8f819d553746d5ecdcd5df4a317129908e55d9da9d6bf3839379
+       sha256sums = 604d13879812bfc79879d845714211f36611d38740e6621c27f390736b43b648
        sha256sums = 36ac88de630e49ea4b067b1f5f229142e4cf97561b98b3bd3d8115a356946692

 pkgname = google-cloud-sdk
diff --git a/PKGBUILD b/PKGBUILD
index c543826..1a0e78c 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -6,12 +6,13 @@
 # Contributor: Justin Dray <justin@dray.be>

 pkgname="google-cloud-sdk"
-pkgver=214.0.0
+pkgver=213.0.0
 pkgrel=1
 pkgdesc="A set of command-line tools for the Google Cloud Platform. Includes gcloud (with beta and alpha commands), gsutil, and bq."
 url="https://cloud.google.com/sdk/"
 license=("Apache")
 arch=('x86_64')
+conflicts=("google-cloud-sdk-minimal")
 depends=('python2')
 optdepends=('python2-crcmod: [gsutil] verify the integrity of GCS object contents')
 options=('!strip' 'staticlibs')
@@ -21,7 +22,7 @@ source=(
   "google-cloud-sdk.sh"
 )
 sha256sums=(
-  'f7c2720792aa8f819d553746d5ecdcd5df4a317129908e55d9da9d6bf3839379'
+  '604d13879812bfc79879d845714211f36611d38740e6621c27f390736b43b648'
   '36ac88de630e49ea4b067b1f5f229142e4cf97561b98b3bd3d8115a356946692'
 )

@@ -93,13 +94,13 @@ package() {

   msg2 "Creating symlinks for applications"
   mkdir -p "${pkgdir}/usr/bin"
-  for i in "${pkgdir}/opt/${pkgname}/bin"/*; do
-    ln -st "${pkgdir}/usr/bin/" "${i#${pkgdir}}"
-  done
+  find "${pkgdir}/opt/${pkgname}/bin" -maxdepth 1 -type f -printf \
+    "/opt/${pkgname}/bin/%f\n" | xargs ln -st "${pkgdir}/usr/bin"
   rm -f "${pkgdir}"/usr/bin/{bq,dev_appserver.py*,endpointscfg.py*,java_dev_appserver.sh}

   msg2 "Fixing file permissions"
   chmod -x "${pkgdir}"/usr/share/man/man1/*
-  find "${pkgdir}/opt/${pkgname}" -name "*.html" -o -name "*.json" -exec chmod -x {} \;
-  find "${pkgdir}/opt/${pkgname}" -name "*_test.py" -exec chmod +x {} \;
+  find "${pkgdir}/opt/${pkgname}" -name "*.html" -print0 | xargs -0 chmod -x
+  find "${pkgdir}/opt/${pkgname}" -name "*.json" -print0 | xargs -0 chmod -x
+  find "${pkgdir}/opt/${pkgname}" -name "*_test.py" -print0 | xargs -0 chmod +x
 }
$ makepkg -sf
==> Making package: google-cloud-sdk 214.0.0-1 (Tue 04 Sep 2018 19:52:51 AEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found google-cloud-sdk_214.0.0.orig.tar.gz
  -> Found google-cloud-sdk.sh
==> Validating source files with sha256sums...
    google-cloud-sdk_214.0.0.orig.tar.gz ... Passed
    google-cloud-sdk.sh ... Passed
==> Extracting sources...
  -> Extracting google-cloud-sdk_214.0.0.orig.tar.gz with bsdtar
==> Starting prepare()...
  -> Checking for newer upstream release
  -> This AUR release: 214.0.0
  -> Latest upstream release: 214.0.0
==> Entering fakeroot environment...
==> Starting package()...
  -> Copying core SDK components
  -> Running bootstrapping script and adding additional components
Traceback (most recent call last):
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/install.py", line 12, in <module>
    import bootstrapping
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/bootstrapping.py", line 46, in <module>
    from googlecloudsdk.core.updater import update_manager
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/core/updater/update_manager.py", line 35, in <module>
    from googlecloudsdk.core import yaml
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/core/yaml.py", line 32, in <module>
    from ruamel import yaml
ImportError: cannot import name yaml
==> ERROR: A failure occurred in package().
    Aborting...

Do note that the last output was me forcing makepkg within aurman directory. This is not using any AUR helper/wrapper to compile it.

Thanks in advance

allgaeuer.fabian commented on 2018-09-04 07:12 (UTC)

@sudoforge Yes, the package has never bundled the app-engine-java component (I always installed the component by modifying the PKGBUILD file). I just wanted to highlight that installing a JDK or JRE is (and never was) sufficient to use the Java environment. This was a bug in the old package because it simply listed as an optional dependency:

'java-environment: for Java version of App Engine'

sudoforge commented on 2018-08-31 16:28 (UTC) (edited on 2018-08-31 16:28 (UTC) by sudoforge)

@tuxsavvy python2-ruamel-yaml is a (bundled) dependency of the SDK, and is not required for building. I'm not sure why you're experiencing that error.

Please upload the following to ptpbw.pw (or a similar pastebin service):

  • The current commit that your cloned repo is at (git rev-parse HEAD)
  • The output of git diff in your cloned repo
  • The output of makepkg -s

tuxsavvy commented on 2018-08-31 10:15 (UTC)

I believe python2-ruamel-yaml might be required because it would fail to complete otherwise. Here is my build log without the dependency:

==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found google-cloud-sdk_214.0.0.orig.tar.gz
  -> Found google-cloud-sdk.sh
==> Validating source files with sha256sums...
    google-cloud-sdk_214.0.0.orig.tar.gz ... Passed
    google-cloud-sdk.sh ... Passed
==> Extracting sources...
  -> Extracting google-cloud-sdk_214.0.0.orig.tar.gz with bsdtar
==> Starting prepare()...
  -> Checking for newer upstream release
  -> This AUR release: 214.0.0
  -> Latest upstream release: 214.0.0
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
  -> Copying core SDK components
  -> Running bootstrapping script and adding additional components
Traceback (most recent call last):
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/install.py", line 12, in <module>
    import bootstrapping
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/bootstrapping.py", line 46, in <module>
    from googlecloudsdk.core.updater import update_manager
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/core/updater/update_manager.py", line 35, in <module>
    from googlecloudsdk.core import yaml
  File "/home/user/.cache/aurman/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/lib/googlecloudsdk/core/yaml.py", line 32, in <module>
    from ruamel import yaml
ImportError: cannot import name yaml
==> ERROR: A failure occurred in package().
    Aborting...

sudoforge commented on 2018-08-29 03:47 (UTC) (edited on 2018-08-29 03:59 (UTC) by sudoforge)

@allgaeuer.fabian This package has, as of my maintership, never bundled the app-engine-java component. You should read and follow the instructions in the currently pinned comment.

allgaeuer.fabian commented on 2018-08-23 09:48 (UTC)

@sudoforge Regarding your commit e01da1e449882ad8e4fe590b01cd09624b58143a: the Java environment requires installation of an additional component app-engine-java. Installing just the JDK or JRE is not sufficient.

sudoforge commented on 2018-08-21 22:09 (UTC) (edited on 2019-05-04 12:36 (UTC) by sudoforge)

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.

troyengel commented on 2018-07-13 23:20 (UTC)

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.

sudoforge commented on 2018-07-13 17:14 (UTC)

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

commented on 2018-07-13 10:00 (UTC)

update, please.

troyengel commented on 2018-06-16 18:01 (UTC)

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

sudoforge commented on 2018-06-02 03:07 (UTC) (edited on 2018-06-02 14:04 (UTC) by sudoforge)

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

troyengel commented on 2018-05-31 23:04 (UTC) (edited on 2018-05-31 23:07 (UTC) by troyengel)

@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 (UTC)

@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 (UTC) (edited on 2018-05-18 21:13 (UTC) by troyengel)

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

sudoforge commented on 2018-05-18 16:45 (UTC) (edited on 2018-05-18 18:38 (UTC) by sudoforge)

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

arbano commented on 2018-05-10 05:59 (UTC)

Thanks for the update!

arbano commented on 2018-05-10 03:46 (UTC)

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

sudoforge commented on 2018-05-08 20:49 (UTC) (edited on 2018-05-08 20:50 (UTC) by sudoforge)

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

oyvindsk commented on 2018-04-24 09:30 (UTC)

@troyengel I understand, and you should of course keep to your vision :) A minimal package is exactly what I want since I have to install additional components anyway. I'll keep using this and apply my "hack". Thanks!

troyengel commented on 2018-04-23 23:25 (UTC)

@oyvindsk - you may be looking for the "full" package which I think would facilitate your need, it's based off a different tarball and includes other components. I created this version specifically to be a minimal footprint of just the basics, it's not really intended (on purpose) to be used in the way you want. See: https://aur.archlinux.org/packages/google-cloud-sdk/

oyvindsk commented on 2018-04-23 09:21 (UTC)

If you try to install or update packages with 'gcloud components ..' you'll get a

"You cannot perform this action because this Cloud SDK installation is managed by an external package manager. Please consider using a separate installation of the Cloud SDK created through the default mechanism .." error.

I call bullshit on this :) You can "fix" it by setting: "disable_updater": false in /opt/google-cloud-sdk/lib/googlecloudsdk/core/config.json

Maybe consider setting this since it makes this package much more useful.

troyengel commented on 2018-04-05 00:04 (UTC)

@MaddyBoo - would be happy to help, however I don't use zsh so I started looking into this... and it's horribly complicated. I can't find any wiki (including Arch's), blog, or man pages which indicate how you install system wide completion files. Everything talks about "must be explicitly enabled from your shell", and refer to triggering it from ~/.zshrc and it's $FPATH. (even man zshcompsys(1) has no clue)

Can you provide another 3rd party package here in Arch which provides zsh completion files systemwide? I looked into the zsh package itself and zsh-completions package, they don't own a system directory (like /etc/zsh.completions.d/ or /etc/zsh/completions or whatnot), so it's just not clear what you do with this file (completion.zsh.inc) provided. Guidance and instructions needed. :)

b0o commented on 2018-04-04 06:26 (UTC)

The PKGBUILD seems to install the bash completions but not the zsh completions, can we get this fixed?

oxplot commented on 2018-02-14 03:24 (UTC)

@troyengel optional subpackage seems to be the ideal thing to do, but I'm not familiar with it and it'll take me sometime to get around to it. Meanwhile, I'll try to get patches in if someone else can work on it.

troyengel commented on 2018-02-04 15:15 (UTC)

The inclusion of google-appengine-go in release 186.0.0 has more than doubled the size of this entire package to over 500MB, it appears that there's a lot of go source getting bundled. Perhaps that can be culled manually.

==== Packages (1) google-cloud-sdk-186.0.0-1

Total Installed Size: 562.75 MiB Net Upgrade Size: 359.64 MiB ====

That was rather unexpected, perhaps the go engine should be an optional subpackage.

adangert commented on 2018-02-01 06:10 (UTC)

File "/usr/lib/python2.7/ssl.py", line 286, in match_hostname % (hostname, dnsnames[0])) ssl.CertificateError: hostname 'metadata.google.internal' doesn't match 'streaming.asonix.dog'

oxplot commented on 2017-11-09 22:54 (UTC)

@johnny12 you can safely ignore those warnings

johnny12 commented on 2017-11-09 13:01 (UTC)

A little over a week ago I installed google-cloud-sdk 177 from the AUR. Since then I upgraded twice to version 178 and now to 179. Both times I received the following warning: WARNING: There are older versions of Google Cloud Platform tools on your system PATH. Please remove the following to avoid accidentally invoking these old tools: /opt/google-cloud-sdk/bin/dev_appserver.py /opt/google-cloud-sdk/bin/gcloud /opt/google-cloud-sdk/bin/bq /opt/google-cloud-sdk/bin/java_dev_appserver.sh /opt/google-cloud-sdk/bin/git-credential-gcloud.sh /opt/google-cloud-sdk/bin/docker-credential-gcloud /opt/google-cloud-sdk/bin/gsutil /opt/google-cloud-sdk/bin/endpointscfg.py Is it desired to fix this warning and if so then how, by simply deleting the files mentioned there? Or should I just ignore this warning? The files listed are all the files in the bin/ directory. Apart from those files there is also a folder named "bootstrapping" that contains files that seem to be related to the files in the bin/ directory, should I also delete that folder (and thus empty the bin/ directory)? Thanks!

oxplot commented on 2017-09-30 09:39 (UTC)

@The_K thanks for the patch. Merged now.

oxplot commented on 2017-09-30 09:21 (UTC)

@Nowaker done

Nowaker commented on 2017-09-29 13:34 (UTC)

Would you please change the package description to include "gcloud" so it's easily discoverable? > Tools and libraries SDK for managing resources on the Google Cloud Platform (gcloud), plus Python/PHP appengine SDK components

the-k commented on 2017-09-14 20:34 (UTC)

I see beta component is not included. Why?

oxplot commented on 2017-07-13 01:24 (UTC)

@mzimmerman tried to reproduce it under a fresh docker image to no avail

bjorntj commented on 2017-07-12 06:31 (UTC)

Hmmm... Funny... Running Arch at work also with more or less the same configuration. When I ran the install there, it worked... What is different, what am I missing?

bjorntj commented on 2017-07-11 11:28 (UTC) (edited on 2017-07-11 11:28 (UTC) by bjorntj)

Trying to install this SDK but I get the following error: ==> Making package: google-cloud-sdk 161.0.0-1 (Tue Jul 11 13:24:18 CEST 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found google-cloud-sdk-161.0.0-linux-x86_64.tar.gz -> Found profile.sh ==> Validating source_x86_64 files with sha256sums... google-cloud-sdk-161.0.0-linux-x86_64.tar.gz ... Passed profile.sh ... Passed ==> Extracting sources... -> Extracting google-cloud-sdk-161.0.0-linux-x86_64.tar.gz with bsdtar ==> Starting prepare()... -> Checking for newer upstream release ==> Removing existing $pkgdir/ directory... ==> Entering fakeroot environment... ==> Starting package()... -> Copying core SDK components -> Running bootstrapping script and adding app-engine-python This will install all the core command line tools necessary for working with the Google Cloud Platform. ERROR: The component listing for Cloud SDK version [161.0.0] could not be found. Make sure this is a valid archived Cloud SDK version. ERROR: (gcloud.components.install) Failed to fetch component listing from server. Check your network settings and try again. ==> ERROR: A failure occurred in package(). Aborting...

mzimmerman commented on 2017-07-04 01:53 (UTC)

-> Running bootstrapping script and adding app-engine-python Traceback (most recent call last): File "/home/matt/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/install.py", line 8, in <module> import bootstrapping File "/home/matt/aur/google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/bootstrapping.py", line 17, in <module> import oauth2client.contrib.gce as gce ImportError: No module named contrib.gce ==> ERROR: A failure occurred in package(). Aborting... seems to be an error with oauth2client, however I did the recommended install? https://github.com/GoogleCloudPlatform/gsutil/issues/330

codepilot commented on 2017-07-03 12:29 (UTC) (edited on 2017-07-03 12:31 (UTC) by codepilot)

@troyengel: Thank you for all efforts and patches you made, and sorry that I didn't recognize it yet and did not answer. I found out that it works very fine with the latest updates, since you did the patch. Anyway, and just for completeness, after a full system upgrade, calling 'from _ssl import RAND_egd' from within python2 fails.

demize commented on 2017-06-27 18:20 (UTC)

Much appreciated.

oxplot commented on 2017-06-22 01:12 (UTC)

@kyrias I removed kubectl bin for now until I get around to splitting off all the other components as well.

troyengel commented on 2017-06-21 19:52 (UTC)

I have disowned this package. 160.0.0 is released for whomever picks it up next.

demize commented on 2017-06-21 13:26 (UTC)

kubectl does not belong in this package since it means that people that use the rest of the kubernetes tools, which is where the tool comes from, cannot install this package. If you want to package it as well, please move it to a split package so that people don't have to choose between the kubernetes package and the google-cloud-sdk, and then have a conflict for the kubernetes package in that one.

oxplot commented on 2017-06-06 05:38 (UTC)

Can we also add the beta commands: diff --git a/PKGBUILD b/PKGBUILD index d407e69..b28af94 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -59,11 +59,11 @@ package() { # kubectl is not in the tarball, add it to the package bootstrap # app-engine-python is actually the PHP+Python SDK widgets combined # NOTE: due to how Google is using argparse we must bare word the components - msg2 "Running bootstrapping script and adding kubectl, app-engine-python" + msg2 "Running bootstrapping script and adding kubectl, app-engine-python, beta" python2 "$pkgdir/opt/$pkgname/bin/bootstrapping/install.py" \ --usage-reporting false --path-update false --bash-completion false \ --rc-path="$srcdir/fake.bashrc" \ - --additional-components kubectl app-engine-python + --additional-components kubectl app-engine-python beta # https://issuetracker.google.com/issues/35900282 msg2 "Fixing appengine bug #35900282 (RAND_egd)" Things like cloud functions are under beta.

troyengel commented on 2017-05-24 23:25 (UTC)

@codepilot - with the 156.0.0 release today, I added in a sed to fix that bug. It doesn't appear upstream is going to fix it anytime soon, it's been open for a year with no results. https://aur.archlinux.org/cgit/aur.git/commit/?h=google-cloud-sdk&id=8653641569769865a10efb100f86cfc301b80942 See how this works out. I wrote the sed to be pretty specific to protect against an unexpected upstream change later.

troyengel commented on 2017-05-12 13:59 (UTC)

OK here we go - everyone please use your voting powers for good on this upstream issue so we can get their eyes on it: https://issuetracker.google.com/issues/38256907

troyengel commented on 2017-05-12 13:45 (UTC) (edited on 2017-05-12 14:10 (UTC) by troyengel)

(edit @codepilot not @Ekaradon sorry!) - have the morning off, had a look; this is actually a bug in Google Cloud SDK. I've never filed a bug with them, I'll see what's involved. Have a look here: https://github.com/openssl/openssl/blob/master/CHANGES Changes between 1.0.2h and 1.1.0 [25 Aug 2016] *) EGD is no longer supported by default; use enable-egd when configuring. We (Arch) do not explicitly pass --enable-egd when compiling OpenSSL (https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/openssl) so the interfaces (ergo, RAND_egd) are not available. The official python2 ssl.py has this properly handled (per my snippet below) but Google is not accounting for this change. I'm able to reproduce this by yanking out some of their code into a standalone file, time to find their bug tracker...

Ekaradon commented on 2017-05-11 13:07 (UTC)

@troyengel: here is my output from typing the command: ``` {15:02}~/aur/google-cloud-sdk:master ✗ ➭ python2 -c 'import sys; print(sys.path)' ['', '/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/gtk-2.0'] ``` It looks fine for me. I tried again today (154.0.1) but the error is still there. I may have to reinstall python2...

troyengel commented on 2017-04-27 11:57 (UTC)

@codepilot - openssl recently upgraded in Arch, many packages have to be rebuilt - did your python2 and all it's components upgrade? Check your pacman.log and see, that might be it. It looks like the SDK is calling a SSL export and it fails; I notice this in the official python2 ssl.py that imports the same thing: try: from _ssl import RAND_egd except ImportError: # LibreSSL does not provide RAND_egd pass Not a real answer for you, but maybe a clue... I just pushed the new 153.0.0 SDK but the release notes don't make mention of this.

codepilot commented on 2017-04-27 09:17 (UTC)

Hello! Since yesterday, I'm getting this error when trying to run dev_appserver.py as usual. --- INFO 2017-04-27 09:07:10,977 sdk_update_checker.py:231] Checking for updates to the SDK. INFO 2017-04-27 09:07:11,533 api_server.py:272] Starting API server at: http://localhost:32965 INFO 2017-04-27 09:07:11,551 dispatcher.py:205] Starting module "default" running at: http://localhost:8080 INFO 2017-04-27 09:07:11,551 admin_server.py:116] Starting admin server at: http://localhost:8000 Traceback (most recent call last): File "/opt/google-cloud-sdk/platform/google_appengine/_python_runtime.py", line 103, in <module> _run_file(__file__, globals()) File "/opt/google-cloud-sdk/platform/google_appengine/_python_runtime.py", line 97, in _run_file execfile(_PATHS.script_file(script_name), globals_) File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/runtime.py", line 185, in <module> main() File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/runtime.py", line 165, in main sandbox.enable_sandbox(config) File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 204, in enable_sandbox from google.appengine.runtime import runtime File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/runtime/runtime.py", line 40, in <module> from google.appengine.runtime import cgi File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/runtime/cgi.py", line 32, in <module> from email import feedparser File "/usr/lib/python2.7/email/feedparser.py", line 27, in <module> from email import message File "/usr/lib/python2.7/email/message.py", line 16, in <module> import email.charset File "/usr/lib/python2.7/email/charset.py", line 13, in <module> import email.base64mime File "/usr/lib/python2.7/email/base64mime.py", line 40, in <module> from email.utils import fix_eols File "/usr/lib/python2.7/email/utils.py", line 28, in <module> import socket File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 842, in load_module return self.import_stub_module(fullname) File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 854, in import_stub_module __import__(fullname, {}, {}) File "/opt/google-cloud-sdk/platform/google_appengine/google/appengine/dist27/socket.py", line 73, in <module> from _ssl import RAND_add, RAND_egd, RAND_status, SSL_ERROR_ZERO_RETURN, SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE, SSL_ERROR_WANT_X509_LOOKUP, SSL_ERROR_SYSCALL, SSL_ERROR_SSL, SSL_ERROR_WANT_CONNECT, SSL_ERROR_EOF, SSL_ERROR_INVALID_ERROR_CODE ImportError: cannot import name RAND_egd --- My solution for this right now is to remove RAND_egd from /opt/google-cloud-sdk/platform/google_appengine/google/appengine/dist27/socket.py.

troyengel commented on 2017-04-24 14:39 (UTC)

Trying something new; Google doesn't have an Atom feed, but I worked with Igor @ https://feed43.com to sort out a way to turn our sha256.txt into an RSS-like feed to monitor: https://feed43.com/google-cloud-sdk-release.xml Let's see how it goes when 153.0.0 is released, I set up IFTTT to watch it and email me on change.

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

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

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

troyengel 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!

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.

vgivanovic commented on 2016-12-18 17:26 (UTC) (edited on 2016-12-19 04:13 (UTC) by vgivanovic)

ERROR: The component listing for Cloud SDK version [137.0.1] could not be found. Make sure this is a valid archived Cloud SDK version. ERROR: (gcloud.components.install) Failed to fetch component listing from server. Check your network settings and try again. This error started with 137.0.0. I am using `fish' if that makes a difference. Installation by hand works. I just did `gcloud components update' successfully.

rdoursenaud commented on 2016-11-16 06:54 (UTC)

@troyengel Thanks! I've been using your package for Google App Engine developments for a while now and it's working perfectly.

troyengel commented on 2016-10-16 14:55 (UTC) (edited on 2016-10-16 14:57 (UTC) by troyengel)

130.0.0 integrates all the below, quick link of changes: https://aur.archlinux.org/cgit/aur.git/commit/?h=google-cloud-sdk&id=edf70e9b24eff06ff59b93bbe9410fe9a43cb513 edit: just noticed I misspelled 'due' in one of my comments, will fix next release

troyengel commented on 2016-10-11 14:08 (UTC)

@rdoursenaud - this seems workable, since I don't live this SDK code can you expand upon what "add the app-engine-python component" entails? is it similar to how we're bootstrapping the kubectl component? ( https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-cloud-sdk#n54 ) Adding the replaces/obsoletes and /usr/bin/ links is a no-brainer, just delete the lines in the PKGBUILD that are actually deleting them I put there because of our conflicts in the first place. :)

rdoursenaud commented on 2016-10-10 14:51 (UTC)

Hi @troyengel, maintainer of google-appengine-python-php here. Looking at https://cloud.google.com/appengine/docs/php/download and https://cloud.google.com/appengine/docs/python/download it seems that the Google Cloud SDK is now superseding the Google App Engine SDK. I thus plan on dropping the package. To ensure a smooth transition, your package must provide the appengine related tools. Could you please add a replaces=('google-appengine-python-php' 'google-appengine- python' 'google-appengine-php'), install '/usr/bin/dev_appserver.py' and '/usr/bin/endpointscfg.py and add the app-engine-python component? Or should we try another approach to provide component level packages, maybe?

troyengel commented on 2016-10-08 18:21 (UTC)

I don't see any harm in this and it's trivial because we're already installing a profile.sh - there's very little google-fu hits when you look for GOOGLE_CLOUD_SDK_HOME so I think it's just something people started doing. I'll put in on my checklist for the next release (130.0.0).

velovix commented on 2016-10-08 01:28 (UTC)

It would be very helpful if this package set the GOOGLE_CLOUD_SDK_HOME environment variable or did something else to allow App Engine plugins to detect where the Cloud SDK home is. The Gradle plugin, for example, is unable to find the SDK on its own. Here is the mechanism plugins use to find the SDK: https://github.com/GoogleCloudPlatform/appengine-plugins-core/blob/75255413b2f92ebe841238241ff40014bc2be0e3/src/main/java/com/google/cloud/tools/appengine/cloudsdk/PathResolver.java#L35

troyengel commented on 2016-09-07 14:54 (UTC)

I will add a conflict once I get back to my build machine -- what that other package is doing is their concern, I am *intentionally* adding kubectl during the build process to this SDK package to avoid having yet another package for no reason, this utility belongs with this SDK. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-cloud-sdk#n53 This package has been around a lot longer than the kubectl-bin, those packagers should be advised to also set a reverse conflict with google-cloud-sdk.

tkral commented on 2016-09-06 17:26 (UTC)

Hi, can you please add conflict with kubectl-bin package? Or even better instead of installing kubectl, just add this package as dependency. Otherwise you get this: error: failed to commit transaction (conflicting files) google-cloud-sdk: /usr/bin/kubectl exists in filesystem Errors occurred, no packages were upgraded.

troyengel commented on 2016-09-04 14:18 (UTC)

The symlink has been removed (it's listed in the RELEASE_NOTES for 124.0.0 as a new addition) for /usr/bin/endpointscfg.py to prevent conflict, and python2-crcmod has been added as an optdep. Release 124.0.0-2 pushed.

ishitatsuyuki commented on 2016-09-04 07:15 (UTC)

Seems a new conflict is here: google-cloud-sdk: /usr/bin/endpointscfg.py exists in filesystem /usr/bin/endpointscfg.py is owned by google-appengine-python-php 1.9.40-1

JP-Ellis commented on 2016-09-04 05:08 (UTC)

You should list `python2-crcmod` as an optional dependency since `gsutil` will make use of it. You can see that at https://cloud.google.com/storage/docs/gsutil/addlhelp/CRC32CandInstallingcrcmod

troyengel commented on 2016-02-26 23:58 (UTC)

They've fixed the bootstrapping error in 98.0.0 as promised, the code looks rather different now. I backed out our fix with this release of 98.0.0-1 package.

troyengel commented on 2016-02-17 00:59 (UTC)

Thanks for the heads up - I've pushed a new 96.0.0-2 PKGBUILD with this sed in it.

rdoursenaud commented on 2016-02-16 08:46 (UTC)

Since latest update, I get the following error: Traceback (most recent call last): File "/tmp/aur-google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/install.py", line 8, in <module> import bootstrapping File "/tmp/aur-google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/bootstrapping.py", line 9, in <module> import setup File "/tmp/aur-google-cloud-sdk/pkg/google-cloud-sdk/opt/google-cloud-sdk/bin/bootstrapping/setup.py", line 41, in <module> reload(google) ImportError: No module named google There's an issue opened upstream with a workaround: https://code.google.com/p/google-cloud-sdk/issues/detail?id=538 To apply it to the PKGBUILD, add this at the end of the prepare() section: cd "${srcdir}/${pkgname}" sed -i "s/'google' in sys.modules/False/" bin/bootstrapping/setup.py

troyengel commented on 2016-01-17 13:57 (UTC)

Thanks, fixed up that word boundary in sed. Did a quick grep of the bin/ directory and it looks like everything's solid again.

FrozenCow commented on 2016-01-17 13:13 (UTC)

google-cloud-sdk already contains `CLOUDSDK_PYTHON=python2`. The current PKGBUILD results in `CLOUDSDK_PYTHON=python22`. I fixed this by changing the line: sed -i 's/CLOUDSDK_PYTHON=python/CLOUDSDK_PYTHON=python2/g' {} \; to: sed -i 's/CLOUDSDK_PYTHON=python\b/CLOUDSDK_PYTHON=python2/g' {} \;

vendion commented on 2015-12-17 11:52 (UTC)

@troyengel: Ah okay I wasn't aware that it checked if CLOUDSDK_PYTHON is set or not, I didn't logout and back in after installing so /etc/profile.d/google-cloud-sdk.sh was never sourced.

justin8 commented on 2015-12-17 02:08 (UTC)

The only exception to that I've encountered was OS X (not linux, but still). And the brew installed python adds it anyway. Alternatively you can export CLOUDSDK_PYTHON=python2 and then gcloud/gsutil/bq/etc will use the right pythong without modifications. but it's a bit stupid that they don't just default to python2 and fallback to python.

troyengel commented on 2015-12-17 01:03 (UTC)

@tuxfusion - you've broken your python2 install. The symlink is created as part of the package: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python2#n95 $ pacman -Qo /usr/bin/python2 /usr/bin/python2 is owned by python2 2.7.11-1 The use of a python2 link is used across all distributions (I had to do something for work that confirmed this - RHEL/CentOS 5, 6, 7, Debian, Ubuntu, etc.) so it's an expected configuration to be on almost every Linux out there besides Arch. (just FYI)

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.

oryband commented on 2015-11-06 10:24 (UTC)

Isn't there a way to bypass the md5 validity check from failing everyone update? this happens too often

mafn commented on 2015-11-01 11:37 (UTC) (edited on 2015-11-01 12:00 (UTC) by mafn)

I'm getting this as well while running `gcloud components update app`: > ERROR: (gcloud) The update action could not be performed because the installation root of the Cloud SDK could not be located. Please re-install the Cloud SDK and try again. Double checked, and `CLOUDSDK_ROOT_DIR` evaluates to '/opt/google-cloud-sdk' and '/opt/google-cloud-sdk/bin' is in my PATH.

jenglisch commented on 2015-10-01 13:43 (UTC)

0.9.80 is latest, md5sum f8a2fabb13e9bd02c7f8b34eb7a4c908

gideonite commented on 2015-08-23 16:43 (UTC)

@ac4r_g0 Running `gcloud alpha genomics variants` gives me the error: ERROR: (gcloud) The update action could not be performed because the installation root of the Cloud SDK could not be located. Please re-install the Cloud SDK and try again. I tried re-installing and re-authenticating but no dice.

gideonite commented on 2015-08-23 16:40 (UTC)

@troyengel Unfortunately, I think it will be difficult to properly create a bdutil package. The user is required to manually modify a script called `bdutil_env.sh` will Google specific project and bucketids. Since bdutil comes with a binary, it's probably not worth creating a package until this type of manual configuration is no longer required (if ever).

troyengel commented on 2015-08-22 01:24 (UTC)

@gideeonite - you are correct, it's a separate download for some reason so you'd make a new package for it. In that PKGBUILD you'd set a requires() of this package to satisfy the install dependencies. https://storage.googleapis.com/hadoop-tools/bdutil/bdutil-latest.tar.gz

gideonite commented on 2015-08-21 19:54 (UTC)

From what I gather bdutil is not included in the Google Cloud SDK. Not sure what the reason for this is. Does it warrant creating a new package? More info here: https://cloud.google.com/hadoop/bdutil.

troyengel commented on 2015-08-21 00:36 (UTC)

FYI: the 0.9.74 update has removed all the help/man files, which means all the man pages in 0.9.73 and before will disappear with this upgrade. There's no mention of this on their website or the RELEASE_NOTES, so I just commented out the PKGBUILD commands for now. It's possible this is a mistake when someone at Google made the new tarball as it seems rather odd - there are over 400 man pages in the older tarball.

ac4r_g0 commented on 2015-08-20 11:58 (UTC)

New release 0.9.74. 0.9.74 (2015/08/19) ================== - new list and import commands under `gcloud alpha genomics variants`.

troyengel commented on 2015-08-14 01:07 (UTC)

@oryband - read all the other comments, it was a new release. You must look at RELEASE_NOTES to know if it's a new version of the tarball. I've updated the PKGBUILD.

oryband commented on 2015-08-12 08:21 (UTC)

still experiencing failed validity checks, please update for now i've been able to install with yaourt by using: yaourt --m-arg "--skipchecksums" google-cloud-sdk that skipchecksums is a makepkg argument that tells makepkg to ignore the checksum :)

troyengel commented on 2015-07-31 12:42 (UTC)

@ogarcia - flagging the package out of date is good enough. Google uses the same download filename on their website, so new versions will of course produce bad checksums -- you have to look at the RELEASE_NOTES inside the tarball to see if it's a new version.

ogarcia commented on 2015-07-31 11:39 (UTC)

Bad md5sum. The good one: fa47d4f428639f164df9c82210e9cf9e google-cloud-sdk.tar.gz

troyengel commented on 2015-07-29 01:06 (UTC)

I just noticed AUR4 has a feature for Co-Maintainers -- if anyone would like to help co-maintain this package just let me know.

rdoursenaud commented on 2015-06-01 12:11 (UTC)

It seems to me that 0.9.62 have been sneaked out since pkgver() returns 0.9.61. Confirmed by the RELEASE_NOTES of a freshly downloaded tarball.

ascii_ch commented on 2015-05-30 10:55 (UTC)

MD5 seems to be wrong. Current MD5 of google-cloud-sdk.tar.gz is 2be73620f53570ea0aeaa2c72dda1692.

meshelton commented on 2015-04-06 21:39 (UTC)

Getting this error after installing $ gcloud components list ERROR: (gcloud.components.list) The update action could not be performed because the installation root of the Cloud SDK could not be located. Please re-install the Cloud SDK and try again.

itwenty commented on 2015-04-03 06:58 (UTC)

Latest version is 0.9.52. Building this fails due to md5 checksum mismatch

confusedfla commented on 2015-02-02 22:54 (UTC)

Hi, I got some troubles with the components lists. It told me that it can't find my installation, as a quick fix I manually patched this line lib/googlecloudsdk/core/config:358 ``` p = file_utils.FindDirectoryContaining(os.path.dirname(__file__), Paths.CLOUDSDK_STATE_DIR) ``` with ``` return os.path.join(self.global_config_dir, ".install") ``` this implies that you have run "mkdir ~/.config/gcloud/.install" before. How did you deal with the installation problem?

giniu commented on 2014-12-10 08:36 (UTC)

where do you found it is 0.9.37? Seems that latest is 0.9.40 now. At least that is the version defined in the sources.

jimenezrick commented on 2014-12-10 00:00 (UTC)

It seems to be a release/checksum mismatch, the latest one now is: 0.9.37 (2014/11/19)

zanegrey commented on 2014-09-21 21:55 (UTC)

Updated md5sums and incorporated changes below: https://github.com/muff1nman/archlinux-packages/tree/master/google-cloud-sdk

zanegrey commented on 2014-09-21 20:31 (UTC)

Out of date. @giniu's script reports the version at 0.9.32

justin8 commented on 2014-08-02 03:07 (UTC)

Can you please make this not include the appengine files. it makes it go from 21MB up to almost 200, not to mention it is already providing files that are in the google-appengine-* packages that have been around for years. Please also fix up: - Your broken python sed that just replacings things everywhere and has already been mentioned. something like this would do only the changes you actually want: grep -rl 'python' "$pkgdir/opt/$pkgname" | xargs sed -i 's|#!.*python\b|#!/usr/bin/env python2|g' find "$pkgdir/opt/google-cloud-sdk/bin/" -type f -maxdepth 1 -exec sed -i 's/CLOUDSDK_PYTHON=python/CLOUDSDK_PYTHON=python2/g' {} \; - Symlink the binaries so that they are actually on the path and usable; unless you remove the appengine parts from this you will inadvertently create conflicts with the appengine packages. This will do it for you: mkdir -p "$pkgdir/usr/bin" find "$pkgdir/opt/$pkgname/bin" -type f -maxdepth 1 -printf "/opt/$pkgname/bin/%f\n" | xargs ln -st "$pkgdir/usr/bin" Or just upload this pkgbuild that does it already: http://storage.googleapis.com/justin8-files/public/google-cloud-sdk-PKGBUILD The only namcap warnings from that package are somewhat ignorable now. If you remove the appengine dependencies you can change it to an any package instead of x86-64/i686, and there are 4 empty directories, but there is a chance that the oauth2-boto plugin needs those; I haven't used it before.

commented on 2014-07-03 21:46 (UTC)

Instead of using sed to modify the source you can use: export CLOUDSDK_PYTHON=/usr/bin/python2

giniu commented on 2014-06-23 20:04 (UTC)

Btw, you can use this: curl -s https://dl.google.com/dl/cloudsdk/release/google-cloud-sdk.tar.gz | tar -zxO google-cloud-sdk/lib/googlecloudsdk/core/config.json | grep '"version"' | sed "s/.*:.*\"\(.*\)\".*/\1/" to check current version

giniu commented on 2014-06-23 19:56 (UTC)

Seems it only happened once, it is 0.9.27 now (version number is in RELEASE_NOTES and in file lib/googlecloudsdk/core/config.json)

numkem commented on 2014-06-23 19:13 (UTC)

Seems like the downloaded archive gets changed quite often while the filename or version doesn't. I don't really know how we could keep up with their changes.

numkem commented on 2014-06-16 13:45 (UTC)

OK! This should be a pretty good version. I was using namcap before but I didn't really understand why it was complaining. With your explanations and some digging and fixed most problems.

giniu commented on 2014-06-14 14:11 (UTC)

Better with every version - though there are still some comments... sorry for that, I just want to help you get it right :) In short, use namcap - https://wiki.archlinux.org/index.php/namcap - architecture of this package isn't "any", there are different libraries installed for 32 and 64 bits (look at stuff listed during install on stdout) - you miss "!strip" option, it causes lots of errors during compilation like: "strip: ...: Unable to recognise the format of file" - this is common issue related to how "go" works - most go related packages in repos have this: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/liteide#n18 - consider downloading tar.gz instead of .zip - google provides both, but tar and gzip are in base, while unzip is not - also, if you switch you might not need to change permissions anymore (guess) - when downloading, consider changing the name of stored file to include version number (see my example with double :: in name, that's how you change name) - it will help build automation scripts (if someone uses those) to get correct sources - add maintainer tag so your name will be in it: [giniu@raven3 google-cloud-sdk]$ namcap PKGBUILD PKGBUILD (google-cloud-sdk) W: Missing Maintainer tag - some other issues found with namcap: 1) your script to rename python into python2 does other things, there is no such thing as python22.5, probably it was legacy script for python2.5 google-cloud-sdk W: Referenced library 'python22.5' is an uninstalled dependency google-cloud-sdk W: Referenced library 'python22.4' is an uninstalled dependency 2) and in other place it looks like it is cutting something out google-cloud-sdk W: Referenced library 'bin' is an uninstalled dependency 3) there are empty directories and no correct flag package options: google-cloud-sdk W: Directory (opt/google-cloud-sdk/platform/gsutil/third_party/gcs-oauth2-boto-plugin/third_party/retry-decorator) is empty 4) still LOT more files miss correct python version - you actually need to change python3 to python after changing python to python2, as it seems, and maybe add python as optional dependency. It needs looking into after you deal with python->python2 rename. google-cloud-sdk E: Dependency python detected and not included (programs ['python', 'python3'] needed in scripts ['opt/google-cloud-sdk/platform/google_appengine/google/net/proto2/pytho n/public/reflection.py', 'opt/google-cloud-sdk/platform/google_appengine/google/appengine/ext/mapreduce/api/map_job/datastore_input_reader.py', 'opt/google-cloud-sdk/platform/google_appe ngine/google/appengine/cron/GrocParser.py', 'opt/google-cloud-sdk/platform/google_appengine/google/appengine/ext/db/djangoforms.py', 'opt/google-cloud-sdk/platform/gsutil/third_party/bot o/boto/services/bs.py', 'opt/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/__init__.py', ........

numkem commented on 2014-06-12 13:04 (UTC)

I've made changes related to your comment. I've also used the new method of using mkaurball instead of makepkg -S

giniu commented on 2014-06-12 06:46 (UTC)

Hi, now it looks little better, but still some comments: - you are using unquoted $pkgdir and $srcdir - if someone builds in dir with spaces, things can go wrong. Use "$pkgdir" and "$srcdir" instead. - by using $pkgdir/opt/google-cloud-sdk/install.sh you are using "python" as interpreter - this script does nothing more than selecting python and running it with correct path, that's why in my example there was python2 instead of install.sh. If you want to use install.sh you should patch it or set environment variables to select python2 instead of python - not everywhere /usr/bin/env python is used, sometimes it is /usr/bin/python - you need to change those as well - not all python scripts have .py extension, you need to look for /usr/bin/python and /usr/bin/env python inside them as well - You have "--path-update true --bash-completion true" while those could be false, then this fake bashrc file will not be created - You don't have to "mkdir -p $pkgdir/etc/profile.d/" if you use -D in install command, it will create directories Keep up good work, I will review this package again after more changes. As as I said, try to run: namcap PKGBUILD namcap (resulting file) it will give you a lot of useful information.

numkem commented on 2014-06-11 14:04 (UTC)

I'm good with that. Need to use it for some project I'm looking into. Still fighting with zsh/bash completions and paths but I'm making progress. Thanks.

barnybug commented on 2014-06-11 13:46 (UTC)

Hey, I could hand the package over to one of you, this was just a first attempt, and sounds like it'd be in better hands..

numkem commented on 2014-06-11 13:35 (UTC)

I believe I've fixed most issues: http://pastebin.com/RyQ2bBVM

giniu commented on 2014-06-11 13:01 (UTC)

Hello, I plan to move this package to community as last optional dependency of python-pandas, but this needs some clean-up and testing before I can make the move. I have some comments: - you install SDK so number should match SDK version number, not gcutil version number (the SDK is numbered 0.9.26). - you depend on python2 but use python everywhere, interpreter needs to be changed in libraries and correct environment variable needs to be set - you modify .bashrc in home directory of someone who builds this package, not installs it - correct way is to place scripts in /etc/profile.d and /etc/bash_completion.d - you don't have to create symlinks to binaries, if path will be set correctly - man pages are installed in wrong place - file ownership of some files is wrong This is a long list, but I've prepared for you a version of this package that has some of it fixed (not all): - http://pastebin.com/HA2DWvsK (PKGBUILD) - http://pastebin.com/0SmxF4kA (profile.sh) Try downloading this version and building, then use "namcap" command on resulting package to see list of remaining issues. You won't be able to fix those .jar issues, because namcap does not see virtual dependency (java-environment, which can point to many versions of java JDK), but it should be enough as a hint of how to proceed. Will you be able to update this? Cheers, Andrzej.