Created attachment 313914 [details] RPM containing French translations as plugin fragments Description of problem: Eclipse sometimes fails to pick up fragment plugins from /usr/share/dropins (or anywhere else I've tried). Version-Release number of selected component (if applicable): 3.4.0-18 How reproducible: Varies. It has happened on three different virtual machine installations (two F9, plus one with all Rawhide updates). It was happening on my desktop machine (F9) when I was running koji builds up to 3.4.0-18, but it somehow came good when I installed 3.4.0-18 from rawhide.(!) Steps to Reproduce: 1. Install Fedora 9 2. yum --enablerepo=rawhide install eclipse-jdt 3. Download the attached eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm and install through yum. 4. Delete ~/.eclipse/ 5. eclipse -nl fr Actual results: The dialog comes up in English. [Upon choosing a workspace, the Babel plugins are not listed in Eclipse's About screens.] Expected results: A dialog allowing the user to choose a workspace directory should come up in French. Upon choosing a workspace, the Babel plugins (org.eclipse.*.nl_fr) should be listed in Eclipse's About screens. Additional info: eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm puts a number of plugin fragments under /usr/share/eclipse/dropins/babel-fr/eclipse/{plugins,features}. Eclipse should be able to pick them up from there because of the line at the end of eclipse.ini: -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins NB: This works with upstream Ganymede 3.4.0, on the affected machines, including the case where eclipse dirs are read-only to the user running eclipse.
Since we patch nothing in the area of p2, this is in all probability an upstream bug. I'm working on it upstream and will include a patch in our RPMs when I have something acceptable.
... and of course I can't duplicate :(
I have some more data, perhaps too much to be useful. But see the log error message three paragraphs down - it might be significant. On one of the affected virtual machines, I tried tarring up /usr/{lib,share}/eclipse. I extracted this to a user directory on the same machine, edited eclipse.ini to suit, ran chown -R root.root, and found that the plugins weren't picked up. The same tarball worked okay when extracted to my main desktop. There must be some environmental factor which differs between the machines. (OTOH my later results indicate that the problem is in the eclipse directories; see below. Perhaps it is both. Oh joy.) I ran eclipse -nl fr -consolelog on the affected virtual machine and on my main desktop, and diffed the logs. This was the only significant difference: !ENTRY org.eclipse.equinox.p2.engine 4 4 2008-08-08 20:27:42.684 !MESSAGE An error occurred while collecting items to be installed !SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2008-08-08 20:27:42.685 !MESSAGE No artifact repository available. On the same virtual machine, running /usr/lib/eclipse -clean as root picked up the translations, and after that the other users also got the translations. Eclipse modified a number of files when run as root. I will attach a list of the files which were modified, as touchedfiles.txt One of these files must represent the difference between breaking and working. Note that the error "No artifact repository available" still appeared in the console log. At this point, I tried running the previously untarred eclipse, and it is still broken, even though /usr/lib/eclipse is now working. This tells me that the critical factor must be in the eclipse directories, presumably one of the files listed in touchedfiles.txt However, on another F9 VM, running eclipse -clean as root achieved nothing. Not even root got the translations.
Created attachment 314031 [details] List of files which were modified when Eclipse ran as root
Created attachment 314033 [details] List of files which were modified when Eclipse ran as root Aligned filenames for readability.
Can you send me (here or via email or something) a tarball of ~/.eclipse when the issue is happening? All those changed files is a good reason to not run Eclipse as root as it can mess things up for regular users :) FWIW the "!MESSAGE No artifact repository available." message is what I was getting when this issue was happening for me with the CDT. I'll see if I can reproduce and then debug and/or come up with a few instrumented JARs for you to plop into your installation so we can get some debug information.
(In reply to comment #3) > However, on another F9 VM, running eclipse -clean as root achieved nothing. > Not even root got the translations. Sorry, better disregard that bit. All three virtual machines are now picking up the translations after running eclipse as root. I can only assume that I previously ran it as user, but thinking I was root.
G'day Andrew, (Sorry, yesterday was a public holiday here in Brisbane.) (In reply to comment #6) > Can you send me (here or via email or something) a tarball of ~/.eclipse when > the issue is happening? All three of my test VMs started working, which makes it a bit hard to provide the ~/.eclipse directory you asked for! (And I should mention that I have generally been deleting ~/.eclipse before running Eclipse, so I'm not sure if it will help much.) > All those changed files is a good reason to not run Eclipse as root as it can > mess things up for regular users :) Ha, yeah ;-) But I find it a little surprising that Eclipse behaves that way. It would be tidier if it used ~/.eclipse even when running as root, rather then quietly changing its behaviour depending on whether it has write access to ECLIPSE_HOME. I guess it's done that way because a lot of Eclipse users are used to running Eclipse from a writeable directory (on Windows, or under /home), and Eclipse historically kept its "mess" all in one place. > FWIW the "!MESSAGE No artifact repository available." message is what I was > getting when this issue was happening for me with the CDT. I'll see if I can > reproduce and then debug and/or come up with a few instrumented JARs for you to > plop into your installation so we can get some debug information. Since my test VMs stopped exhibiting the problem, I decided to use a fresh install of F9 and try again, documenting my steps: ----------------------------------------- 1. extract Fedora 9 VMware image from vmplanet.net (the smallest F9 image I could find, about 500MB): http://vmplanet.net/node/49 2. change version numbers of VMware files (.vmx and .vmdk) to run under VMware Server 1.0x: http://www.desktop-virtualization.com/2008/02/07/convert-vmware-server-20-vms-into-server-104/ 3. reduce VM memory to 256MB (from 512) 4. log in as vmplanet, password is vmplanet.net 5. su - # root password is also vmplanet.net 6. #edited /etc/yum.repos.d/*.repo to point to local brisbane mirror 7. yum -y --enablerepo=rawhide install eclipse-platform openssl 8. yum install curl 9. curl -O http://seanf.fedorapeople.org/bugs/eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm 10. rpm -i eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm 11. yum install strace 12. [as vmplanet user] strace -etrace=open eclipse -nl fr -consolelog >eclipse.log 2>strace.log 13. #tarred up ~/.eclipse as user-eclipse-dir.tar.bz2 ----------------------------------------- Oh, and this *did* reproduce the problem - the workspace selection dialog came up in English, not French. (In fact, I just did the whole thing again to make sure it was safe to remove some false steps from the list above, and it happened again. That's all five of my virtual machines (plus my development machine) which have shown this problem when eclipse-3.4 was first installed.) I will attach the log files and a copy of the ~/.eclipse directory which was created at step 12. If they don't help, you could try installing the F9 VMware image to see if you can reproduce the problem. In any case, I now have a system image I can use to run your instrumented jars under. Sean.
Created attachment 314280 [details] eclipse console log from comment 8
Created attachment 314281 [details] strace log from comment 8
Created attachment 314282 [details] ~/.eclipse/ tarball from comment 8
Hi Sean, (In reply to comment #8) > (Sorry, yesterday was a public holiday here in Brisbane.) Not a problem at all. > (In reply to comment #6) > > All those changed files is a good reason to not run Eclipse as root as it can > > mess things up for regular users :) > > Ha, yeah ;-) But I find it a little surprising that Eclipse behaves that way. Don't think I don't agree. > I guess it's done that way because a lot of Eclipse users are used to running > Eclipse from a writeable directory (on Windows, or under /home), and Eclipse > historically kept its "mess" all in one place. Yeah. > 1. extract Fedora 9 VMware image from vmplanet.net (the smallest F9 image I I can't say I've ever used VMware, but in theory my qemu virtual machine and/or my local F9-rawhide hybrid will be sufficient to reproduce. > I will attach the log files and a copy of the ~/.eclipse directory which was > created at step 12. Cool, I'll take a look. > In any case, I now have a system image I can use to run your instrumented jars > under. Great. I'll try to get them to you today or tomorrow.
eclipse-nls langpacks are working for me now with current rawhide. :-)
Hmm but not today... with another install. (After running as root I see a localized eclipse.)
(In reply to comment #14) > Hmm but not today... with another install. > > (After running as root I see a localized eclipse.) Don't run Eclipse as root :)
(In reply to comment #15) > (In reply to comment #14) > > Hmm but not today... with another install. > > > > (After running as root I see a localized eclipse.) > > Don't run Eclipse as root :) True, but the Eclipse documentation <http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/running_eclipse.htm> does recommend running eclipse -initialize as a user with write permissions when using shared installs, apparently for performance reasons. Obviously, doing this as root is not advisable, but if the Eclipse files and directories were owned by the user "eclipse", we could have a post-install script to run eclipse -initialize -clean -nosplash under the user "eclipse" whenever installing an Eclipse-related project. If running as root does solve the problem, this approach should do it too, only more safely. (What happens on a system where the user has already defined a user "eclipse"? Is there a clean way to deal with this sort of thing?)
Me too. I see, for example, these rpm's freshly install from rawhide: $ rpm -qa eclipse\* eclipse-mylyn-webtasks-3.0.1-2.fc10.noarch eclipse-changelog-2.6.2-2.fc10.x86_64 eclipse-cdt-5.0.0-6.fc10.x86_64 eclipse-cdt-mylyn-5.0.0-6.fc10.x86_64 eclipse-swt-3.4.0-24.fc10.x86_64 eclipse-subclipse-1.2.4-11.fc9.x86_64 eclipse-rcp-3.4.0-24.fc10.x86_64 eclipse-phpeclipse-1.2.0-0.4.svn1573.fc10.x86_64 eclipse-platform-3.4.0-24.fc10.x86_64 eclipse-rpm-editor-0.4.0-3.fc10.x86_64 eclipse-pydev-1.3.18-1.fc10.x86_64 eclipse-ecj-3.4.0-24.fc10.x86_64 eclipse-mylyn-3.0.1-2.fc10.noarch eclipse-jdt-3.4.0-24.fc10.x86_64 ... but eclipse only reports these features: *** Features: org.eclipse.cvs (1.1.0.v20080603-7C79E8M9EI99m9c9S) "Eclipse CVS Client" org.eclipse.help (1.0.0.v20080603-7r7xEHJEJkZu5nE6Q4Qrtvu6JZ9L) "Help System Base" org.eclipse.platform (3.4.0.v20080610-9I96EhtEm-T_5LxIsybz-3MdGZmOA3uwv7Ka_M) "Eclipse Platform" org.eclipse.rcp (3.4.0.v20080324a-989JERhEk-jWnd5IY8K5tjxB) "Eclipse RCP" org.fedoraproject.ide.feature (1.0.0) "Fedora Eclipse Product Plug-in" Something is broken here.
I installed f10 beta but kept my f9 home directory. I then yum installed eclipse-cdt which of course brought in other modules like eclipse-platform. But I found that eclipse-cdt was not one of my features. I then tried launching eclipse as root and that worked. So I went back to user and deleted ./eclipse. Now cdt is there. So it seems that eclipse doesn't know how to handle old config directories.
(In reply to comment #18) > I installed f10 beta but kept my f9 home directory. I then yum installed > eclipse-cdt which of course brought in other modules like eclipse-platform. But > I found that eclipse-cdt was not one of my features. I then tried launching > eclipse as root and that worked. So I went back to user and deleted ./eclipse. > Now cdt is there. So it seems that eclipse doesn't know how to handle old > config directories. You shouldn't run eclipse as root as it will write things to /usr/lib{,64} that may cause issues in the future. There is a separate issue here that running as root is not fixing :) Also, you should probably get a new ~/.eclipse/org.eclipse.platform_3.4.0-<a hash of /usr/lib> alongside ~/.eclipse/org.eclipse.platform_3.3.0-<hash>. Do you?
I am not running it as root. Based on some comments in this bug I just wanted to see if root was properly configured. It was. So I tried the next step of deleting .eclipse. That made my cdt install work. It used to have both a patfor_3.4.0 and a platform_3.3.0. Now it only has patform_3.4.0 and it is working properly.
I tested again today with current rawhide (with eclipse-3.4.1) and ja langpack worked okay for me again. (In reply to comment #18) Shmuel, your issue sounds different - I guess CDT is not using the dropins directory? Could you you a separate bug report about your issue: I think incompatibility of 3.3 and 3.4 config may be a known issue though.
(In reply to comment #18) and (In reply to comment #21) > I tested again today with current rawhide (with eclipse-3.4.1) and ja langpack > worked okay for me again. Right, "again", so it was working all along, or maybe at various times. For me at least, it never worked (add-on features). > (In reply to comment #18) > Shmuel, your issue sounds different - I guess CDT is not using the dropins > directory? > Could you you a separate bug report about your issue: I think incompatibility > of 3.3 and 3.4 > config may be a known issue though. Although 3.3->3.4 may come into play, I believe what's described here is all really just one bug, which, for me anyway, has just been fixed in rawhide. I now see features from CDT, PYdev, etc. that were not enabled before.
*** Bug 468714 has been marked as a duplicate of this bug. ***
Moving back to assigned based on bug 468714.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 480557 has been marked as a duplicate of this bug. ***
Uff. I just got this one on rawhide when installing eclipse-cdt-5.0.1-3.fc11.i586 :-( It seems like "eclipse -clean" didn't help (IIRC it helped before...). But removing .eclipse "fixed" the problem ...
:( I just verified that this appears to be fixed with 3.5 but there's little-to-no chance of it being fixed in 3.4.x. We're going to try to do an update to 3.5.x in the F-11 cycle but it'll be risky.
Note that there's an upstream change in 3.4.2 that makes the -clean trick not work. Crappy, I know :(
*** Bug 514077 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.