Package Details: google-earth-pro 7.3.6.10201-2

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: LicenseRef-Google-custom
Provides: google-earth
Submitter: Det
Maintainer: iyanmv
Last Packager: iyanmv
Votes: 1081
Popularity: 2.50
First Submitted: 2017-01-23 16:08 (UTC)
Last Updated: 2025-05-06 10:32 (UTC)

Pinned Comments

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 .. 41 42 43 44 45 46 47 48 49 50 51 .. 106 Next › Last »

Det commented on 2013-03-11 12:06 (UTC)

Saw it, responded to it, will do so again. The problem is that it's a _Git_ version. If this was just a bad commit it'd be stupid to actually do something about it. I like it the way it is and unless you can _prove_ through an actual released version that I need to have 'em: I won't. As a matter of fact, rc1 was just tagged and I see no indication of deprecating variables that aren't separated from the surrounding text with curly brackets: https://mailman.archlinux.org/pipermail/pacman-dev/2013-March/016750.html. The commit "makepkg: fix incorrect bracket usage" is something totally different: http://gitorious.org/pacman/mainline/commit/2abe1f16461133c0dc386f8ecb8b06865c22940b.

Det commented on 2013-03-09 09:48 (UTC)

I'm just messing with you :D. Of course it's the better way. I updated google-earth6 as well.

Det commented on 2013-03-08 18:11 (UTC)

There is a downside with automatic installations but I'm just trying to think this through here. I will let you know when I have something.

Scimmia commented on 2013-03-08 17:52 (UTC)

Why? There's no down sides. That is the correct way of doing it if the program needs libgl. You really think it's better to leave out a required dep entirely?

Det commented on 2013-03-08 17:50 (UTC)

I just said that and I don't have any plans on doing it here.

Scimmia commented on 2013-03-08 16:25 (UTC)

The best way is to include the virtual deps "libgl" and "lib32-libgl", which will prompt the user to pick one if they don't have any installed. Even if it's from the AUR, anything that actually provides libgl should have it in the "provides" array, which would satisfy the dep if it's already installed.

Det commented on 2013-03-08 12:47 (UTC)

Oh hey oliv, you're alive. Mind updating 'vmware-patch', by any chance?: https://aur.archlinux.org/packages/vmware-patch/ Anyway, the thing is that, first of all including '(lib32-)mesa-libgl' in the dependencies would mean that everybody would have to install it, even if they already had a proprietary driver (meaning nvidia or catalyst), second, even if I was to include '(lib32-)libgl', provided by (lib32-)nvidia-/catalyst-utils, and let the user choose between the 3, there's still the issue of people wanting to use one from the AUR. This is why it's easier to just include all in the optdepends=() and let the user decide what he wants to do.

oliv commented on 2013-03-08 10:27 (UTC)

There seems to be a missing dependency for 64 bits systems: lib32-mesa-libgl

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 106 Next › Last »