RM: removal of gcj-4.3 and java-gcj-compat from unstable

[Matthias Klose]

Package: ftp.debian.org

Please remove gcj-4.3 and java-gcj-compat from unstable.

gcj is still used on hppa, kfreebsd and hurd(?), all other architectures use 
openjdk-6 as the default java.  the platforms above work ok-ish such that 
packages can be built, although with workarounds. gcj-4.4 looks better on these 
platforms than 4.3.  If we need an alternative for gcj-4.4 I'd rather package 
gcj-4.5 derived from the gcc-snapshot package just building the c, c++ and java.


All versioned dependencies on java-gcj-compat are fixed/removed [1], the 
gcj-jre, gcj-jre-headless and gcj-jdk packages provide the old java-gcj-compat 
packages.  java-gcj-compat should be removed together with gcj-4.3.


  Matthias

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=jgc-vdep;users=debian-j...@lists.debian.org



--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc0fa13.5060...@debian.org

Re: Latest sun-java6-plugin

[Matthias Klose]

On 09.04.2010 17:11, Sylvestre Ledru wrote:

Le vendredi 09 avril 2010 à 16:18 +0200, Niels Thykier a écrit :

Søren Holm wrote:

Hi

Apparently ypou are mossing to generate the symbolic link to libnpjp2.so in
/usr/lib/mozilla/plugins for java applets to work.

Could you please add it ??



Hi

I have moved this to debian-java@lists.debian.org (which is our debate
list).

Originally I would have opened a bug on this on your behalf, but I
noticed that I do not have this symlink either but I still have
functional applets.
   I use the icedtea6-plugin package and not sun-java6 to provide my
plugin though (and I am running a testing/Squeeze machine).

Is it this bug ?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518558


sounds like it. I think I missed the fix in sun-java to remove the old/add the 
new alternative on upgrade, like done in openjdk.



--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bbf5275.6080...@ubuntu.com

Re: [Summery] Re: Integrating the FOSDEM 06 Draft into the Java

[Matthias Klose]

On 27.03.2010 01:24, Matthew Johnson wrote:

On Fri Mar 26 21:47, Eric Lavarde wrote:

OK, I'm not exactly enthusiastic, but I can live with this, as long as
the wording of the policy is adapted accordingly.

Why I'm not enthusiastic: should I manage to get into Debian yet another
Java runtime, which is not compatible with either gcj, nor with openjdk,
then the result could be that quite a lot of packages wouldn't be policy
compliant anymore, because they wouldn't work with "all" JRE anymore.


I personally view adding more JREs as a bad plan. I believe we should be aiming
to reduce their number, ideally to one (at least, to one that behaves as
/usr/bin/java and that packages depend on; or - one that is _supported_ as
/usr/bin/java).

After all, despite multiple python interpreters, only one of them is supported
as /usr/bin/python.


there is more than one which is supported. only one of them is supported as the 
default. yes, using alternatives would break the dependencies of packages.


the handling of the java* binaries via alternatives bothers me. we do have 
update-java-alternatives to help people to ensure consistency with all links, 
but we cannot rely on these links to build stuff (all our packaging is based on 
a JAVA_HOME set). Various helpers and scripts do their own selection of the jvm 
used.


Ideally, every platform should build openjdk-6 (the last build added was the SH4 
port), but it requires some porting work which needs to be done (hppa), or 
backported/merged (bsd). Any help?


Even in openjdk-6 we currently have four different jvm's:

 - hotspot jit, used on x86 and sparc, with sparc not having upstream
   support, and unbuildable with b19

 - the zero port, an interpreter which is somehow platform independent
   (except for hppa).

 - shark (a jit extending zero), currently packaged as openjdk-6-jre-zero
   on x86, armel, powerpc.

 - the ARM assembler interpreter, an optimized zero interpreter for ARM.

 - cacao, a JIT integrated into openjdk-6, currently maybe usable on armel
   and powerpc.

Hmm, these are already five ...

For experimenting, you can access the various jvms using the -cacao|-zero|-shark 
options given to java (and installing the corresponding jre packages).


So the java situation looks more complicated than i.e. the python situation, 
where we still have one default implementation of the default interpreter.


If you reduce the number of JREs and maybe converge on the one available on most 
platforms (zero), you'll make java unusable on most platforms because of the 
performance of the interpreter. If you rely on a JIT, you are bound to the 
availability of the JIT on a specific architecture (both hotspot and shark 
(using llvm) not supporting all architectures).


Updating gcj using openjdk instead of classpath might be another way to provide 
a common jvm for all architectures.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bad8bd9.4030...@ubuntu.com

Re: [Summery] Re: Integrating the FOSDEM 06 Draft into the Java

[Matthias Klose]

On 26.03.2010 23:03, Mehdi Dogguy wrote:

Niels Thykier wrote:


Personally I disagree here, openjdk-6 comes with a webplugin
(icedtea6-plugin) that works very well for me.



It may work with common Java applets but doesn't work well for
cryptographic stuff. Ask any french guy that pays his taxes online :)


I fail to see your bug report. did you check with plugin in unstable?

  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bad8125.6060...@ubuntu.com

Re: Integrating the FOSDEM 06 Draft into the Java Policy

[Matthias Klose]

On 23.03.2010 11:54, Niels Thykier wrote:

Sylvestre Ledru wrote:

Le mardi 23 mars 2010 à 10:26 +0100, Niels Thykier a écrit :

Hi

I have compiled two patches against the current policy that I intend to
apply Friday assuming there are no objections.

Nice work. Glad to see that finally evolving.

Could you just add a few bit on the gcj part ?
* What it is/was ?


Personally I felt the first paragraph of the gcj part was enough. To the
best of my knowledge this is why the gcj stuff is. If you feel it is not
enough (and the addition draft below does not help), then I will need
some pointers to what you would like to see.

That being said I think it would be easier to understand if I replaced
"native code" with "machine code" and I intend to implement this with
the next diff.


* Why it is no longer allowed ?
* What kind of information are expected to grant a packager the
permission to ship gcj-code



Sure, what do you think of this:

In the past gcj packages were added in order to improve
performance of Java libraries and programs. However, this
performance comes at the cost of size, extra compilation
time and creates architecture dependent packages.


not only in the past.


A request for permission to add gcj should packages should
convince the Java Team that the performance boost of adding
the gcj package or packages out-weights the disadvantages.


this is always true for archs not having vm with a JIT.


The request and the permission may be limited to certain
architectures.


that should be removed. there is a list of these archs in
/usr/share/gcj/debian_defaults which should be sourced in debian/rules.
it's fine to build these packages on every arch. the empty package doesn't hurt, 
and you won't have to make changes to the packaging if a new architecture is added.


the packages do make sense for architectures which only come with the ZeroVM in 
OpenJDK, and no JIT.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba8c33c.8070...@debian.org

Re: Integrating the FOSDEM 06 Draft into the Java Policy

[Matthias Klose]

On 23.03.2010 10:26, Niels Thykier wrote:

Hi

I have compiled two patches against the current policy that I intend to
apply Friday assuming there are no objections.


mentioning default-jdk-doc would be useful.


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba8c38b.5060...@debian.org

Re: Bug#571532: gij: Bus error when executing ant

[Matthias Klose]

severity 571532 grave
thanks

On 27.02.2010 18:08, Torsten Werner wrote:

severity 571532 important
thanks

On Thu, Feb 25, 2010 at 10:43 PM, Matthias Klose  wrote:

so why does 1.7 work, and not 1.8?


I have no idea why gij fails with bus error. I have uploaded a new
source package ant1.7 that can be used by packages that are arch
dependent. Downgrading the severity because we will have a workaround.


We are short before the freeze; the release architectures still include 
architectures which require gij in it's current form (hppa, kfreebsd-i386 and 
kfreebsd-amd64). Please either port OpenJDK to these archs (hey, you're still an 
OpenJDK maintainer ;), or stay with the current ant version in testing. 
Packaging the 1.8 version as ant1.8 might be the better choice.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8966ef.2030...@debian.org

Re: Considering RM of jamvm and cacao

[Matthias Klose]

On 12.02.2010 21:30, Damien Raude-Morvan wrote:

Hi,

On 12/02/2010 20:29, Niels Thykier wrote:

Vincent Fourmond wrote:

[...]
+1. We basically only need openjdk and gcj (and the cacao variant of
openjdk, which is performing much better on some platforms, it seems).


Just for clarification, by "the cacao variant of openjdk" did you mean
"icedtea-6-jre-cacao", which is a part of the openjdk-6 source package?


In fact, cacao variant of openjdk is built using "cacao-source" source
package which openjdk-6 Build-Depends on.


I will just give a couple of days for people to reply to this - assuming
no one objects, I will (probably) file the RMs on Monday or Tuesday.


So on "cacao" case, I'm against dropping this package :
- "cacao" source package generate "cacao-source" which if a
Build-Depends of openjdk-6
- I think we might not drop openjdk-cacao-variant as it's the only
viable JVM alternative on some arch (alpha, mips, mipsel ?)


the cacao source package and the cacao binary package should be dropped. the 
cacao-source source package and the cacao-source binary package built from this 
package should be kept.


if classpath should be kept, then it should build-depend on cacao-source, and 
use the just built gjdoc to build its documentation.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b79a6cc.8010...@ubuntu.com

Re: State of openjdk on hppa

[Matthias Klose]

On 05.01.2010 19:13, Tom Rodriguez wrote:

openjdk builds on hppa, but doesn't run (yet). Andrew Haley once debugged it 
and found out at least one things which would need to be fixed: the assumption 
in the C++ interpreter that the stack always grows downwards, and not upwards 
as on hppa.

please could one of the hotspot developers sched some light on this, how easy 
this might to be fix, and if there are other assumptions?


Could you give more detail on where exactly the direction of growth is being 
assumed?  I know there's an accessor in frame that's supposed to describe the 
direction of growth of the expression stack which is used a few places in the 
code:

   // expression stack (may go up or down, direction == 1 or -1)
  public:
   intptr_t* interpreter_frame_expression_stack() const;
   static  jint  interpreter_frame_expression_stack_direction();

I would think this has to be set correctly for HPPA to work.  Is it?  It's 
possible that the C++ interpreter would also need to consult this when pushing 
values for it to work correctly.


thanks for the pointer. zero sets this independently of the architecture. now 
checking the obvious fix.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: swt-gtk 3.5.1 (updated package)

[Matthias Klose]

On 09.12.2009 00:03, Benjamin Drung wrote:

Am Dienstag, den 08.12.2009, 23:44 +0100 schrieb Matthias Klose:

On 08.12.2009 19:14, Adrian Perez wrote:

Hello Mathias.

Although is still an open discussion, we're making our best efforts to
not build SWT from eclipse at all, and just make it depend on the
swt-gtk generated packages.


no, that's the wrong thing to do. The packages should not be built twice. if you
have separate sources, then eclipse should *build-depend* on these packages, and
not build them twice.


Yes, that's what we discussed and intend to do.


Forgot to add that in this case, please package swt-gtk as a versioned source 
package, so that eclipse is still usable once a new swt-gtk-x.y is uploaded.



--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559986: FTBFS: default-jdk-builddep: Depends: gcj-jdk but it is not going to be installed

[Matthias Klose]

On 11.12.2009 05:25, Cyril Brulebois wrote:

Hi,

please note that even if the other bug (#560093) got closed, your
package still can't be built:
| The following packages have unmet dependencies:
|   default-jdk-builddep: Depends: gcj-jdk but it is not going to be installed
| E: Broken packages

(This is sid/amd64.)

Logging into the chroot, I'm getting this:
$ apt-get install -s default-jdk-builddep
→ fine.

$ apt-get install -s default-jdk-builddep gjdoc
→ default-jdk-builddep: Depends: gcj-jdk but it is not going to be installed

$ apt-get install -s default-jdk-builddep gcj-jdk
→ fine.

So it appears to me that having gcj-jdk provide gjdoc isn't
sufficient, since apt-get prefers the real package over the provided
one, stumbles upon some conflicts, and fails to figure out a solution;
while there are clearly “easy” ones.

  1. http://lists.debian.org/debian-devel-changes/2009/12/msg00756.html

I'm Cc-ing -java@, they might tweak some package relationships to help
package managers figure out a solution.


I would prefer to see gjdoc being removed for the release, if possible. for the 
packages build-depending it for now, just remove it from the b-d's and make sure 
that javadoc is used instead of gjdoc. If for some reason, you need it 
explicitely, maybe b-d on gcj-jdk | gjdoc. The list of packages are:


aspectj babel jaminid jesd jmdns libcsv-java libjibx-java mina trilead-ssh2 
weirdx

I'll care about gcj-4.3, and classpath should use the just built gjdoc like the 
gcj-4.4 build does.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: swt-gtk 3.5.1 (updated package)

[Matthias Klose]

On 08.12.2009 19:14, Adrian Perez wrote:

Hello Mathias.

Although is still an open discussion, we're making our best efforts to
not build SWT from eclipse at all, and just make it depend on the
swt-gtk generated packages.


no, that's the wrong thing to do. The packages should not be built twice. if you 
have separate sources, then eclipse should *build-depend* on these packages, and 
not build them twice.



--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Something fishy with java? sbuild/apt-get? edos?

[Matthias Klose]

On 08.12.2009 23:19, Cyril Brulebois wrote:

Niels Thykier  (08/12/2009):

For the babel case aptitude revealed the following problem:
default-jdk-builddep depends on gcj-jdk, which conflicts with gjdoc.

This is also the case for brltty; except the gjdoc is only an
indirect B-D.


Niels kindly reported the bug against java-gcj-compat-dev as #560093.

Since that wasn't caught by edos, I've opened #560099.


the mid-term solution is to use default-jdk. if gjdoc is a b-d, please change it 
to gcj-jdk-4.4 for now.


I'll see to have a temparary fix for this in the archive.

  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: swt-gtk 3.5.1 (updated package)

[Matthias Klose]

On 08.12.2009 15:15, Adrian Perez wrote:

Please process this upload.
Sorry about not including the link in the previous message, something I assumed 
;)
http://mentors.debian.net/debian/pool/main/s/swt-gtk/swt-gtk_3.5.1-1.dsc


what is the status of building these packages from the eclipse sources, instead 
of having a separate source package?


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: which source package has the source for javac in openjdk?

[Matthias Klose]

On 07.12.2009 14:22, Paul Wise wrote:

On Mon, Dec 7, 2009 at 9:05 PM, Vincent Fourmond  wrote:


  Admitedly, this way of packaging is not the most transparent there is.


Hopefully it will now be a thing of the past since we have dpkg-source
v3 formats are now accepted in the archive.


no, unless you write a patch for IcedTea to handle unpacked sources.

  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of openjdk on hppa

[Matthias Klose]

On 07.12.2009 14:36, Onkar Shinde wrote:

Hi,

java3d currently fails to build on hppa because it uses some sun
specific APIs and default-jdk is GCJ on hppa. A solution for this
could be to use openjdk-6-jdk build-dep instead of default-jdk. But
the problem is that there are no openjdk-* packages on hppa.

Does anyone know if there is any effort going on to make openjdk-*
packages available on hppa. If not then I will have to make java3d a
!hppa package.


openjdk builds on hppa, but doesn't run (yet). Andrew Haley once debugged it and 
found out at least one things which would need to be fixed: the assumption in 
the C++ interpreter that the stack always grows downwards, and not upwards as on 
hppa.


please could one of the hotspot developers sched some light on this, how easy 
this might to be fix, and if there are other assumptions?


thanks, Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: About eclipse (was Re: Package depending on netbeans)

[Matthias Klose]

On 12.11.2009 12:51, Niels Thykier wrote:

Sylvestre Ledru wrote:

Le jeudi 12 novembre 2009 à 00:05 +0100, Niels Thykier a écrit :

[...]
Hi

[...]
One of the prime factors for not uploading to Debian yet is that eclipse
does not use system jars but pre-bundled ones. We are currently working
on that and three other things[1] we want fixed before we upload to
Debian/Experimental.


IMO as seen with the Ubuntu upload you get broader testing with an uploaded 
version. There are architectures which are not yet tested by anybody like mips*, 
hppa. You maybe don't want to remove the code from the eclipse sources, but just 
use the system jars instead. Upload a first version now, and a "final" one later.



I believe most of these are already in the repository with an acceptable
version (once you have "translated" the between Fedora and Debian naming
and packaging conventions)- though I recall something about us
discontinuing tomcat5 due to lack of manpower.


Maybe an appropriate version, but all without the OSGi metadata. How is working 
on adding this?


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

default-jdk-doc - provide a non-changing path to the JDK api docs

[Matthias Klose]

Checked in a patch for java-common to build a default-jdk-doc package providing 
a symlink /usr/share/doc/default-jdk/api to currently point to the docs of the 
openjdk-6-doc package. Many packages already build-depend on openjdk-6-doc 
directly and will have to be rebuilt for the next openjdk-7 or whatever java 
version. Future uploads should use this package/path.


Not uploading, I think there are some policy changes pending for this package.

  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Latest sun java5 packages

[Matthias Klose]

On 22.09.2009 16:42, Diederik de Haas wrote:

On 2009-09-22 Dalibor Topic wrote:

The raw data for them is at http://jdk-distros.dev.java.net.

cheers,
dalibor topic

Those packages will install java, but not as integrated to the debian system as 
I want to.


wrong.


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#365408: Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk

[Matthias Klose]

On 20.09.2009 13:43, Niels Thykier wrote:

Package: java-common
Version: 0.33
Severity: normal

I second this proposal using the java-{jre,jdk} for free and 
java-{jre,jdk}-nonfree
for nonfree packages.


No, we should develop against a spec, not against a product. maybe this was more 
wanted in the past, but we should not make this distinction in the presence of 
OpenJDK.




--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#543085: libhibernate3-java: FTBFS: You must specify a valid JAVA_HOME or JAVACMD!

[Matthias Klose]

On 23.08.2009 23:38, Damien Raude-Morvan wrote:

It's linked to default-jdk switch to JDBC6

An issue report [1] is open upstream on this subject, but it's not fixed and,
sadly, proposed patch just add stubs methods.

Ubuntu [2] build hibernate with an explicit dependencies on GCJ compiler.

[1] http://opensource.atlassian.com/projects/hibernate/browse/HHH-2412
[2] http://patches.ubuntu.com/libh/libhibernate3-java/libhibernate3-
java_3.3.1.GA+dak1-3ubuntu1.patch


as long as the source package only builds binary-indep packages, the same 
workaround can be applied. but because Debian uses GCJ for some architectures 
you still need to take care about the differences between Openjdk and GCJ for 
architecture dependent packages.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: javadoc problem with default-jdk

[Matthias Klose]

On 05.08.2009 20:02, Michael Koch wrote:

On Wed, Aug 05, 2009 at 06:26:44PM +0200, Picca Frédéric-Emmanuel wrote:

Le Wed, 05 Aug 2009 15:52:34 +0200,
Matthias Klose  a écrit :


On 05.08.2009 17:00, Picca Frédéric-Emmanuel wrote:

hello as I am working on my remotetea package, I build it using the
pbuilder.

and it seems that depending on default-jdk is not enought to produce
good documentation with javadoc. Indeed it do not find the
documentation for standard classes of java.

what must I add as build dependency to produce the right
documentation ?


the java docs built form OpenJDK can be found in openjdk-6-doc. But
instead of directly depending on this package, we should create a
default-jdk-doc package and make sure that generated references don't
refer to the openjdk-6-doc directory.


ok for the standard documentation but what about all the javadoc api
provided by the java packages with a -doc.

if my package provide some javadoc documentation it should be
accessible to other packages during there build process.

How can we deal with this.

did I missed something.

This is just to have all javadoc api consistant for all java packages.


Always put it into /usr/share/doc//api.


No, this looks wrong, because you cannot enforce this for packages where the 
docs are shipped in the same package. You should use /usr/share/doc/package>/api, and maybe add a directory /usr/share/doc/ with an api 
symlink to /usr/share/doc//api, if the docs are in a separate package.



--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: javadoc problem with default-jdk

[Matthias Klose]

On 05.08.2009 18:26, Picca Frédéric-Emmanuel wrote:




 Le Wed, 05 Aug 2009 15:52:34 +0200,

Matthias Klose  a écrit :


On 05.08.2009 17:00, Picca Frédéric-Emmanuel wrote:

hello as I am working on my remotetea package, I build it using the
pbuilder.

and it seems that depending on default-jdk is not enought to produce
good documentation with javadoc. Indeed it do not find the
documentation for standard classes of java.

what must I add as build dependency to produce the right
documentation ?


the java docs built form OpenJDK can be found in openjdk-6-doc. But
instead of directly depending on this package, we should create a
default-jdk-doc package and make sure that generated references don't
refer to the openjdk-6-doc directory.


ok for the standard documentation but what about all the javadoc api
provided by the java packages with a -doc.

if my package provide some javadoc documentation it should be
accessible to other packages during there build process.

How can we deal with this.

did I missed something.

This is just to have all javadoc api consistant for all java packages.


we discussed this at Debconf. You generally don't want to have a libfoo-java, 
which includes the api docs, depend on any other -apidoc packages. It's clear 
that the generated docs will point to some non-existing local URLs in this case.

The alternative would be to always have a separate libfoo-java-apidoc package.
For now you maybe have to build-depend on every -doc package explicitely.


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: javadoc problem with default-jdk

[Matthias Klose]

On 05.08.2009 17:00, Picca Frédéric-Emmanuel wrote:

hello as I am working on my remotetea package, I build it using the
pbuilder.

and it seems that depending on default-jdk is not enought to produce
good documentation with javadoc. Indeed it do not find the
documentation for standard classes of java.

what must I add as build dependency to produce the right documentation ?


the java docs built form OpenJDK can be found in openjdk-6-doc. But instead of 
directly depending on this package, we should create a default-jdk-doc package 
and make sure that generated references don't refer to the openjdk-6-doc directory.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Fwd: SONAME for python modules is bad?

[Matthias Klose]

On 25.07.2009 05:47, Matthew Johnson wrote:

On Sat Jul 25 11:28, Mathieu Malaterre wrote:

On Fri, Jul 24, 2009 at 7:45 PM, Max Bowsher  wrote:
...

It would be extremely nice too if all wrap language would adopt the
same convention. So that toolkit such as VTK/ITK/GDCM wrapping their
interface into multiple languages (namely: Tcl, Python, Java, C#)
could simply decide:
(1) Allow SONAME
(2) Use a directory convention libfoo-$SOVERSION/$NAME.so

for packaging mutiple modules.


It is unclear to me what you are trying to standardize.


How does one install multiple version of the same python/java/cli module ?


(speaking for Java) At the moment, you don't.


Wrong. It's already done, including a version in the file name and having a 
symlink to an unversioned jar. It should be possible to do something similiar 
with jni bindings.




--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#537290: classpath-common,gcj-jdk: Conflicting file /usr/share/man/man1/gappletviewer.1.gz

[Matthias Klose]

reassign 537290 classpath-common
thanks

No, there's nothing wrong with gcj-jdk. It defines a conflict with the current 
classpath-common. What needs to be done: update classpath to 0.98, build cacao 
using the new classpath, then decide what to do with the tools which are both 
built by gcj-jdk and classpath, if we want to avoid the conflict. 
classpath/cacao should at least provide something like /usr/lib/jvm/ 
and provide alternatives as other JVM's do.


Maybe it is a help to provide a new cacao-source source package just building 
the cacao-source binary package, which then is then used by classpath and 
openjdk-6 to build the cacao runtime.


If nobody is interested in classpath, then we maybe should remove it.

  Matthias

On 16.07.2009 14:10, Daniel Schepler wrote:

Package: classpath-common, gcj-jdk
Severity: serious

classpath-common and gcj-jdk both have the file
/usr/share/man/man1/gappletviewer.1.gz.  It seems gcj-jdk tried to "fix" the
issue using a versioned conflict with classpath-common; however, that makes
cacao's Build-Depends unsatisfiable as it Build-Depends on both classpath-
common and default-jdk-builddep (at least on !alpha).

Wouldn't it make sense to handle this as an alternative, since gcj uses
classpath libraries anyway?



--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: OpenJDK 6 Certification for Ubuntu 9.04 (jaunty)

[Matthias Klose]

Andrew Haley schrieb:
> In 
> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000587.html
> Matthias Klose wrote:
> 
>> The Ubuntu Java development team is pleased to announce completed
>> certification of OpenJDK 6 for Ubuntu 9.04, continuing Ubuntu's tradition of
>> integrating the latest and greatest open source technologies into a
>> high-quality, easy-to-use Linux distribution.
>>
>> After signing the Sun TCK agreement earlier this year, Java developers
>> went to work with the certification process and received final
>> certification from Sun in late May.
> 
> And you didn't announce it till now.  Such amazing self-control.  :-)

well, we had a bug in the fontconfig configuration file leading to too large
vertical layout in dialogs, which was fixed in an update, and this update did
migrate to jaunty-updates last Friday.

>> This certification means that the OpenJDK 6 package included with Ubuntu
>> 9.04 now passes the rigorous testing of the Java SE Test Compatibility Kit
>> (TCK) and is compatible with the Java(TM) SE 6 platform on the amd64 (x86_64)
>> and i386 (ix86) architectures.
> 
> Congratulations, and welcome to the club!  I was beginning to wonder if Red 
> Hat
> and Fedora were going to be the only member for ever.

And many thanks for guiding me through the setup for the TCK!

So it should be possible to certify the Debian packages as well (maybe not the
ones in lenny, but more likely a backport).  I will not do this myself, the
certification is time consuming. If somebody wants to get involved with the
certification of the Debian OpenJDK-6 packages (after doing the paperwork of
signing the TCK and the SCA), please let me know, and I'll help where I can.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: openjdk-6 6b14-4 built but not uploaded

[Matthias Klose]

Luk Claes schrieb:
> Matthias Klose wrote:
>> According to the buildd logs the openjdk-6 6b14-4 build for mipsel did 
>> finish on
>> Jun 20, but was not uploaded until now.  Is there any interest within the 
>> mips
>> porters on openjdk-6 on mips*, or should we just remove it from the archive 
>> and
>> drop openjdk support on mips?
> 
> Scheduled for upload now. Do you think the failure on hppa was temporary
> or is there a bug to be filed?

thanks! No, it needs porting work (the implementation makes the assumption that
the stack always grows downwards; unknown if there are other issues). Andrew
Haley did look at it. For now nobody was interested in working on the port.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: hinting java updates to testing

[Matthias Klose]

Pierre Habouzit schrieb:
> On Wed, Jun 24, 2009 at 11:39:16PM +0200, Matthias Klose wrote:
>> The current set of java packages (introducing java for hppa) in unstable 
>> seem to
>> be ready for testing:
>>
>>  java-common 0.32
>>  java-gcj-compat 1.0.80-5
>>  gcj-4.4 4.4.0-8
>>  gcc-defaults 1.87
>>
>> Afaics only gcj-4.4 seems to be too young for the migration to testing.
>>
>>   Matthias
> 
> Afaics the migration is tied to the eglibc one, I've placed the hint,
> but it's likely to fail until eglibc is ready.

I can't see that. Now that gcj-4.4 is in testing, there shouldn't be any glibc
specific dependencies. At least I can't see these in the update excuses.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

hinting java updates to testing

[Matthias Klose]

The current set of java packages (introducing java for hppa) in unstable seem to
be ready for testing:

 java-common 0.32
 java-gcj-compat 1.0.80-5
 gcj-4.4 4.4.0-8
 gcc-defaults 1.87

Afaics only gcj-4.4 seems to be too young for the migration to testing.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: buildd localies

[Matthias Klose]

Rail Aliev schrieb:
> Hi,
> 
> I'm trying to package jwordsplitter and has encountered the following
> trouble.
> 
> The package was almost done when I decided to run Junit test case while
> building. Everything is OK when I run the test via debuild in usual
> environment but them fail when I build the package in pbuilder.
> 
> After some investigations I found that the tests are locale dependent and
> cannot be run with LANG=C.  is set. Seems like
> pbuilder doesn't generate en_US.UTF-8 locale (and it is visible from
> logs as well).
> 
> Do buildd machines have en_US.UTF-8 locale or should I add some trick to
> run the tests properly?

create the locales when they are missing. see the gcc-4.x source packages for an
example (debian/rules2, debian/locale-gen).

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: hppa in danger of being ignored for testing migration and eventual removal

[Matthias Klose]

dann frazier schrieb:
> On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote:
>> On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes  wrote:
>>> * Has progress been made regarding proper java support?
>> What is considered proper java support? GCJ?
>>
>> Dave, have you tinkered with GCJ lately?

GCJ-4.4 works fine on hppa, currently waiting in NEW ... so if you do want to
see this resolved, please help with getting this accepted.

Note that this doesn't work very well with NPTL (Ubuntu karmic), so please make
sure that this continues to work with an glibc update.

OpenJDK is non-trivial. Andrew Haley did have a look at this and came to the
conclusion that the byte code interpreter for the zero port needs porting for
archs with upward growing stacks.

Maybe hotspot is an alternative? Did somebody ask HP to open-source their
hotspot port of sun-java5?

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

gcc-4.4 & gcj-4.4/java-common uploads to unstable

[Matthias Klose]

Planning a gcc-4.4 upload for unstable for next week. It's not a transition (not
changing any GCC defaults), but is likely to delay transitions of other packages
due to new symbols in the various GCC runtime libraries. For now I'm not aware
of any regressions in the runtime libraries, however builds for mips* are still
outstanding. I would appreciate access to a fast mips* machine, or a build log
for the current gcc-4.4 package in experimental.

gcj-4.4 welcomes back hppa as a java architecture.  gcj-4.3 is available on
hurd-i386. Besides kfreebsd, java is now available on all architectures. For
unstable, I plan to change the java-common defaults to point to opendjk for all
hotspot archs, and to gcj-{jre*,jdk} when these packages are in testing. I'd
like to have some feedback about the java default for the non-hotspot openjdk
archs first before moving those to openjdk; both debian-java and the openjdk
co-maintainer seem to be pretty dead/mia.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

OpenJDK & Cacao & GCJ & Java defaults in unstable

[Matthias Klose]

Hi,

openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.

There are two new binary packages offering additional JVMs:

 - openjdk-6-jre-zero: built on amd64 and i386. This is the JVM used by
   default on the non-hotspot archs (armel, alpha, s390, mips, mipsel,
   powerpc, m68k?). Maybe useful for debugging issues with the zero JVM on
   archs which are more accessible.

 - icedtea-6-jre-cacao: built on alpha, armel, mips, mipsel, s390, i386,
   amd64, powerpc). The Cacao JVM and JIT is not yet feature complete
   compared to the hotspot JVM, but is much faster than the Zero JVM
   and offers an alternative on platforms which don't have the Hotspot
   JVM.

The additional JVM's can be called with

  java [-cacao|-zero]

or for the java tools with

   [-J-cacao|-J-zero]

This is currently a Debian/Ubuntu only option; integration into IcedTea is in
progress.

To make a JVM the default, make it the first one in /etc/java-6-openjdk/jvm.cfg.

GCJ is still the work horse to build and bootstrap OpenJDK. IMO it still does
make sense to keep the '-gcj' packages for software which is known to work with
GCJ. I plan to have a recent GCJ-4.x release for the next Debian release.

Once openjdk-6 moves to testing, I propose to change the default in the
default-{jre,jdk} packages to point to the openjdk-6 packages. This works well,
except for one thing: packages will be built with -source 1.6 by default, which
makes the resulting .class/.jar files unusable with older java versions (1.4 and
1.5). I would like to propose a change in the Debian java policy, that java
packages must be built for the version which is sufficient for a sucessful
build. The changes are trivial; I already did check in changes for ant and ant
build- and runtime dependencies into the debian-java svn.

There is currently work-in-progress to extend the Zero JVM with a JIT (called
shark).  This is still experimental work, currently requires llvm-2.4 (unstable
has 2.5). I would welcome feedback from port maintainers about zero/shark.
Please consider to join the IcedTea mailing list.

  Matthias

PS: I would appreciate some help with openjdk in Debian; the current maintainer
team is MIA or inactive.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: /usr/lib/jni in library path for sun-java[56]

[Matthias Klose]

severity 382686 important
tag 382686 + wontfix
thanks

these are binaries, and we are not allowed to ship those in modified form.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Eclipse & RCP deployment

[Matthias Klose]

Harald Krammer schrieb:
> Hello Pantelis,
> 
> Pantelis Koukousoulas schrieb:
>> On Wed, Dec 31, 2008 at 4:28 PM, Harald Krammer  
>> wrote:
> [..]
>>> Hello,
>>> I would like to deploy a customized Eclipse development environment on
>>> Debian Etch/Lenny.
>> Excellent!
>> We have already started an effort to get eclipse into shape for debian
>> and there is
>> a preliminary "monolithic" package. See:
> 
>> http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2008-December/018863.html
>> for the details.

how does this compare to the packages started by Michael?
See http://lists.debian.org/debian-java/2008/06/msg00036.html

>> Nathan summers (aka Rockwalrus) seems to also be reviving his efforts
>> so you can see
>> the ubuntu eclipse-team stuff and
> 
>> https://bugs.launchpad.net/eclipse-ubuntu

>* I have dropped ALL not-absolutely-essential features in favor
> of having things work from the POV of the user so it is almost
> possible to
>   understand how the packaging  works :-)  (hint: focus on the
> pretty big/hairy scripts under debian/scripts)

It may be better to build on top on the existing packaging. It's there for a
reason. I think your approach makes it difficult to update the package in the
distribution. Please make sure that your package does build on platforms like
mips, powerpc and sparc as well.

>* GCJ dropped, builds/uses openjdk-6 now which means no bizarre
> random segfaults all over the place, undoubtedly a good thing :-)

No, it's bad for all those platforms which don't have a JIT. It's a different
(good) thing to build with OpenJDK, but don't drop the -gcj packages.

>* The SWT .so files are built from source. The .so files that
> come with the source zip are explicitly deleted before the build

these have to be removed from the source, not deleted at build time.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: icu4j_3.8.1-1_i386.changes ACCEPTED (fwd)

[Matthias Klose]

Andreas Tille schrieb:
> Hi,
> 
> as you can see icu4j is now accepted and available for unstable.  There
> was some discussion which version might be best for the final goal to
> package eclipse.  I'm waiting for input of people who tested version
> 4.x.

independent of the version the osgi meta information must be included if you
want to use it for eclipse.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[Fwd: [Devjam] Final Program Free Java Meeting at Fosdem - Brussels, Belgium on 7 and 8 February 2009]

[Matthias Klose]

FYI, this was announced on debian-java earlier, but not the final agenda.

  Matthias
--- Begin Message ---
Hi all,

In less than 2 weeks our little big event will take place!

The program for our libre java meeting at Fosdem has been finalized.
There are posters with a summary of the talks to print out at:
http://www.klomp.org/mark/classpath/fosdem09/poster_09.odg
http://www.klomp.org/mark/classpath/fosdem09/poster_09.pdf

Talk abstracts and bios of the speakers can be found at:
http://fosdem.org/2009/schedule/devroom/freejava

The wiki has some pointers to extra activities:
http://wiki.debian.org/Java/DevJam/2009/Fosdem
Including a dinner on Saturday night. Please add yourself if you want to
attend before Wednesday, January 28th

Hoping to see you all there, your friendly ad hoc Fosdem meeting
committee,

Dalibor Topic,
Andrew John Hughes,
Andrew Haley,
David Herron
and Mark Wielaard


___
Devjam mailing list
dev...@developer.classpath.org
http://developer.classpath.org/mailman/listinfo/devjam
--- End Message ---

Re: java bytecode / java runtime version mismatch

[Matthias Klose]

Mark Wielaard writes:
> Hi Matthias,
> 
> On Tue, 2008-10-28 at 09:25 +0100, Matthias Klose wrote:
> > I filed bug reports for packages building with openjdk-6 or cacao-oj6,
> > producing java bytecode for version 50, and which still depend on
> > java-runtime5, or earlier (attached at the end).
> >
> > This package builds with openjdk-6 or cacao-oj6, which is not the
> > default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
> > creates java bytecode for version 50, which cannot be used by older
> > jvms.
> 
> I thought all (free) runtimes accepted version 50 bytecode these days,
> even if they say they implement only java-runtime5. Is this a problem in
> practice? And if so against which runtimes? We might want to just fix
> those runtimes.

problems were reported with at least sun-java5, which doesn't accept
openjdk-6 bytecode.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

java bytecode / java runtime version mismatch

[Matthias Klose]

I filed bug reports for packages building with openjdk-6 or cacao-oj6,
producing java bytecode for version 50, and which still depend on
java-runtime5, or earlier (attached at the end).

For lenny+1, when using openjdk/cacao as the default, there will be a
lot more of these mismatches (I fixed about 30 packages in the
pkg-java repo), so maybe a lintian check for this kind of mismatch
would be nice.

  Matthias

Bug mail:
User: debian-java@lists.debian.org
Usertags: jbc-mismatch

This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.

It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].

You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.

Note: this report may be a false positive, if all bytecode files have
version 49 or less.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OpenJDK build attempts on the testing security infrastructure

[Matthias Klose]

Riku Voipio schrieb:
> Also I notice the packages are built with ecj using the slowish gij
> interpreter. perhaps the package build could be made faster by using
> gcj precompiled ecj-gcj package?

unfortunately this doesn't help; java-gcj-compat-dev already depends on ecj-gcj.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OpenJDK build attempts on the testing security infrastructure

[Matthias Klose]

[sorry for not replying earler. please CC the package maintainer address, I 
don't read debian-java
on a daily basis]

Florian Weimer schrieb:
> Here are the results of building some OpenJDK packages on the security
> buildd infrastructure (with the test suites disabled).

thanks for doing this.

> First, for openjdk-6 6b11-6+lenny1, we have:
> 
> Successes: amd64, armel, i386, ia64, mips, mipsel, powerpc, sparc
> Failures: alpha, s390
> 
> The s390 failure may be due to too little RAM allocated to the instance
> (on lxdebian.bfinv.de).

tried to work around this prentending to have at least some amount of RAM 
(packages in
experimental); the buildds may swap, but hopefully succeed. unfortunately it's 
the openjdk build
system implementing these 'constraints'. The experimental buildd doesn't show 
this failure, but
chokes on insufficiant disk space. hurray!

> The alpha failure is:
> 
> gcc-4.3  -O3-fno-strict-aliasing -fPIC -W -Wall  -Wno-unused 
> -Wno-parentheses  -D_LITTLE_ENDIAN -g   -D_alpha_  -DARCH='"alpha"' -DLINUX 
> -DRELEASE='"1.6.0_0"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT 
> -D_LP64=1 -I. 
> -I/build/buildd/openjdk-6-6b11/openjdk/control/build/linux-alpha/tmp/java/java.lang.management/management/CClassHeaders
>  -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export 
> -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include 
> -I../../../src/share/native/sun/management  
> -I../../../src/share/native/common -I../../../src/solaris/native/common 
> -I../../../src/share/native/java/lang/management 
> -I../../../src/solaris/native/java/lang/management-c -o 
> /build/buildd/openjdk-6-6b11/openjdk/control/build/linux-alpha/tmp/java/java.lang.management/management/obj64/UnixOperatingSystem_md.o
>   ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
> In file included from /usr/include/sys/procfs.h:31,
>  from 
> ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c:52:
> /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory
> In file included from 
> ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c:52:
> /usr/include/sys/procfs.h:32:21: error: asm/elf.h: No such file or directory
> In file included from 
> ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c:52:
> /usr/include/sys/procfs.h:76: error: expected specifier-qualifier-list before 
> 'elf_gregset_t'
> 
> The alpha buildd needed more that five hours to reach that point.

the alpha build succeeds on the experimental buildd.

> Build times are generally acceptable, with the exception of armel,
> which needed almost 45 hours.

you could reduce this by some hours by using openjdk-6 itself as the staging 
system. I didn't try
this yet, so I can't give the exact figures.

> The picture for cacao-oj6 6b11-2+lenny1 is like this:
> 
> Successes: amd64, armel, i386, s390
> Failures: powerpc 
> 
> The powerpc failure is due to a cyclic build dependency, IOW we simply
> could not test the build.

powerpc can be configured to use gcj as a stage1 system as well. I think build 
time is not critical
on powerpc, so you may prefer this.

> armel is at about 19 hours, so almost acceptable.  However, in
> practice, this likely adds to the 45 hours of openjdk-6, resulting in
> 64 hours of total build time, which is totally out of question.
> Otherwise, the build times are fine.

this calculation is only true if you have to fix something in both the zero 
port and the cacao port
(or the jdk). If you have to fix something in the hotspot runtime only, it is 
safe to announce
changes once amd64, i386 and sparc are built. assuming you have to buildds this 
is 45h (or less if
using openjdk as the staging system).

> The package tried to build on mipsel, blocking the buildd for extended
> periods of times.  This has to be fixed.

I don't have results for mips* myself. the experimental buildds didn't try to 
build the packages yet.

> Consequently, it would seem attractive to trade cacao-oj6 for openjdk-6
> on ARM.

besides the better test results for openjdk-6.

> I'm not sure what to do about the alpha and s390 build issues.

me neither. alpha is attractive because it's the only available 
runtime/development env. on this
platform (and who knows if we will have another release for alpha ...).

For Ubuntu I did go on with the b12 code drop and the current icedtea updates, 
which show comparable
results on i386, amd64, sparc, ia64, powerpc. Alpha doesn't seem to be a 
problem as shown on the
experimental buildd, but I can't say much about s390, mips, mipsel and armel 
(both for openjdk and
cacao). I won't have the time during the next three or four weeks to further 
work on these packages
for a probable upload to unstable. But it's not just me in the maintainer team, 
so if somebody else
wants to push this, please go ahead. Looking at the bts you'll see that most 
issues reported for the
Debian pack

cacao update

[Matthias Klose]

Hi,

I would like to upload an updated cacao pre 0.99.4, builing a cacao-source 
package which can be used
as a b-d for cacao-oj6. this should go unstable, so that the buildds can build 
cacao-oj6. cacao is
not in testing, so this should not make things worse in unstable.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for cacao-oj6

[Matthias Klose]

Florian Weimer writes:
> > the openjdk-6 package runs the testsuite. if the security team prefers
> > shorter build times, then the testuite can be disabled in security
> > uploads.
> 
> Uhm, okay.

I didn't change this in the -2 upload.

> > the testsuite is not run in the cacao-oj6 package.
> 
> And build times are reasonably fast.

unfortunately the -2 build did fail on s390 and armel.

 - s390: rebuilt by hand on raptor/unstable without problems.
   Bastian pointed to #479952 as a possible reason. would it
   be possible to do a test-rebuild on the machine which is
   used security updates?

 - armel: failed to build on ALL6500; asking the buildd admins to
   restart a build on argento (where the build did succeed before).

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for cacao-oj6

[Matthias Klose]

Bastian Blank writes:
> On Sun, Aug 24, 2008 at 09:43:38PM +0200, Florian Weimer wrote:
> > A security update for the OpenJDK 6 source base will require more than
> > 60 hours of armel build time, and more than two weeks[1] on sparc for
> > openjdk-6 alone (don't know cocoa-oj6 yet).
> 
> The fastjar changes are aimed to decrease this build times for
> openjdk-6. cocoa-oj6 is AFAIK for arches where cocoa have a JIT but
> openjdk not (s390, powerpc, arm*).

cocoa-oj6 already build-depends against the new fastjar, so build
times won't improve. the slowest architecture is armel, the package is
only built on armel, s390, powerpc, i386 and amd64. 32bit sparc is not
supported by cacao in the current form as distributed by upstream.

> >  Anything longer than half a
> > day is very difficult for us.
> > [1] Estimate based on a built time of 205 hours on lebrun, which has got
> > a 750 MHz CPU.  spontini is a U60, which is probably only half as
> > fast.
> 
> Well, you know that there is a T2000 available and if the security team
> needs a faster buildd they have to ask.

the estimate is wrong. the openjdk-6 package runs the testsuite. if
the security team prefers shorter build times, then the testuite can
be disabled in security uploads. the testsuite is not run in the
cacao-oj6 package.

if the security team has the opportunity to use a faster machine,
please consider using it.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for cacao-oj6

[Matthias Klose]

Florian Weimer writes:
> * Luk Claes:
> 
> > Matthias Klose wrote:
> >> proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
> >> copy of the openjdk-6 package with the cacao sources
> >> included. Compared to openjdk-6 on architectures without the Hotspot
> >> JIT support, cacao-oj6 (including a JIT) is a much faster JVM on the
> >> architectures where it does build (powerpc, s390, armel for
> >> now). Discussed this at Debconf with some people. I was told to get
> >> agreement with debian-security about the maintainability (because of
> >> the duplicate sources). See #495256 as well.
> >
> > What was the conclusion of the discussion with the Security Team?
> 
> I don't recall a discussion.

No, this was at Debconf; I had the impression that somebody from the
security team was sitting around as well.

> Anyway, I want to see a -2 first, to see if it can actually be
> auto-built on all release architectures, and what the timings are.

Trying to do that (although I wouldn't mind if somebody else could do
that; still travelling with bad network connectivity).

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

packages with build dependencies on openjdk-6-jdk

[Matthias Klose]

Unfortunately there is a lot of packages with build dependencies on
openjdk-6-jdk directly, which is a bit unfortunate. Most likely all
packages build depending on openjdk-6-jdk should have RC bug reports
because they may contain 1.6 bytecode. The following should be checked
for the release:

 - if a package build-depends on openjdk-6-jdk or cacao-oj6-jdk,
   it should be compiled with `-target 1.4' (or 1.5?).

 - if no target option is used, it should only depend on 
   java-runtime6 or java-runtime6-headless.

 - build dependencies should be of the form openjdk-6-jdk |
   cacao-oj6-jdk, or else builds will fail on s390.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

freeze exception for cacao-oj6

[Matthias Klose]

proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
copy of the openjdk-6 package with the cacao sources
included. Compared to openjdk-6 on architectures without the Hotspot
JIT support, cacao-oj6 (including a JIT) is a much faster JVM on the
architectures where it does build (powerpc, s390, armel for
now). Discussed this at Debconf with some people. I was told to get
agreement with debian-security about the maintainability (because of
the duplicate sources). See #495256 as well.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

freeze exceptions - making {java-gcj-compat,openjdk-6-jre}-headless installable without the complete jre packages

[Matthias Klose]

currently the -headless packages are not installable without having
the complete -jre packages installed on the system. the reason for
this is a dependency on the complete -jre packages in packages which
are dependencies of the -headless packages. The fix is to include an
alternative dependency on the -headless default-jre package. This
includes:

 libmx4j-java 3.0.2-4
 libregexp-java 1.4-5
 jakarta-log4j 1.2.15-4
 

java-package was extended to provide the "-headless"variants of the
java-runtime packages as well. this is done in 

 java-package 0.42

please consider a freeze exception for these packages.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

building openjdk-6 for m68k

[Matthias Klose]

the openjdk-6 6b11-4 should build on m68k. It may take a few weeks,
but I currently don't see any issue with it. If you do so, please keep
the build tree, so that the testsuite can be run, after the build
finishes (taking some more weeks to finish).

thanks, Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

OpenJDK for lenny

[Matthias Klose]

So, we are late with OpenJDK for lenny. I still think lenny would
benefit from having OpenJDK. I'm proposing the following steps,
realizing that not all of them probably can be realized.

 - The current 6b11-2 package is not yet ready for migration. We will
   need a -3 upload which properly will fix build issues, and adds
   ports for alpha, mips, mipsel and m68k. s390 support is pending
   some build issues (Bastian Blank is working on those).

 - Upload a -3, which should be a candidate for testing. If the s390
   bits are not yet ready, have an opportunity to upload a -4.
   The current status can be seen in the repository.

 - At this point we'll have OpenJDK VM with a JIT (amd64, i386, sparc)
   and an interpreter (alpha, armel, ia64, mips, mipsel, m68k,
   powerpc, s390). The intrepreter is good for building stuff, but
   runtime performance ...

 - Allow tzdata to build a tzdata-java package; the openjdk-6 is
   prepared to use the data from tzdata-java (which comes in a
   different file format). With this openjdk-6 doesn't have to be
   updated for new timeezone data.

 - Allow a java-common update to build default-* for alpha, pointing
   to openjdk-6.

 - Allow cacao-oj6 (currently in NEW) into testing. This just uses
   the same packaging as openjdk-6, but uses the cacao JIT for alpha
   and powerpc (and amd64, i386, maybe mips*). This adds a usable
   runtime for these two architectures. Sources and packaging are the
   same as openjdk-6 (and cacao).

 - Allow java-common to point the default-* for the hotspot JIT archs
   (amd64, i386, sparc) to point to openjdk-6.
   This only should be done if a rebuild test of the archive is
   successful.

 - Allow java-common to point the default-* for the cacao JIT archs
   (alpha, powerpc) to point to cacao-oj6.

We won't have a openjdk-6 for arm and hppa; I'm currently not aware of
a working jdk on these architectures to build openjdk-6 or cacao-oj6.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483060: RFP: jscheme -- needed for openjdk to enter main

[Matthias Klose]

Package: wnpp
Severity: important

see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=140
for the details



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OpenJDK 6 in Debian? Main, contrib or non-free?

[Matthias Klose]

Eric Lavarde writes:
> Hi,
> 
> I noticed that FreeMind works with OpenJDK 6 (as present in Ubuntu 
> 8.04). Is this package supposed to come to Debian, and will it be in 
> main, contrib or non-free?

please see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=138

plus the thread starting at
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-April/44.html

help is appreciated in going over Thomas' issues, which are not yet
covered in the bug report 138.

openjdk doesn't make sense in contrib or non-free.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proper way to specify Java build-dep

[Matthias Klose]

Adam C Powell IV writes:
> On Mon, 2008-05-05 at 16:58 +0200, Michael Koch wrote:
> > On Mon, May 05, 2008 at 10:23:41AM -0400, Adam C Powell IV wrote:
> > > Greetings,
> > > 
> > > My package babel recently closed bug 477845 by changing a build
> > > dependency from java-gcj-compat to default-jdk-builddep.  Unfortunately,
> > > this made it FTBFS on hppa, s390, arm and alpha, where before it built
> > > everywhere except arm.
> > > 
> > > What is the right thing to do in this situation?  Do I exclude those
> > > architectures from the package build list?  Is there a "java-works"
> > > architecture variable which will automatically add arches as their java
> > > implementations work?
> > > 
> > > [Please CC me in replies.]
> > 
> > These arches currently dont work, rigth. I"m testing a solution for
> > this. In general just B-D on default-jdk-builddep is okay.

it is only correct if your package doesn't build other architecture
dependent packages, which is not the case for babel.

the build failure on s390 is unexpected; is it possible to extract a
test case?

> Just curious, what will happen regarding testing transitions in the
> meantime?  And long-term, can I assume that the package will build and
> transition as soon as the infrastructure is in place, without another
> upload?

the infrastructure is in place; the packages can move to testing once
the hppa, arm and alph binaries are not in unstable anymore.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openjdk-6_6b08-1_i386.changes REJECTED

[Matthias Klose]

Thomas Viehmann schrieb:
> Hi,
> 
> the java.net list is subscriber only and after some chat it appears that
> most of the problems are indeed local to Debian, so I dropped them from
> the CC.

Didn't notice the subscriber-only thing. I added the list for this reply for
some input on the generated files.

> Matthias Klose wrote:
>>>>> - The debian/copyright file seems to miss a lot of
>>>>>   copyright notices (e.g. of Red Hat, Maxwell, ASF,
>>>>>   I stopped after finding four). This is the main
>>>>>   reject reason.
> 
> Of course, the ASF copyright is included in debian/copyright, shame on me.
> Thanks Matthias for pointing that out on IRC.

- About Red Hat; these files were submitted by a RedHat developer, who
  is listed in debian/copyright, but Red Hat itself was not listed. Added.
- Same for the Maxwell name, which came in with a patch to the IcedTea
  repository.
- Added two other names, and two organizations.
- I am not aware of missing license in the debian/copyright

On IRC Thomas and I agreed on not including the names for copyrights in
GNU files like aclocal.m4, install-sh, and other similiar files. It would be
nice if a common practice could be documented, how such files should be handled.

This is what I committed:
$ bzr diff
=== modified file 'copyright'
--- copyright   2008-04-01 07:24:19 +
+++ copyright   2008-04-19 13:43:26 +
@@ -57,9 +57,18 @@
 Portions Copyright © 2007 Joshua Sumali <[EMAIL PROTECTED]>
 Portions Copyright © 2007 Christian Thalinger <[EMAIL PROTECTED]>
 Portions Copyright © 2007 Mark Wielaard <[EMAIL PROTECTED]>
-
+Portions Copyright © 2007, 2008 Red Hat, Inc.
+Portions Copyright © 2001-2003 Jon A. Maxwell (JAM)
+Portions Copyright © 1992, 1995-2007 Sun Microsystems, Inc.
+Portions Copyright © 2007 Matthew Flaschen
+Portions Copyright © 2000-2002 Marc De Scheemaecker
+Portions Copyright © 1991-1998 Thomas G. Lane
+Portions Copyright © 2007 Free Software Foundation, Inc.
+
 OpenJDK:
-Copyright © 2007 Sun Microsystems, Inc.
+Copyright © 1996-2007 Sun Microsystems, Inc.
+For third party copyrights see below (copies from the third party readme).
+Portions Copyright © 1993-1999 IBM Corp.

 Java Access Bridge:
 Portions Copyright © 2002-2007 Bill Haneman <[EMAIL PROTECTED]>
@@ -72,7 +81,7 @@
 Portions Copyright © 2002-2007 Darren Kenny <[EMAIL PROTECTED]>

 Packaging:
-Copyright © 2007 Canonical Ltd.
+Copyright © 2007, 2008 Canonical Ltd.

 --


>>>>> - There are some files in the generated subdir that
>>>>>   I'm not sure I found the source of. Could you
>>>>>   clarify this a bit for me?
> 
> Matthias pointed to the source for the IDL-generated files on IRC,
> resolving quite a bit of the concerns. Thanks.
> Some stuff I am currently not sure about how to find the source (all in
> generated/)
> - java/nio,

see jdk/make/java/nio

> - the language specific stuff, (files ending in _??.java, some in
>   */{lang,util}),

see jdk/make/java/java

> - the things generated by mc.scm (com/sun/corba/se/impl/),

not sure what you exactly mean.

> - some stuff in */management/ (some with "generated by rmic" notice).

see jdk/src/share/classes/sun/management/resources.

> The source for all of these probably is well known to the experts, so
> the above is as much for my own reference as it for you knowing what I
> am presently not sure about in case you want to help me find things.

Maybe a build log can help finding the locations of the build bits and the
source files. Please see:
https://launchpad.net/ubuntu/+source/openjdk-6/6b09-0ubuntu2/+build/563835

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openjdk-6_6b08-1_i386.changes REJECTED

[Matthias Klose]

Thomas Viehmann schrieb:
> Hi,
> 
> Matthias Klose wrote:
>> thanks for looking into this. after the second try to upload and 10
>> days in the
>> NEW queue the review is a bit terse.
>>
>>> Up to now I found:
>>> - The debian/copyright file seems to miss a lot of
>>>   copyright notices (e.g. of Red Hat, Maxwell, ASF,
>>>   I stopped after finding four). This is the main
>>>   reject reason.
> 
>> it would be helpful if you could mention those. it would be
>> appreciated if you
>> could act proactively.
> 
> Quite frankly, all of those that I found can be found by
>   find -type f | xargs -d '\n' grep -i copyright
> (of course, be sure to untar at least the tar-archive before that, for
> bonus points check that you don't have other archives that want unpacking).
> Yes, there are a lot of false positives with that grep and you can do
> all sorts of post-processing, but it is not rocket science to find the
> notes, either.
> 
> Seriously, checking copyright and license information is one of the
> crucial things that happens during the NEW queue processing. It should
> be no surprise that it is something to get right on the first attempt,
> particularly if they are easily found with a bit of grep or just looking
> at the files. Doing this a second time after looking at a hundred or so
> source files to assess the quality of omissions is just as annoying to
> me as having another upload going to NEW is to you.

so apparently four people didn't notice this. why not share your findings?

>>> - There are some files in the generated subdir that
>>>   I'm not sure I found the source of. Could you
>>>   clarify this a bit for me?
>> which files? Sorry, I really dislike rejecting a package for
>> clarification
>> reasons. You can ask if you are unsure.
> 
> Indeed, and it would have been that if you did not miss a whole bunch of
> copyright notes.

again, please could you share your findings?

>>> - usr-share-doc-symlink-without-dependency
>>>   is an explicit policy violation and not allowed.
>> please be specific. or this lintian not detecting indirect dependencies?
> 
> I read policy 12.5 to require a direct dependency, but if all of these
> are indirect dependencies, I will not reject the package again just for
> that.

I filed #476810 for this. From my point of view interpretation of policy doesn't
belong to NEW processing.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openjdk-6_6b08-1_i386.changes REJECTED

[Matthias Klose]

Thomas Viehmann schrieb:
> Hi,
> 
> I'm afraid that openjdk-6 still needs some work:

thanks for looking into this. after the second try to upload and 10 days in the
NEW queue the review is a bit terse.

> Up to now I found:
> - The debian/copyright file seems to miss a lot of
>   copyright notices (e.g. of Red Hat, Maxwell, ASF,
>   I stopped after finding four). This is the main
>   reject reason.

it would be helpful if you could mention those. it would be appreciated if you
could act proactively.

> - There are some files in the generated subdir that
>   I'm not sure I found the source of. Could you
>   clarify this a bit for me?

which files? Sorry, I really dislike rejecting a package for clarification
reasons. You can ask if you are unsure.

> - usr-share-doc-symlink-without-dependency
>   is an explicit policy violation and not allowed.

please be specific. or this lintian not detecting indirect dependencies?

> While you're doing stuff, you could also get rid of
> - substvar-source-version-is-deprecated

thanks for the hint, but this doesn't belong into a reject message.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: reverse depends

[Matthias Klose]

Thomas Viehmann writes:
> Hi Matthias,
> 
> in addition to the list of arch packages built from sources
> declaring build-depends on binaries of java-gcj-compat, there
> also is libplplot9-java declaring a depends.
> 
> Either this needs a good plan or I'm missing something.

no, you don't miss anything. Maybe these people filing the RC reports
could help with this.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#476658: postgresql-pljava - direct dependencies on libgcj and misleading package name

[Matthias Klose]

Package: postgresql-pljava
Version: 1.4.0-1
Severity: important

postgresql-8.3-pljava-gcj currently directly depends on a specific
version of libgcj, which is unneeded, and doesn't allow the bindings
to work with another jvm. The upstream should be built without setting
USE_GCJ, but by setting JAVA_HOME to /usr/lib/java-gcj and adding
/usr/lib/java-gcj/bin to PATH.

The name of the binary package is wrong. The package itself contains
jni bindings and has nothing to do with gcj in the first place. Please
have a look at the glib-java package how jni bindings can be packaged:

 - libpostgresql-8.3-pl-java, binary indep, holding the jar file
 - libpostgresql-8.3-pl-jni, binary arch, holding the jni bindings
   (these two packages could be merged into one).
 - libpostgresql-8.3-pl-java-gcj, binary-arch, built using
   dh_nativejava (using aotcompile) to optimize performance when
   running with the gij runtime. Only this package depends on
   libgcj-bc (not on a specific libgcj library package).
   See for example the libxerces2-java source how such a package
   is built.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: reverse dependencies

[Matthias Klose]

Petter Reinholdtsen writes:
> 
> [Michael Koch]
> > The question is how reliable can this be? Its probably better to
> > just remove the package to signal the user that he needs to
> > reconfigure something instead of silently updating to some dummy
> > package and let him wonder why something broke now that worked for a
> > long time.
> 
> I afraid that signal will fail to reach any user.

might be, but #(any user) of free-java-sdk == 0

> Happy hacking,

Please go ahead. If either Rene or you have the time to support these
users, do it.  Don't let others do it.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: reverse dependencies

[Matthias Klose]

IMO classpath-tools and free-java-sdk should be removed as well.

Thomas Viehmann writes:
> Working... done.
> Will remove the following packages from unstable:
> 
> libsablevm-classlib1-java | 1.13-2 | all
> libsablevm-native1 | 1.13-2 | alpha, amd64, arm, armel, hppa, hurd-i386, 
> i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
> sablevm-classlib | 1.13-2 | source
> 
> Maintainer: Grzegorz B. Prokopski <[EMAIL PROTECTED]>
> 
> --- Reason ---
> 
> --
> 
> Checking reverse dependencies...
> ** libsablevm1 has an unsatisfied dependency on alpha: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on alpha: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on alpha: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on amd64: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on amd64: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on amd64: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on arm: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on arm: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on arm: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on armel: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on armel: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on armel: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on hppa: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on hppa: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on hppa: 
> libsablevm-classlib1-java
> ** jikes-sablevm has an unsatisfied dependency on hurd-i386: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on i386: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on i386: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on i386: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on ia64: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on ia64: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on ia64: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on m68k: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on m68k: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on m68k: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on mips: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on mips: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on mips: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on mipsel: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on mipsel: libsablevm-native1 
> (>> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on mipsel: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on powerpc: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on powerpc: libsablevm-native1 
> (>> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on powerpc: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on s390: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on s390: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on s390: 
> libsablevm-classlib1-java
> ** libsablevm1 has an unsatisfied dependency on sparc: 
> libsablevm-classlib1-java (>> 1.13)
> ** libsablevm1 has an unsatisfied dependency on sparc: libsablevm-native1 (>> 
> 1.13)
> ** jikes-sablevm has an unsatisfied dependency on sparc: 
> libsablevm-classlib1-java
> ** classpath-tools has an unsatisfied build-dependency: 
> libsablevm-classlib1-java
> Dependency problem found.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: O: classpath-tools - Free 'javah', 'javap', 'serialver' equivalents

[Matthias Klose]

reassign 473289 ftp.debian.org
thanks

this should be removed instead. These tools are now up to date in the
icepick package.

Gregory B. Prokopski writes:
> Package: wnpp
> Severity: normal
> 
> Hi,
> 
> This package needs a new maintainer,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: O: free-java-sdk - Complete Java SDK environment consisting of free Java tools

[Matthias Klose]

reassign 473284 ftp.debian.org
thanks

no, this package needs to be removed.

Gregory B. Prokopski writes:
> Package: wnpp
> Severity: normal
> 
> Hi,
> 
> This package needs a new maintainer,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java-common_0.28_i386.changes REJECTED

[Matthias Klose]

Michael Koch writes:
> On Wed, Mar 05, 2008 at 08:52:30PM +0100, Matthias Klose wrote:
> > Joerg Jaspert writes:
> > > Hi Maintainer,
> > > 
> > > rejected, lots of
> > > 
> > > E: default-jdk: no-copyright-file
> > > E: default-jdk: debian-changelog-file-missing-or-wrong-name
> > 
> > noted.
> > 
> > > Additionally you might want to listen/talk to others in the java team, 
> > > which
> > > have concerns about the package, just asking me about it...
> > 
> > would those "others" (plural) in the java team please notify me about
> > their concerns?  afaik these were addressed.  But maybe that's the
> > usual Debian communication ...
> 
> Well, that was me.

fine, who else?  or was Joerg (again) inaccurate?

> I strongly object that upload how it went. There are some issues that
> should be solved before the upload and as thats a policy change it needs
> to be explicitely ACKed by other DDs.

which policy change?   There's nothing new which does change the state
of the current java policy.  If you do want to use the opportunity of
that change to clean up the policy, that's fine with me, but please
don't use that "argument" for anything. fyi, these bugs about policy
changes are now nearly two years old, so I don't expect those to be
resolved before 6.0.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java-common_0.28_i386.changes REJECTED

[Matthias Klose]

Joerg Jaspert writes:
> Hi Maintainer,
> 
> rejected, lots of
> 
> E: default-jdk: no-copyright-file
> E: default-jdk: debian-changelog-file-missing-or-wrong-name

noted.

> Additionally you might want to listen/talk to others in the java team, which
> have concerns about the package, just asking me about it...

would those "others" (plural) in the java team please notify me about
their concerns?  afaik these were addressed.  But maybe that's the
usual Debian communication ...

have a nice evening.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Autobuilding packages depending on sun-java6-jdk

[Matthias Klose]

Florian Weimer writes:
> This does not work in a pristine build environment (such as one set up
> by pbuilder) because the DLJ has to be accepted, which can't work in a
> non-interactive environment.
> 
> How do you cope with that?

Preseed the debconf value.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing distro-{jre,jre-headless,jdk,jdk-builddep} packages

[Matthias Klose]

Vincent Fourmond writes:
> 
>   Hello Eric,
> 
> Eric Lavarde wrote:
> > I don't see the advantage of this approach over well defined virtual
> > packages, which I notice you seem anyway to implicitly expect
> > (java5-runtime, java5-sdk, etc...).
> > Can you perhaps elaborate a bit on this?
> 
>   Autobuilders cannot work with virtual packages. pbuilder cannot either.

exactly; assume we build with icedtea-jdk on i386 and amd64,
icedtea-jdk-zero on powerpc, cacao on arm and kaffe on ia64,
java-gcj-compat-dev on all other archs, then the proper b-d would look
like:

  icedtea-jdk [i386 amd64], icedtea-jdk-zero [powerpc], cacao [arm], kaffe 
[ia64], java-gcj-compat-dev [!i386 !amd64 !powerpc !arm !ia64]

instead of

  distro-jdk-builddep

And having a change in one arch changing it's preferred jre/jdk, you
start changing each package ...

plus you can have versioned dependencies on real packages.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Introducing distro-{jre,jre-headless,jdk,jdk-builddep} packages

[Matthias Klose]

[sent to debian-java@lists.debian.org and [EMAIL PROTECTED]

For packaging we currently use a build dependency on a package which
we did agree for packaging (java-gcj-compat-dev).  Now with other more
conformant Java implementations available, we might want to change to
those implementations for building the packages in the archive.  It
looks like we won't have stuff like OpenJDK and IcedTea available for
all architectures, but might be able to replace some parts with
alternate implementations, e.g. replacing the VM with cacao for some
architectures.  This will result in different package names for
different architectures.  Therefore I'd like to introduce dependency
packages which can be used / referenced across platforms.  The
packages itself are empty except for distro-jre-headless which
contains a symbolic link

  /usr/lib/jvm/distro-java -> java-gcj

These packages itself don't hold any other binaries and/or links to
the referenced packages.  We might need to discuss what we minimally
expect from a package claiming to provide a certain version of a
runtime.  The "upstream" version of these packages corresponds to the
provided runtime (use 1.5 or 5)?  These packages are proposed to be
built from the java-common package.

Comments?

  Matthias


=== ../distro-jre_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 4032 bytes: control archive= 523 bytes.
 533 bytes,14 lines  control  
  72 bytes, 1 lines  md5sums  
 Package: distro-jre
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List 
 Installed-Size: 28
 Depends: distro-jre-headless (= 1.5-28), java-gcj-compat (>= 1.0.77-4)
 Provides: java-runtime, java2-runtime, java5-runtime
 Section: interpreters
 Priority: optional
 Description: Standard Java or Java compatible Runtime
  This package points to the Java runtime, or Java compatible
  runtime recommended for the i386 architecture,
  which is java-gcj-compat-dev for .

=== ../distro-jre-headless_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 4170 bytes: control archive= 587 bytes.
 696 bytes,18 lines  control  
  81 bytes, 1 lines  md5sums  
 Package: distro-jre-headless
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List 
 Installed-Size: 36
 Depends: java-common, java-gcj-compat-headless (>= 1.0.77-4)
 Suggests: distro-jre
 Provides: java-runtime-headless, java2-runtime-headless, java5-runtime-headless
 Section: interpreters
 Priority: optional
 Description: Standard Java or Java compatible Runtime (headless)
  This package points to the Java runtime, or Java compatible
  runtime recommended for this architecture, which is
  java-gcj-compat-headless for i386.
  .
  The package is used as dependency for packages not needing a
  graphical display during runtime.

=== ../distro-jdk_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 4028 bytes: control archive= 523 bytes.
 525 bytes,14 lines  control  
  72 bytes, 1 lines  md5sums  
 Package: distro-jdk
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List 
 Installed-Size: 28
 Depends: distro-jre (= 1.5-28), java-gcj-compat-dev (>= 1.0.77-4)
 Provides: java-sdk, java2-sdk, java5-sdk
 Section: devel
 Priority: optional
 Description: Standard Java or Java compatible Development Kit
  This package points to the Java runtime, or Java compatible
  development kit recommended for this architecture, which is
  java-gcj-compat-dev for i386.

=== ../distro-jdk-builddep_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 3994 bytes: control archive= 477 bytes.
 432 bytes,12 lines  control  
  81 bytes, 1 lines  md5sums  
 Package: distro-jdk-builddep
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List 
 Installed-Size: 28
 Depends: distro-jdk (= 1.5-28)
 Section: devel
 Priority: optional
 Description: Standard Java or Java compatible build dependencies
  This package points to the build dependencies used to build
  packages requiring a Java or Java compatible Development Kit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

java status on the ports

[Matthias Klose]

Besides m68k hopelessly being behind we do have serious problems on
alpha, arm and hppa.

 - on arm, the bytecode compiler (ecj) doesn't produce correct code.
   there is currently a workaround to build the package on arm using
   byte-compiled code built on another architecture.  Aurelian has
   more information on that issue.  Afaik not a problem on armel.

 - on alpha, we do have testsuite failures, leading to a non-working
   interpreter (see http://bugs.debian.org/464156). We can build
   gcj-4.3 and ecj, but nothing more (if ecj is built with gcj-4.3).

 - on hppa, we do see bus errors trying to run the interpreter, plus
   new testsuite failure (see http://bugs.debian.org/464160).

Any help to fix these ports is appreciated, having a replacment for
gcj on these archs is fine as well.

Test results on all other architectures look fine.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help needed on the Java policy

[Matthias Klose]

Andrew Vaughan writes:
> If you are going to rework the virtual packages, please consider adding 
> -nox packages so that java{,5}-runtime can depend the appropriate X windows 
> packages, and server apps that don't need X windows can depend on 
> java{,5}-runtime-nox.

see java-gcj-compat-headless, currently in NEW.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help needed on the Java policy

[Matthias Klose]

Eric Lavarde writes:
> Hi everybody,
> 
> thanks for your answers, it looks like we don't have yet a consensus. 
> Let me try to suggest one.
> 
> POINT 1:
> 
> I would suggest to modify the Java Policy along these lines:
> - the specific java runtimes listed before java(2)-runtime are the ones 
> tested by the packager, and for which he's ready to stand up and make it 
> work (the supported runtimes).
> - if a bug report is related to another java runtime and the bug can't 
> be reproduced under the "supported" runtimes, the maintainer may 
> reassign the bug report to the "faulty" runtime package.
> 
> If there is a consensus on this one, I'll file a patch on java-common.

these packages having a last alternative dependency on '| java2-runtime'

> POINT 2:
> 
> I will duplicate the bug I got on FreeMind in 4 and forward them as follows:
> 
> 1. to sun-java5-jre and sun-java6-jre because they miss the X-library 
> dependencies, it can't be that my package has to depend on those in 
> order to work (how should I know which ones are required?).

for now, see the Recommends of that package.

> 2. to gij because it provides java2-runtime but doesn't provide the AWT 
> library.

no.

> 3. to gij again because, even after installation of libgcj9-0-awt, 
> FreeMind doesn't work properly with it.

maybe. please file an upstream report, then file a bug report in
debian and mark it as forwarded.


   Maybe having the sun-java[56] in debian is a mistake. It misleads
   people (even maintainers like you) to just use these, and not care
   about the free java stack.  Keep in mind that there's only a
   handful of people involved in java packaging in debian (sorry if I
   did miss someone).


  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#448286: java-common: [POLICY-PROPOSAL] Almost all Java libraries should be in section libs.

[Matthias Klose]

Eric Lavarde writes:
> Hi,
> 
> number of binary packages is relatively easy if it doesn't need to be 
> precise:
> 
> $ aptitude -F '%20p %13s' search '~Djava' | wc -l
> 419
> (all packages depending on packages containing java in their name; a 
> quick browsing through it tells me that it's a rather meaningful list)

packages ending in -gcj should be counted as well, other packages like
bsh are not on your list. I think Michael did have a more complete
list.

> Is there a command to get the source package name based on the binary 
> package name (aptitude doesn't seem to know about source packages)? Then 
> it's as easy... (I've got an idea of an ugly apt-cache hack, but perhaps 
> there is better)

use dctrl-tools to get the source package name from the binary package
name.

> What do you mean with "a proposal for archive admins"? Are you referring 
> to some part of the Debian policy I should actually know about? (well, 
> I'm no DD, so I've got an excuse)

no, afaik the last two sections added (perl and python) by archive
admins themself for technical reasons, not for some policy.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#448286: java-common: [POLICY-PROPOSAL] Almost all Java libraries should be in section libs.

[Matthias Klose]

Michael Koch writes:
> On Sat, Oct 27, 2007 at 10:24:56PM +0200, Eric Lavarde wrote:
> > Package: java-common
> > Version: 0.26
> > Severity: wishlist
> > 
> > 
> > Hello,
> > 
> > in section 2.4 "Java libraries" it should be specified that packages
> > containing such libraries should belong to the 'libs' section and not
> > to the 'devel' section.
> > 
> > As Java libraries, to the difference of C libraries, are at 
> > the same time for runtime and development usage, they could be in both,
> > but as 85% of them are already in this section, it makes more sense to
> > make it consistent this way. Also, a java developer should know this,
> > where a java user might not expect libraries to be in devel.
> 
> Agreed.
> 
> It would be better create an special 'java' section (as perl and python
> have there own sections too) but thats another issue.

afaics this needs some data (# of source packages for the new section,
# of binary packages for the new section), then a proposal for archive
admins.

please could somebody provide this information / package lists and
post it to debian-java?

I don't like having to change package sections twice.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eclipse-cdt FTBFS with gcj-4.2

[Matthias Klose]

reassign 432541 eclipse-cdt
clone 432541 -1
reassign -1 gcj-4.3
thanks

eclipse-cdt still FTBFS, so keeping a duplicate there.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#432541: eclipse-cdt FTBFS

[Matthias Klose]

Andrew Haley schrieb:
> Thomas Girard writes:
> 
>  > It built successfully in June[2], and started to fail building in July[3].
> 
> Ping Doko: what did you change in this time window?

On July 18:
gcc-4.1 (4.1.2-14) unstable; urgency=low

  * Update to SVN 20070718.
  * Update boehm-gc, libjava from the gcc-4.1 Fedora branch 20070718.

On July 18, gcj-4.2 was made the default gcj.

All the changes to gcj can be seen here:

http://packages.debian.org/changelogs/pool/main/g/gcj-4.1/current/changelog
http://packages.debian.org/changelogs/pool/main/g/gcj-4.2/current/changelog
http://packages.debian.org/changelogs/pool/main/g/gcc-defaults/current/changelog

Thomas, please could check with gcj-4.3 (from experimental) / gcc-snapshot?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IcedTea - a first step towards OpenJDK

[Matthias Klose]

Matthias Klose writes:
> IcedTea is a temporary fork of OpenJDK which allows building with a free
> toolchain and adding/replacing code which is not yet available under a free
> license. First deb Packages for amd64 and i386 are available at
> 
>   deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/
>   deb-src http://people.ubuntu.com/~doko/ubuntu/ gutsy/
> 
> Although the packages are built on gutsy, they are installable on sid as well.

the packages are now updated to the b19 build.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IcedTea - a first step towards OpenJDK

[Matthias Klose]

peter green schrieb:
>
>> well, then its cheaper to add it.
>>
>>
>>
> I've attatched a new debian/control with the build-deps fixed up to
> allow for building on sid.

fixed.

>> well, this is wrong, you are lacking the correct libraries. see
>> linux32(1) for
>> the personality thing.
>>
> I've attatched a new debian/rules with a check added so it errors out
> early and with instructions on what to do if it detects someone trying
> to build in a i386 chrot on an amd64 system without switching personality.

I don't like that one; this really is a setup issue of your chroot, it doesn't
belong into the package.

peter green schrieb:
> I have also discovered that the plugin package that icedtea builds is
> uninstallable if the plugin directories don't exist (which will happen
> unless the user has every supported browser installed), a new postinst
> that fixes this issue is attatched.

please send diffs instead of complete files; this is fixed for the next snapshot
package.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IcedTea - a first step towards OpenJDK

[Matthias Klose]

peter green schrieb:
> Matthias Klose wrote:
>> ok, except wget should not be part of the b-d's, if the zip file
>> already exists.
>>   
> The configure script checks for it and errors if it is not there.

well, then its cheaper to add it.

>> did you set the 32bit personality before entering the chroot? If not
>> try to use
>> schroot which does this for you (if correctly configured).
>>
>>   
> no, I've never had to for building debian packages before and i've no
> idea how to do it either. I really would rather avoid switching to a
> soloution like schroot if I can. Is there a way I can set it manually?
> (googling for linux kernel personality brought up mostly info on the
> linux compatibility features in sco unix)

well, this is wrong, you are lacking the correct libraries. see linux32(1) for
the personality thing.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IcedTea - a first step towards OpenJDK

[Matthias Klose]

peter green schrieb:
>> IcedTea is a temporary fork of OpenJDK which allows building with a free
>> toolchain and adding/replacing code which is not yet available under a
>> free
>> license. First deb Packages for amd64 and i386 are available at
>>
>>  deb http://people.ubuntu.com/~doko/ubuntu/
>>  gutsy/
>>  deb-src http://people.ubuntu.com/~doko/ubuntu/
>>  gutsy/
>>
>>
>> Although the packages are built on gutsy, they are installable on sid
>> as well.
> Unfortunately while the binary may be installable on sid the source
> doesn't seem to be buildable on it.
> 
> firstly I needed to do some tweaks to build-deps were needed to provide
> alternatives to ubuntu only packages. I added xbase-clients as an
> alternative for xprop and libxul-dev as an alternative for firefox-dev.
> wget was also missing from the build-deps.

ok, except wget should not be part of the b-d's, if the zip file already exists.

> However even with those things fixed it still doesn't build for me, in a
> 64 bit chroot on a 64 bit box and a 32 bit chroot on a 32 bit box I get
> the following errors
> 
> find rt -name '*.java' | sort > rt-source-files.txt
> nowarn -g -d lib/rt -bootclasspath '' -source 1.6 \
>  -sourcepath
> rt:openjdk/j2se/src/share/classes:openjdk/j2se/src/solaris
> /classes:generated:jce \
>  @rt-source-files.txt
> make[1]: nowarn: Command not found

ok, please install ecj by hand; that may be the dependency error (ecj-gcj not
depending on ecj).

> and in a 32 bit chroot on a 64 bit host I got the following error

did you set the 32bit personality before entering the chroot? If not try to use
schroot which does this for you (if correctly configured).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

IcedTea - a first step towards OpenJDK

[Matthias Klose]

IcedTea is a temporary fork of OpenJDK which allows building with a free
toolchain and adding/replacing code which is not yet available under a free
license. First deb Packages for amd64 and i386 are available at

  deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/
  deb-src http://people.ubuntu.com/~doko/ubuntu/ gutsy/

Although the packages are built on gutsy, they are installable on sid as well.
These packages target developers only. Feedback about the following topics is
appreciated:

 - packaging and installation issues; the packaging is derived from the
   sun-javaX packages, so the packages do have the same "features" and
   bugs.

 - license issues; we currently cannot upload the packages, because some
   files still have non-free or no licenses. Unfortunately there doesn't
   exist yet a list of problematic files.

 - usability; do packages and applications build and run with the new
   jre and jdk (focus on main)?

Please contact Michael Koch or me if you do want to join the packaging and
maintainance effort. Thanks for any input.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Memory problems with gij-4.1 and glibc 2.6

[Matthias Klose]

Andrew Haley writes:
> Marcus Better writes:
>  > I have recently had problems building Java packages. The build would just
>  > eat memory, and occasionally show things like:
>  > 
>  > GC Warning: Repeated allocation of very large block (appr. size 524288000):
>  > May lead to memory leak and poor performance.
>  > GC Warning: Out of Memory!  Returning NIL!
>  > 
>  > Turns out this is bug #433391, so beware...
> 
> It's probably not a bug in gcj: every time I've seen this it has
> turned out to be a bug in the application.  Of course, if you can
> reproduce this in a way that allows me to attach a debugger I'll fix
> it.

turned out to be a problem with glibc-2.6, 2.6.1 now includes a
workaround/fix, so this problem shouldn't show up anymore.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gcj-4.1/arm

[Matthias Klose]

Aurelien Jarno writes:
> 
> Matthias Klose a écrit :
> > That is strange; looks like the just built interpreter doesn't
> > work.  Maybe we should get it working upstream first.
> > 
> >   Matthias
> > 
> > Joey Hess writes:
> >> So far, I'm stuck here:
> >>
> >> Adding java source files from srcdir 
> >> '../../../../../src/libjava/classpath'.
> >> Adding java source files from VM directory /tmp/gcj-4.1-4.1.2/src/libjava
> >> Adding java source files from VM directory 
> >> /tmp/gcj-4.1-4.1.2/build/arm-linux-gnu/libjava
> >> Adding generated files in builddir '..'.
> >> /tmp/gcj-4.1-4.1.2/build/gcc/gcj 
> >> -B/tmp/gcj-4.1-4.1.2/build/arm-linux-gnu/libjava/ 
> >> -B/tmp/gcj-4.1-4.1.2/build/gcc/ -C -g -w --encoding=UTF-8 -bootclasspath 
> >> '' --classpath 
> >> /tmp/gcj-4.1-4.1.2/src/libjava:/tmp/gcj-4.1-4.1.2/build/arm-linux-gnu/libjava:../../../../../src/libjava/classpath:../../../../../src/libjava/classpath/external/w3c_dom:../../../../../src/libjava/classpath/external/sax:../../../../../src/libjava/classpath/external/relaxngDatatype:../../../../../src/libjava/classpath/external/jsr166:.::
> >>  -d ../../../../../src/libjava/classpath/lib @classes
> >> Exception in thread "main" java.lang.ExceptionInInitializerError
> >><>
> >> Caused by: java.lang.NullPointerException
> >><>
> >> make[7]: *** [compile-classes] Error 1
> >> make[7]: Leaving directory 
> >> `/tmp/gcj-4.1-4.1.2/build/arm-linux-gnu/libjava/classpath/lib'
> >>
> >> -- 
> >> See shy jo
> > 
> 
> I also have a problem while bootstrapping it. It waits indefinitely on:
> 
> checking if /home/aurel32/gcj/gcj-4.1-4.1.2/build/gcc/gcj supports
> -fno-rtti -fno-exceptions
> 
> It looks like the generated compiler does not work.

I didn't see this failure yet. So maybe this is a bug in the libffi
backport for arm? btw, Martin Michlmayr checked that Phil Blundell has
a copyright assignment for GCC, so if somebody updates the arm libffi
support for the trunk, I assume it can be submitted upstream.

  Matthias

Re: Plans about OpenJDK ?

[Matthias Klose]

Yann Dirson writes:
> Hi Debian-Java team,
> 
> Following the recent OpenJDK announcement, I suppose that many Debian
> users, but also DD's with packages that still require Sun JDK to
> build/work, can't wait to see it packaged :)
> 
> The only information I could find about openjdk is the Nov'06 ITP's
> for the early parts - nothing in various list archives or in svn.  Has
> anyone started to work on this ?  Is any help needed ?

I did have a look at Ola's packages for the compiler and the vm,
currently looking at the openJDK.  A headless jdk/vm not needing the
binary blobs seems to be most likely go get it into the free sections
of the archive.  Because openJDK won't be available for all
architectures we will have to use gcj for most of our architectures.
I didn't set up a repository yet.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: maven2 for Debian

[Matthias Klose]

[EMAIL PROTECTED] writes:
> I think it would be better to just leave the version as is and accept  
> that multiple version sit around on the file system. They don' cause  
> any harm anyway.

they do. Do you volunteer to provide security upgrades for two years
for 10 versions of the same library?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#411692: bootchart-view: Needs libgtkpeer.so when converting a bootchart to EPS or PNG format

[Matthias Klose]

Jörg Sommer writes:
> Hi Java team,
> 
> I've got a bug report that libgtkpeer.so is missing if gcj-4.1 is used.
> 
> IMO this is a bug in gcj. kaffe and sablevm provide through dependencies
> the file libgtkpeer.so.

This is done by intent, so you are able to run java apps without
graphical ui's on machines which don't have gtk and X installed.

What is missing (and fixed and gcc svn) is a missing recommends on
libgcj7-awt in the libgcj7-0 or gij-4.1 packages (however gij already
recommends libgcj7-awt).

> kaffe -> kaffe-pthreads | kaffe-jthreads  -- both ship libgtkpeer.so
> sablevm -> libsablevm1 -> libsablevm-native1
> 
> Where is the bug? Must the bootchart-view package depend on libgcj7-awt
> or classpath-gtkpeer?

yes, maybe we should introduce a new virtual package
java-runtime-with-ui, which is provided by the packages above.

  Matthias

gnome-java bindings

[Matthias Klose]

Please could you consider uploading the current gnome-java bindings
(including the vte bindings) to unstable?  You can get the current
versions from Ubuntu feisty. I won't have the time to upload these
versions myself.

Thanks, Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Will eclipse be part of etch?

[Matthias Klose]

Filipus Klutiero writes:
> Did this hesitation include making sure that #401570/#406583 is not a 
> serious eclipse bug?

both bugs are reported against swt-gtk and still open; it's fixed in
the pkg-java svn.  We (Michael Koch and me) did try several times to
convince the swt-gtk maintainer to build the swt-gtk packages from the
eclipse source, but we didn't have any success.  The binaries built
from the swt-gtk source are unusable at least for eclipse.

The binaries built from the eclipse source could provide the binaries
built from the swt-gtk source, but I currently don't see a way to not
allow installation of the -jni and the -java package built from
different sources.

  Matthias




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Location of API docs

[Matthias Klose]

Mark Wielaard writes:
> Hi Matthias,
> 
> On Thu, 2007-01-11 at 21:11 +0100, Matthias Klose wrote:
> > The idea was to make the -doc packages depend on other -doc packages
> > so that references to other packages can be resolved; unfortunately
> > gjdoc doesn't support that yet.
> 
> What would you need from gjdoc to support 'that'?
> Could you give an example, I am afraid I was unable to follow the
> discussion to see what is really needed here.

Assuming that the doc is installed in /usr/share/doc/libfoo-java/api,
a reference to a class Bar should point to ../../libbar-java/api. Not
yet sure how to find the location for this reference (but it seems to
be easier to use the name of the java package in all cases, instead of
the name of the -doc package in some cases).

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Location of API docs

[Matthias Klose]

Marcus Better writes:
> Matthias Klose wrote:
> >> which seems more sensible to me. Should I change it to
> >> /usr/share/doc/$package/api? I assume I should also create a doc-base.
> 
> > where $package is the name of the library package, not the name of the
> > doc package (if there exists an extra -doc package).
> 
> How come? I thought we put api docs in the -doc package, if there is
> one.

exactly, but into the /usr/share/doc/$package/api directory, not into
the /usr/share/doc/$package-doc/api directory.

> > The idea was to make the -doc packages depend on other -doc packages
> > so that references to other packages can be resolved;
> 
> Seems more reasonable to build-depend on the other doc packages to get the
> references right,

sure, if you get this working, this would be fine. Please summarize on
the list.

> and then Recommend or Suggest the others. For example,
> you can make good use of api docs for a library without having
> classpath-doc.

Recommends sounds be useful.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Will eclipse be part of etch?

[Matthias Klose]

Steve Langasek writes:
> On Tue, Dec 19, 2006 at 02:16:54AM -0800, Peter Ronnquist wrote:
> > It seems like eclipse will not be part of the etch release. Is this
> > a mistake?
> 
> No, it is not; it's a direct consequence of the eclipse maintainers not
> having a releasable package at the appropriate point in the release cycle.
> 
> > Eclipse is depending on a new version of jsch and since etch is in freeze
> > its not easy to update jsch.
> 
> eclipse is not the only reverse-dependency of jsch, and the update of jsch
> is a large one that may destabilize its reverse-dependencies.

eclipse currently is RC bug free. From my point of view jsch is stable
enough to enter testing; maybe Michael could provide more evidence for
the safty of the upgrade.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Location of API docs

[Matthias Klose]

Paul Cager writes:
> I am updating the BCEL library to the new upstream version. The old
> version installed the Javadocs into:
> 
>   /usr/share/doc/$package/doc/api
> 
> Daniel Baumann queried this last night on IRC, and it seems that other
> (newer) packages (e.g. libxalan2-java-doc) install into
> 
>   /usr/share/doc/$package/api
> 
> which seems more sensible to me. Should I change it to
> /usr/share/doc/$package/api? I assume I should also create a doc-base.
> 
> Any comments?

where $package is the name of the library package, not the name of the
doc package (if there exists an extra -doc package).

The idea was to make the -doc packages depend on other -doc packages
so that references to other packages can be resolved; unfortunately
gjdoc doesn't support that yet.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Repackaging question

[Matthias Klose]

Marcus Better writes:
> Matthias Klose wrote:
> > Marcus Better writes:
> >> instance we ship a lot of packages that build with Maven, but since we
> >> don't have Maven in Debian, we use the included, pre-generated, Ant build
> >> file instead. What should we do about those?
> > 
> > if these packages are in main, file a RC report and remove them, at
> > least from testing.
> 
> That's a bit drastic, no? Those packages are no different from packages with
> pre-generated configure scripts and the like, and those are accepted in
> main, IIRC.

you can recreate them using packages in main. you can't do this
with the maven jars.

> > Then package maven and maven2.
> 
> "Good idea, why don't you try it?", to quote someone on -project
> recently. :-)
> 
> Actually I'm planning to have a go at those, but they are rather
> complicated.
> 
> > which packages are these?
> 
> AFAICT, all of Jakarta Commons, dom4j, jaxen, and probably a lot more. Plus

looked at libcommons-logging-java, jaxen, dom4j, which do not use
maven for the build. so which sources are actually including maven
jars?

> upcoming Tomcat 6.

that's easy. package it for non-free or don't package it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Repackaging question

[Matthias Klose]

Marcus Better writes:
> Andrew Haley wrote:
> >  > It's a good idea to remove generated javadoc and jar files and classes.
> > 
> > Very much so.  Unless you build from source, you have no way to know
> > that the binaries correspond to that source code.  You can't even
> > guarantee that you're not violating the GPL, which requires you to
> > provide source code on demand.
> 
> That may be a valid argument, but there are more troubling cases. For
> instance we ship a lot of packages that build with Maven, but since we
> don't have Maven in Debian, we use the included, pre-generated, Ant build
> file instead. What should we do about those?

if these packages are in main, file a RC report and remove them, at
least from testing.  I don't care that much about contrib. Such
packages may exist in non-free.

Then package maven and maven2.

which packages are these?

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC-DRAFT] Debian-Java point of view about JDK under the GPL

[Matthias Klose]

Andrew Haley writes:
> Matthias Klose writes:
>  > Arnaud Vandyck writes:
>  > > Hi debian-java team,
>  > > 
>  > > I'd like us to write a common position statement about the jdk under
>  > > the gpl. I think these points should be mentioned:
>  > > 
>  > > o This is really a good thing for us because it is now really the GPL
>  > > (+Classpath exception), not a MPL like license;
>  > > 
>  > > o Sun worked hard to have the jdk in Debian for some time now. (My
>  > > POV: not the right way, but they did it, thanks ;-));
>  > > 
>  > > o Let be patient. There is still a lot of work for everything to be 
> integrated;
>  > 
>  >   o Debian currently supports java compatible infrastructure on more
>  > archs than the sun jdk supports.  I would like to pick up the ideas
>  > from the Oldenburg meeting last year for arch dependent packages
>  > default-jre and default-jdk.
> 
> Yeah.  It would be nice to try to figure out where Java run-times for
> the various architectures are going to come from.
> 
> What architectures do you support with the Sun JRE?

currently none; delaying that until the SDK is available ...

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: openjdk-hotspot-jvm -- Hotspot JVM from Sun

[Matthias Klose]

Ola Lundqvist writes:
> Hi
> 
> On Thu, Nov 16, 2006 at 11:22:37PM +0100, Matthias Klose wrote:
> > Ola Lundqvist writes:
> > > -rw-r--r-- root/root 77508 2006-11-16 20:38 ./usr/include/jvmti.h
> > > -rw-r--r-- root/root 68996 2006-11-16 20:38 ./usr/include/jni.h
> > > drwxr-xr-x root/root 0 2006-11-16 20:38 ./usr/include/linux/
> > > -rw-r--r-- root/root  1780 2006-11-16 20:38 
> > > ./usr/include/linux/jni_md.h
> > > -rw-r--r-- root/root 13258 2006-11-16 20:38 ./usr/include/jmm.h
> > 
> > that is definitely wrong. please move these to a private area.
> 
> Ok, if they are private, should they be included at all?

yes, every jdk provides them. you usually want them installed, but in
a directory where these can be access by a specific include only.

> > > drwxr-xr-x root/root 0 2006-11-16 20:38 
> > > ./usr/lib/openjdk-hotspot-jvm/
> > 
> > why -jvm? is there a separate dir for -jdk?
> 
> Because the package name is -jvm. It has no jdk functionality as it is not
> released yet.

maybe. but different directories for jvm and jdk are a bad
idea. please have a look at  the java-gcj-compat and sun-java5
packages. both jre and jdk should install into a common directory.

> > please provide the jvm in /usr/lib/jvm, as we currently do for the
> > majority of packaged runtimes.
> 
> Oh such a directory exist. I'll move it there. I'll check the other jvms
> to see how they handle the structure.

that would be nice.  I had a chat with Tom Marble how to better handle
the set of alternatives forming a runtime or a jdk, but none of us did
write down a proposal yet.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC-DRAFT] Debian-Java point of view about JDK under the GPL

[Matthias Klose]

Arnaud Vandyck writes:
> Hi debian-java team,
> 
> I'd like us to write a common position statement about the jdk under
> the gpl. I think these points should be mentioned:
> 
> o This is really a good thing for us because it is now really the GPL
> (+Classpath exception), not a MPL like license;
> 
> o Sun worked hard to have the jdk in Debian for some time now. (My
> POV: not the right way, but they did it, thanks ;-));
> 
> o Let be patient. There is still a lot of work for everything to be 
> integrated;

  o Debian currently supports java compatible infrastructure on more
archs than the sun jdk supports.  I would like to pick up the ideas
from the Oldenburg meeting last year for arch dependent packages
default-jre and default-jdk.

> o We (Ola Ludvig and other?) are working to build hotspot and javac
> with free software;

I would like to see a dedicated group caring about these
packages. "Debian Java maintainers" seems a bit broad.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: openjdk-hotspot-jvm -- Hotspot JVM from Sun

[Matthias Klose]

Ola Lundqvist writes:
> -rw-r--r-- root/root 77508 2006-11-16 20:38 ./usr/include/jvmti.h
> -rw-r--r-- root/root 68996 2006-11-16 20:38 ./usr/include/jni.h
> drwxr-xr-x root/root 0 2006-11-16 20:38 ./usr/include/linux/
> -rw-r--r-- root/root  1780 2006-11-16 20:38 ./usr/include/linux/jni_md.h
> -rw-r--r-- root/root 13258 2006-11-16 20:38 ./usr/include/jmm.h

that is definitely wrong. please move these to a private area.

> drwxr-xr-x root/root 0 2006-11-16 20:38 ./usr/lib/openjdk-hotspot-jvm/

why -jvm? is there a separate dir for -jdk?

please provide the jvm in /usr/lib/jvm, as we currently do for the
majority of packaged runtimes.

> -rw-r--r-- root/root   1503518 2006-11-16 20:38 ./usr/lib/sa-jdi.jar

is this arch-specific? is this jvm-specific?

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#387875: Patch for ARM gcj

[Matthias Klose]

Daniel Jacobowitz writes:
> On Thu, Nov 09, 2006 at 07:59:20PM +0100, Matthias Klose wrote:
> > Riku Voipio writes:
> > > tags 387875 +patch
> > > thanks
> > > 
> > > Verified that gcj-4.1 builds with this patch, and with patched version
> > > ecj-bootstrap build fine as well.
> > 
> > just to clarify, could you verify, that packages using gjdoc and ecj
> > build as well?
> 
> He wrote on IRC:
> 
>  drow: apparently installing fails :|
>  installing gjdoc that is
>  Setting up gjdoc (0.7.7-6) ...
>  gcj-dbtool-4.1 succeeded unexpectedly
>  gcj-dbtool-4.1 succeeded unexpectedly
>  java.io.IOException: Invalid argument < available>>
>  .
> 
> Where do we go from here?  If the patch is still an improvement, I'd
> suggest including it; I'm not going to have another day to figure out
> what's wrong with gjdoc for a while.

Looks like we are back to a state where basic java programs do work? 
Riku, does a HelloWorld program compiled to native code work?

I'll include the patch with the next upload (maybe today, or else on
Monday).

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gcj/java status

[Matthias Klose]

Steve Langasek writes:
> On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote:
> > Steve Langasek writes:
> > > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
> > > > Please consider moving the following packages to testing:
> 
> > > > gcj-4.1
> 
> > > I'm wondering whether the build-dependencies of gcj-4.1 are really 
> > > accurate. 
> > > Is it really the case that gcj-4.1 will build against any version of
> > > gcc-4.1-source between 4.1.1 and 4.1.2?  How is this done, when the 
> > > gcc-4.1
> > > source package appears to incorporate various updates from svn into the
> > > actual tarball being distributed?  Doesn't this imply that gcj-4.1 and
> > > gcc-4.1 will need to be updated in lockstep?
> 
> > no, only the upstream tarball is used from gcc-4.1-source. the
> > patches are used from the gcj-4.1 source. The patches in
> > gcc-4.1-source are needed to build cross compilers, based on
> > gcc-4.1-source.
> 
> My point was that the upstream tarball shipped within the gcc-4.1 source
> package differs between 4.1.1-13 and 4.1.1-19, and according to the
> changelog appears to incorporate additional changes from upstream svn.  Have
> I misunderstood?

the upstream tarball has the same code, just some more GFDL'ed files
removed. changes from upstream svn are included as a diff.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian-Edu and Java (Was: java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit)

[Matthias Klose]

Petter Reinholdtsen writes:
> The most important feature is java applet support.  Some of the
> important test cases are listed on
> http://wiki.debian.org/DebianEdu/JavaInDebianEdu>.  Last time I
> tested, few of them were working properly in Etch with gcjappletviewer. :(

apparently before java-gcj-compat-plugin entered the archive,
equivalent with the classpath-0.92 release.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]