googleearth-5.0.11337.1968_beta have bug. Local carset (russian tested) not reflected correctly. This ebuild fix that problem. Reproducible: Always googleearth-5.0.11337.1968_beta works faster then googleearth-4, but it have bugs, seems in it's qt. The new ebuild make symlinks from googleearth libs directory to relevant system libs for curl, qt4, mesa, gcc, icu and zlib. And it have linguas use-flags for delete non used locales. I'm not maintainer, and ebuild may be not relevant, but it work. See attached file.
Created attachment 185294 [details] new ebuild shared some libs, have linguas use-flag
This does not belong to bugzilla OR devrel.
Well, there's already x11-misc/googleearth-5.0.11733.9347 in the tree but for the sake of completeness I gonna reassign this bug to the corresponding maintainers.
I have updated the ebuild provided by Alexey. These are the changes starting from the most important fix: 1. locale bug patch: This bug is very serious and leads to data loss! It happened to me, and after realizing the root cause (it took months), I had to restore my placemarks from an earlier backup, losing some precious ones and patch the googleearth starting script. If for the user locale the default decimal separator is the comma, the decimal values get lost in GE 5.1. See the Google Earth 5.1 wrong coordinates bug (but setting the LC_NUMERIC is enough): http://www.google.com/support/forum/p/earth/thread?tid=72b851d55f188cea&hl=en 2. dejavu fonts: optional RDEPEND entry media-fonts/dejavu as an alternative to ttf-bitstream-vera. As the Bitstream fonts are latin1-only, using them is not a good choice for googleearth. As latin1 has never been enough for my language, I've been using dejavu since forever over bitstream without any disadvantages (set in package.provided). See bug #129117 for details. 3. qt4 use flag: two more symlinks are added for /opt/${PN}/plugins/imageformats/, they are essential for proper web content display (Wikipedia, Panoramio pictures). The removal of the bundled libs is not enough, as the program won't find the Qt system libs (at least the imageformats), that's the reason why symlinks are needed. See (imageformats are not reported here, though): http://www.google.com/support/forum/p/earth/thread?tid=466e4cb94e0d8200&hl=en 4. opengl use flag: I chose this one instead of mesa as it exists already and is usually tied to mesa installation. I did not put it into RDEPEND, however, because virtual/opengl is an unconditional dependency of the package, so mesa needs to be installed in any case. By setting this use flag users can enable the system lib over the bundled libGLU.so. I am not completely sure but I feel a little speedup with it. The symlink might not be needed, but I use it this way. 5. curl use flag: I left it in, as it just works all right. The symlink might not be needed, but I use it this way. 6. removed chmod on /opt/${PN}/xml directory: as it does not exist anymore. 7. rm libcrypto.so* not applied: this lib is not part of GE package anymore. 7. icu use flag not applied: as I don't have the package dev-libs/icu installed, I didn't test it. 7. gcc, zlib use flags not applied: their libs are not part of the package anymore. 8. the LANGS improvement is not included: because I did not tested it. 9. improvements are for x86 only (except locale patch): as I only have an x86. See bug #212373 for previous efforts. Please, update the googleearth ebuild to give users a quicker, nicer and, most important, a seamlessly working Google Earth. Finally I have.
Created attachment 210788 [details] the improved ebuild for the latest version
Created attachment 210789 [details, diff] patch for the locale wrong coordinates bug
Created attachment 210791 [details, diff] diff against the latest ebuild
Created attachment 210797 [details] googleearth-5.1.3533.1731 ebuild fixed gentoo ebuild (from official portage), added 'gdal' and 'nss_mdns' USE-flags. There is no symlinks needed now. It delete qt.conf, so now your it uses your qt-theme if you ise qt4 USE-flag. enjoy.
Alexey, The symlinks are needed at least for plugins/imageformats if you want to see the pictures in Wikipedia and Panoramio placemarks. I guess this is what you wanted to say in pkg_postinst. A for loop is not needed to delete. media-libs/mesa is a dependency of virtual/opengl, so it should not be added to RDEPEND. The locale patch is essential to avoid potential data loss of My Places.
(In reply to comment #9) > Alexey, > The symlinks are needed at least for plugins/imageformats if you want to see > the pictures in Wikipedia and Panoramio placemarks. I guess this is what you > wanted to say in pkg_postinst. > A for loop is not needed to delete. > media-libs/mesa is a dependency of virtual/opengl, so it should not be added to > RDEPEND. > The locale patch is essential to avoid potential data loss of My Places. Hm... When I install that new ebuild (with qt4 USE-flag), I can't see panoramio pictures, but after reboot (not because of this) I can see it. So, you suggest not delete plugins/imageformats (or do symlinks) for see panoramio pictures without rebooting? About virtual/opengl: I think you right, because media-libs/mesa is the only one dependency of virtual/opengl.
Can you tell me how to reproduce the bug with comma and bad locale? When does it lead to data loss, and what should people do? Won't data loss occurs if people have places saved in their locale, and now they run the patched ebuild? Should they also clear cache and whatnot, as somebody at the google forums says?
Hm seems to me that the bug occurs only when system qt is used instead of the bundled one, right?
You can reproduce the bug and test the workaround: 1. Set your locale to e.g. hu_HU.utf8 2. Open googleearth-5.1 with previously saved My Places. 3. Observe the false coordinates by either clicking on them or opening the xml file afterwards. This occurs with both bundled and system qt libs. At least that was the case with the previous beta version. I haven't tried it since with the recently released one, they might have fixed this in the bundled libs, but it is surely not fixed in Qt-4.5.3. Workaround is to set the LC_NUMERIC to C. Clearing the cache is not needed. If it is set so in the startup script (like in the patched ebuild), the placemarks won't get overwritten with false coordinates.
Thanks. Committed 5.1.3533.1731-r1 with the decimal separator patch and dejavu font alternative. The main problem of unbundling libs is the lack of 32bit qt4 on amd64.
(In reply to comment #14) > The main problem of unbundling libs is the lack of 32bit qt4 on amd64. Thanks for clearing this up. Does this mean that it will never be fixed like this or we can expect 32bit qt libs in portage in the near future? And isn't it possible to provide an x86-only fix, especially because it could be selectable through IUSE="-qt4" flags. Thx
(In reply to comment #14) Decimal patch doesn't work here. I need to set LC_ALL=C instead of LC_NUMERIC. My standard environment has LC_ALL and LC_CTYPE set (both to de_DE.UTF-8).
(In reply to comment #16) > (In reply to comment #14) > Decimal patch doesn't work here. I need to set LC_ALL=C instead of LC_NUMERIC. > My standard environment has LC_ALL and LC_CTYPE set (both to de_DE.UTF-8). Hm, that's right, LC_ALL overrides everything else. Any idea to solve this in a transparent way, or just add a warning that's unsupported? Overriding LC_ALL in the launcher would not be a good solution. Is there a reason to use LC_ALL? Looking at http://www.gentoo.org/doc/en/guide-localization.xml you should use LANG to set defaults and LC_* for individual overrides, I don't see a need for LC_ALL.
googleearth-5.1.3533.1731-r1 now unbundles qt4 (unless qt-bundled flag is enabled) please test if that works (sync, reemerge and don't enable the flag)
(In reply to comment #18) > googleearth-5.1.3533.1731-r1 now unbundles qt4 (unless qt-bundled flag is > enabled) > > please test if that works (sync, reemerge and don't enable the flag) > Many thx guys - works fine here and finally solved this ugly issue.
*** Bug 252419 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > (In reply to comment #14) > Decimal patch doesn't work here. I need to set LC_ALL=C instead of LC_NUMERIC. > My standard environment has LC_ALL and LC_CTYPE set (both to de_DE.UTF-8). I added a 'unset LC_ALL' to the script, which should cover those using LC_ALL. All the unbundle dependencies proposals in the attached ebuilds were also implemented, closing.
