Created attachment 360940 [details] configuration details of eclipse (from the "About Fedora Eclipse" window Description of problem: I have just upgraded Fedora 11 today (sept 14th) which included the following upgrades: Sep 14 11:35:18 Updated: 1:eclipse-swt-3.4.2-15.fc11.x86_64 Sep 14 11:35:19 Updated: 1:eclipse-rcp-3.4.2-15.fc11.x86_64 Sep 14 11:35:34 Updated: 1:eclipse-platform-3.4.2-15.fc11.x86_64 Sep 14 11:36:30 Updated: 1:eclipse-jdt-3.4.2-15.fc11.x86_64 Sep 14 11:37:16 Updated: 1:eclipse-pde-3.4.2-15.fc11.x86_64 Since then, it is not possible to use the CDT plugin (nor oprofile, or valgrind). There is no C/C++ perspective and CDT does not show up in the "Plug-in details" or "Feature details" windows. Therefore, all my C projects are not usable at all. Version-Release number of selected component (if applicable): I have installed the following packages: # rpm -qa | grep eclipse eclipse-platform-3.4.2-15.fc11.x86_64 eclipse-pde-3.4.2-15.fc11.x86_64 eclipse-emf-2.4.2-3.fc11.noarch tomcat5-jasper-eclipse-5.5.27-6.2.fc11.noarch eclipse-mylyn-pde-3.1.0-3.fc11.noarch eclipse-rcp-3.4.2-15.fc11.x86_64 eclipse-gef-3.4.2-3.fc11.noarch eclipse-valgrind-0.2.1-2.fc11.x86_64 eclipse-cdt-mylyn-5.0.2-4.fc11.x86_64 eclipse-linuxprofilingframework-0.2.0-2.fc11.x86_64 eclipse-oprofile-0.2.0-2.fc11.x86_64 eclipse-cdt-5.0.2-4.fc11.x86_64 eclipse-cdt-sdk-5.0.2-4.fc11.x86_64 eclipse-swt-3.4.2-15.fc11.x86_64 eclipse-pydev-1.4.4-2.fc11.x86_64 eclipse-dtp-1.6.2-2.fc11.noarch eclipse-mylyn-java-3.1.0-3.fc11.noarch eclipse-nls-3.4.0.v20090620043401-2.fc11.noarch eclipse-mylyn-3.1.0-3.fc11.noarch eclipse-birt-2.3.2-2.fc11.noarch eclipse-jdt-3.4.2-15.fc11.x86_64 icu4j-eclipse-3.8.1-5.fc11.x86_64 eclipse-nls-es-3.4.0.v20090620043401-2.fc11.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
There's a bug in the 3.4.x series that bites us in the case of upgrades. It's fixed in 3.5.x (we can't back-port due to a million requirements, etc.). Try running with -clean. If that doesn't work, try mv ~/.eclipse{,.bakBug523195} and see if that works.
I've found the same bug. For me, running Eclipse with -clean didn't help, but removing ~/.eclipse/org.eclipse.platform_3.4.0_793567567 solved the problem. Starting Eclipse without the plugins messed with my customized window layout. I had to restore the workspace from backup to get everything back to normal.
Hi, I removed the ~/.eclipse/org.eclipse.platform_3.4.0_793567567 directory and it worked for me. The layout was also messed up but the rest worked without problems. Thank you!
I was thinking. It might be possible to work around this bug by creating a new ~/.eclipse/org.eclipse.platform* directory after each minor upgrade. Say, by incrementing the 793567567 sufix. Just an idea.
If it were only that easy :) RPM transactions can't touch /home so that won't work.
This bug bites me with every Eclipse update. Todays update hosed everything. Even after deleting the .eclipse directory most of the installed plugins are not detected. I had to install subclipse and epic from the projects web repositories via the eclipse update manager to get them working again. This is very annoying as workspace state gets reset and i have to reinstall the WDT tools every time an update comes along. My installed eclipse packages: eclipse-rcp-3.4.2-16.fc11.x86_64 eclipse-changelog-2.6.7-1.fc11.x86_64 eclipse-rpm-editor-0.4.2-3.fc11.x86_64 eclipse-epic-0.6.35-1.fc11.noarch icu4j-eclipse-3.8.1-5.fc11.x86_64 eclipse-mylyn-java-3.1.0-3.fc11.noarch eclipse-quickrex-3.5.0-11.fc11.noarch eclipse-jdt-3.4.2-16.fc11.x86_64 eclipse-mylyn-3.1.0-3.fc11.noarch eclipse-emf-2.4.2-3.fc11.noarch eclipse-emf-sdo-2.4.2-3.fc11.noarch eclipse-platform-3.4.2-16.fc11.x86_64 eclipse-pydev-1.4.4-2.fc11.x86_64 eclipse-svnkit-1.2.3-1.fc11.noarch eclipse-gef-3.4.2-3.fc11.noarch tomcat5-jasper-eclipse-5.5.27-6.2.fc11.noarch eclipse-subclipse-1.6.0-1.fc11.noarch eclipse-pde-3.4.2-16.fc11.x86_64 eclipse-cdt-5.0.2-4.fc11.x86_64 eclipse-swt-3.4.2-16.fc11.x86_64
There is nothing we can do except trying to minimize updates (upstream devs are not able to fix the problem for 3.4 series). We are pushing only when there is a bug preventing eclipse from working correctly. The bug is fixed in 3.5 so as soon as Fedora 12 is our you should start using it.
What irks me most about this update is that subclipse and epic stopped working. These are installed from the Fedora repository. I can find no way to get them working again other than installing them from the original projects websites via the update manager. Did i only get half the update? Or am i missing something?
(In reply to comment #8) > What irks me most about this update is that subclipse and epic stopped > working. These are installed from the Fedora repository. > > I can find no way to get them working again other than installing them > from the original projects websites via the update manager. > > Did i only get half the update? Or am i missing something? Removing .eclipse and running eclipse -clean should fix it. If not please remove .eclipse, run eclipse -clean -debug -consolelog and attach the log here.
Removing .eclipse and running eclipse -clean fixed the problem. subclispe and epic are working again. Now i'm somewhat curious. Why didn't removing .eclipse and running eclipse without the -clean switch not work. Is there another location, besides .eclipse and the workspace, where eclipse stores data i do not know about?
Removing .eclipse should have worked. Perhaps there was something cached in the workspace? -clean doesn't force a reconciliation of the dropins directories AFAIK.
I experienced this problem with Eclipse / CDT. I could not solve the problem by deleting/moving the .eclipse directory and starting eclipse with the -clean option, as suggested above. However, the problem went away when I removed the .eclipse directory and started eclipse as root. I opened the problem workspace, opened the required perspective (which was now visible) and then closed eclipse. When opened again as a non-root user, the perspective was restored. I can't explain this behaviour but it might be of use to someone else...
Please don't run Eclipse as root. Ever. It will write to /usr/lib{,64} and can completely mess things up for non-root users. Removing .eclipse should work with 3.4.x (3.5.x will be in F-12 and above which has a fix for this issue). Try a clean workspace as well if that doesn't work.
FC12 yumex 14:06:44 : ERROR: Dependency resolving completed with errors 14:06:44 : ERROR: Missing Dependency: eclipse-cdt = 1:6.0.0-10.fc12 is needed by package 1:eclipse-cdt-mylyn-6.0.0-10.fc12.i686 (fedora) 14:06:44 : ERROR: Missing Dependency: eclipse-cdt = 1:6.0.0-10.fc12 is needed by package 1:eclipse-cdt-sdk-6.0.0-10.fc12.i686 (fedora) It would be nice (since Qt4.5 is included) to add the Eclipse Qt designer plugin so Eclipse allows the qt designer.
(In reply to comment #14) > FC12 yumex > > 14:06:44 : ERROR: Dependency resolving completed with errors > 14:06:44 : ERROR: Missing Dependency: eclipse-cdt = 1:6.0.0-10.fc12 is needed > by package 1:eclipse-cdt-mylyn-6.0.0-10.fc12.i686 (fedora) > 14:06:44 : ERROR: Missing Dependency: eclipse-cdt = 1:6.0.0-10.fc12 is needed > by package 1:eclipse-cdt-sdk-6.0.0-10.fc12.i686 (fedora) I see all three in the repository. Perhaps a yumex bug? If this problem persists, please open a new bug against eclipse-cdt package. Thanks. > It would be nice (since Qt4.5 is included) to add the Eclipse Qt designer > plugin > > so Eclipse allows the qt designer. There's a wish list on the Fedora wiki. It's easy to package if you're interested in doing it. See: http://fedoraproject.org/wiki/Packaging:EclipsePlugins
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.