MIR - move to main for openoffice.org 3 build-depends

Promoting the ones which already were in main in hardy.

> These packages are needed for build-depends of openoffice.org 3.0.0.

yes, but we need the MIRs anyway.

Matthias Klose [2008-12-07 17:23 -0000]:
> yes, but we need the MIRs anyway.

Context: Some of those were already reviewed for hardy, and many sound
trivial. We agreed that we can process the easy ones with just the
normal review that ~ubuntu-mir does anyway, and set the ones to
needsinfo which raise questions or look maintenance intense.

https://wiki.ubuntu.com/MainInclusionReport-commons-httpclient

https://wiki.ubuntu.com/MainInclusionReport-libcommons-codec-java

https://wiki.ubuntu.com/MainInclusionReport-lucene2

https://wiki.ubuntu.com/MainInclusionReport-saxonb

lp-solve and suitesparse have previously been in main during gutsy development (not at actual gutsy release)

lp-solve reviewed, approved, promoted.

suitesparse review/ack/promoted

commons-httpclient: needs update to current java packaging policy (default-jdk-builddep)

commons-httpclient: also needs binary depends update; don't prefer kaffe, use default-jre

libcommons-codec-java: likewise (kaffe -> default-jdk/jre)

lucene2: needs migration to default-jdk/jre, otherwise ok.

saxonb: needs default-jre/jdk migration

Also, this package is huge (3.7 MB), and OO.o already uses other XSLT processors during build. Is this just a build-time, or also a runtime dependency? If the latter, is it possible to use libxalan2-java, which the current OO.o already pulls in? Or does OO.o 3 move from xalan to saxonb?

libxpp2-java has kaffe from universe as build-dep too.

same here: libxpp3-java has kaffe from universe as build-dep.

libjaxen-java has build-depends on libxom-java, which depends on libjaxen-java ... maybe we can prevent this circle somehow?

libxom-java (xom) has depends on libjaxen-java, which build-depends on libxom-java.

libjtidy-java doesnt depend on anything:

according to debian/java policy section "2.4. Java libraries", it must depend on the proper runtime:
 > Java libraries must depend on the needed runtime environment (java1-runtime and/or java2-runtime) but should not depend (only suggest) java-virtual-machine.

javadb-je-java build-depends on glassfish-javaee which is in universe. probably needs to be added here too. also it should build-depend on default-jdk-builddep from what i see (and not java-gcj-compat-dev) afaiu.

libjaxen-java also needs to be migrated to default-jdk build depend.

xom also needs to be migrated to default-jdk

note: all four I did above. They also need default-jre (and not only -jdk):
 * libxpp2-java, libxpp3-java
 * libjaxen-java
 * libxom-java
 * libdb-je-java

also
 * libjtidy-java # needs default-jdk as build-depend

Hi,

I thought I would put some of the points regarding build/runtime dependencies here so anyone who works on fixing these libraries would know.
1. default-jdk-builddep is only required if there is a arch specific <name>-gcj binary package being built.
2. Most of the libraries do not need any UI apis from java runtime (awt, swing) and hence should depend on 'default-jre-headless | java2-runtime-headless'. In case the libraries are using source compatibility with new java versions (1.5 or 1.6) then the dependency should be modified accordingly.

Martin,

saxonb is a runtime dep also but only for openoffice.org-java-common which is not on the cd (afaik).

Chris

Actually the changelog says this:

"remove xalan/xerces conditionals, add saxon ones"

So it is changing from xalan/xerces to saxonb instead.

Most of the packages have been updated and converted to default-java now.

On Fri, Dec 19, 2008 at 04:23:13AM -0000, Chris Cheney wrote:
> Most of the packages have been updated and converted to default-java
> now.
>

Could you update the bug stati of the packages fixed accordingly, so
we know which ones to take another look at?

Thanks,

 - Alexander

The packages marked confirmed should be properly converted now.

jaxme - FTBFS when converted to default-java - debian bug 508956
libjdom1-java - I believe this package is ready as is.
lucene2 - FTBFS
xom - FTBFS - seemingly random worked on my system then didn't

Chris,

I don't see a reason wht lucene2 would FTBFS with conversion to default-java. Do you have a log anywhere?

Onkar,

lucene2 FTBFS at least on my jaunty chroot without even converting to default-java. However converting it to default-java FTBFS as well.

Chris

Chris,

I wonder what the problem is. As you can see at https://launchpad.net/ubuntu/jaunty/+source/lucene2, the last build was without problem. I will see tonight if I can convert it to default-java.

Onkar,

Well I'm building the java packages on amd64 arch so perhaps the jdk isn't quite bug-free on it. Just to make sure you understood what I said before, just a straight rebuild on lucene2 that is presently in the archive _as is_ without making any changes to it at all FTBFS, at least when attempting to build it on amd64.

Chris

Chris,

I understood you correct before. I tried building lucene2 yesterday on my pc (i386) and it failed there too. But it is worth mentioning that the build failure is due to failed unit test. It is possible that something in JRE has changed in recent version due to which this unit test failed.

I think for now we can bypass the failed unit test(s) and convert the package to default-j*. Meanwhile we should contact upstream asking them to analyze the unit test failure.

commons-httpclient approved, depends on codec-java

libcommons-codec-java approved/promoted

libcommons-digester-java a/p

jtidy approved. I promoted the source and libjtidy-java to main, but kept libjtidy-java-doc in universe, since it depends on classpath-doc. Would be good to fix, though (only suggest classpath-doc).

jaxme needs default-jdk conversion first, and the FTBFS resolved

libdb-je-java looks ok now. However, there is no chance to use libdb4.7-java, which is already in main? I don't see how a pure Java implementation, which doesn't even keep up with original libdb's transaction data format changes is more beneficial than using the official java bindings of db?

libjaxen-java: 2/3 of the deb is documentation, which ought to be split out to safe CD space. However, packaging is fine now, promoted.

libjdom1-java: sounds like the 1001st reimplementation of an XML parser *sigh*, but looks ok. Promoted.

This is also a target for documentation split out, although it only buys 150 KB compressed. Might become relevant when under pressure.

libxpp[23]-java a/p

dom4j: *yet* another DOM parser, argh! a/p, I guess we don't have much choice.

saxonb a/p.

So the remaining issues here:
 - fix the three FTBFS (the three incompete tasks)
 - answer redundancy question about libdb-je-java (not a blocker, but it's not currently holding up building)

On Tue, Jan 06, 2009 at 10:56:37AM -0000, Martin Pitt wrote:
> libdb-je-java looks ok now. However, there is no chance to use
> libdb4.7-java, which is already in main? I don't see how a pure Java
> implementation, which doesn't even keep up with original libdb's
> transaction data format changes is more beneficial than using the
> official java bindings of db?

libs that require native bindings are not that commonly used in java
community because of its portability issues. Actually projects will
usually tend to migrate away from them because there is just no simple
way to ship it in a cross-platform fashion ... except for a few
rareexceptions (like swf).

In this sense getting changes for this into upstream tree sounds
unlikely.

So unless its really API compatible, I doubt that we can make
openoffice use that instead of libdb-je-java - and adding yet another
patch that stays with us forever wouldnt be scalable either.

 - Alexander

Hi all,
   It might be obvious Openoffice.org was being built in archive but
have dependancy wait on i386 for libstlport4.6-dev and for all other
architectures for liblucene2-java

https://launchpad.net/ubuntu/+builds?build_text=openoffice.org&build_state=all
--
          Regards,
          Shirish Agarwal
  This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17

I have uploaded lucene2 with default-j* changes in control file and a patch to disable the unit test that was causing build failure.

lucene2 a/p

libdb-je-java promoted

Chris,

Found the reason for the jaxme build failure that you have mentioned in the debian bug. OpenJDk has it's own implementation of javax.xml.bind.Marshaller and javax.xml.bind.Unmarshaller. Both these implementation contain an abstract method getListener.

$ javap javax.xml.bind.Marshaller |grep getListener
    public abstract javax.xml.bind.Marshaller$Listener getListener();
$ javap javax.xml.bind.Unmarshaller |grep getListener
    public abstract javax.xml.bind.Unmarshaller$Listener getListener();

There are two solutions to this.
1. Make sure that rt.jar is the last file in classpath when package is built. Not sure if this can be achieved from debian/rules file.
2. Patch the files in question from jaxme source to include empty implementations of this method.

I'll promote jaxme and xom to main for now, to unblock OO.o 3 for the next alpha. However, these two still need to be fixed.

xom is still failing due to the buildd and/or some weird bug in i386 openjdk-6. I just rebuilt it on my local machine and it built fine once again.

https://bugs.launchpad.net/ubuntu/+source/xom/+bug/329903

jaxme seems much more complicated than originally thought. I tried first moving/removing the rt.jar to the end of the classpath, that seemed to mostly work but then it died later in what appeared to be unit tests.

The I tried the adding empty classes method which so far seems to indicate Marshaller in java has been entirely rewritten since this library was last touched. I'm not sure how many empty methods I will end having to make before it will actually finish compiling and even if I do make them all I don't know if it will pass the unit tests. But I'm still working on this so it might actually end up working, who knows.

I'm not sure this is actually the proper thing to do with respect to all these new methods in Marshaller. Can someone who is more familiar with Java please take a look at jaxme?

Thanks,

Chris

It looks like the jaxme in their svn repository would probably compile with current Java, but the organization of the package has changed, so if someone is familiar with packaging of java programs packaging the new version may resolve this problem.

The fun bit is that the new jaxme uses maven, which seems to pull a lot more java packages into main.

Would it be possible to just pull in some changes (or the complete code) of the new upstream version, but otherwise keep the build system?

The directory layout of the new source appears to be completely different as well, so if it is it would probably require someone who knows what they are doing better than me. It has been several years since the last official release of jaxme.

Matthias,

I discussed this issue with Martin and he thought you might be able to resolve these two problems?

I do not know enough about Java to determine how to safely backport the changes needed for jaxme and updating to the subversion release seems to not be a good idea due not knowing if it is reliable also it switches to maven which brings in many more packages from universe.

The xom issue appears to be either something related to the buildd or something else causing the level of resources to increase such that it can't compile on the buildd. I am not sure what is happening here as it compiles fine on my local machine and the previous person who uploaded it had it compile fine for them as well. Perhaps some configuration file needs to be tweaked? I remember that something like that needed to be done in the past for gcj native compiles for OOo, but my memory may be faulty.

Chris