1. Google Earth Version: google-earth-stable-7.0.2.8415-0.x86_64

2. Operating System: Fedora 18

3. Summary of issue (including error messages): GE can not be installed due to conflict:

Transaction Check Error: file /usr/bin from install of google-earth-stable-7.0.2.8415-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64

4. Links to other posts about this issue (please don't repost bugs): https://bugzilla.redhat.com/show_bug.cgi?id=870655

5. Reproduction Steps: Download 64-bit rpm from GE website. Install with yum localinstall google-earth-stable_current_x86_64.rpm

6. What is the expected output or behavior? What do you see instead? GE installs. Instead the mentioned conflict is displayed.

7. Workaround (if you've found one) Installing with rpm -U --force

I have the same exact problem installing Google Earth on Fedora 18-64bit system.

Another reporting the same issue with Fedora 18 64-bit.

Same issue here with Fedora 18-64bit

Same issue with Fedora 18 32bit

Transaction Check Error: file /usr/bin from install of google-earth-stable-7.0.2.8415-0.i386 conflicts with file from package filesystem-3.1-2.fc18.i686

Same here, Fedora 18 64-bit

file /usr/bin from install of google-earth-stable-7.0.2.8415-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64

...i think i am going to switch to slackware

...i think i am going to switch back to slackware

Same issue with Fedora 18 x86_64 (32 and 64bit GE).

Folks, this obviously affects all users on Fedora 18.

I don't think adding more "same here" comments will provide any additional information or incentive to the developers for them to fix the issue, while it annoys people who starred it to be notified of updates.

Just star the issue, that'll give an indication of how many users are affected.

I have the same problem

Same issue with Fedora 18 32bit

mirko is right.

There has been a fix found for f17. by deleting a font.conf file. I tried on f18 didnt work. Maybe that might give a clue to fix this one.

Same problem

The work around didn't work for me

Comment deleted

I have google earth working on fedora18 64bit (18 installed as an upgrade from 16 via 17).

The required steps are to remove the persian fonts file and install the 32bit version of the mesa-dri-drivers. These provide /usr/lib/dri/r300_dri.so which is what was missing and causing it to crash for me. The google earth rpm also needs to be force installed to get around the ownership of /usr/bin issue.

These are the commands that worked for me.

wget http://dl.google.com/dl/earth/client/current/google-earth-stable_current_x86_64.rpm

rpm -ivh google-earth-stable_current_x86_64.rpm --force

mv /etc/fonts/conf.d/65-fonts-persian.conf{,.bak}

yum install mesa-dri-drivers*.i686

How can it take over a month to fix a minor packaging issue?

Could anyone successfully login to google earth

I have, but it needed another package which wasn't pulled in by the dependencies on the package.

yum install redhat-lsb.i686

For 32bit,login to terminal su -- wget http://dl.google.com/dl/earth/client/current/google-earth-stable_current_i386.rpm ( should download 32 bit for ) and use the following to install rpm -ivh google-earth-stable_current_i386.rpm --force

But unfortunately it wasnt working for me,Could someone shade some light

It works for me, $wget -c http://dl.google.com/earth/client/current/GoogleEarthLinux.bin

yum install redhat-lsb

sh GoogleEarthLinux.bin

Esto me sirvió:

#18 richardj...@googlemail.com

I have google earth working on fedora18 64bit (18 installed as an upgrade from 16 via 17).

The required steps are to remove the persian fonts file and install the 32bit version of the mesa-dri-drivers. These provide /usr/lib/dri/r300_dri.so which is what was missing and causing it to crash for me. The google earth rpm also needs to be force installed to get around the ownership of /usr/bin issue.

These are the commands that worked for me.

wget http://dl.google.com/dl/earth/client/current/google-earth-stable_current_x86_64.rpm

rpm -ivh google-earth-stable_current_x86_64.rpm --force

mv /etc/fonts/conf.d/65-fonts-persian.conf{,.bak}

yum install mesa-dri-drivers*.i686

Finally, I made it working on Fedora-18 64bit with Infinality patches installed from "www.infinality.net"!

Even, none of the above solutions worked for me (I didn't want to un-install Infinality patches, because they're so awesome :-)). The only way to make it working is to do the following changes on your system :

mv /etc/fonts/infinality/conf.d/21-aliases-wine-osx.conf /etc/fonts/infinality/conf.d/21-aliases-wine-osx.conf.bck mv /etc/fonts/infinality/conf.d/60-group-non-tt-fonts.conf /etc/fonts/infinality/conf.d/60-group-non-tt-fonts.conf.bck mv /etc/fonts/infinality/conf.d/60-group-tt-fonts.conf /etc/fonts/infinality/conf.d/60-group-tt-fonts.conf.bck unlink /etc/fonts/conf.d/65-fonts-persian.conf cd /opt/google/earth/free/ mv libGLU.so.1 GOOGLE_libGLU.so.1 ln -s /usr/lib/libGLU.so.1 libGLU.so.1

Thanks to the great posts that helped me to resolve this :

http://www.infinality.net/forum/viewtopic.php?f=2&t=272

https://ask.fedoraproject.org/question/7458/how-do-i-get-googleearth-working-in-fc18/

Cheers,

Tarkan

This bug still persists on Fedora 18.

The fix is simple. The %dir macro has been overused in the spec file. All someone needs to do is remove '%dir %{_bindir}' from the '%files' section and rebuild. The spec file isn't even public, but the problem seems quite obvious...

Linking to other thread for someone to merge if they can/ wish.

https://code.google.com/p/earth-api-samples/issues/detail?id=923

I posted there as it was the only link that appeared when using the error message as a search query.

This is how I got Google Earth working on Fedora 18 64 bit (using AMD Catalyst 13.1 drivers), note the dependencies on i686 libraries:

yum install lsb (might be that this was not needed) rpm -U --force google-earth-stable_current_x86_64.rpm mv /etc/fonts/conf.d/65-fonts-persian.conf{,.bak} yum install mesa-dri-drivers*.i686 yum install redhat-lsb.i686

Thanks #29 - worked for me

same issue with fedora 18 x64:

file /usr/bin from install of google-earth-stable-7.0.3.8542-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64

would be great if it would be fixed

How to "fix": 0. If you don't already have rpmrebuild, install it from: http://sourceforge.net/projects/rpmrebuild/files/rpmrebuild 1. rpmrebuild -ep google-earth-stable_current_x86_64.rpm 2. Search for the line containing /usr/bin (the line: %dir %attr(0755, root, root) "/usr/bin"), and remove it. 3. Save end exit. Answer yes. It will then tell you the location of the fixed rpm. 4. yum install PATH_TO_FIXED_RPM

thank you amir... that was a great fix! :)

thank you amir. worked for me also.

Amir,

Thank you. I did not know abut rpmrebuild until I saw your post. It worked great and Google Earth is now running.

Ultimately, it would be better if some sort of check were in the file which would check if a RedHat or Fedora distro is being used and automatically disregard that line or substitute an appropriate one instead of trying to change the permissions of an already existing /usr/bin folder.

Thanks Amir, i put link on my http://blog.dellunto.net/?p=117 about your fix, it saved me a lot of time!!!! Just a note, you can install rpmrebuild with yum install rpmrebuild Thx again man

http://code.google.com/p/earth-issues/issues/detail?id=1525#c35 SL.Haffly, The problem has nothing to do with Fedora or Red Hat. No third party rpms for any distro should EVER own /usr/bin. That's the job of one single package maintained as part of the distro. Red Hat and Fedora are just doing a better job of protecting their users from poorly written (like this one) or malicious packages from other sources than distributions where this package works out of of the box.

russell,

I think that is what I was trying to say. I appreciate Red Hat and Fedora for their efforts. I also appreciate Google Earth. I was trying to say that the Google Earth installer, not Fedora or Red Hat should check to see if /usr/bin exists and use that instead of trying to create something with different permissions, especially since the existing folder with the existing permissions works just fine.

SL.Haffly, Actually what I was saying is they don't even need to check for /usr/bin. If it isn't there then that's one very broken Linux box that has far bigger problems than getting Google Earth installed. Owning /usr/bin, unless you're the one distribution maintained package responsible for bootstrapping the file system, is a big no, no. Its a rookie packaging mistake but one that's very, VERY, easy to fix which is why this bug is so frustrating.

russell,

Thanks. I understand now. The question then is that if it is so easy to fix, why hasn't the fix been made? Is someone intentionally trying to break compatibility with Red Hat/Fedora systems? I should certainly hope not. Microsoft did that enough to break OS/2's capability to run Windows programs (sometimes better than native Windows could).

I doubt this is intentional. I agree with Russell that this is probably just a rookie packaging mistake.

why should google break compatiblity to fedora? there wouldnt be a reason for it. its just a bug, and as linux packaging probably has a low priority to the google earth development team, this is taking so long.

Sorry, just a bit of paranoia based on prior experience.

I tried Amir's fix in Fedora 19 for the 32-bit version of earth but the line to be removed does not exist in the rpm file. I searched for every occurrence of "%" and that failed to find the line also.

I would like to hear a response from Google explaining the status of this issue and providing an ETA for the fix to the package.

Terry

Hi Terry, On Fedora 19, the version of rpmrebuild is currently: $ rpm -q rpmrebuild rpmrebuild-2.8-2.fc19.noarch

This version has a problem to deal with the rpm program in Fedora 18/19, as you can see from the following error message: $ rpmrebuild -ep google-earth-stable_current_i386.rpm error: incorrect format: invalid field width

On Fedora 18, this problem was fixed in an updated package rpmrebuild-2.9-1.fc18.noarch.rpm. From some reason, this fix has not appeared yet in Fedora 19 (it will hopefully appear shortly, see: https://bugzilla.redhat.com/show_bug.cgi?id=894042).

Solution:

Meanwhile if you would like a working rpmrebuild for Fedora 19, you can install the fixed version of Fedora 18:

yum install http://dl.fedoraproject.org/pub/fedora/linux/updates/18/i386/rpmrebuild-2.9-1.fc18.noarch.rpm

Amir,

Thanks for the info.

Terry

Thanks, Amir.

32 worked for me also.

I had already installed xorg-x11-drv-nvidia-libs.i686 and redhat-lsb.i686. Google Earth appears to be fully functional.

Google Earth package team, Please apply the rpmrebuild patch removing /usr/bin and fix this trivial error. It would also be nice if you included a recommendation to use the native nvidia driver when that graphics card is present.

http://forums.fedoraforum.org/showthread.php?t=288007: post 15: "I can confirm that following the instructions in post 6 Google Earth does now work for me with the nVidia driver installed, but not with nouveau."

I am somewhat amazed that this issue (which prevents the installation of the rpm version for all users) still persists more than nine months after it was first reported, when the fix is so trivial to implement.

Shame on you Google, shame.

This comment was added simply to indicate that the issue is not simply historical but ongoing as of the 13th of September 2013.

I know Daniel... it's pathetic.

Sean

I have a feeling that Google Purposely Sabotages RPM packages. because the debian packages work a lot better. This is probably due because of Canonical and Google relationship. If you notice the Chrome browser also has some bugs that are not in Ubuntu along with Google voice that makes a bad sound when it starts... I thing in common that all the Google packages have the issues. They have been attacking RedHat subliminally, for example the Chrome Browser used to give errors that the OS was obsolete when using RHEL 6.x. Why else do you think they don't fix it for so long and so many complaints?

I don't think Google is trying to maliciously sabotage anything. This has most probably not a very high priority for a big company lime Google (as can be seen on the big number of open issues in this tracker). I'm sure they'll fix it as soon as someone has some spare time.

It's also possible that no one at Google has ever looked at this thread.

I followed the #29 post and google-earth crashed anyway(running 3-11.4-201.fc19.x86_64). However, the same set of steps worked on my laptop i686 machine which is running the same OS. So, instead of installing the x86_64 rpm, download the i386 version and use

rpm -U --force google-earth-stable_current_i386.rpm

I still get a lot of error messages appearing on the console, but it seems to be working as advertised. Just for the record, the error messages are

[1015/124025:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.

Fedora 19 x86_64 also afflicted.

This issue affects Fedora 20 as well.

I wonder if someone from Google Earth team is reading this issue tracker. It is opened for an year now with no response for them. Not to say that they claim Fedora is a supported platform on their site and this package seems to be broken for at least 3 Fedora releases...

on fc20 did

rpm -U --force google-earth-stable_current_x86_64.rpm

% google-earth got graphic overlay data, but no imagery. ran Santa's tour and it crashed with attached message

Comment deleted

Comment deleted

Hi, You can install Google Earth from PostInstallerF...

or compile ous src.rpm ....

http://sourceforge.net/projects/postinstaller/files/fedora/releases/20/SRPM/google-earth-7.1.2.2041-1.fc20.src.rpm

I tried every suggestion in this issue tracker, with no luck. I really had high hopes for Amir's suggestion, #32, but no joy there either. I did discover that if I force the use of my high power nVidia graphics, it will not crash, but then I get the "no land" issue. Even if track down and fix the "no land" thing, that's not a good solution, as Earth should not require the high power 3D gaming graphics adapter.

The "current stable" release of Earth is version 7.x ... in the end, I simply found my last rpm file that had version 6.x, installed it with the --force option, and it's working just fine.

I have created this script which seems to work for Fedora 18, 19 and 20.

!/bin/bash

wget http://dl.google.com/dl/earth/client/current/google-earth-stable_current_x86_64.rpm yum install -y redhat-lsb mv /etc/fonts/conf.d/65-fonts-persian.conf{,.bak} yum install -y mesa-dri-drivers*.i686 rpm -ivh google-earth-stable_current_x86_64.rpm --force

Please let me know your results!

It worked! on my Fedora 20: # uname -a Linux isobel1 3.12.10-300.fc20.x86_64 #1 SMP Thu Feb 6 22:11:48 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

with HP-z800 workstation NVidia Quadro FX4800 graphics

Many thanks, --Irwin Sobel

i.e. #61 worked

61's install solution seems to work with fedora 19. no image appears in the gui however...

I installed google-earth for 64 from the SourceForge PostInstallerF page and it installed fine but crashed whenever I did anything (select stuff in the left bar, zoom around, etc).

I take it back #61 no longer works on my fedora 20. It comes up and then crashes with the following error msgs (started from terminal window):

[0218/113014:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses() [0218/113014:WARNING:backend_impl.cc(1875)] Destroying invalid entry. [0218/113014:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. .... lots of this one ... [0218/113020:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. [0218/113020:WARNING:backend_impl.cc(1875)] Destroying invalid entry. [0218/113020:WARNING:backend_impl.cc(1875)] Destroying invalid entry. [0218/113020:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. .... lots of this one ... [0218/113021:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. [0218/113021:WARNING:backend_impl.cc(1594)] Messed up entry found. [0218/113021:WARNING:backend_impl.cc(1875)] Destroying invalid entry. [0218/113021:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. [0218/113021:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. [0218/113021:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler. [0218/113021:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.

Another crash happened while handling crash!

How can it take over a year to fix a minor packaging issue?

Well, for me it is quite simple. Google Earth team (if there is one) is not interested in properly supporting Fedora.

I think #68 hit it on the head. Google Earth can't be bothered with Fedora or a showstopper like this would have been fixed in a week.

If it had been the Ubuntu package not working it would have been fixed long ago. Because, you know, that's so "cool" and "hip". ;-)

I suspect RedHat is more of a challenge to google in the server cloud space thingy than Canonical could ever hope to be... Google's doing it's best to break Mozilla, I suspect that Comment 40 is closer to the mark than some might think - do no harm; yeah, right.

at #61: no earth shown. The install works, but when I start google-earth from the command line, the applications shows up without the earth being shown. And this error in the terminal: [0311/105150:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses()

It's even more complicatd than I thought in #66... It will run from the Gnome-GUI shortcut, but the outer layers of the DB are infected with seemingly random-colored pixels overlaid on the data... the stuff's spatially non-uniform... some areas of the globe are clear, while others have the junk overlaid to varying levels of zoom. By the time you zoom down to cities and roads, the junk disappears, but comes back when you zoom out again (see #62 for my machine description)... latest kernel is 3.13.6-200.fc20.x86_64 #1 SMP

This link helped me get GE running good on a Fedora 19 32-bit system: https://productforums.google.com/forum/#!topic/earth/u478GSAN9no

I had to force install the package, as is demonstrated in the link, and then in order to reinstall the filesystem I was required to edit the google-earth.repo file found within the /etc/yum.repos.d/ directory and change enabled from 1 to 0.

Execute this workaround with caution as I am a new user of Fedora and Linux in general and I know it is not recommended to edit files within the filesystem. My boss just got me up and running on Fedora and helped me execute this workaround on a workstation without much vital data on it.

Hope this helps.

Chris

Thanks, rpmrebuild solution (#32) worked for me.

Google, you must be joking. This bug is there for nearly two years and makes your product non-installable on all Fedora's, RHEL's, CentOS'es and maybe others. Currently I cannot install it on Fedora 20, because your engineers cannot create the RPM SPEC the right way. Well, if you cannot commit this one-liner in nearly two years this says a lot about quality of your products and assures about your ignorance of users and their feedback.

Hi guys, i don't know if this might resolve your problem, but i had the same problem and i find this to fix...

Source: www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-rpm-using.html

10.2.2.2. Conflicting Files

If you attempt to install a package that contains a file which has already been installed by another package, the following is displayed:

Preparing... ########################################### [100%] file /usr/bin/foo from install of foo-1.0-1 conflicts with file from package bar-2.0.20 To make RPM ignore this error, use the --replacefiles option:

rpm -ivh --replacefiles foo-1.0-1.i386.rpm

Good luck!

Totally agree with #76. We are seeing with Google the same story we saw in the past with windows....

Beware using the work around in #77 is a hack that will allow you to install google earth but it is very likely to break future upgrades of your system packages. You are far better to use one of the rpmrebuild workaround packages.

I'm going to say this again because this bug is so rediculous. For Google to fix this issue for everyone, everywhere it is a ONE LINE CHANGE to their spec file. The level of apathy demonstrated by not even commenting on this issue is beyond inexcusable.

The level of apathy demonstrated by not even commenting on this issue is beyond inexcusable.

There are getting to be a bunch of posts of this nature here - they're really not helpful. Google has been running a repo with broken RPM's for a couple years now - and even links prominently to it on their page. Please understand that there are multiple communication methods, active and passive being two - this really isn't apathy on Google's part - it's telling RPM-based system users to get stuffed; showing disrespect to a group is a perfectly effective means of communication - let's just accept that and move on, hoping that they change their mind about using their position to create the impression that some distros "have problems", but complaining here isn't a source of power in this situation.

However, as long as this bug remains open, we can help each other use Earth, so let's not fill it up with complaints, which won't do anything except add to the noise here. To avoid doing that myself, here's a link to the solution I use to run Earth on several f20 machines:

http://forums.fedoraforum.org/showpost.php?p=1678303&postcount=60

This works perfectly for me, and ensures I get the security fixes in the system Qt libs. I've asked over at postinstaller to have this method included, but it seems Earth has disappeared from their repo. I'm guessing that wasn't because they wanted to get rid of it, since the postinstaller folks seem to generally have the community's best interests at heart.

Despite my expository text, this comment is actually useful for [theoretical] development work as it contains a link to instructions for fixing the /usr/bin problem correctly and a library stub source file necessary for a more secure Earth RPM to be [theoretically] produced and points out that the existing RPM has a potential for third-party security risks.

it's not helpful at all. what should be put into a bug report: factual information describing fail or workaround modality. What should not be put into a bug report: compaints it's not being fixed fast enough. There are other avenues for such complaints. Repeating information (eg. this works perfectly... me2) doesn't even belong in those... if ya get my drift.

bug still present on fedora 21beta

This also has problems the other way around with F21 beta ... I can't upgrade the filesystem package:

Transaction check error: file /usr/bin from install of filesystem-3.2-28.fc21.x86_64 conflicts with file from package google-earth-stable-7.1.2.2041-0.x86_64

To run a simple "yum update", I have to let yum download it for me (just run yum update, letting it fail), then:

rpm -ivh --replacefiles /var/cache/yum/x86_64/21/updates-testing/packages/filesystem-3.2-28.fc21.x86_64.rpm

then rerun the yum update.

Este tipo sabeee....

wget http://dl.google.com/dl/earth/client/current/google-earth-stable_current_x86_64.rpm

rpm -ivh google-earth-stable_current_x86_64.rpm --force

mv /etc/fonts/conf.d/65-fonts-persian.conf{,.bak}

yum install mesa-dri-drivers*.i686

Solution for this problem ==> https://productforums.google.com/forum/#!topic/maps/F1bX-cJab_o

I tried solution at #85 and GE installed but upon invocation crashed with attached transcript and referenced crashlog file. System is Fedora 20 %uname -a Linux isobel1 3.18.9-100.fc20.x86_64 #1 SMP Mon Mar 9 16:27:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Hardware is HP Z800 w 5.8GBRAM and 12 cores w Quadro FX 4800/PCle/SSE2 graphics

irwin, Amir's comment #32 worked for me: #32 amir...@gmail.com

How to "fix": 0. If you don't already have rpmrebuild, install it from: http://sourceforge.net/projects/rpmrebuild/files/rpmrebuild 1. rpmrebuild -ep google-earth-stable_current_x86_64.rpm 2. Search for the line containing /usr/bin (the line: %dir %attr(0755, root, root) "/usr/bin"), and remove it.

I just commented the line by putting a # symbol at the start of the line. I had already installed xorg-x11-drv-nvidia-libs.i686 and redhat-lsb.i686. Google Earth appears to be fully functional.

Do you have an Nvidia graphics card?

3. Save end exit. Answer yes. It will then tell you the location of the fixed rpm.
4. yum install PATH_TO_FIXED_RPM

Bob, I did the commenting-out (poorly described in #85) with # as you did. I also just yum install'ed the xorg-x11-drv-nvidia-libs.i686 and redhat-lsb.i686 with all associated dependencies. Result roughly the same crash.

I also rebooted and tried again with same result.

My grapics card is Nvidia Quadro FX 4800

Can someone just ping them about this bug via Twitter maybe? https://twitter.com/googleearth

(I'm not on Twitter myself, so I can't.)

Just to confirm that this bug is present in CentOS 7.1.1503 - it's quite amazing that Google Earth is packaged up with a reference in the manifest to /usr/bin. Despite the download page http://www.google.com/earth/download/ge/agree.html claiming the RPMs will work on Fedora, they actually don't work at all on any Fedora (or CentOS) release!

This is as good a failure as the 2-odd years that the "64-bit" Linux Google Earth download actually contained 32-bit binaries, which was incredibly sloppy packaging also.

Why after 2 years has Google still not fixed this issue? Ridiculous....

On Fedora 22:

Error: Transaction check error: file /usr/bin from install of google-earth-stable-7.1.4.1529-0.x86_64 conflicts with file from package filesystem-3.2-32.fc22.x86_64

On 3.19.8-100.fc20.x86_64 ... [0621/100446:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses() [0621/100446:ERROR:x509_certificate_nss.cc(730)] CERT_PKIXVerifyCert for www.google.com failed err=-8181 [0621/100446:ERROR:x509_certificate_nss.cc(730)] CERT_PKIXVerifyCert for kh.google.com failed err=-8181

Noted same as #92

Simple packaging bug opened in 2012, still won't install on RHEL 7 or any RHEL/CentOS/Fedora variant without force:

Transaction check error: file /usr/bin from install of google-earth-stable-7.1.4.1529-0.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64

derp

Just upgraded to Fedora 22 and same problem reported:

rpm -iv --force google-earth-stable-7.1.4.1529-1.i386.rpm

file / from install of google-earth-stable-7.1.4.1529-1.i386 conflicts with file from package filesystem-3.2-32.fc22.i686 file /usr/bin from install of google-earth-stable-7.1.4.1529-1.i386 conflicts with file from package filesystem-3.2-32.fc22.i686

Solution was : #rpm -iv --force google-earth-stable-7.1.4.1529-1.i386.rpm

Comment: For the more 'savvy' of us this is not a big deal but for the regular user that doesn't have cli knowledge, I guess it is a big issue!