Package Details: google-earth-pro 7.3.6.9796-1

Git Clone URL: https://aur.archlinux.org/google-earth-pro.git (read-only, click to copy)
Package Base: google-earth-pro
Description: 3D interface to explore the globe, terrain, streets, buildings and other planets (Pro version)
Upstream URL: https://www.google.com/earth/
Licenses: custom
Provides: google-earth
Submitter: Det
Maintainer: iyanmv
Last Packager: iyanmv
Votes: 1077
Popularity: 0.64
First Submitted: 2017-01-23 16:08 (UTC)
Last Updated: 2024-02-27 14:45 (UTC)

Pinned Comments

iyanmv commented on 2022-12-13 22:54 (UTC)

I will not update (for now) to the latest version 7.3.6.9326 because it crashes continuously for me.

stronnag commented on 2022-06-18 17:03 (UTC)

Thanks, unfortunate timing then.

For reference, with Gnome shell / wayland I need to

unset QT_QPA_PLATFORMTHEME
unset QT_QPA_PLATFORM

to avoid 

Google Earth has caught signal 6.

Det commented on 2017-08-24 15:33 (UTC) (edited on 2017-12-05 16:17 (UTC) by Det)

✔ NOTE The "Free" Google Earth has been dropped: https://support.google.com/earth/answer/168344?hl=en

All future updates go to Google Earth Pro (also free): https://aur.archlinux.org/packages/google-earth-pro/

Latest Comments

« First ‹ Previous 1 .. 21 22 23 24 25 26 27 28 29 30 31 .. 105 Next › Last »

agapito commented on 2014-01-13 02:38 (UTC)

Using radeonsi driver (HD7950) google earth was totally frozen my computer. With xf86-video-ati-git from aur, google-earth works perfect now.

Det commented on 2014-01-08 20:20 (UTC)

@darkshines, we know. It's even in the Wiki: https://wiki.archlinux.org/index.php/Google_Earth#Earth_shows_a_blue_marble_with_yellow_borders

darkshines commented on 2014-01-08 19:48 (UTC)

If anyone encounters a bug where there is no land, just a blue marble and black land when you zoom in, disable texture compression in the preferences.

zottelef commented on 2013-12-30 14:47 (UTC)

google-earth crashes with noveau driver 1.0.10-2 and xorg 1.15.0-2 on linux kernel 3.12.6-1. Architecture x86_64 1230/154828:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses() [1230/154828:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. [1230/154828:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. ... Another crash happened while handling crash!

hutou commented on 2013-12-15 21:34 (UTC)

I tried your suggestion and compilation was Ok, so second assignment was correctly done. Then I move the "if [ "$CARCH" ... fi" block to just before the "options=('!emptydirs')" line and compilation was Ok again. Then I successively moved this block down one line and finally found the line which caused the bug to appear : it was line 30, beginning with "[ "$CARCH" = 'x86_64' ]". After several tests, I can conclude now that aura does not correctly interpret the old [ ... ] construct, nor the [ ... ] && [ ... ] foo="bar" trick. Replacing all [ ... = ... ] with [[ ... == ... ]] and putting an if/fi around lines 30 and 37 solve the aura's problem.

Det commented on 2013-12-14 22:47 (UTC)

It seems like Aura's parser somehow halts on the first encounter of the dependencies, instead of reading all the way through. If you do what you did, but then remove the if/else/fi condition altogether, do you still get the correct dependencies? Also, as mentioned, the ld-lsb/any thing was never an Aura issue. I was simply explaining to you why both Pacman and Yaourt were trying to install 'lib32-glibc'. It's listed as a dependency for both architectures assumably because the package is defined as 'any' and therefore built only on a 64-bit system.

hutou commented on 2013-12-14 22:22 (UTC)

I tried the --hotedit to edit PKGBUILD on the fly. I first removed the [ "$_bin32" != '1' ] statement, but no luck. I then moved the "depends" and "optdepends" first assignments to an else statement in the "if [ "$CARCH" = 'i686' ]..." statement and bingo, aura compile is Ok. Very strange ! As for ld-lsb, even if arch=('any') is a bad idea, the 'depends' variable should remain empty if $CARCH is not equal to "x86_64" and this time, aura behaviour is just correct !

Det commented on 2013-12-14 21:40 (UTC)

Well, actually they both (i686 and x86_64 versions) list "lib32-glibc" as a dependency. It's a mistake in the PKGBUILD to define the package as 'any'. Anyway, could you test what I mentioned?

hutou commented on 2013-12-14 21:34 (UTC)

What is very strange, is that the ld-lsb PKGBUILD files are indentical in both repositories Archlinuxfr and AUR. and when ArlinuxFr repository is defined "pacman -S" and "yaourt -S" complain about lib32-glibc dependency while "aura -A" just compiles without any warning.

Det commented on 2013-12-14 21:10 (UTC)

Mmh. It could be with the "[ "$_bin32" != '1' ]" statements or just Aura trying to fetch the first list of dependencies it can find. The latter's a little unlikely considering Aura's age and the number of votes it's got (https://aur.archlinux.org/packages/aura/). Anyway, could you try it out by first removing the "[ "$_bin32" != '1' ]" checks with the "--hotedit" flag?

« First ‹ Previous 1 .. 21 22 23 24 25 26 27 28 29 30 31 .. 105 Next › Last »