Arch Linux User Repository

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

Cheers

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.

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

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

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

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.

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

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?

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.

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.