Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1302131
Summary: | eclipse-cdt-arduino entirely non-functional | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dennis W. Tokarski <dwt> | ||||||||
Component: | eclipse-cdt | Assignee: | Roland Grunberg <rgrunber> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 23 | CC: | akurtako, eclipse-sig, jjohnstn, krzysztof.daniel, mat.booth, rgrunber | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
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 19:23:15 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Dennis W. Tokarski
2016-01-26 21:55:40 UTC
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. (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. 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. 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 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. 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. 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 (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. 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. 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? 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. 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. (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 Created attachment 1135108 [details] Attachment for comment #13 Log from the host system. Created attachment 1135109 [details] Another attachment for Comment #13 Log from the VM system. |