Bug#827280: jython: Jython 2.7.0 released 2015-05, package should be updated

[Russel Winder]

Package: jython
Version: 2.5.3-9
Severity: normal

Dear Maintainer,

The jython package reports version 2.5.3, but Jython 2.7.0 was release 2015-05 
and so the package should be
updated.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jython depends on:
ii  antlr3.2 3.2-14
ii  libasm3-java 3.3.2-3
ii  libguava-java19.0-1
ii  libjffi-java 1.2.7-9
ii  libjline-java1.0-2
ii  libjnr-constants-java0.8.6-7
ii  libjnr-netdb-java1.1.4-2
ii  libjnr-posix-java3.0.12-2
ii  libjnr-x86asm-java   1.0.2-5
ii  liblivetribe-jsr223-java 2.0.6-1
ii  libreadline-java 0.8.0.1+dfsg-4+b1
ii  openjdk-8-jre-headless [java5-runtime-headless]  8u91-b14-2
ii  perl 5.22.2-1
pn  python:any   

Versions of packages jython recommends:
ii  openjdk-8-jdk [java-compiler]  8u91-b14-2

Versions of packages jython suggests:
ii  jython-doc   2.5.3-9
pn  libmysql-java
pn  libpostgresql-jdbc-java  
ii  libservlet3.1-java   8.0.32-1

-- debconf-show failed

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#793630: groovy 1.8.6 and libcommons-cli-java 1.3.1 FTBFS

[Russel Winder]

Emmanuel, Miguel,

On Wed, 2015-07-29 at 09:57 +0200, Emmanuel Bourg wrote:
 Le 29/07/2015 03:35, Miguel Landaeta a écrit :
 
  Since you have worked upstream with libcommons-cli-java, I hope to
  don't bother you with this help request.
 
 commons-cli provides several parsers with different behaviors. Up to 
 1.2
 there was a gnu and a posix parsers, and starting with 1.3 I 
 introduced
 a new unified parser (DefaultParser). You may try using it, it's just 
 a
 matter of changing the instantiation and it's likely to work better.

As far as I am aware, the Apache Groovy source explicitly imports and
uses the GnuParser – even now despite it being deprecated – as part of
the CliBuilder class. All other uses of org.apache.commons.cli in the
Apache Groovy source use DefaultParser. If I remember correctly,
DefaultParser, which is PosixParser I believe, enforces bursting of
single hyphen options, which is fine for the Groovy command line, but
not sufficiently flexible for the CliBuilder.

The Java Way is for a version of something, in this case Groovy 1.8.6
to retain its original dependency, in this case Commons CLI 1.2.x,
rather than have the dependencies altered without a new release – most
people get their dependencies from JCenter or Maven Central via Gradle
or Maven.

Apache Groovy 1.x series is no longer maintained. All effort is now on
the Apache Groovy 2.4.x and 2.5-SNAPSHOT versions. If Debian is to
remove Commons CLI 1.2 then I suggest removing the groovy package since
the groovy2 package is in place already, and is the right version for
Debian to go with.

Unless I am missing something.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#733234: Groovy fails with groovy.lang.MissingMethodException

[Russel Winder]

On Sat, 2014-05-03 at 16:03 -0300, Miguel Landaeta wrote:
[…]
 
 FYI: If there are not objections and I don't stumble upon any other
 blocker issue, I intend to upload groovy2 package during the next week
 to unstable.
 

That works for me.

Gradle 1.12 was released a few days ago. It will be the last in the 1.x
series, the next Gradle will be 2.0 and it will depend on Groovy 2,
probably 2.2.2. My guess is that it will be 4 to 8 weeks, but I am not a
Gradle insider. I can find out more if that would help.

As far as I am aware no other mainstream Groovy-based system depends on
Groovy 1: Griffon, Grails, Gant, Lazybones, GroovyFX, all work on Groovy
2.2.

Groovy 2.3 is in release candidate cycle, and is the first Groovy to
officially support Java 8, though it still works with Java 6 for those
who have not yet realized that 6 is a dead version of Java :-)
Personally I only use Java 8 and have done for many, many months.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#733234: Groovy fails with groovy.lang.MissingMethodException

[Russel Winder]

On Fri, 2014-04-18 at 00:44 +0100, Stephen Nelson wrote:
[…]
 
 I'm looking at this too, as it stops work on building Spring using
 Gradle. I updated groovy to 1.8.9, and still gradle fails. So I
 thought about including the required dependencies to enable the groovy
 tests. This will prove the software performs as originally intended.
 So far, I've got the tests to compile but not yet run with groovy
 1.8.9. I can continue with that, but I agree getting a more recent
 groovy would be advantageous for reasons other than gradle.

I am a Debian Sid user and supporter (people keep trying to take me to
Fedora, but I resist :-) I am also on the Groovy development team, wrote
Gant and am driving the reworking of GPars. I am a Java 8 user, for me
all Javas prior to 8 no longer exist. I mention all this (that Miguel
already knows), to reinforce that I want to be constructive and
supportive in what is turning into a bit of a mess.

The core problem here with the Java and Groovy support on Debian is the
policy of one and only one version, and no use of Maven Central or
Bintray/jCentre for build.

The whole Java milieu revolves around concurrent multiple versions of
artefacts, with dependency management. People try and avoid multiple
versions of an artefacts running at the same time on a single JVM
instance, but when they do that then they use OSGi.

Frameworks like Gradle, Grails, Griffon generally carry their own
version of Groovy so as to ensure no incompatibilities or dependency
hell.  Gradle is currently stuck on using Groovy 1.8.6 because of some
breaking change in 1.8.7 and later. The Gradleware folk are looking to
upgrade to Groovy 2.2.2 for Gradle 2.0 which will be the next release
after 1.12 in a few days. Gradleware have a timeboxed approach so 2.0 is
effectively imminent.

Most people these days are using GVM Tool (a bash script system) to
download Gradle, Grails, Groovy, Vert.x, Griffon, etc. This works well
and nigh on obviates the need for any of these to be packaged by Debian.

On the other hand Gradle is now the standard build framework for
Android, and AndroidStudio the default IDE. I mention this to suggest
that having up to date Gradle is probably more important than up-to-date
Groovy. This is reinforced because most people will use Maven Central to
get Groovy from for their projects anyway. So just because Gradle uses
Groovy 1.8.6, the systems built using Gradle are likely using Groovy
2.2.3 (or now 2.3.0-beta).

Gradle is also becoming a C++ build system to replace Make, CMake,
Autotools, and do battle with SCons and Waf. Like Waf, projects will use
the Gradle Wrapper so that the project can use the right version of
Gradle and thence Groovy to avoid problems. Of course this usage means
Gradle Wrapper falls into the same problem as Waf with respect to Debian
packaging policy.

Shortly Gradle will be using Groovy 2.2 and I think that is the right
point to get a Gradle/Groovy system into Jessie. I'm afraid there is no
point in trying to get any Groovy later than 1.8.6 in if Gradle 1.x is
in Debian and the single version only policy is to be maintained.

Do let me know what I can do to help here. Although I compile Groovy
master/HEAD for my use and use GVM for Gradle, I want to see a modern
Gradle (and Groovy) in Debian. The best thing of course would be to
allow the latest Gradle to use whichever Groovy it wants, and allow the
latest Groovy to be installed as well. However I understand this is
incompatible with Debian packaging policy. Thus the only feasble thing
to provide maximum benefit is to package the latest Gradle and just use
the dependencies it demands.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#733234: Groovy fails with groovy.lang.MissingMethodException

[Russel Winder]

On Fri, 2014-04-18 at 17:54 +0200, Emmanuel Bourg wrote:
 Thank you for stepping in Russel.

No problem, glad to help.

 Just to clarify the unique version policy isn't an absolute
 requirement. If it's necessary multiple versions of an application or
 library can be packaged (for example JUnit 3 and 4, Maven 2 and 3,
 Tomcat 678, ASM 3 and 4, etc).
 
 Thanks to your explanations it becomes clear I think that we must
 package groovy 2 separately, and keep the original groovy package at
 version 1.8.6 until the transition to Gradle 2 is complete.

This (mostly) works for me. If there is (Groovy|Gradle|Grails|Griffon)
(1|2|3) then the dependency problem becomes a lot less painful.



PS I am fairly sure we've collaborated before, was it something such as
Commons CLI?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#728562: libgpars-groovy-java, groovy: error when trying to install together: overwriting /usr/share/groovy/lib/gpars.jar

[Russel Winder]

Andreas,

On Sun, 2013-11-03 at 02:34 +0100, Andreas Beckmann wrote:
 Package: libgpars-groovy-java,groovy
 Version: 2.1.6+dfsg-1
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-file-overwrite
 
 Architecture: amd64
 Distribution: sid + experimental
 
 Hi,
 
 automatic installation tests of packages that share a file and at the
 same time do not conflict by their package dependency relationships has
 detected the following problem:
 
   Preparing to replace groovy 1.8.6-1 (using .../groovy_2.1.6+dfsg-1_all.deb) 
 ...
   Unpacking replacement groovy ...
   dpkg: error processing /var/cache/apt/archives/groovy_2.1.6+dfsg-1_all.deb 
 (--unpack):
trying to overwrite '/usr/share/groovy/lib/gpars.jar', which is also in 
 package libgpars-groovy-java 0.10-1
 
 This is a serious bug as it makes installation fail, and violates
 sections 7.6.1 and 10.1 of the policy. An optimal solution would
 consist in only one of the packages installing that file, and renaming
 or removing the file in the other package. Depending on the
 circumstances you might also consider Replace relations or file
 diversions. If the conflicting situation cannot be resolved then, as a
 last resort, the two packages have to declare a mutual
 Conflict. Please take into account that Replaces, Conflicts and
 diversions should only be used when packages provide different
 implementations for the same functionality.

Whilst this may a priori be a failure of the Debian packaging rules, the
situation stems from the fact that GPars used to be a totally separate
thing from Groovy, but now the Groovy distribution includes and relies
on GPars even though it is has a separate development line. I argue that
the Debian package strategy may well be the underlying problem here
because it does not allow multiple versions of artefacts as is standard
practice in the JVM-verse.

Whilst libgpars-groovy-java used to be a good idea, the gpars artefact
should be an integral part of the groovy package from Groovy 2.0
onwards.

Also worth noting that GPars 0.10 is ancient, we are now at 1.1 and
wondering when to release 1.2.

 Here is a list of files that are known to be shared by both packages
 (according to the Contents file for sid/amd64, which may be
 slightly out of sync):
 
   /usr/share/groovy/lib/gpars.jar

This raises the issue of why Debian has a single unnumbered artefact
when the Java universe works with numbered artefacts so that different
versions can be used in the same system.  In particular, in order to
have Gradle 1.x installed, Groovy 1.8.x must be installed, which means
Groovy 2.1.x cannot be installed unless Gradle is removed. There is a
viscous circle here leading to Debian being unable to support the Groovy
infrastructure.

Debian really needs to change it's Java and Groovy policies to enable
multiple versions of artefacts.

To be honest the current situation means most people ignore the Debian
packaging system for Java and Groovy (and indeed Scala, Ceylon, Kotlin,
Clojure, etc.) and use the language specific installations. For Groovy
this means using GVM, which is a Bash based package installer which just
requires some Java install at JAVA_HOME. Most people use the Oracle
distribution, particularly those of us using Java 8 – which cannot be
packaged by Debian for Unstable for sensible reasons.
 
 This bug is assigned to both packages. If you, the maintainers of
 the two packages in question, have agreed on which of the packages will
 resolve the problem please reassign the bug to that package. You may
 also register in the BTS that the other package is affected by the bug.
 
 Cheers,
 
 Andreas
 
 PS: for more information about the detection of file overwrite errors
 of this kind see http://edos.debian.net/file-overwrites/.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#683595: gradle: Gradle package will not install if Tomcat 7 is installed

[Russel Winder]

Package: gradle
Version: 1.0~m3-1
Severity: important

Dear Maintainer,

The Gradle package seems to explicitly depend on Tomcat 6 rather than the 
presence of a Tomcat. Since in
Debian Tomcat 6 and Tomcat 7 cannot coexist, it is not possible to have both 
Tomcat and Gradle packages
installed on the same machine.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=str=こんにちわ世界, 
bytes_read=21, bytes_written=21) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gradle depends on:
ii  ant   1.8.2-4
ii  ant-optional  1.8.2-4
ii  bnd   1.50.0-5
ii  bsh   2.0b4-12
ii  checkstyle5.4-2
ii  default-jre-headless  1:1.6-47
ii  groovy1.8.6-1
ii  ivy   2.2.0-2
ii  junit44.10-3
ii  libantlr-java 2.7.7+dfsg-4
ii  libasm3-java  3.3.2-1
pn  libcodenarc-groovy-java   none
ii  libcommons-beanutils-java 1.8.3-3
ii  libcommons-cli-java   1.2-3
ii  libcommons-codec-java 1.6-1
ii  libcommons-collections3-java  3.2.1-5
ii  libcommons-httpclient-java3.1-10
ii  libcommons-io-java1.4-4
ii  libdom4j-java 1.6.1+dfsg.2-6
ii  libgoogle-collections-java1.0-2
pn  libgradle-core-java   none
pn  libgradle-plugins-javanone
ii  libjansi-java 1.4-3
ii  libjaxen-java 1.1.3-1
pn  libjetty-extra-java   none
ii  libjetty-java 6.1.26-1
pn  libjna-posix-java none
pn  libjoptsimple-javanone
ii  libjsch-java  0.1.42-2
pn  libjzlib-java none
pn  liblogback-java   none
ii  libmaven-ant-tasks-java   2.1.3-2
ii  libmaven2-core-java   2.2.1-8
pn  libplexus-component-api-java  none
ii  libplexus-containers-java 1.0~beta3.0.7-5
ii  libservlet2.5-java6.0.35-4
ii  libslf4j-java 1.6.5-1
pn  libsvnkit-javanone
pn  libtomcat6-java   none
ii  libwagon-java 1.0.0-2
ii  testng5.11+dfsg-3

Versions of packages gradle recommends:
pn  libgradle-announce-java  none
pn  libgradle-antlr-java none
pn  libgradle-code-quality-java  none
pn  libgradle-ide-java   none
pn  libgradle-jetty-java none
pn  libgradle-maven-java none
pn  libgradle-osgi-java  none
pn  libgradle-scala-java none
pn  libgradle-wrapper-java   none

gradle suggests no packages.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#617772: Groovy with non-default JRE

[Russel Winder]

Miguel,

On Fri, 2011-03-11 at 15:47 -0430, Miguel Landaeta wrote:
 On Fri, Mar 11, 2011 at 12:26 PM, Russel Winder rus...@russel.org.uk wrote:
  Groovy 1.7.9 hit the streets yesterday, along with 1.8.0-rc-2.  I don't
  know if this changes anything on the todo list.
 
 Not at all, the fix for this bug should be uploaded together with the new
 upstream release.

I heard yesterday that there is a problem with 1.7.9 you just packaged
and had accepted into unstable that means 1.7.10 will come out very soon
now.  I don't believe this is a regression per se, but the fact that
Guillaume et al. are seeking to rush out a new bug fix release is fairly
indicative of the problem being reasonably serious.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please 
use
debian-j...@lists.debian.org for discussions and questions.

Bug#617772: Groovy with non-default JRE

[Russel Winder]

Miguel,

Groovy 1.7.9 hit the streets yesterday, along with 1.8.0-rc-2.  I don't
know if this changes anything on the todo list.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please 
use
debian-j...@lists.debian.org for discussions and questions.

Re: Groovy in Debian

[Russel Winder]

On Thu, 2011-02-17 at 15:11 -0430, Miguel Landaeta wrote:
[ . . . ]
 That notification is due an old Groovy package that I prepared and uploaded
 to mentors but was never uploaded to the archive. That notification will go 
 away
 very soon.

Splendid.  I suspected it would but was just checking.

 Regarding 1.7.8, Tony Mancill has just uploaded this version to unstable.
 Thanks for notifying this to us.

I got the acceptance notification, so see things have happened nice and
quickly, thanks for responding to my email promptly.

Sending in notes as I did is the trivial bit, it is you people doing
that packaging that do the hard work, thanks for undertaking it.

The JVM eco-system seems to be hard one to handle in Debian -- I guess
because of the jar hell problem.  Presumably this will only get worse
as OSGi and/or Project Jigsaw go into real production so that it is
possible, indeed required, to have multiple versions of jars all loaded
at once.  I assume all the JVM-related packages will have to head
towards being packaged with their version number in the name as GCC is? 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please 
use
debian-j...@lists.debian.org for discussions and questions.

Groovy in Debian

[Russel Winder]

Hi,

It's great that the version of Groovy packaged in Debian is being
upgraded from 1.7.4 -- I just received the 1.7.7 accepted into unstable
notice.  I understand though that there is a critical regression that
had to be fixed and so 1.7.8 was released yesterday.  

Does the notification of the existence of 1.7.5 in
http://packages.qa.debian.org/g/groovy.html go away when 1.7.7 goes live
in unstable?

Thanks.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please 
use
debian-j...@lists.debian.org for discussions and questions.

Bug#580160: groovy: stargGroovy can't find javac

[Russel Winder]

Ludovic,

On Sun, 2010-08-08 at 18:17 +0200, Ludovic Claude wrote:
 
 startGroovy tries to locate javac in order to build the JAVA_HOME 
 variable. We should not depend on the JDK, groovy works very well on a 
 small JRE, but startGroovy should be patched to use the default location 
 of JAVA_HOME on a Debian system.
 
 Ludovic

I had thought that the Debian package used its own launcher script
replacing the groovy and startGroovy from the upstream distribution --
on the very sensible grounds that Debian defines a specific path for the
things that the upstream scripts have to infer.  Also the upstream
scripts try to cope with all Posix compliant systems, which a Debian
specific script does not have to.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please 
use
debian-j...@lists.debian.org for discussions and questions.

Bug#402642: java-package: does not work with sun jre-1.6

[Russel Winder]

Is there a Debian or Ubuntu package of java-package updated for JDK 6?
Saves me having to replicate all the changes that I guess several people
have already made in order to create a Java SE 6 package.

Thanks.

( Of course it would be easier if Debian and Ubuntu just packaged Java
SE 6 :-) 
-- 
Russel.

Dr Russel Winder+44 20 7585 2200
41 Buckmaster Road  +44 7770 465 077
London SW11 1EN, UK [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers