libxalan2-java to main - second take

[Wolfgang Baer]

Michael Koch wrote:
> On Sun, Mar 20, 2005 at 01:19:17PM +0100, Wolfgang Baer wrote:
[...]
>>
>>The documentation is build with xalan (I do not mean the javadocs here)
>>and therefore fails in a chroot environment as I get GTK-Warning
>>errors, -Djava.awt.headless=true seems to have no effect.
>>
>>I didn't find something in the policy which states that a package must
>>be buildable in a chroot environment. I do not know if therefore a
>>FTBS in a chroot is RC if it is buildable outside a chroot.
>>
>>If it must be buildable in chroot environment, there would be the
>>(less preferable) possiblity to omit the documentation from the
>>libxalan2-java-doc packages except the javadocs. And later add them
>>back if the free vms are capable of using the -Djava.headless=true
>>property.
> 
> 
> Sounds like a bug somewhere. gjdoc had this behaviour under some
> circumstances too.

I also thought the -Djava.awt.headless feature is working.

> 
>>gjdoc needs some change in the startup script to pass needed java
>>vm options to the used vm. In this case I need to pass -xm256m to the
>>kaffe vm to not run out of memory. I think this could be solved easily
>>through allowing to pass vm arguments like:
>>
>>exec ${JAVA} ${VM_ARGS or something} -classpath ${gjdocpath} gnu.classpath.tools.gjdoc.Main ${1+"$@"}
>>
>>What do you think, Michael ? Is this achievable - or any other ideas.
>>Currently gjdoc runs everytime with the default memory scheme of the
>>executing vm - this way we could influence the vm arguments parameters.
> 
> 
> Please file a bug for this against gjdoc. This should be fixed upstream.
> And this way it doesn't get forgotten.

Regarding libxalan2-java to main:

I think we can risk to ignore the GTK-Warnings when building in chroots.
If someone complains about not being buildable in chroot and thinks this 
is RC we can remove the docs - and only ship with the javadocs.

But to move to main - the gjdoc fix has to be made first :-)
I filed already a wishlist bug.

>>The other topic to discuss is - what about if gij-3.4 is removed from
>>debian after sarge. I don't think this will happen as gcc-2.95 is still
>>available in unstable. But if this will happen we need another way
>>to build libxalan2-java with free tools as otherwise we will have
>>to move a bunch of packages back to contrib.
>>
>>I think we can believe that either of the following is true after sarge:
>>- gcj-3.4 will stay in debian
>>- one of the free vms implements -Djava.endorsed.dirs (gcj is working
>>   on that already for the in this case needed w3c packages)
> 
> 
> Afaik sabelvm supports java.endorsed.dirs already. Perhaps you can use
> it to build the package.

I didn't succced neither with the java.endorsed.dirs nor with the
different bootclasspath features. The same for kaffe -Xbootclasspath/p
had also no effect. Strange.

I therefore would build it with gij-3.4 as it is available and will
be available for some more time. And gij is currently working on the
endorsed.dirs feature for w3c packages.

Wolfgang