Bugzilla – Full Text Bug Listing
| Summary: | Did XULRunner on build.eclipse.org change? | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | d_a_carver, grant_gayed, jacek.pospychala, overholt, sebastian.zarnekow |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 287455 | ||
|
Description
David Williams
I've marked as blocker, since it prevents everyone's UI Unit tests from running. using rpm -qa | grep xul shows what mozilla-xulrunner190-1.9.0.13-1.4 is installed. And, using rpm -qi mozilla-xulrunner190-1.9.0.13-1.4 shows it was installed on Mon 24 Aug 2009 12:05:01 PM EDT This 'fits' with our "last good build" since our builds are stamp with UTC times. So, eastern time, last good UI test was done at 11:15. I'm not sure what was previously installed, or why changed, but on my "local" linux machine, I have xulrunner-1.9-1.el5 which works fine with Eclipse. Did you intentionally "downlevel"? Of course, I just half understand this stuff, so could be something else entirely. I think we might be seeing a dupe of bug #234910. I looked through the output of rpm -qa --last and it *appears* that prior to yesterday we had Firefox 2.0 with no separate xulrunner RPM. Now it appears SLES 10 SP2 has moved to separate xulrunner and firefox3 packages. Grant, does xulrunner 1.9.0.13 ring any bells for you? We're seeing the same error that Andrew Niefer saw here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=234910#c3 Did XULRunner Change? I was asked to install it in bug 286646 .... (In reply to comment #4) > Did XULRunner Change? I was asked to install it in bug 286646 .... > Yes, there are incompatibilities with the latest XULRunner and eclipse. I believe the platform is aware, but wasn't able to address it in time for Galileo release. Eclipse 3.5 should be fine with any xulrunner <= 1.9.1. The error gives the impression of a problem with xulrunner (libxul.so could not resolve a gdk symbol), but I'd like to give it a try on the build machine. I hate to sound selfish, but bug bug 286646 was for one project ... and now that change is effecting many. Plus, they appear to have the ability to "point to" and use whatever XULRunner they'd like, in their own directory, so ... I'd say if this puzzle isn't solve in the next few hours the change for bug 286646 should be reverted, until understood and solved. That said, I don't want to mess up Grant's "experiments", if ongoing. Plus, I've added Jacek to CC of this bug to make sure we don't break ATF "mid build". Jacek, can you think of a reason why your tests might pass, but eclipse IDE won't work? (Maybe you should test for that too :) Denis, did you config/make your own version of xul runner, or get a pre-built version? If pre-built, maybe the version of GDK used there was different than what's on build machine? I've spent some time investigating and am not sure why this is happening. Doing "ldd /usr/lib/xulrunner-1.9.0.13/libxul.so" indicates that the dependencies should all resolve, and the xulrunner glue step succeeds, which is when dependencies are loaded. I can continue looking into this later, but in the meantime, to unblock the other projects, the xulrunner install can move and ATF can point at it explicitly. Just do the following as root: ./xulrunner --unregister-global mv xulrunner <theAtfProjectRootOrWherever> sure, Denis you can revert changes made in bug 286646, if that affects others. I thought that there's no XULRunner installed on build.eclipse.org, but if so, where is it, so ATF could use it as well? It'd be perfect if build.server.org could have several versions of XULRunner available - at least 1.8.* and 1.9*, because ATF is targetting both (incompatible versions). For what its worth, I tried building xulrunner 1.9.1.2 from source distribution, directly on the PPC machine, and received the following errors during ./configure *** The pkg-config script could not be found. Make sure it is *** in your path, or set the PKG_CONFIG environment variable *** to the full path to pkg-config. *** Or see http://www.freedesktop.org/software/pkgconfig to get pkg-config. configure: error: Library requirements (gtk+-2.0 >= 2.10.0 gtk+-unix-print-2.0 glib-2.0 gobject-2.0 gdk-x11-2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. So, poked around a bit (remember, I only half know what I was doing) and set export PKG_CONFIG=/usr/lib/pkgconfig ran again, and then got *** Your version of pkg-config is too old. You need version 0.9.0 or newer. *** See http://www.freedesktop.org/software/pkgconfig configure: error: Library requirements (gtk+-2.0 >= 2.10.0 gtk+-unix-print-2.0 glib-2.0 gobject-2.0 gdk-x11-2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. So ... it may not be directly related to original error here ... but, to me, is a sign that some stuff is "out of date"? Plus, if I'm reading this right, the error message mentions library requirement of gtk+-2.0 >= 2.10.0 implies our build.eclipse.org version gtk2-2.8.11-0.24 is too old for this version of xulrunner? build.eclpse.org is anything bug a "desktop machine" so it's not surprising it have "old" versions installed since it's just never mattered before. XULrunner had some dependencies, which were installed as well. mozilla-xulrunner190-gnomevfs-1.9.0.13-1.4 Mon Aug 24 12:05:03 2009 mozilla-xulrunner190-1.9.0.13-1.4 Mon Aug 24 12:05:01 2009 firefox3-gtk2-2.10.6-0.4.3 Mon Aug 24 12:04:43 2009 firefox3-atk-1.12.3-0.4.3 Mon Aug 24 12:04:13 2009 firefox3-pango-1.14.5-0.4.3 Mon Aug 24 12:04:11 2009 firefox3-glib2-2.12.4-0.4.3 Mon Aug 24 12:04:03 2009 firefox3-cairo-1.2.4-0.4.3 Mon Aug 24 12:04:01 2009 If it's all right with you guys, I'll just remove all those packages that I installed Aug 24 and call it a day. Make sense? (In reply to comment #11) > ... > If it's all right with you guys, I'll just remove all those packages that I > installed Aug 24 and call it a day. Make sense? > Sounds right to me ... but you probably weren't asking me. :) Jacek, if you have a version that works "in your home directory", as you said in bug 286646#3, I think you could put that in subdirectory in /shared/common/ as well as any future versions you'd get/compile for the ppc architecture. Yes, I was asking you, since you're our fearless leader :) All the new packages are gone: rpm -qa --last | head -10 evms-gui-2.5.5-24.67.2 Mon Jul 13 15:54:48 2009 Feel free to test and close as appropriate! (In reply to comment #12) > Jacek, if you have a version that works "in your home directory", as you said > in bug 286646#3, I think you could put that in subdirectory in /shared/common/ > as well as any future versions you'd get/compile for the ppc architecture. good idea. It's in /shared/common now. All, sorry for trouble! I hope your tests are as green as ATF's now ;-) We're green again. Makes me wonder how we're working at all :) ... but we're back to happy state. Thanks, everyone. *** Bug 287455 has been marked as a duplicate of this bug. *** To cross reference, this issue has popped back up. See bug 295394. (Not sure exact same reasons ... but same error message). |