From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: The OpenOffice.org Base program shuts down very early on (like, when you ask it to create a new database, or ask it to connect to an existing database). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Start Base 2.Try to create a new database 3. Additional info:
Created attachment 112212 [details] demo test program compile with g++ java.c -lgcj
Created attachment 112213 [details] hsqldb.jar dump in cwd
running the attached program gives... java.lang.NoClassDefFoundError: while resolving class: org.hsqldb.jdbcDriver at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.newInstance() (/usr/lib/libgcj.so.6.0.0) at .__gxx_personality_v0 (/home/caolan/java/a.out) at .__gxx_personality_v0 (/home/caolan/java/a.out) at .__gxx_personality_v0 (/home/caolan/java/a.out) at .__libc_start_main (/lib/tls/libc-2.3.4.so) at .__gxx_personality_v0 (/home/caolan/java/a.out) Caused by: java.lang.ClassNotFoundException: org.hsqldb.persist.HsqlProperties not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./hsqldb.jar], parent=gnu.gcj.runtime.VMClassLoader{urls=[core:/], parent=null}} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0) ...8 more gcc/libgcj 4.0.0-0.34 Same works under sun-jdk-1.4.2.07
This is strange. org.hsqldb.persist.HsqlProperties really doesn't exist in hsqldb.jar. hsqldb is useful enough that we should package it on its own - especially if it will be installed by OO.o anyways. I've FC-ified the hsqldb JPackage. It passes your test. I'll attach it to this case. Is there any way you could use this instead of the one bundled in OO.o?
Created attachment 112216 [details] Proposed hsqldb package that passes the test case.
That's hsqldb 1.73.3 while OOo uses the 1.8.0RCX as from http://hsqldb.sourceforge.net/. The changes from 1.73.3 to hsqldb 1.8.0 are almost excluselively done to support OOo requirements apparently. A packaged 1.8.0 would be ideal.
Created attachment 112249 [details] Proposed 1.8.0RC9 SRPM
(In reply to comment #6) > That's hsqldb 1.73.3 while OOo uses the 1.8.0RCX as from > http://hsqldb.sourceforge.net/. The changes from 1.73.3 to hsqldb 1.8.0 are > almost excluselively done to support OOo requirements apparently. A packaged > 1.8.0 would be ideal. Okeedokes. See the newly attached draft 1.8.0RC9 SRPM.
Yup, works with OOo's database frontend. I'd prefer not to build my own hsqldb anyway, if you push hsqldb into rawhide I'll doctor things to use it.
Anthony, thanks for the upgraded srpm and for having copied me in this message. Please note that JPackage is an Open Source upstream project. We should not fork from community Open Source projects, but contribute our changes upstream first. To guarantee that we do not diverge, we have a procedure in place to handle cases like this. I happen to be one of the upstream maintainers of this package (with Ralph Apel which is not from Red Hat) and will gladly incorporate your changes upstream and then import it into dist CVS. Please don't add this new version directly into Fedora (or any Red Hat distro) without following the upstream route. I am attaching a fixed spec file with the version and release corrected to JPackage new standards. I will be building this upstream and merging it into the devel branch of dist CVS. I will not build the package though, as Gary is building all packages on Fedora. Will let you know as soon as it is done (we are handing off RHAPS V1 U1 tomorrow, so it is kind of hectic around here -- I will do my best to get it done fast though). Regards to all, Fernando
Created attachment 112265 [details] RPM spec file with fixed V-R
(In reply to comment #10) > Anthony, thanks for the upgraded srpm and for having copied me in this message. > > Please note that JPackage is an Open Source upstream project. We should not > fork from community Open Source projects, but contribute our changes upstream > first. To guarantee that we do not diverge, we have a procedure in place to > handle cases like this. Yes, I realize this. I sent a request to you and the jpackage-discuss list about upgrading just a short while ago. > I am attaching a fixed spec file with the version and release corrected to > JPackage new standards. I will be building this upstream and merging it into > the devel branch of dist CVS. Great - thanks! AG
Small problem: other packages in Fedora require the 1.7 series of hsqldb and have not been tested with the 1.8 RC. In jpackage.org I have no problem as we have a 'devel' area to keep these upcomming versions of packages, but we will have a collision in Fedora. The usual alternative is to create a temporary new package (different package name) for either the old version or for the new version. The former is safer but requires updating all the packages that depend on this one. The second has the inconvenience of interfering with the package when it is finally upgraded and requiring an Obsoletes, which will prevent the first approach in the future. I would prefer to use some non-standard name like hsqldb-oo for this release and then Obsoletes it when 1.8.0 is available. NOTE: When taking it upstream, I noticed that the version of the package is still wrong. For historical reasons (change in version numbering by the hsqldb folks) the version should be 1.80 (as opposed to 1.8.0). We are waiting for the 2.x series to correct this.
(In reply to comment #13) > Small problem: other packages in Fedora require the 1.7 series of hsqldb and > have not been tested with the 1.8 RC. No, nothing in Fedora depends on any version of hsqldb - except for OO.o. Perhaps you mean that other packages in JPackage.org require the 1.7 series. > The usual alternative is to create a temporary new package (different package > name) for either the old version or for the new version. [snip] > I would prefer to use some non-standard name like hsqldb-oo for this release and > then Obsoletes it when 1.8.0 is available. Well, if that's the case, perhaps there's no reason for it to go into JPackage at all, and we can just drop it into FC. Nothing in JPackage will depend on it.
Yes, but hsqldb is already part of the RHAPS stack that is being compiled with gcj and added to Fedora in Rawhide. Eventually that hsqldb package will be installed on Fedora systems, together with OO. We still need to avoid the collisions and keep things in a way that they don't interfere with future updates and so on.
Is testing RHAPS with 1.8RC9 is out of the question? Otherwise maybe it's best just to update OO.o's private hsqldb.
Well, the version for Fedora is a "progressive" one. But Andrew Healy wants to keep it as much as possible equal to the one in RHAPS and I can understand why (much easier to compare and track down toolchain/library problems). What we can do is to keep the private copy in OO and replace it in an update which may find 1.8.0 released and tested with JOnAS, JBoss ans others.
*** Bug 151967 has been marked as a duplicate of this bug. ***
*** Bug 151969 has been marked as a duplicate of this bug. ***
Well, if we can just decide how to deal with this hsqldb deployment issue, I can confirm that everything does appear to work at runtime with gcj. http://www.spindazzle.org/green/index.php?p=43 Caolan: Fernando is suggesting that we just update OO.o's private hsqldb for now. Is this a non-starter? The only other option right now seemed to be to make a FC-only hsqldb-oo package. Both of these would only be temporary measures until JPackage revs to hsqldb revs to 1.8. What do you think?
I'lll bump our internal version up to 1.8.0RC9, this is on the horizon for upstream as well anyway for unrelated issues. So when something like 1.9.90 shows up it'll be 1.8.0RC9 anyway.
The RPM that will be in Fedora will be hsqldb-1.80_1jpp_1fc this will probably happen shortly after the 1.8.0 HSQLDB release is officially out and the dependencies have been tested and proved to work with that version. As long as there isn't any RPM with the same name ('hsqldb') in the Fedora collection I am happy.
Bumped internal OOo hsqldb to 1.8.0RC9, works in 1.9.88-4. Upstream will also bump their hsqldb copy to 1.8.0.RC9 for 1.9.89 so issue is resolved from my POV.