Bug 1759176 - Eclipse fails to install out-of-the-box on F31
Summary: Eclipse fails to install out-of-the-box on F31
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Mat Booth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
: 1806086 (view as bug list)
Depends On: 1759179 1759187
Blocks: F31FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2019-10-07 14:32 UTC by Mat Booth
Modified: 2020-05-04 16:50 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-05 10:55:43 UTC
Type: Bug


Attachments (Terms of Use)

Description Mat Booth 2019-10-07 14:32:11 UTC
When you attempt to install Eclipse on F31 you get the following error:


[mbooth@fedora31 ~]$ sudo dnf install eclipse
Last metadata expiration check: 0:24:07 ago on Mon 07 Oct 2019 14:28:53 BST.
Error: 
 Problem: package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - conflicting requests
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded
(try to add '--skip-broken' to skip uninstallable packages)


There are two "workarounds":

1) Users must first enable the eclipse module to install the latest version of modular Eclipse:

[mbooth@fedora31 ~]$ sudo dnf module enable eclipse:latest

2) Users must first disable all conflicting java modules to install obsolete ursine version of Eclipse:

[mbooth@fedora31 ~]$ sudo dnf module disable eclipse maven

Comment 1 Mat Booth 2019-10-07 14:40:36 UTC
I filed bug 1759179 against the maven module to stop filtering the glassfish-el package, which should allow the eclipse module to drop the glassfish-el package and fix the conflict.

Comment 2 Mat Booth 2019-10-07 14:53:21 UTC
I filed bug 1759187 against the eclipse module to stop shipping glassfish-el package, because we'll be able to consume it from the maven module instead.

Comment 3 Fedora Blocker Bugs Application 2019-10-07 15:05:06 UTC
Proposed as a Blocker for 31-final by Fedora user mbooth using the blocker tracking app because:

 The Eclipse IDE is not installable out of the box due to a conflict between modules and ursine package requirements. This will affect upgrades for users with Eclipse installed.

Comment 4 Zbigniew Jędrzejewski-Szmek 2019-10-07 15:50:32 UTC
This issue was discussed during today's FESCo meeting (see https://pagure.io/fesco/issue/2236#comment-602778), and we voted to make it a FE.

Comment 5 Mikolaj Izdebski 2019-10-31 07:39:22 UTC
Requested maven filter changes (bug #1759179) are implememented and available as updates in updates-testing-modular. However that doesn't fix the issue with Eclipse installability - neither eclipse-platform no glassfish-el are installable, see below.

The issue is that the old module version is still available from fedora-modular repo, even though updated module is available in updates-testing-modular (or updates-modular once the update is pushed to stable), and filter of the old module version seems to be in effect.

Contents of fedora-modular are frozen before GA and nothing can be altered in that repo. If maven filter was changed before GA (even during final freeze, as it had freeze exception) then it would be pushed to fedora-modular repo and would fix the issue. Post-GA update will land in updates-modular and won't fix the issue.

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular module provides maven
maven-1:3.5.4-5.module_f28+3939+dc18cd75.noarch
Module   : maven:3.5:2820190416211833:819b5873:x86_64
Profiles : default
Repo     : fedora-modular
Summary  : Java project management and project comprehension tool

maven-1:3.5.4-5.module_f28+3939+dc18cd75.noarch
Module   : maven:3.5:2820190416211833:819b5873:x86_64
Profiles : default
Repo     : updates-modular
Summary  : Java project management and project comprehension tool

maven-1:3.5.4-5.module_f29+6921+ca3ed728.noarch
Module   : maven:3.5:2920191030094746:868ae023:x86_64
Profiles : default
Repo     : updates-testing-modular
Summary  : Java project management and project comprehension tool

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular module info maven | grep Version
Version          : 2820190416211833
Version          : 2820190416211833
Version          : 2920191030094746
Version          : 2820190530101447
Version          : 2820190530101447
Version          : 2820190530101447

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular install eclipse-platform
Error: 
 Problem: conflicting requests
  - package eclipse-platform-1:4.12-6.module_f31+6165+9b01e00c.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular install glassfish-el
Error: Unable to find a match: glassfish-el

Comment 6 Bruce Bigby 2019-11-02 15:41:22 UTC
I'm seeing this problem, too.  I can't install eclipse-platform.

Error: 
 Problem: package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - conflicting requests
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded
(try to add '--skip-broken' to skip uninstallable packages)

Comment 7 Bruce Bigby 2019-11-02 15:43:25 UTC
I removed all eclipse modules and after attempting to reinstall eclipse-platform, the installation fails still.

Comment 8 Parminder Lehal 2019-11-05 21:19:38 UTC
when will this be fixed? What is the point of releasing fedora if even eclipse can't be installed? Is the whole point of release  to damage fedora trust and brand?

Comment 9 Serge Pavlovsky 2019-11-08 17:32:18 UTC
lol, it means current fedora is 30

Comment 10 Bruce Bigby 2019-11-14 19:59:39 UTC
Any outlook on this? Can I install a F30 toolbox on a Fedora 31 release? Then, I can install eclipse-platform in the F30  toolbox.

Comment 11 Bruce Bigby 2019-11-15 03:33:06 UTC
I was able to create a Fedora 30 toolbox with the commands ...

1. First, install the toolbox program, if you haven't installed it already.

   sudo dnf install toolbox

2. Now, create a fedora 30 toolbox.

   toolbox create --image registry.fedoraproject.org/f30/fedora-toolbox:30

3. Then, I enter it.  If you only have one toolbox, you can enter simply ...

   toolbox enter

   Otherwise, you will have to be more specific, such as ...

   toolbox enter --release 30

4. Installed eclipse

   sudo dnf install eclipse-platform eclipse-cdt

5. Install any other eclipse components that you need, etc., if any.

Comment 12 Bruce Bigby 2019-11-25 03:08:24 UTC
Is this ever going to be fixed?

Comment 13 Alexander Kurtakov 2019-11-25 06:21:06 UTC
(In reply to Bruce Bigby from comment #12)
> Is this ever going to be fixed?

This is blocked by fedora infrastructure issues and policies regarding modularity. As these are not things we (eclipse maintainers) can influence we strongly suggest trying our flatpak https://flathub.org/apps/details/org.eclipse.Java . It should provide you with very similar experience.

Comment 14 Bruce Bigby 2019-11-25 12:42:33 UTC
Okay, I'll give the Flatpak a try.

Comment 15 Bruce Bigby 2019-11-30 02:17:24 UTC
The Flatpak appears to be just for Java.  I want CDT.  Now, I tried the first of the workarounds as a commenter described earlier, ...

----------------

There are two "workarounds":

1) Users must first enable the eclipse module to install the latest version of modular Eclipse:

[mbooth@fedora31 ~]$ sudo dnf module enable eclipse:latest

2) Users must first disable all conflicting java modules to install obsolete ursine version of Eclipse:

[mbooth@fedora31 ~]$ sudo dnf module disable eclipse maven

------------------

and eclipse installed okay, but when I open a project and attempt to open a new source file, eclipse hangs so I have to kill it, but when I reopen eclipse, the file that I attempted to open is open in an eclipse tab. Unfortunately, since the Fedora 31 eclipse is newer than the fedora 30 eclipse in my toolbox, now I can run the fedora 30 eclipse safely without compromising the integrity of my eclipse projects.  :-(

Comment 16 Jan Vlug 2019-11-30 09:42:52 UTC
@Bruce Bigby: Did you consider / test to install Eclipse from the download as it is directly distributed by the Eclipse Foundation?

Comment 17 Kenneth Soerensen 2019-11-30 10:02:29 UTC
For Eclipse CDT I can recommend to download eclipse-cpp-2019-09-R-linux-gtk-x86_64.tar.gz and extract it to /opt/. That worked out-of-the-box for me.

Comment 18 Andy Green 2019-12-01 07:52:34 UTC
(In reply to Bruce Bigby from comment #15)
> The Flatpak appears to be just for Java.  I want CDT.  Now, I tried the
> first of the workarounds as a commenter described earlier, ...
> 
> ----------------
> 
> There are two "workarounds":
> 
> 1) Users must first enable the eclipse module to install the latest version
> of modular Eclipse:
> 
> [mbooth@fedora31 ~]$ sudo dnf module enable eclipse:latest

This was all it needed for me.

But this was quite a major issue for Fedora release, I use eclipse cdt a lot and it's DOA for weeks.

> and eclipse installed okay, but when I open a project and attempt to open a
> new source file, eclipse hangs so I have to kill it, but when I reopen
> eclipse, the file that I attempted to open is open in an eclipse tab.
> Unfortunately, since the Fedora 31 eclipse is newer than the fedora 30
> eclipse in my toolbox, now I can run the fedora 30 eclipse safely without
> compromising the integrity of my eclipse projects.  :-(

Arcane lore: Eclipse has always needed to be started from the commandline with a magic "-clean" arg to not blow itself to hell on old workspace after updates.

Comment 19 Bruce Bigby 2019-12-04 00:41:06 UTC
I know that I can install Eclipse from the Eclipse Foundation and put it in /opt. I've done that in the distant past.  Luckily, I'm not desperate since this is a home desktop and I'm not doing real work on it so I can wait for a fix, but if I get tired of waiting, I'll install Eclipse via the Foundation, or I'll consider porting my hobby project to Code Blocks.  It's great that we have choices.

Comment 20 Bruce Bigby 2019-12-04 00:52:57 UTC
Oh, by the way, I ran "eclipse -clean", and the hang still occurs. Puzzled.  Not sure how to debug this java process.

I attached to the Java thread that was using 100% CPU and this is the backtrace:

-----------------------------------------------------------------------------------

(gdb) where
#0  0x00007f7becb4ba0d in cairo_matrix_transform_point () at /lib64/libcairo.so.2
#1  0x00007f7becb3c91d in _do_cairo_gstate_user_to_backend () at /lib64/libcairo.so.2
#2  0x00007f7becb36e6d in _cairo_default_context_line_to () at /lib64/libcairo.so.2
#3  0x00007f7becb92a59 in cairo_line_to () at /lib64/libcairo.so.2
#4  0x00007f7bf407d52e in draw_error_underline () at /lib64/libpangocairo-1.0.so.0
#5  0x00007f7bf407d668 in pango_cairo_renderer_draw_error_underline () at /lib64/libpangocairo-1.0.so.0
#6  0x00007f7bf405584b in pango_renderer_draw_layout_line () at /lib64/libpango-1.0.so.0
#7  0x00007f7bf4055d54 in pango_renderer_draw_layout () at /lib64/libpango-1.0.so.0
#8  0x00007f7bf407f228 in _pango_cairo_do_layout () at /lib64/libpangocairo-1.0.so.0
#9  0x00007f7bde43dcaf in Java_org_eclipse_swt_internal_gtk_OS__1pango_1cairo_1show_1layout ()
    at /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.112.0.v20190908-0312/libswt-pi3-gtk-4928r15.so
#10 0x00007f7bf6dd85f6 in  ()
#11 0x0000000000000007 in  ()
#12 0x00000000ec830810 in  ()
#13 0x00000067ec830b40 in  ()
#14 0x00000000ec82d620 in  ()
#15 0x00000000c077c8a0 in  ()
#16 0x00007f7bf708ceec in  ()
#17 0x00000000c077d7f8 in  ()
#18 0x00007f7bf709ee68 in  ()
#19 0x00000001001f53c0 in  ()
#20 0x00007f7bf7084418 in  ()
#21 0x0000004400000002 in  ()
#22 0x00007f7c048c7b50 in  ()
#23 0x00000000ebbeea50 in  ()
#24 0x00000000ec82d620 in  ()
#25 0x00000001001f53c0 in  ()
#26 0x00000000ebbeea50 in  ()
#27 0x0000000000000007 in  ()
#28 0x00000000fa618a58 in  ()
#29 0x0000000000000001 in  ()
#30 0x0000000000000011 in  ()
#31 0x0000000000000009 in  ()
#32 0x00007f7b00000000 in (anonymous namespace)::AtomicExpand::tryExpandAtomicRMW(llvm::AtomicRMWInst*) () at /lib64/libLLVM-9.so
#33 0x00007f7c05f31840 in  ()

---------------------------------------------------------------------------------------------------------------------------------

Maybe this will help. Don't know.

Comment 21 Bruce Bigby 2019-12-04 02:15:26 UTC
Never mind.  Sadly, the pango lines in the back-trace reminded me that pango appears to have a problem with the "Comic Mono" font, which I downloaded from site,

https://dtinth.github.io/comic-mono-font/

and love absolutely!  Sadly, I can't use it for Eclipse or Gnome Builder.  I filed a bug report against pango, but I have no idea whether the problem is indeed with pango or the font itself.

Fortunately, Comic Mono works as my main Gnome Shell mono font. I've had NO issues.  I've used "Comic Mono" in VSCode, too, but some applications seem to have a problem with it via pango.

To fix my Eclipse hang problem, I edited the file,

.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.workbench.prefs

and replaced all occurrences of "Comic Mono" with a different font name.  Now, Eclipse is fine.  I really wish that I could use "Comic Mono", because it really is a nice easy-to-read pleasant playful font to use.  Oh well.  Bummer. :-(

Comment 22 Bruce Bigby 2019-12-04 02:35:32 UTC
By the way, the font, "Comic Sans MS Regular", works fine, but it is a proportional font. I prefer a monospace font for programming. Comic Mono would be perfect, if it weren't for its fatal interaction with pango.

Comment 23 Bruce Bigby 2019-12-04 02:47:48 UTC
Yay! I found a mono-space font, called "Comic Relief", that is just as good as the "Comic Mono" font that I had been using.  If you're interested, see the URL,

https://www.fontsquirrel.com/fonts/comic-relief?q%5Bterm%5D=comic&q%5Bsearch_check%5D=Y


The main site URL is ...

https://www.fontsquirrel.com/

Comment 24 Bruce Bigby 2019-12-04 02:49:21 UTC
Actually, "Comic Relief" doesn't appear to be a monospace font.  I'll keep looking.  Sorry for cluttering up this bug report.

Comment 25 Mat Booth 2019-12-05 10:55:43 UTC
I believe we've managed to resolve all the necessary issues with FESCo, Releng and Modularity teams.

It should now be possible to install Eclipse from the Fedora repositories in the normal way:

$ sudo dnf install eclipse
$ # ... OR ...
$ sudo dnf groupinstall eclipse
$ # ... OR ...
$ sudo dnf module install eclipse


Don't forget if you explicitly disabled any modules, you will first need to reset them before installing Eclipse, e.g.:

$ sudo dnf module reset eclipse ant maven

Sorry for the inconvenience.

Comment 26 relentless.1980 2020-01-14 17:30:04 UTC
Today I cannot install eclipse.

I upgraded from Fedora 30 with eclipse 2019-03 installed a few weeks ago. Today I tried to launch it the for the 1st time after I upgrade to Fedora 31 but eclipse crashed during start up.
I removed eclipse via dnf and did 

$ sudo dnf module reset eclipse ant maven

thereafter I tried to install eclipse via dnf

$ sudo dnf install eclipse
Last metadata expiration check: 0:00:16 ago on Di 14 Jan 2020 18:28:53 CET.
Error: 
 Problem: package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - conflicting requests
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)

I did an dnf upgrade beforehand as well.

Please help

Comment 27 Kim van der Riet 2020-01-20 02:31:37 UTC
I am seeing the same as above. I upgraded from F30, but first had to uninstall eclipse to get the upgrade to work. Now, with F31 upgraded, I see the same message as Comment #26. I also performed the module reset mentioned above, but to no avail.

This is still broken, unfortunately.

Comment 28 Kim van der Riet 2020-01-20 02:45:37 UTC
If I enable the eclipse module first, then install eclipse, it works fine:

sudo dnf module enable eclipse:latest
sudo dnf install eclipse

In the event a user does not enable the module, is it possible to give a useful error message rather than a misleading one about unmet dependencies? Perhaps a hint?

Comment 29 Christian Krause 2020-04-08 13:00:45 UTC
I stumbled over this issue as well. On a fresh F31 installation, "sudo dnf install eclipse" does not work (output similar to comment #26). The workaround described in comment #28 helps.

I would still consider this a bug, since the well-known standard operation to install a package fails. The 1st described method of comment #25 is not working. Please re-open the bug report.

Comment 30 Zbigniew Jędrzejewski-Szmek 2020-04-08 14:15:22 UTC
$ sudo podman run -ti fedora:31 /usr/bin/bash
# dnf upgrade
...
# dnf install eclipse
Last metadata expiration check: 0:02:04 ago on Wed Apr  8 14:11:26 2020.
Error: 
 Problem: conflicting requests
  - package eclipse-jdt-1:4.14-5.fc31.noarch requires eclipse-platform = 1:4.14-5.fc31, but none of the providers can be installed
  - package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.14-5.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed

  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is filtered out by modular filtering <========
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e.noarch is filtered out by modular filtering <========

  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)

Yep, seems to be still broken.

Comment 31 Christian Krause 2020-04-13 20:16:51 UTC
*** Bug 1806086 has been marked as a duplicate of this bug. ***

Comment 32 Christian Krause 2020-04-13 20:20:11 UTC
Here is a potential work-around which worked for me:

Disable fedora-module (and updates-modular) entirely. Either by editing the according files in /etc/yum.repos.d/ or by disabling them on the command line.

Without having anything from the modular repositories installed, the following command line should install the non-modular eclipse version:

dnf --disablerepo fedora-modular --disablerepo updates-modular install eclipse


Note You need to log in before you can comment on or make changes to this bug.