Created attachment 457177 [details] screenshot of the dialog in question Description of problem: When trying to import new project from git://gitorious.org/bitlbee/bitlbee.git, git part works just fine. However, when it finishes another wizard jumps up to create a new C project. In the wizard I have selected "Don't share" and "Project Wizard" where I selected Make Project, and then just clicked Next. Got to the dialog shown below, where no clicking or selecting did anything. When I tried to reproduce this, I wasn't even able to start the wizard and the only possibility was not to make any project at all (i.e., select General Porject) and then tried to Convert to C/C++ project, which failed again with "Make Project", so I have just used plain C project, but that's suboptimal and not what normal user would expect and hope for. Version-Release number of selected component (if applicable): eclipse-platform-3.6.1-2.fc14.x86_64 eclipse-cdt-7.0.1-2.fc14.x86_64 java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.x86_64 eclipse-egit-0.9.3-1.fc14.noarch How reproducible: there is no clear way, many many weird issues, however certainly none of options I tried leads to a clear way how to Steps to Reproduce: 1.see above 2. 3. Actual results: Expected results: Additional info:
*** Bug 648924 has been marked as a duplicate of this bug. ***
(In reply to comment #0) I attempted to reproduce in a virtual f14 machine as I am currently still running f13. I was able to achieve some success, but it required some work. First of all, your project is an GNU Autotools Project. It requires that configure is run to create config.h. To get this working, I did Import->Git->Projects from Git I filled in the information for the git repository and then selected No sharing and Use Project Wizard. I selected C Project. I followed your instructions and the build immediately failed due to missing config.h. I deleted my project. I then tried to do it all again, but it claimed that bitlbee was already in the workspace. I couldn't see it in any of the views so I opened the Git Perspective and it showed me the bitlbee repository I had previously cloned. Right-clicking on the repository, there was an option to Import Projects which took me through the cycle again. This time, I chose a GNU Autotools Project (Empty Project). The C Project wizard warned me against calling the project bitlbee, but if I didn't choose that name, the project would end up empty. The build started and configuration failed because glib2 was missing. It turned out I had to "yum install glib2-devel" to remove this problem. I did a reconfigure and this time it complained that there was no ssl chosen. To get around this, I selected the Project->Properties->Autotools->Configure Settings and under Advanced, I added --ssl=openssl. I then did a clean build and the build went until it got to the lib directory where it complained that bitlbee.h was not found. The header file is found in the top-level directory so something is amiss in the build as I noticed this should have been covered in the Makefile.settings file. I stopped at this point as I clearly past where you got. My rpms are the same as yours, only I am running on an i686 box. Perhaps you can try what I did and see if you can get similar success. If it still fails, try looking in the error logs to see if a failure was logged. You can get there via Help->About Eclipse Platform->Installation Details->Configuration Tab->View Error Log.
(In reply to comment #2) > (In reply to comment #0) > First of all, your project is an GNU Autotools Project. It requires that > configure is run to create config.h. It is not ... that ./configure is a hand-made script, not generated by autotools (developer hates autotools as in his opinion too bulky). But maybe it doesn't matter from the Eclipse's point of view. > I then tried to do it all again, but it claimed that bitlbee was already in > the workspace. Yes, that was my experience as well. > I stopped at this point as I clearly past where you got. Yes, you did ... it seems to be fatal mistake to think that bitlbee is not Autools project (when it isn't), but that's certainly not a mistake in Eclipse. So, when I ran the wizard with GNU Autotools setting I've got an Eclipse project generated. Then indexing, rebuilding, etc. started and Eclipse crashed (bug 649234). When I have restarted Eclipse, indexing started again, but then stopped with Došlo k interní chybě během: "C/C++ Indexer". vtable stub (that's "There was an inernal error during: "C/C++ Indexer"). > You can get there via Help->About Eclipse Platform->Installation > Details->Configuration Tab->View Error Log. See attachment 457391 [details] So, the executive summary is that Eclipse crashed and it wasn't able to index project properly on the first run.
The vtable stub error means some class was cached and when unmarshalled it had changed since it was cached. I suggest a few things. 1. Move your ~/.eclipse directory somewhere 2. start with the -clean option on a brand new workspace 3. Try to re-import your project as a GNU Autotools C project Regarding the Autotools aspect: if you require that ./configure is run prior to building, you will need to use a GNU Autotools project or you have to create a custom builder to run it or else simply run it manually outside of Eclipse yourself prior to building. A regular Makefile project has no knowledge of configuration scripts.
btw: I also did a yum update after installing F14. If you happen to have a beta version, you might want to consider this as well. There might be a dependency that has changed.
(In reply to comment #3) > So, when I ran the wizard with GNU Autotools setting I've got an Eclipse > project generated. Then indexing, rebuilding, etc. started and Eclipse crashed > (bug 649234). When I have restarted Eclipse, indexing started again, but then > stopped with > > Došlo k interní chybě během: "C/C++ Indexer". > vtable stub > > (that's "There was an inernal error during: "C/C++ Indexer"). > > > You can get there via Help->About Eclipse Platform->Installation > > Details->Configuration Tab->View Error Log. > > See attachment 457391 [details] > > So, the executive summary is that Eclipse crashed and it wasn't able to index > project properly on the first run. I created an F14 virtual machine on my x86_64 laptop today and I am running into various crashes as you did. A member of the java group is experiencing similar problems with the CDT on f14 and x86_64. After some experimentation, it appears to be the jvm on x86_64 as he has noted the failures for lower levels of eclipse platform and cdt fail. As well, he has no such problems with the same levels of code on i686. Both of us are able to have things working fine with: java-1.6.0-openjdk-1.6.0.0-41.b18.fc13. I do not know if this is the latest version that will work, but it happened to be the version in f14 alpha live and I was not experiencing any problems in another f14 x86_64 virtual machine that has this version installed. As a workaround, consider grabbing the java-1.6.0-openjdk rpms (whatever you currently have installed, e.g. normal rpm, the javadoc rpm, and the devel rpm) from Koji for this f13 release on x86_64. You will have to remove your current openjdk rpms by using e.g.: sudo rpm -e --nodeps java-1.6.0-openjdk java-1.6.0-openjdk-devel java-1.6.0-openjdk-javadoc Go to the directory where you downloaded the jvm rpms and do: sudo yum localinstall java-1.6.0-openjdk*.rpm The yum localinstall will fill in any new dependencies in automatically. If you run into problems simply reinstall/update the openjdk rpms from your f14 yum repository. I was able to use this workaround successfully and after was able to build and index bitlbee on x86_64 f14.
(In reply to comment #6) > I was able to use this workaround successfully and after was able to build and > index bitlbee on x86_64 f14. Yes, user interface would deserve a lot of improvements (making a new project from repository is very fragile and any step from The Right Path™ leads to errors), but with old JDK I was able to import bitlbee project to Eclipse and edit it. So, bug 647737 is alive and well, but this one is NOTABUG.
(In reply to comment #7) > (In reply to comment #6) > > I was able to use this workaround successfully and after was able to build and > > index bitlbee on x86_64 f14. > > Yes, user interface would deserve a lot of improvements (making a new project > from repository is very fragile and any step from The Right Path™ leads to > errors), but with old JDK I was able to import bitlbee project to Eclipse and > edit it. > > So, bug 647737 is alive and well, but this one is NOTABUG. Would you be so nice to open bug reports for all the steps you think are misleading?
Created attachment 458525 [details] screencast of the process (In reply to comment #8) > Would you be so nice to open bug reports for all the steps you think are > misleading? I haven't said misleading, but too complicated and misbehaving in some parts. I have tried to create a small screencast of the process with my comments. Sorry, audio is apparently too low, you have to pull up the volume to max.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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