Bug 1302131 - eclipse-cdt-arduino entirely non-functional
eclipse-cdt-arduino entirely non-functional
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: eclipse-cdt (Show other bugs)
23
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Roland Grunberg
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-26 16:55 EST by Dennis W. Tokarski
Modified: 2016-03-10 22 EST (History)
6 users (show)

See Also:
Fixed In Version: eclipse-cdt-8.8.0-6.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-23 14:23:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log file from eclipse -consoleLog -debug (302.74 KB, text/plain)
2016-02-08 17:29 EST, Dennis W. Tokarski
no flags Details
Attachment for comment #13 (302.47 KB, text/plain)
2016-03-10 22:34 EST, Dennis W. Tokarski
no flags Details
Another attachment for Comment #13 (302.47 KB, text/plain)
2016-03-10 22:38 EST, Dennis W. Tokarski
no flags Details

  None (edit)
Description Dennis W. Tokarski 2016-01-26 16:55:40 EST
Description of problem:
After installing the eclipse-cdt-arduino rpm, there is supposed to
be a prefences menu for it under Window->preferences->C/C++. It
is not there.

The plugin also doesn't show up under Help->Installation Details.


Version-Release number of selected component (if applicable):
eclipse-cdt-arduino-8.8.0-3.fc23.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Install eclipse-cdt-arduino-8.8.0-3.fc23.x86_64. (and btw, on a clean
   system this of course pulls in all the necesary support including
   eclipse-cdt, but also an extra 120 Megs or so by way of eclipse-jdt
   and eclipse-pde...seriously, WTF???? Does the use of plugins really
   require the plugin development environment??)
2. Look under Window->preferences->C/C++, observer no "Arduino" entry
3. 

Actual results:
Plugin is neither usable nor discoverable.

Expected results:
Expected plugin to become available and work.

Additional info:
Erasing the cdt-arduino rpm and installing the plugin from the
Eclipse Marketplace works as expected. But this is a single
user only installation and not system wide, so that's somewhat
unsatisfactory.

The rpm drops its files in /usr/lib64/eclipse/dropins. Permissions
look OK, matching other plugins which do work. Moving the files into
reasonable places from cdt-arduino to cdt doesn't help. Neither does
renaming cdt-arduino to simply arduino. Maybe there's a manifest
that needs updating and the post-install scripts are missing it?

Being just a user, I don't know enough about the plugin system to
take any more guesses.
Comment 1 Roland Grunberg 2016-02-03 11:43:55 EST
Regarding CDT Arduino bringing in PDE, and JDT (which you're right, is crazy) :

It looks like org.eclipse.cdt.arduino.ui -> org.eclipse.remote.ui -> org.eclipse.ui.trace , and org.eclipse.ui.trace is something packaged as part of the Eclipse PDE UI, which then brings in the JDT. The requirement for org.eclipse.ui.trace is only so that the org.eclipse.ui.trace.traceComponents extension point may be used (http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fextension-points%2Forg_eclipse_ui_trace_traceComponents.html) . I think making the dependency optional could resolve this and I would even argue that it's an upstream bug.

On the other hand this can also be considered a Fedora packaging bug. org.eclipse.ui.trace ships upstream in the SDK but not in the platform product so there's some justification for placing it in PDE. However it has no dependency on other PDE components, so maybe placing it in platform would make more sense from a user download -size perspective.

Mat, thoughts ?



Regarding the missing arduino functionality, this also appears to be a packaging bug :

eclipse-cdt-arduino requires google-gson and apache-commons-compress but they aren't symlinked into the dropins folder during %install. eclipse-cdt doesn't build using %mvn_install so this would beed to be done manually.

!SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-03 11:37:21.646
!MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle com.google.gson 2.2.4.
!SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-03 11:37:21.646
!MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle org.apache.commons.compress 1.6.0.
Comment 2 Mat Booth 2016-02-04 11:03:07 EST
(In reply to Roland Grunberg from comment #1)
> Regarding CDT Arduino bringing in PDE, and JDT (which you're right, is
> crazy) :
> 
> It looks like org.eclipse.cdt.arduino.ui -> org.eclipse.remote.ui ->
> org.eclipse.ui.trace , and org.eclipse.ui.trace is something packaged as
> part of the Eclipse PDE UI, which then brings in the JDT. The requirement
> for org.eclipse.ui.trace is only so that the
> org.eclipse.ui.trace.traceComponents extension point may be used
> (http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.pde.doc.
> user%2Freference%2Fextension-points%2Forg_eclipse_ui_trace_traceComponents.
> html) . I think making the dependency optional could resolve this and I
> would even argue that it's an upstream bug.
> 
> On the other hand this can also be considered a Fedora packaging bug.
> org.eclipse.ui.trace ships upstream in the SDK but not in the platform
> product so there's some justification for placing it in PDE. However it has
> no dependency on other PDE components, so maybe placing it in platform would
> make more sense from a user download -size perspective.
> 
> Mat, thoughts ?
> 

You're probably right that this dep should be optional.

I was looking for what the idiomatic usage of this extension point is and interestingly, if you look at org.eclipse.jdt.debug or org.eclipse.jdt.launching which also make use of it, you'll find no deps on org.eclipse.ui.trace in their manifests.
Comment 3 Roland Grunberg 2016-02-04 12:18:19 EST
Dennis, could you try out the following builds to see if they resolve the issue on f23 :

This should solve the broken arduino issue :
http://koji.fedoraproject.org/koji/taskinfo?taskID=12855033
You'll need eclipse-cdt-8.8.0-6.fc23.x86_64.rpm, and eclipse-cdt-arduino-8.8.0-6.fc23.x86_64.rpm and possibly more depending on how many cdt bundles you have that would need to update as well.

This should solve the unnecessary dependence on eclipse-pde, eclipse-jdt :
http://koji.fedoraproject.org/koji/buildinfo?buildID=724986
You'll need just eclipse-remote-2.0.1-2.fc23.noarch.rpm

I'll probably end up backporting this even to f22.
Comment 4 Fedora Update System 2016-02-04 14:42:24 EST
eclipse-remote-2.0.1-2.fc23 eclipse-cdt-8.8.0-6.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b836b8a61b
Comment 5 Dennis W. Tokarski 2016-02-04 22:53:58 EST
OK, tried those but we're only half way there.

I only needed cdt, cdt-arduino, and -remote as it turned out. This
time jdt and pde were not pulled in.

But cdt-arduino still doesn't show up in preferences or the installation
details list.

google-gson and apache-commons-compress are installed but did not
get symlinked into the dropins directory as you mentioned they should.

Where precisely should those links point? I can at least try to set
them up manually and see if that's truly the only remaining problem.
Comment 6 Roland Grunberg 2016-02-05 11:11:57 EST
The links are part of the rpm (http://koji.fedoraproject.org/koji/rpminfo?rpmID=7325960) so they should be at those locations on the system. 
'rpm -qf /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/com.google.gson_2.2.4.jar /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/org.apache.commons.compress_1.6.0.jar' should return eclipse-cdt-arduino-8.8.0-6.fc23.noarch.
Comment 7 Fedora Update System 2016-02-05 18:51:28 EST
eclipse-cdt-8.8.0-6.fc23, eclipse-remote-2.0.1-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b836b8a61b
Comment 8 Dennis W. Tokarski 2016-02-05 22:30:59 EST
(In reply to Roland Grunberg from comment #6)
> The links are part of the rpm
> (http://koji.fedoraproject.org/koji/rpminfo?rpmID=7325960) so they should be
> at those locations on the system. 
> 'rpm -qf
> /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/com.google.gson_2.2.4.
> jar
> /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/org.apache.commons.
> compress_1.6.0.jar' should return eclipse-cdt-arduino-8.8.0-6.fc23.noarch.

Ah. They're correct then. I was looking directly in the dropins directory.

Still, eclipse doesn't see the plugin. And it gets stranger...

I have a laptop (Lenovo thinkpad T61) where I've been trying all this,
and a guest VM which I run on it. The host and the guest are both running
F23 up to data as of today. Just to be thorough, on each system I erased
all eclipse packages, then installed just the three new ones I need from the
set you pushed out, letting yum pull in the necessary requirements. So both
systems have the following set of eclipse packages: 

eclipse-avr-2.3.4-10.fc23.noarch
eclipse-cdt-8.8.0-6.fc23.x86_64
eclipse-cdt-arduino-8.8.0-6.fc23.x86_64
eclipse-ecf-core-3.12.0-1.fc23.x86_64
eclipse-emf-core-2.11.1-1.fc23.x86_64
eclipse-equinox-osgi-4.5.1-7.fc23.x86_64
eclipse-filesystem-1.0-5.fc23.x86_64
eclipse-launchbar-1.0.1-0.1.git3c10977.fc23.noarch
eclipse-platform-4.5.1-7.fc23.x86_64
eclipse-remote-2.0.1-2.fc23.noarch
eclipse-rse-3.7.0-5.git97bd591.fc23.noarch
eclipse-swt-4.5.1-7.fc23.x86_64
eclipse-tm-terminal-4.0.0-3.fc23.noarch

(I added the eclipse-avr package later. Its presence or absence
seems irrelevant.)

I have also moved ~/workspace and ~/.eclipse out of the way to
force eclipse into thinking it's getting a fresh start.

Running eclipse on the VM system under Window=>preferences=>C/C++ I
see the Arduino entry between Appearance and Autotools; on the host
system it's not there. Likewise it can be seen under Help=>Installation
Details on the VM, but not on the host.

Is there somewhere else that eclipse squirrels away hidden state
that might be messing this up? Just for grins I logged into another
uid which has never before used eclipse and got the same result: no
arduino plugin menu entry.

Does eclipse keep any other startup logs I can fish through? I did find
what are supposed to be error logs under Help=>Installation Details
in the Configuration tab. On the VM there are a couple of lines for
each start showing the Arduino plugin being started. In the host log
the string "arduino" is not to be found.

I'm at a loss.
Comment 9 Roland Grunberg 2016-02-08 11:12:17 EST
Do you see other plugin contributions to the UI, like the C/C++ perspective, C/C++ preference page entry ? If not, this might indicate a deeper issue with the Eclipse installation itself, and not the just CDT.

The main location Eclipse modifies are in $HOME/.eclipse and the actual workspace location, so clearing/moving those should have worked. Also it's not recommended to run Eclipse as root. While I don't think you have I thought I'd mention it just in case, and an 'rpm -qV eclipse-platform' might reveal if it has been. Running as root in the past meant Eclipse would write to the shared location /usr/lib*/eclipse which pretty much destroyed the setup.

You could try creating a file called '.options' containing :

org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true

Then run : 'eclipse -debug -consolelog >log' from the same directory as the created .options file (generally in $HOME)

You can then cancel the workspace prompt, or just close it immediately and attach the contents of the log. If you see any messages about 'Unable to satisfy dependency', those would be relevant.
Comment 10 Dennis W. Tokarski 2016-02-08 17:29 EST
Created attachment 1122294 [details]
Log file from eclipse -consoleLog -debug

(In reply to Roland Grunberg from comment #9)
> Do you see other plugin contributions to the UI, like the C/C++ perspective,
> C/C++ preference page entry ? If not, this might indicate a deeper issue
> with the Eclipse installation itself, and not the just CDT.
> 

Nope, everything else shows up as it should. It's just the arduino plugin
that's a problem as far as I can see.

> The main location Eclipse modifies are in $HOME/.eclipse and the actual
> workspace location, so clearing/moving those should have worked. Also it's
> not recommended to run Eclipse as root. While I don't think you have I
> thought I'd mention it just in case, and an 'rpm -qV eclipse-platform' might
> reveal if it has been. Running as root in the past meant Eclipse would write
> to the shared location /usr/lib*/eclipse which pretty much destroyed the
> setup.
> 

'rpm -qV eclipse-platform' produces no output and return code zero. You're
right that root has never used eclipse.

> You could try creating a file called '.options' containing :
> 
> org.eclipse.equinox.p2.core/debug=true
> org.eclipse.equinox.p2.core/reconciler=true
> 
> Then run : 'eclipse -debug -consolelog >log' from the same directory as the
> created .options file (generally in $HOME)
> 
> You can then cancel the workspace prompt, or just close it immediately and
> attach the contents of the log. If you see any messages about 'Unable to
> satisfy dependency', those would be relevant.

Aha. I had discovered -consoleLog and -debug over the weekend, but the
output was very sparse and unhelpful. No mention of cdt-arduino at all
until I removed .eclipse and workspace, then this complaint showed up:

 61 !ENTRY org.eclipse.equinox.p2.publisher.eclipse 4 0 2016-02-08 16:53:12.070
 62 !MESSAGE Unable to acquire PluginConverter service during generation for: /usr/lib64/eclipse/dropins/cdt-arduino.

But the same complaint was issued for everything in dropins.

Now with your .options file the output is similarly sparse but at
least cdt-arduino is mentioned. Removing .eclipse and workspace first
produces much more information, log file attached.

This time there are a whole lot of "unable to satisfy dependency"
messages including:

!ENTRY org.eclipse.equinox.p2.director 2 0 2016-02-08 14:40:46.082
   1097 !MESSAGE Problems resolving provisioning plan.
   1098 !SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-08 14:40:46.082
   1099 !MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle com.google.gson 2.2.4.
   1100 !SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-08 14:40:46.084
   1101 !MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle org.apache.commons.compress 1.6.0.

'rpm -qv' for google-gson and apache-commons-compress produces no output
and return code zero. I'm tempted to reinstall those packages and see
what happens...but that might just destroy evidence if there's some more
obscure bug my setup happens to have exposed. It may be better to follow
this through to the end.

What next?
Comment 11 Roland Grunberg 2016-02-17 11:09:22 EST
Sorry for the delay, but this is quite strange to see.

The thing that stood out even more than the arduino.core failure are the org.eclipse.platform.ide failures :
!MESSAGE Unable to satisfy dependency from org.eclipse.platform.ide 4.5.1.v20160106-1000 to a.jre.javase [1.6.0].

As far as I know this happens with a corrupted Eclipse but if 'rpm -qV eclipse-platform' is quiet then this can't be the case. Is your '/etc/eclipse.ini' the same for both your host and VM ? Could you also try the following : 'find /usr/lib*/eclipse/ | xargs rpm -qf | sort -u'. This might take some time but I'm interested to see if the result contains anything of the form 'file $FILEPATH is not owned by any package'.

I'm able to reproduce the error by doing some things that Fedora Eclipse has explicitly prevented for a while.
Comment 12 Fedora Update System 2016-02-23 14:23:12 EST
eclipse-cdt-8.8.0-6.fc23, eclipse-remote-2.0.1-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 13 Dennis W. Tokarski 2016-03-10 22:32:17 EST
(In reply to Roland Grunberg from comment #11)
> Sorry for the delay, but this is quite strange to see.
> 
> The thing that stood out even more than the arduino.core failure are the
> org.eclipse.platform.ide failures :
> !MESSAGE Unable to satisfy dependency from org.eclipse.platform.ide
> 4.5.1.v20160106-1000 to a.jre.javase [1.6.0].
> 
> As far as I know this happens with a corrupted Eclipse but if 'rpm -qV
> eclipse-platform' is quiet then this can't be the case. Is your
> '/etc/eclipse.ini' the same for both your host and VM ? Could you also try
> the following : 'find /usr/lib*/eclipse/ | xargs rpm -qf | sort -u'. This
> might take some time but I'm interested to see if the result contains
> anything of the form 'file $FILEPATH is not owned by any package'.
> 
> I'm able to reproduce the error by doing some things that Fedora Eclipse has
> explicitly prevented for a while.

/etc/eclipse.ini is the same on the VM and the host.

The search for orphaned files on the VM turns up nothing:

   [root@raid-lvm-scratch Desktop]# find /usr/lib*/eclipse/ | xargs rpm -qf | sort -u
   eclipse-cdt-8.8.0-6.fc23.x86_64
   eclipse-cdt-arduino-8.8.0-6.fc23.x86_64
   eclipse-ecf-core-3.12.0-1.fc23.x86_64
   eclipse-emf-core-2.11.1-1.fc23.x86_64
   eclipse-equinox-osgi-4.5.1-7.fc23.x86_64
   eclipse-filesystem-1.0-5.fc23.x86_64
   eclipse-platform-4.5.1-7.fc23.x86_64
   eclipse-swt-4.5.1-7.fc23.x86_64

On the host I get this:

eclipse-cdt-8.8.0-6.fc23.x86_64
eclipse-cdt-arduino-8.8.0-6.fc23.x86_64
eclipse-ecf-core-3.12.0-1.fc23.x86_64
eclipse-emf-core-2.11.1-1.fc23.x86_64
eclipse-equinox-osgi-4.5.1-7.fc23.x86_64
eclipse-filesystem-1.0-5.fc23.x86_64
eclipse-platform-4.5.1-7.fc23.x86_64
eclipse-swt-4.5.1-7.fc23.x86_64
file /usr/lib64/eclipse/dropins/cdt-arduino/features is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/epl-v10.html is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/feature.properties is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/feature.xml is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737 is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/license.html is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/META-INF is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/META-INF/MANIFEST.MF is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/plugins is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/plugins/org.eclipse.cdt.arduino.core_1.0.0.201510090737.jar is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/plugins/org.eclipse.cdt.arduino.ui_1.0.0.201510090737.jar is not owned by any package


Interesting. Those orphaned features and plugins directories are from
the earlier and older eclipse-cdt-arduino which was installed from the repos
way back when. 

Here's what I think must have happened...recall I earlier mentioned moving some
of those directories around to see if the original package had just dropped them
in the wrong place. No joy, so later I moved them back where they belonged and
removed eclipse-cdt-arduino. But I must have moved those directories back to the
wrong place--they should have been under the cdt-arduino/eclipse directory. yum and
rpm will both complain if files they need to remove are already missing, but I
must have missed that. Afterward, of course, rpm will confirm the package is not
installed so I was happy. But those subdirectories got incorrectly left in place.

And that, it seems, was all it took to create the problem once the original package was fixed.

I think this definitively solves my original problem. 

However, you noted some log messages you said appeared wrong in comment #11.
That same example you gave plus numerous others still occur on both my host
and VM. I will attach both logs.

If this is really a separate issue and you want to pursue it, I'm happy to
experiment for you. Possibly one of us should open a separate bug report?

Thanks, Roland!

--Dennis
Comment 14 Dennis W. Tokarski 2016-03-10 22:34 EST
Created attachment 1135108 [details]
Attachment for comment #13

Log from the host system.
Comment 15 Dennis W. Tokarski 2016-03-10 22:38 EST
Created attachment 1135109 [details]
Another attachment for Comment #13

Log from the VM system.

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