Fedora 14 surprises

Well, I had two big surprises in Fedora 14:

1. Eclipse CDT immediate crash: I didn’t expect it at all, and it was very hard to believe, but it was correct. The Eclipse shipped with Fedora 14 is broken by default. Just open a C/C++ project in it and let it start indexing the project… in a few seconds Eclipse will crash. Update: apparently this bug only affects 64bit installs (Fedora 14 x86_64)

Well, it turned out that the problem is in the OpenJDK version shipped with Fedora 14, and I forced to install a propriety JDK to have a working eclipse. Fortunately, a workaround is being identified recently and the bug is being worked on. The bug not only affects Fedora 14 OpenJDK, but also the next version of propriety JDK too: if you install the next to-be-released JDK 6 (update 23) you’ll see the same problem.

Fedora is known as a developer friendly distro, and seeing such a problem with Eclipse – being an important development IDE – is very sad. What was very surprising for me was this: why this bug was not identified sooner (more on this follows at the end)? You can see that duplicates have started to appear soon after release…

2. I enabled “ir” keyboard layout and soon realized that Ctrl+Space (prints a ZWNJ character very useful in correct Persian typing)doesn’t work. After reporting, it became clear that this bug is actually the same as this one which I myself had reported a while back and was fixed in an update. I thought that the update will make it into final Fedora 14 release, but it didn’t. It is now available as an update for Fedora 14, but it was much better if it was in Fedora 14 release. This bug affects many keyboard layouts, so it will cause a negative impression. Anyway, if you do use keyboard layouts other than us, you should probably update your xorg-x11-xkb-utils package to make sure that all keys function as expected.

What is clear from the above is that we really need much more tests in Fedora pre-releases. While Fedora QA team is doing a great job, and they are becoming better and better each release, but there are still many use-cases not covered by their test lists. Also, it is clear that we need much more community involvement in Fedora testing. Personally, I didn’t find the Eclipse bug until late after Fedora 14 RC1 release. While I started testing F14 since Alpha (I never was able to install Alpha as I mentioned earlier, because of inability to install from an NTFS partition which is also true with F14 unfortunately), but it was after deciding to use RC1 seriously that I tryed Eclipse. I regret it now. But this makes it clear that (almost?) no one has tested Fedora 14 x86_64 Eclipse before release; and it is shocking a little; considering the importance of this application. (Update: added x86_64 to make it clear that the bug is for x86_64 only)

The second bug is another example: I found the bug in Fedora 14 Beta, and was surprised that why almost nobody had catch it before.

The point of this post was not complaining about the bugs, but to say that we need to encourage more testing of Fedora pre-releases. Another thing is that we should expand the current test cases considerably. Different aspects of a distribution needs to be tested which are much more than current test cases. Currently, a set of packages are recognized as “critical-path” packages. As they are critical, there should be test cases covering them. The second mentioned bug falls in this category: the bug is in a critical-path package.


20 responses to this post.

  1. I don’t agree that noone is testing Eclipse in rawhide. I’m doing this everyday and using it for development but the bug you refer to happens to be just on 64bit installs and a number of people happen to stay on 32bit for some reason.


    • I’m now more than happy that I’d put an “almost” in my sentence. I’ll edit the post though to make it more clear, but I think it still shows that we are very short on testers. Such an application doesn’t need many testers?… I don’t know how much 32 bit testers we have, but I wonder if they are many…


      • The only testers I know are Eclipse plugins developers which doesn’t make us the best testers. We have so many ideas for things to implement/enhance that any help is welcome.
        Actually we need people taking care of the base Java libraries most. Because currently we (Eclipse maintainers) get more bugs than we can take care of. Note that this are not just Eclipse bugs but bugs in Ant, Maven, apache-commons and so on. And if we count the time spend on updating new versions it looks like we spend more time on the libraries below Eclipse compared to Eclipse+plugins.

      • Yeah, the main point of my post was just that: we need more testers. And I personally will try to do more tests in future. I’m also thinking if we can try having some package specific “unit tests”. Maybe we can come up with a suggestion for AutoQA… but anyway, more real testers is a must anyway (put aside the need of more packagers you mentioned).

        Finally, thanks a lot for the great work you are doing. 🙂

  2. Posted by Jesse Keating on November 9, 2010 at 3:38 am

    I used Eclipse extensively on F14 from branch point on through the release. And I’m on x86_64. However I use it for python development, not C, and thus it did not crash on me. With software such as eclipse, the possible use cases are staggering. I grant that using it to develop C or C++ isn’t that far fetched, but most other people I know use it to develop java, and a few of us work in python. What we need is people to rally behind specific packages or package sets and define use cases to test for, in order to increase test coverage. And by people, I really mean volunteers.


    • Yes. I’d personally test it much sooner if I knew that it is not tested by others… apparently there is a lot to be done in “testing” area.


  3. Posted by mohsen on November 9, 2010 at 10:05 am

    thanks man, it was perfect


  4. Posted by Matěj Cepl on November 9, 2010 at 12:56 pm

    I see a huge difference between these two bugs:

    * Eclipse bug is just a bug. Stuff happens. Yes, it is sad how few C/C++ programmers use Eclipse (instead of vim/emacs/whatever), but aside from that I don’t see any systemic problem here. Of course, we programmers are more excited about this but I don’t think there is anything special to see about this.
    * ibus problem … this is bad. We terribly suck in testing (and feedback generally) for minorities (although speaking about Chinese+Indians+Persians+other Asians who need ibus as about minorities is a problem in itself). Not only people who need ibus, but also people who need accessibility stuff. I am just a Czech guy with locale cs_CZ, but even not having character out of iso-8859-1 makes me see in how many places we suck. I don’t dear to imagine how it would be if I am in the world outside of eight-bit codepages. And yes, even I always switch of ibus, because it (and its predecessors) crashed on me so much.

    Oh well


    • First, notice that the problem is not that few C/C++ programmers use Eclipse (Look at the popularity of the bug), the problem is that there are few people testing Eclipse CDT before Fedora release. And I consider Eclipse CDT an “important” fedora package which deserve to be checked to make sure that it at least works in very simple test cases after release and not “Just crash”.

      And a note about the second one: it was not an IBus bug, it is an Xorg XKB bug (more fundumental). 😛 And also, the bug affects any layout which uses a character defined by it’s hex code.


  5. Posted by Anonymous on November 9, 2010 at 9:36 pm

    Disappointingly, VirtualBox-OSE is also broken. The only “clean” solution seems to be to use the version at VirtualBox.org.


    • Well, notice that VirtualBox-OSE is a rpmfusion package and so is not considered a part of “Fedora”. And rpmfusion should have much less pre-release testers too…


  6. Posted by Moein on November 10, 2010 at 1:42 am

    Debian rocks !


    • Well, there is a difference between a fast paced, leading edge distribution and a conservative one. And I prefer the former! 😛 Look at the above, both of the bugs are upstream bugs; and finally someone should catch & fix them. And it is Fedora… 😀


    • Ubuntu 10.10 failed big time for me. After an update i ended up with a unrecoverable black screen.
      I am running fedora 14 now.



  7. Posted by Caleb on January 15, 2011 at 3:35 am

    Guyz, after installling my fedora 14, i cant c where i can start a new project of c++ or python in my eclipse, there is only General and CVS, how do you guyz start a project, CDT and pydev are already installed but i cant start a python project


    • Try installing the package: tomcat5-jsp-2.0-api and see if it solves your problem. (after installing the package run “eclipse -clean”)


  8. I’m facing the same problem as Caleb. Eclipse does not show C/C++ or Java in project list. I’m using Fedora 14 X86_64. I found that CDT is installed (yum list eclipse*). Could you please advise us to solve it?

    I’ve not migrated from Fedora 13, so Eclipse cacheing is not a issue here.

    Earlier I faced the problem, I’m not sure how it recovered (actually seemed to be recovered in a weired way). Seemed like adding some more plugins within Eclipse, and everything started working,


    • 1. Have you checked to see if tomcat5-jsp-2.0-api package is installed?

      2. If the above package is installed, you should check the eclipse error messages to see why the CDT/Java plugins doesn’t work. For the error messages, in Eclipse go to Help->About Eclipse Platform->Installation Details->Configuration->View Error Log
      You should see one or more exceptions or error messages which will indicate why those plugins doesn’t work.

      3. You can try running Eclipse with a different user to see if it makes any difference. If so, there is a problem either in your ~/.eclipse directory or in your workspace configuration.

      4. Have you ever run eclipse by root? This can cause problems too. If you’ve run eclipse by root even once, you should either remove all configuration files created in eclipse directories (which is a bit hard), or remove all eclipse packages and then remove any eclipse directories in your system to make sure that nothing is left and then reinstall eclipse.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: