Re: Bug#975016: #975016 - OpenJDK 17 support state for Bullseye

[Matthias Klose]

On 2/10/22 11:26, Moritz Mühlenhoff wrote:
> Am Thu, Feb 03, 2022 at 03:59:00PM +0100 schrieb Thorsten Glaser:
>> Hi Holger,
>>
>>> and filed against src:debian-security-support, as openjdk-17 seems to be
>>> supported and src:debian-security-support's purpose is to documented what's
>>
>> no, 11 is supported, 17 is just for users to run third-party
>> stuff on (IIUC).
> 
> In Bullseye 11 is the default Java and fully covered by security support.
> 
> 17 can be installed (and it can also take over the typical alternatives),
> but nothing pulls it in via dependencies. But if anyone needs to run an
> application requiring 17, this is the JRE of choice (those are rare at
> this point, but it will change over the life time of Bullseye).
> 
> And yes there have been security updates for 17 already, but it's a best 
> effort
> thing. If someone commits to rebuild the openjdk-17 uploads to unstable
> for bullseye-security (along with proper testing), we can also omit a note
> for src:debian-security-support.

"along with proper testing" means, that we can turn on again the tests during
the build, which requires a heap of new upstream versions for jtreg, jtharness,
testng, groovy, and probably much more.

Matthias

Re: build package with source and target = java15

[Matthias Klose]

On 5/19/21 11:06 AM, Cyril Richard wrote:
> Hello. 
> 
> I'm trying to update my java package with pbuilder before updating it on 
> debian. This one now uses java15. 
> Then, the control files: 
> 
> Build-Depends: debhelper-compat (= 13), 
> default-jdk, 
> javahelper 
> 
> does not work anymore because default-jdk stands for java11 in the SID build 
> environment. 
> 
> I tried to replace default-jdk by openjdk-11-jdk, but I have the following 
> error: 
> 
> make[1]: Entering directory '/build/spview-2.0.0~rc1' 
> jh_build --javacopts="-source 15 -target 15" --no-javadoc spview.jar sources 
> jh_build: error: Cannot find any JAVA_HOME: aborting 
> make[1]: *** [debian/rules:8: override_jh_build] Error 25 
> make[1]: Leaving directory '/build/spview-2.0.0~rc1' 
> make: *** [debian/rules:5: binary] Error 2 
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2 
> I: copying local configuration 
> E: Failed autobuilding of package 
> 
> 
> Could someone help me to fix the issue?

openjdk-15 has been removed from testing, and probably will be removed from
unstable soonish.  Maybe use openjdk-16, or even -17 which is likely to become
the next OpenJDK LTS release.  Also Emmanuel is already doing test rebuilds
against 17.  I don't see any setting (and exporting) of JAVA_HOME in your rules
file.

Matthias

Re: debhelper 13 (was Re: Kotlin: looking for a DD to review/upload)

[Matthias Klose]

On 5/7/21 5:36 PM, Thorsten Glaser wrote:
> On Fri, 7 May 2021, Matthias Klose wrote:
> 
>> Is there any reason to use debhelper 13?  Does it have anything that
>> is relevant for java packages? Just asking because that's usually
>> something which needs to be downgraded for backports. But I assume
>> there are enough dependency requiring debhelper v13 as well ...
> 
> That’s Ubuntu you’re talking about. I’m still totally annoyed for
> my PPA builds that bionic and focal don’t have debhelper 13 available.
> 
> Debian backports, at least for the last 3+ years, have had reasonably
> up-to-date debhelper, as downgrading the version just for backporting
> is really undesired as backports change and hindering things in sid.
> 13~bpo10+1 has a changelog date of 27 Apr 2020…

please see https://wiki.ubuntu.com/UbuntuBackports if you want to contribute a
backport.

backports for stable release updates can't be used.

Matthias

Re: Kotlin: looking for a DD to review/upload

[Matthias Klose]

On 4/29/21 5:01 PM, Sunil Mohan Adapa wrote:
> Hello,
> 
> Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into
> Debian. We need a DD willing to upload it.

> The actual upload needs to wait for openjdk-8, which is currently in the
> NEW queue, to be accepted first. However, the wait time can be used to
> do any final reviews.

- please can we have a sane upstream version? Like 1.3.31
  and then document in debian/README.source about the additional
  components added?  Is it likely that these other components
  need updates without a kotlin update?

- debian/bootstrap creates a deb, which has the deb itself
  in the root directory.

- debian/rules has
export JDK_16="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_17="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_18="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_9="/usr/lib/jvm/java-11-openjdk-amd64"
  which are meaningless, as every command is executed in its
  own subshell.

- after installing the bootstrap deb, and trying the build,
  I get:

[ERROR] Failed to execute goal on project kotlin-maven-plugin: Could not resolve
dependencies for project
org.jetbrains.kotlin:kotlin-maven-plugin:maven-plugin:1.3.31: The following
artifacts could not be resolved:
org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31,
org.jetbrains.kotlin:kotlin-scripting-compiler:jar:1.3.31: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the artifact
org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31 has not been downloaded from it
before. -> [Help 1]

Matthias

Re: Potential bug in openjdk-11 on mips64el

[Matthias Klose]

On 2/15/21 1:40 AM, Olek Wojnar wrote:
> Done! [1] Unfortunately, I don't see anything useful there but perhaps one
> of you will.
> 
> -Olek
> 
> [1]
> https://gist.githubusercontent.com/olekw/32e54c0829d739e8fa88893a853c0fa8/raw/b2fce4d2ab77555a3d28c22441f1de3cb2d99f38/bazel-bootstrap-zero-jre

The log just shows that the compiler is called once with -J-zero, so I assume
that you use the hotspot VM for anything else.

You could also try to edit
/usr/lib/jvm/java-1.11.0-openjdk-amd64/lib/jvm.cfg
moving the zero line to  the top, and then use the zero VM by default:

$ java --version
openjdk 11.0.10 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1)
OpenJDK 64-Bit Zero VM (build 11.0.10+9-Ubuntu-0ubuntu1, interpreted mode)

Re: Potential bug in openjdk-11 on mips64el

[Matthias Klose]

[also forwarding to the Debian mips porters]

On 2/12/21 10:26 PM, Olek Wojnar wrote:
> Hello Java Team and OpenJDK Team,
> 
> I'm hesitant to start filing potentially serious bugs at this point in the
> release cycle so please let me know if there's something I'm missing in
> this situation.
> 
> I've been trying to get the bazel-bootstrap package to build on mips64el.
> It's *almost* completing now but it runs into an error when trying to clean
> an output directory.[1] This is using `deleteRecursively` from Guava [2]
> which is supposed to delete files and directories recursively, as the name
> implies. However, it throws an error [3] complaining that the target is a
> directory. This error makes no sense and the code works just fine on all
> other architectures supported by Bazel (amd64, arm64, ppc64el, s390x,
> ppc64, and riscv64).
> 
> Any insights or suggestions would be greatly appreciated!

you could try to debug with java -zero / javac -J-zero on amd64.

Matthias

> -Olek
> 
> [1]
> https://salsa.debian.org/bazel-team/bazel-bootstrap/-/blob/olek-mips-riscv-3/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/VanillaJavaBuilder.java#L379
> [2]
> https://salsa.debian.org/java-team/guava-libraries/-/blob/master/guava/src/com/google/common/io/MoreFiles.java#L521
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=bazel-bootstrap=mips64el=3.5.1%2Bds-3%7Eexp2=1612583842=0
> 

Re: Usage of language specific profiles in build dependencies

[Matthias Klose]

On 2/11/21 10:40 AM, Paul Gevers wrote:
> Hi,
> 
> On 11-02-2021 10:16, Matthias Klose wrote:
>> These dependencies should look like:
>>
>>   default-jdk [!hppa !hurd-i386 !kfreebsd-any]
>>
>> or
>>
>>   default-jdk [alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel
>> powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32]
>>
>> It's also ok to use something like
>>
>>   default-jdk [!hppa !hurd-i386 !kfreebsd-any] 
>>
>> to be able to build with the nojava profile.  I also see this used in many 
>> mono
>> related build dependencies.
>>
>> Having such build dependencies in a package that is a required package for
>> almost everything isn't helpful.
> 
> Maybe a very stupid solution would be to have default-jdk be available
> on all architectures, but just not pull in anything? IIUC that would
> lead to build failures (because code that really needs the jdk will
> FTBFS) but it avoids busywork for maintainers that are not involved in
> bootstrapping java. Machine time is cheap, volunteer time is not.

Seriously?  We didn't have any changes to the java architectures for the past
three years.  Calling a one time change "busywork"?

Usage of language specific profiles in build dependencies

[Matthias Klose]

Please see https://bugs.debian.org/982085

I think it's wrong to encode build dependencies for language stacks that are not
available on some platforms, just using a profile.

Seen in gettext:

  default-jdk , maven-repo-helper 

and also in db5.3.

A more cooperative usage of such build dependencies can be seen in brltty
collectd gdcm liblouisutdml link-grammar octave opencv openmpi r-base rjava
swi-prolog ucx vtk7 vtk9 z3 and probably other packages.

These dependencies should look like:

  default-jdk [!hppa !hurd-i386 !kfreebsd-any]

or

  default-jdk [alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel
powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32]

It's also ok to use something like

  default-jdk [!hppa !hurd-i386 !kfreebsd-any] 

to be able to build with the nojava profile.  I also see this used in many mono
related build dependencies.

Having such build dependencies in a package that is a required package for
almost everything isn't helpful.

Matthias

Re: OpenJDK 17 for bullseye-backports

[Matthias Klose]

[please ignore this thread started by Adrian; he's making statements on behalf
of other teams, which are not correct. Also he "forgot" to CC the security team
and the package maintainers. The issue is handled in #975016.]

On 2/6/21 11:47 PM, Emmanuel Bourg wrote:
> Le 02/02/2021 à 19:04, Adrian Bunk a écrit :

> I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad
> idea. Shipping OpenJDK 17 is worth considering though.
> 
> 
>> My suggestion:
>>
>> No OpenJDK other than 11 is shipped in bullseye.
>>
>> If at the time of the bullseye release openjdk-17 in unstable is ready 
>> to migrate to testing except for the freeze, this means that:
>> 1. it will migrate at the first migration of bookworm, and
>> 2. the binaries will be installable on all architectures in bullseye
>>
>> The bootstrap could then be avoided by verbatim copying of this
>> openjdk-17 sources and binaries for all architectures from bookworm
>> to bullseye-backports.
>>
>> Subsequent updates of openjdk-17 in bullseye-backports would then follow 
>> the normal backports rules.
> 
> If openjdk-17 can't be shipped in bullseyes even with prominent warnings
> that it's unsupported, then this sounds like a good idea.

See #975016.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#98
lists the proposals made.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#123
lists the OK of the security team for all proposals.

So I'm going with option 1, preparing for an openjdk-17 in bullseye, and
preparing release notes and notes for security support.  This is more
conservative than option 2, but allows to do better than the commitment made.

The option also has the advantage that approval is only needed by the security
team.  openjdk-17 already is in testing.  granting unblock requests for new
snapshot builds by the release team would be appreciated, but isn't strictly
necessary as long as we can build newer snapshots. And that can be checked in
unstable.

Matthias

Re: okay to prepare 11.0.9.1+1 for Debian stable proposed updates?

[Matthias Klose]

On 11/25/20 12:05 AM, tony mancill wrote:
> Thank you for the recent uploads of 11.0.9.1 [1].  Given that it
> addresses JDK-8250861 [2] (which is serious, although I'm unsure as to
> whether it is DSA-worthy) and there are likely derivatives that would
> benefit from the update, would you mind if I prepare an upload of
> 11.0.9.1 for Debian stable?

that would be Moritz' call.

Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Matthias Klose]

On 11/18/20 8:03 PM, Adrian Bunk wrote:
> On Wed, Nov 18, 2020 at 12:20:37PM +0100, Matthias Klose wrote:

>> For OpenJDK there are two other possibilities, which would require approval 
>> by
>> release managers / stable release managers.
>>
>>  - openjdk-16 will be released in April 2021, which is expected
>>before the bullseye release. Shipping openjdk-16 instead of
>>openjdk-15 would have the advantage that you are able to build
>>openjdk-17 directly, without having to build openjdk-17 (LTS).
>>
>>This would require a feature freeze exception for bullseye.
>>
>>  - package a snapshot of openjdk-17 (in April/May 2021), and
>>only ship openjdk-17 in bullseye.   In that case, update to
>>the final openjdk-17 release in Oct 2021 as a stable release
>>update, or as a security update.
>>
>>This would require a feature freeze exception for bullseye.
>>
>>After the bullseye release, it would require an approval of
>>the stable release managers, or approval by the security
>>team as a security update.  I'm not saying that this package
>>should see constant security support, but it is likely
>>that openjdk-17 sees extended support upstream.
> 
> New OpenJDK versions tend to cause both buildtime and runtime breakages 
> in reverse dependencies, some of them hard to resolve and requiring 
> updates to new upstream versions which in turn require new dependencies
> that might not even be in Debian.

New upstream versions likely do that, that's not an attribute of OpenJDK.

What's your point?

Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Matthias Klose]

On 11/18/20 7:46 PM, Moritz Muehlenhoff wrote:
> On Wed, Nov 18, 2020 at 12:20:37PM +0100, Matthias Klose wrote:
>> [removed the Python 2 bits]
>>
>> On 11/17/20 11:08 PM, Moritz Muehlenhoff wrote:
>>> Package: debian-security-support
>>> Severity: normal
>>> X-Debbugs-Cc: d...@debian.org, t...@security.debian.org
>>
>>> openjdk-15 will be included, but not covered by support
>>> (as it's only needed to bootstrap openjdk-16 and eventually
>>> openjdk-17, the next LTS release of Java).
>>>
>>> How about the following for "security-support-limited"?
>>>
>>> 
>>> openjdk-15Only included for bootstrapping later OpenJDK 
>>> releases
>>> 
>>>
>>> One important thing: These only applies to Bullseye and
>>> security-support-limited is currently independent of releases, so this
>>> needs to be fixed or alternatively we need to stop rebuilding the current
>>> unstable package for older releases and instead branch of per distro.
>>
>> As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, 
>> 15
>> with 14, 16 with 15. Only having 11 in bullseye would make backports more
>> "interesting".
>>
>> For OpenJDK there are two other possibilities, which would require approval 
>> by
>> release managers / stable release managers.
> 
> If the whole "buildlibs" (or however it gets called in the end) 
> infrastructure is
> ready for bullseye it would also be an option to include 
> openjdk-15/openjdk-16 in
> there? As such, it would be non-available to users by default, but present for
> bootstraps.

sure, if you don't change it for the sid/unstable packages.

Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Matthias Klose]

On 11/18/20 1:36 PM, Florian Weimer wrote:
> * Matthias Klose:
> 
>> As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, 
>> 15
>> with 14, 16 with 15. Only having 11 in bullseye would make backports more
>> "interesting".
> 
> All recent OpenJDK releases can be built by themselves, right?

yes, forgot to mention that.

Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Matthias Klose]

[removed the Python 2 bits]

On 11/17/20 11:08 PM, Moritz Muehlenhoff wrote:
> Package: debian-security-support
> Severity: normal
> X-Debbugs-Cc: d...@debian.org, t...@security.debian.org

> openjdk-15 will be included, but not covered by support
> (as it's only needed to bootstrap openjdk-16 and eventually
> openjdk-17, the next LTS release of Java).
> 
> How about the following for "security-support-limited"?
> 
> 
> openjdk-15Only included for bootstrapping later OpenJDK 
> releases
> 
> 
> One important thing: These only applies to Bullseye and
> security-support-limited is currently independent of releases, so this
> needs to be fixed or alternatively we need to stop rebuilding the current
> unstable package for older releases and instead branch of per distro.

As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, 15
with 14, 16 with 15. Only having 11 in bullseye would make backports more
"interesting".

For OpenJDK there are two other possibilities, which would require approval by
release managers / stable release managers.

 - openjdk-16 will be released in April 2021, which is expected
   before the bullseye release. Shipping openjdk-16 instead of
   openjdk-15 would have the advantage that you are able to build
   openjdk-17 directly, without having to build openjdk-17 (LTS).

   This would require a feature freeze exception for bullseye.

 - package a snapshot of openjdk-17 (in April/May 2021), and
   only ship openjdk-17 in bullseye.   In that case, update to
   the final openjdk-17 release in Oct 2021 as a stable release
   update, or as a security update.

   This would require a feature freeze exception for bullseye.

   After the bullseye release, it would require an approval of
   the stable release managers, or approval by the security
   team as a security update.  I'm not saying that this package
   should see constant security support, but it is likely
   that openjdk-17 sees extended support upstream.

Matthias

Re: Potential issue with JNA native library search path on some architectures

[Matthias Klose]

On 10/19/20 9:04 PM, Reinhard Pointner wrote:
> Dear libjna-java package maintainers,
> 
> 
> The libjna-java package seems to apply a few patches that make things work
> on some architectures but not others.
> 
> 
> 1.
> This patch will make JNA search for jnidispatch in
> /usr/lib/arm-linux-gnueabi/jni on all arm platforms, but this path is wrong
> on some arm platforms:
> *
> https://sources.debian.org/patches/libjna-java/4.5.2-1/04-load-native-code-from-fs.patch/
> 
> armhf -> /usr/lib/arm-linux-gnueabihf/jni
> arm64 -> /usr/lib/aarch64-linux-gnu/jni)
> 
> I would recommend adding all /usr/lib/*/jni folders to the search path if
> we can't know the if we can't know in advance where the *.so file is going
> to be.

No, I think the getMultiArchPath function should be fixed.  Maybe track it down
where the copy comes from, and send a patch there as well?  The cpu detection
might be problematic, because you run the 32bit code on 64bit kernels as well.

Matthias

swt4-gtk in unstable for 100 days

[Matthias Klose]

Hi,

swt4-gtk is stuck in unstable for 45 days, the previous version was stuck for 50
days without migrating.  Apparently Debian follows upstream to not build on
32bit archs anymore.  That's ok, however please could somebody file removal
requests for all the i386 packages which need removal now?

Matthias

Re: OpenJDK 14 (ea) entering testing

[Matthias Klose]

On 14.12.19 12:01, YunQiang Su wrote:
> Lilian BENOIT  于2019年11月16日周六 上午5:56写道：
>>
>>
>> Hello,
>>
>> In july, a message "OpenJDK 13 (ea) entering testing" has been sended on
>> this mailing-list.
>> (https://lists.debian.org/debian-java/2019/07/msg9.html)
>> There was a question : Would anybody be interested in setting up a
>> machine to check builds with interim OpenJDK versions?
> 
> @Matthias Klose do you mean that set up an build daemon,
> and try to build all of the related packages with every major version
> of openjdk?
> 
> If so, I think that I can help.

doing a test rebuild would help, yes.  But there should be at least a mass-bug
filing as a follow-up to document the ftbfs.

Matthias

Re: Feedback on OpenJDK jpackage tool early access builds

[Matthias Klose]

On 02.09.19 13:22, Dalibor Topic wrote:

Hi Emmanuel,

thank you for your interest - the jpackage source code can be found in the 
JDK-8200758-branch of the JDK sandbox repository at

https://hg.openjdk.java.net/jdk/sandbox


I haven't looked into that yet, but some questions first:

 - is the tool able to create source packages? and maybe
   differentiate here between pure source packages, and
   "source" packages just containing jar files?

 - is the tool able to build without fetching anything
   from random websites? e.g. to create a self-contained
   source repository?

These are two re-occurring issues when creating deb packages which can be 
uploaded to the Debian archives.


Matthias

Re: Java 8 and 11 quarterly release tags

[Matthias Klose]

On 17.07.19 14:51, Martijn Verburg wrote:
> Hi all,
> 
> I've updated the info below - happy building!
> 
> On Tue, 16 Jul 2019 at 23:44, Martijn Verburg 
> wrote:
> 
>> Hi all,
>>
>> For this quarterly release the tags are:
>>
>> *Java 8 (all non-aarch64)*
>>
>> * jdk8u222-b10 (which matches jdk8u222-ga)
>>
>> *Java 8 (aarch64):*
>>
>> * aarch64-shenandoah-jdk8u222-b10

yes, and aarch32 is missing.

>> *Java 11:*
>>
>> * jdk-11.0.4+11 (which matches jdk-11.0.4-ga)
>>
>> *Java 12*
>>
> 
>  * jdk-12.0.2+9 (which matches jdk-12.0.2-ga)

no, that's now jdk-12.0.2+10, but that doesn't matter, it's all the same.

Matthias

OpenJDK 13 (ea) entering testing

[Matthias Klose]

The next OpenJDK LTS will be OpenJDK 17, to be released in September/October
2021.  So we will stay with OpenJDK 11 for bullseye.  However we should start
testing packages using the interim versions, or else we'll have again one big
version bump from 11 to 17.  To get a bit more exposure of these interim
versions, I'll let these migrate to testing, and to have a safer fallback if
packages get accidentally removed from unstable.  OpenJDK 12 will be removed
from unstable soonish, because it won't see the next round of security updates
anymore later this month.

Please stay away from backporting these interim versions to stable backports.

Would anybody be interested in setting up a machine to check builds with interim
OpenJDK versions?

Thanks, Matthias

Re: Debian distributions of stable OpenJDK updates

[Matthias Klose]

On 29.05.19 23:51, Emmanuel Bourg wrote:
> Le 26/05/2019 à 23:51, tony mancill a écrit :
> 
>> For the update to buster via testing-proposed-updates, I have prepared
>> 11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
>> at buster via t-p-u and with the changelog updated to note that 11.0.3+7
>> is the GA release from OpenJDK.  This will address the CVEs currently
>> open against the version in buster.
> 
> Is the +deb10u1 suffix necessary for a testing-proposed-updates upload?
> Just asking, because if I backport that for stretch that will make a not
> very nice 11.0.3+7-4+deb10u1~bpo9-1 version. Would 11.0.3+7-5 work?

Please don't add more confusion to the versioning.  Honestly we should just
migrate the current package in unstable to testing.  We will get the final
11.0.4+x update in a month anyway.

But yes, 11.0.3+7-5 should work as well.

Matthias

Re: openjdk-8 re-uploaded to unstable (currently in NEW)

[Matthias Klose]

On 26.05.19 21:13, Matthias Klose wrote:
> The openjdk-8 packages which were unfortunately removed from unstable 
> (although
> the issue #915620 only asked for the removal of some binaries), are now again 
> in
> NEW, targeting unstable.  One of the FTP assistants is objecting to the upload
> to unstable, apparently because somebody (security team, Moritz?) asked to
> restore these packages in experimental instead of unstable.  Otoh, we still 
> need
> these packages in unstable to bootstrap kotlin (yes we can bootstrap in
> experimental, but then it's not assured how to build kotlin for unstable with 
> an
> experimental build).
> 
> I honestly don't understand why FTP master would have such an objection, so
> please clarify what prohibits the acceptance to unstable with an RC issue to 
> not
> propagate these packages to testing.

The packages are now accepted and the 8u212-b03 upstream version is now uploaded
as well.

The changes and buildinfo files didn't exist anymore for the powerpc, ppc64,
sparc64 and x32 binaries, so if a porter wants to restore those, please rebuild
them with manually installed openjdk-8 packages from snapshot.debian.org.

Matthias

Re: Mystery meat OpenJDK builds strike again

[Matthias Klose]

On 27.05.19 18:23, Gil Tene wrote:
>> Did you try to contact Debian folks to give them opportunity to fix those 
>> security concerns before going public with them? Or did they not react in 
>> time?
> 
> Multiple times over ~4.5 years, and through multiple channels. The
> “we don’t care”, “go away, vendor”, and “java and openjdk do versioning
> wrong” reactions are the most common. Many were less polite than that.
> The defensive tone of the email you see on this thread is about average.
> The denial and deflection attempts you see there are also common.

I can't follow that.  There is not a single bug report about that in the Debian
tracker.   Looking at the Debian Java mailing list, there is not a single
posting from your side.  And I can't remember that being discussed on the ML
either.  Also not on the distro-pkg-dev ML.  Same thing for the Ubuntu bug
tracker.  So which channels are you using?

> Some people just don’t want help, at least not from some. And that’s fine.

I raised questions about the versioning on the jdk ML's multiple times.  Most of
those were ignored, or saw the versioning as being correct.  I brought up the
configuration issues at this year OpenJDK committers workshop, but it was voted
down because other topics seemed more pressing to discuss.

Matthias

Re: Debian distributions of stable OpenJDK updates

[Matthias Klose]

On 26.05.19 23:51, tony mancill wrote:
> Thank you for weighing in on the thread.  I have been building openjdk
> packages all weekend and now understand that the version number is
> required to be numeric as per the upstream build system - i.e.,
> VERSION_BUILD won't pass the test here [1] if it is arbitrarily changed
> from from 7 to ga.  So 11.0.3+7 it is.  My bad for proposing otherwise
> in this thread, before I got more familiar with the build system...
> 
> For the update to buster via testing-proposed-updates, I have prepared
> 11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
> at buster via t-p-u and with the changelog updated to note that 11.0.3+7
> is the GA release from OpenJDK.  This will address the CVEs currently
> open against the version in buster.
> 
> Does that sound acceptable for upload to Debian?  Would you prefer a
> different approach?

Please coordinate with Moritz, as he is doing the security updates. Either
testing-proposed-updates or testing-security is ok.

Re: Debian distributions of stable OpenJDK updates

[Matthias Klose]

On 26.05.19 23:55, Emmanuel Bourg wrote:
> Le 26/05/2019 à 21:52, Matthias Klose a écrit :
> 
>>> It looks like upstream is going to append a -ea suffix to the version
>>> reported by the pre-releases [1]. This is a welcome clarification and we
>>> should ensure our builds do it as well.
>>
>> no, at least not for the recent release:
>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
> 
> Well, my comment was based on this post:
> 
>   https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009370.html
> 
> If I understand well, non GA releases will be reported with a -ea suffix
> when typing "java -version" (at least for OpenJDK 8, I haven't checked
> for OpenJDK 11). If upstream does this, so should we, otherwise we'll be
> blamed for falsifying the version reported.

no, this is unfortunately a configure option, not a property of the source
tarball.  But yes, will add that until upstream hopefully fixes this.

Re: Mystery meat OpenJDK builds strike again

[Matthias Klose]

I am disappointed to see such trolling, bashing and telling fake news on a
technical mailing list.  Is this Azul's business model to promote their own
binary builds?

Such behavior propagates e.g. via twitter
https://twitter.com/jroper/status/1130678379403857920

I'm starting the discussion about version numbers and release information in a
new thread.

I am neither involved with any Docker image nor with any Debian backport.

Debian provides security support for its stable release (stretch, 9.x).
openjdk-11 isn't part of any released Debian version.

Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is
committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until
the EOL of Ubuntu 16.04 LTS (around April 2021).

Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update
to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the
security pocket).

There is no mystery meat, just security supported uploads for both Debian and
Ubuntu.

On 15.05.19 20:49, Gil Tene wrote:
> Umm…
> 
> Lumpy.local-43% docker run -it --rm openjdk:8 java -version
> openjdk version "1.8.0_212"
> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01)
> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)
> Lumpy.local-44% date
> Wed May 15 11:41:12 PDT 2019
> 
> Look at the build number carefully… This was populated no later
> than March 27, 2019. 3 weeks before the actual 8u212 was released
> on April 16, 2019.

The Debian openjdk-8 source package is put together from the jdk8u,
aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects.  Certainly not
ideal, however these packages can only be made if all the sources are available,
or tagged.

I am happy to see that the aarch64-port tries to keep up with the jdk8u project
however this is a different story with the aarch32-port project:  The project
doesn't have *any* prerelease tags, plus the project updates it's release tags
only months after the jdk8u releases.  So blaming Debian for shipping what they
are able to ship and Azul holding back source releases yourself?   Ein Schelm
wer Böses dabei denkt ...

> Similarly:
> 
> Lumpy.local-46% docker run -it --rm openjdk:11 java -version
> openjdk version "11.0.3" 2019-04-16
> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91)
> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing)
> Lumpy.local-47% date
> Wed May 15 11:43:12 PDT 2019
> 
> This one was populate dno later than April 3, 2 weeks before
> the actual 11.0.3 was released on April 16, 2019
> 
> If anyone was wondering about the importance of having version strings say
> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any
> and all OpenJDK builds that are not an actual release build, the above shows
> you how bad things get when that practice is not followed.

Don't trust the label, just the content.  I agree that the java community is
much more label/version driven, however this is not a reason to discredit other
sane builds.

> Why Debian populated their repos with these builds is their business, and
> why docker chose to use those specific debian builds can be speculated
> about all we want. the details don't matter. The end result of these
> cumulative "reasonable" (according to some people) choices is that the
> default openjdk runs done by millions of people on docker right now are
> using "mystery meat", incomplete, and exposed builds while seeming to
> report (to the lay person) a Java version that would suggest a real 8u212
> or 11.0.3 (which one would expect has the security vulnerabilities in the
> April update addressed, the bug fixes included, etc.).

Again, I see this as an advertising or promotion email for the Azul binary
builds.  Fine, do so.  Both please use marketing lists and not the OpenJDK
technical lists.

Matthias

Re: Debian distributions of stable OpenJDK updates

[Matthias Klose]

On 22.05.19 12:24, Emmanuel Bourg wrote:
> Le 22/05/2019 à 06:17, tony mancill a écrit :
> 
>> For stable backports and buster, I agree that we should upload an
>> 11.0.3-ga package, particularly given the vulnerabilities still present
>> in 11.0.3+1: CVE-2019-2698, CVE-2019-2684, and CVE-2019-2602
> 
> I've uploaded 11.0.3+1 with a patch bringing it up to 11.0.3+7 to
> stretch-backports yesterday, it's still pending validation.
> 
> 
>> It would be nice to do the same for buster, although now that 11.0.4+x
>> has been introduced to unstable, I believe we'll have to be creative
>> with the naming, either by introducing an epoch or using the
>> "11.0.4+1_really11.0.3-ga" trick.
> 
> I think we should leave 11.0.4 in unstable until the GA release in July
> and upload 11.0.3+7-4 directly to testing through
> testing-proposed-updates. I'm volunteering to deal with this upload if
> Matthias agrees.

well, I disagree ;)  The Debian security team has the policy to take any OpenJDK
update and backport that to stable release.   From my point of view, the Debian
release team is playing games with both the security team, and the OpenJDK
packagers to force something else, although it's unknown to me what they really
want to achieve, if further backports land in stable-security anyway.

>> In general, I think it would be helpful for our users if we uploaded the
>> prereleases to experimental but stuck to GA releases for unstable,
>> testing, and backports.  I think it is easy to mistake, for example, an
>> 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
>> distributed by other projects.

I would like to avoid experimental, because it really doesn't get much testing.
 See the openjdk-11 updates as a stable release branch, and it's worth to check
these out early, because upstream doesn't test most Debian architectures.

> It looks like upstream is going to append a -ea suffix to the version
> reported by the pre-releases [1]. This is a welcome clarification and we
> should ensure our builds do it as well.

no, at least not for the recent release:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html

Matthias

Re: Debian distributions of stable OpenJDK updates

[Matthias Klose]

On 24.05.19 20:29, Martijn Verburg wrote:
> On Fri, 24 May 2019 at 15:40, tony mancill  wrote:
> 
>> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
>>> Le 23/05/2019 à 19:04, Martijn Verburg a écrit :
>>>
 What was the difficulty in grabbing the 11.0.3+7 tag directly?
>>>
>>> The difficulty is the policy that applies to backported packages. A
>>> package that is backported from the Debian release n+1 to the release n
>>> has to remain upgradable when the system is upgraded. For this to happen
>>> the version backported must rank lower than the version in the next
>>> release. That's why there are weird suffixes appended to the versions of
>>> the backported packages (1.2.3-1~bpo9+1 is lower than 1.2.3-1).
>>>
>>> Currently Debian Buster has openjdk-11/11.0.3+1-1, so it isn't possible
>>> to upload the version 11.0.3+7-1~bpo9+1 to stretch-backports. The only
>>> solutions is to either upgrade openjdk-11 in testing to a version higher
>>> than 11.0.3+7, or patch the existing version. Since testing is currently
>>> frozen and difficult to update until the release of Buster, it leaves
>>> only the patch solution.
>>
>> Emmanuel,
>>
>> It seems like we need to bring this up with the Release and Security
>> teams.  Releasing Buster with mulitple critical open CVEs in the JVM
>> isn't a good experience for our users.  My proposal is that we do what
>> we need to get 11.0.3-ga-1 into Buster.
>>
>> From a versioning standpoint, this should work.  Am I missing something?
>>
>> $ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1
>> is newer"
>> 11.0.3-ga-1 is newer

I don't think that playing games with version numbers is a good thing to do.
Version numbers should match the upstream source release, and the binary
packages should not change that version.  Of course openjdk has a split
personality to give even another version when called with java --version

The final 11.0.3 release:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html

does *not* contain the ea specifier.

> We (AdoptOpenJDK) would really be appreciative of that! We're aiming to get
> consistency amongst all of the OpenJDK providers that 'good known GA'
> versions are deployed to end users.  I can only apologise for not having
> reached out to the Debian community earlier to collaborate.  Appreciate the
> efforts being put in here!

I don't care what AdoptJdk is doing.  In the past, the only activity by AdoptJdk
was trying to promote their builds for inclusion in some Linux distros.
AdoptJdk only supports a subset of the Debian architectures, and we really don't
need yet another IcedTea.

> Is there anything we can do to help going forward?  OpenJDK upstream has a
> pretty good established policy around having the `-ga` suffix added to
> versions it would like downstream to take as a formal release. 

This is a recent addition. Last time I asked on an upstream mailing list,
everybody seemed fine with the versioning:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000969.html

> Is there
> anything else that OpenJDK can do to help Debian?  One thing that
> AdoptOpenJDK provides is a free test pipeline in it's build farm that could
> happily receive the Debian built binary and put it through 100,000+ tests
> and see if it matches what other OpenJDK providers are broadly producing,
> would that be of interest?

I'm moving that discussion to upstream, but in summary you shouldn't a dozen of
configure options to configure your build from source.  Just release a sane
upstream tarball.

Matthias

openjdk-8 re-uploaded to unstable (currently in NEW)

[Matthias Klose]

The openjdk-8 packages which were unfortunately removed from unstable (although
the issue #915620 only asked for the removal of some binaries), are now again in
NEW, targeting unstable.  One of the FTP assistants is objecting to the upload
to unstable, apparently because somebody (security team, Moritz?) asked to
restore these packages in experimental instead of unstable.  Otoh, we still need
these packages in unstable to bootstrap kotlin (yes we can bootstrap in
experimental, but then it's not assured how to build kotlin for unstable with an
experimental build).

I honestly don't understand why FTP master would have such an objection, so
please clarify what prohibits the acceptance to unstable with an RC issue to not
propagate these packages to testing.

Matthias

Re: Why OpenJDK debugging symbols for 12 and 13 are not allowed?

[Matthias Klose]

On 11.04.19 13:01, Mykola Nikishov wrote:
> Hi,
> 
> While multiple versions of openjdk-*-jdk could be installed at the same
> time, it is not the case for packages that provide debugging symbols for
> post-11:
> 
> --8<---cut here---start->8---
> $ for v in 8 11 12 13 ; do p="openjdk-$v-dbg" ; echo $p ; apt-cache show $p | 
> grep Conflicts ; done
> openjdk-8-dbg
> openjdk-11-dbg
> openjdk-12-dbg
> Conflicts: openjdk-11-dbg
> openjdk-13-dbg
> Conflicts: openjdk-11-dbg
> --8<---cut here---end--->8---
> 
> So, debug symbols for JDK 11, 12 and 13 are not co-installable.

some debug files translate to the same build id, and the same file name.

Re: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)

[Matthias Klose]

On 11.04.19 20:24, Paul Gevers wrote:
> Hi doko,
> 
> On 07-04-2019 12:08, Samuel Thibault wrote:
>>> I disagree.  I'll do the next upload with Samuel's proposed patches, not
>>> enabling that by default, together with the planned security update.  Then
>>> people can start testing if the wrapper works.
>>
>> Well, I'm afraid that what will happen is that the people who will
>> test will simply find out that it just works for them (just like it
>> does already for them with openjdk-8) ; will we then conclude near the
>> release that it should be enabled by default for Buster, and then be hit
>> by the much wider exposition to jaw?
>>
>> If on the contrary we enable it by default during the freeze, we will
>> have *way* more testing coverage, and thus be much more confident with
>> keeping it enabled by default in Buster if we don't see bug reports.
> 
> Although I agree with Samuel here, can we please-pretty-please get an
> upload even if you don't enable it, such that we can get this story into
> buster?

yes, will be part of the CPU update next week.

Re: Bug#924634: libuima-as-java depends on the removed libspring-jms-java

[Matthias Klose]

Control: severity -1 serious

On 06.04.19 14:55, Chris Hofstaedtler wrote:
> Control: severity 924634 wishlist
> 
> * Matthias Klose  [190406 12:53]:
>> libuima-as-java depends on the removed libspring-jms-java in unstable.
> 
> Lowering severity as libspring-jms-java is still built by
> libspring-java (4.3.22-3). If newer developments show up, please
> re-raise the severity.

done. libspring-java has an RC issue, so if it gets removed, then
libuima-as-java gets removed as well. So somebody has to make sure that the RC
issues in libspring-java get resolved, or that libuima-as-java doesn't depend on
libspring-java anymore.

Matthias

Re: Bug#900912: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Matthias Klose]

On 06.04.19 15:13, Paul Gevers wrote:
> Hi
> 
> On 06-04-2019 08:55, Samuel Thibault wrote:
>>> please don't NMU. In the past the atk patches broke the non-atk use case 
>>> way too
>>> often.  Maybe you want to upload to a PPA or to experimental to give this a
>>> little bit more testing.
>>
>> Can we then at least upload all changes except enabling atk, i.e.
>> the attached patch which just fixes loading atk without enabling it
>> by default?  So that there is even no need for any external PPA or
>> experimental (which would be quite involved for people to configure),
>> instead people can just enable from the configuration file, as expected
>> and documented.
> 
> With my release team member hat on: we want accessibility enabled by
> default. We're late already, I would want this rather sooner than latter
> in buster, such that there is some real live testing before we release.
> Sure, there are chances for bugs, but if that's the case, let's find
> them and fix them.

I disagree.  I'll do the next upload with Samuel's proposed patches, not
enabling that by default, together with the planned security update.  Then
people can start testing if the wrapper works.

Enabling features during the freeze which were broken most of the time during
the development cycle sounds risky.  We don't have release goals anymore.

Matthias

Re: Bug#900912: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Matthias Klose]

On 01.04.19 17:24, Samuel Thibault wrote:
> Samuel Thibault, le lun. 01 avril 2019 15:54:17 +0200, a ecrit:
>> Vincent Privat, le ven. 24 août 2018 18:33:56 +0200, a ecrit:
>>> Patching openjdk with your try/catch proposal and making the ATK wrapper a
>>> Recommends sounds a good idea.
>>>
>>> Don't wait for openjdk guys for an answer: they simply don't care anymore 
>>> with
>>> desktop technologies.
>>
>> FI, I plan to upload the attached NMU, which does it:
> 
> But currently the 11.0.3+4-3 version is blocked in unstable, and notably
> due to a regression on libreoffice, so I'm not sure what to do for now.

please don't NMU. In the past the atk patches broke the non-atk use case way too
often.  Maybe you want to upload to a PPA or to experimental to give this a
little bit more testing.

Matthias

cross-building OpenJDK and JNI bindings

[Matthias Klose]

According to http://crossqa.subdivi.de/src/openjdk-11 there is one missing issue
to cross build OpenJDK itself (#925467, please make ant and ant-optional M-A:
foreign).  Note that the Debian tracker gives this M-A as well.

Looking further, we should make other build systems like gradle and groovy M-A:
foreign as well, together with *all* their binary-indep dependencies.   And
probably mark every binary-indep package as M-A: foreign ...

Time to add that to the java policy?  Maybe not now, but maybe for bullseye. But
a fix for ant would be appreciated now.

Matthias

Re: Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Matthias Klose]

On 14.03.19 23:03, Emmanuel Bourg wrote:
> 
> 
> On 13/03/2019 17:47, Matthias Klose wrote:
> 
>> please look at the new upstream 1.7.2 and 1.8 releases.
> 
> I got a quick look at these new versions released this week, IcedTea Web
> 1.7.2 is rather close to the version in unstable since October and has a
> few extra Java 9+ fixes, it's probably worth considering for Buster.

see https://launchpad.net/ubuntu/+source/icedtea-web/1.7.2-0ubuntu1
for a packaging proposal.

Re: icedtea-web FTBFS with OpenJDK 11

[Matthias Klose]

On 13.03.19 10:54, Andreas Tille wrote:
> On Tue, Mar 12, 2019 at 11:41:22AM +0100, Andreas Tille wrote:
>> Michael Crusoe has suggested a workaround[1].  What do you think about
>> this?
> 
> In case there is no answer to this question I assume it is OK to
> upload the workaround.  Hope you agree with this.

please look at the new upstream 1.7.2 and 1.8 releases.

Re: has anybody looked at adoptopenjdk

[Matthias Klose]

On 17.09.18 16:09, shirish शिरीष wrote:
> Dear all,
> 
> I was reading 
> https://blog.joda.org/2018/08/java-is-still-available-at-zero-cost.html
> 
> I know that the Debian openjdk team is small . Has anybody have been
> able to look at -
> 
> https://adoptopenjdk.net/support.html
> 
> and
> 
> https://github.com/AdoptOpenJDK/openjdk-build
> 
> This might be something the debian-java team could look at or perhaps
> team with at some later date once they have the house a bit in order ?

the problem with that is that it supports less architectures than OpenJDK. Yes,
the additional testing for the platforms they support is good, but we regress
with other platforms.

Re: OpenJDK 11 -- testing needed

[Matthias Klose]

On 20.07.2018 23:28, Emmanuel Bourg wrote:
> Le 20/07/2018 à 22:14, Markus Koschany a écrit :
> 
>> I think the sooner we make OpenJDK 11 the default the better. This makes
>> it more likely that we detect runtime issues before the freeze. I
>> suppose there will be some FTBFS fallout again but I expect it to be in
>> the same range when we switched from 9 to 10.
> 
> Java 11 no longer contains JAX-WS (the javax.xml.ws and javax.jws
> packages) and we don't have a replacement yet. This will affect at least
> Spring, Tomcat and Netbeans. I started packaging the standalone JAX-WS
> implementation [1], one new dependency is already in sid (saaj), another
> one is in the NEW queue (jaxws-api), and 6 more have to be uploaded
> (javax.jws, gmbal, gmbal-pfl, gmbal-commons, metro-policy and mimepull).
> These packages are ready but need some polishing (proper package
> description and copyright review).
> 
> For a smooth transition I think we should switch the default JRE to
> OpenJDK 11 once jaxws lands in sid.

this has now landed. Anything else to update before we do the switch?

Matthias

OpenJDK 11 -- testing needed

[Matthias Klose]

Hi,

OpenJDK now is feature complete, and the package in unstable should migrate to
testing soonish.  I didn't do any test rebuilds with 11 yet, but I think now
it's time to start doing these.  Chris West did these for 10, but doesn't seem
to be active at the moment.  Is there anybody volunteering to do test rebuilds
with 11, or should we just change the default and then start fixing issues?

Matthias

bumping the default Java from 9 to 10 ... and 11

[Matthias Klose]

The last security updates for OpenJDK were only released for OpenJDK 10.
OpenJDK 9 is now unsupported upstream.  At some point in the near future we
should switch to OpenJDK 10 as the default JDK (which is supported at least
until early 2019).  At some point the the not so distant future, i.e. before any
Debian freeze, we should switch to OpenJDK 11 as the default JDK.  This is the
OpenJDK which supposedly will see some long term support.  LTS by Oracle/OpenJDK
speaking means twice the time of a short term release (i.e. 12 months); LTS by
Oracle/OpenJDK writing and/or wishful thinking means 36 months.  Please watch
[1] and have your own interpretation.  However it looks like that OpenJDK 11
will see some extended long term support by other contributors.  The fallback
for Debian, if OpenJDK cannot be made the default, would be to default the next
Debian release to OpenJDK 8, which is still supported by OpenJDK (the jdk8u
project handed over to project owners outside of Oracle).

Side note:  The upcoming Ubuntu 18.04 LTS release is shipping with OpenJDK 10 as
the default, hopefully having OpenJDK 9 removed from the archive for the
release.  The goal is to update the 18.04 LTS to OpenJDK 11 once it is released.
 Patches for 10 compatibility are submitted to Debian, or should be submitted
shortly (with Tiago doing most of the work).

  Matthias

[1] https://fosdem.org/2018/schedule/event/state_openjdk/

Re: OpenJFX 9 integration

[Matthias Klose]

On 04.04.2018 07:10, Sebastiaan Couwenberg wrote:
> On 10/23/2017 01:00 AM, Emmanuel Bourg wrote:
>> Le 22/10/2017 à 12:57, Matthias Klose a écrit :
>>> (C) looks like the best workaround for now.  Looking at at least four 
>>> security
>>> releases per year, and maybe the double amount of package uploads, the 
>>> OpenJDK
>>> package has a higher upload frequency anyway.  There is however a risk that 
>>> an
>>> OpenJDK (security) update won't build anymore with a prebuilt OpenJFX (not 
>>> sure
>>> if that is a real issue).  In any case, the OpenJDK package should have a 
>>> build
>>> profile to build without OpenJFX support.
>>
>> Ok let's do that. The name of the package is open to discussion, as well
>> as how the OpenJFX files will be distributed between the openjdk-9-*
>> packages.
>>
>> For the name, since OpenJFX is now clearly becoming an extension of
>> OpenJDK I was thinking about naming the source package
>> "openjdk-9-openjfx" or "openjdk-9-jfx", and appending "-build" to the
>> binary package. What would be a good location for installing the build
>> directory?
>>
>> Regarding the distribution of the files, the lib/modules file of
>> openjdk-9-jre-headless will now contain the JavaFX classes, but the
>> native libraries should go into openjdk-9-jre. javapackager and
>> ant-javafx.jar would go into openjdk-9-jdk-headless.
> 
> Can progress be made with the above? Or is it blocked on lack of
> feedback from Matthias?
> 
> A number of packages fail to build now that openjdk-9 is the default-jdk
> and are forced to disable openjfx support to keep their packages in testing.

I wouldn't spend any time on that. We are moving towards 11, and openjfx is
split out there. So yes, maybe packages have to drop openjfx support for some 
time.

Matthias

Re: Bug#870258: GCC 7 related library transitions

[Matthias Klose]

On 13.03.2018 09:38, Emilio Pozuelo Monfort wrote:
> On 03/03/18 10:59, Emilio Pozuelo Monfort wrote:
>> As you can see it's a bunch of packages building with gcc-6 & g++-6. They 
>> probably
>> need new upstream versions that support GCC 7. The only exception is 
>> libpam-script
>> build-depending on libgfortran3 for no apparent good reason. I filed #889876 
>> for that.
> 
> I filed bugs for these:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=gcc-6-rm
> 
>> As for the GCJ removal, I crafted this list of binary packages. This is 
>> running
>> for sid, so it catches more stuff.
> 
>> Some things here need to be updated to use openjdk or default-jdk, e.g. 
>> kamailio, pdftk, libidn...
>> Other things likely need to be removed since GCJ is no more, e.g. ant-gcj, 
>> ecj-gcj...
> 
> And for these:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=gcj-rm

Please could you extend the latter with bug reports where
default-jdk/default-jre is going to away altogether because it's provided by
gcj?  Things like db5.3 come to my mind ...

Matthias

Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net

[Matthias Klose]

Rory, Dalibor,

is it really necessary to have these advertisements of Oracle's binary only,
architecture limited builds on a mailing list of a community project dedicated
to build binaries from sources?  I can't find such advertisements on e.g.
mailing lists for the Fedora project either.

Thanks, Matthias


On 28.11.2017 16:45, Rory O'Donnell wrote:
> Hi All,
> 
> *JDK 10 Early Access  build 33 is available at : - **jdk.java.net/10/*
> 
> 
> Notable changes since previous email.
> 
> JDK-8180019
>  - *javadoc treats failure to
> access a URL as an error , not a warning.*
> If javadoc cannot access the contents of a URL provided with the -link or
> -linkoffline options,the tool will now report an error.
> Previously, the tool continued with a warning, producing incorrect 
> documentation
> output.
> 
> JDK-8175094 *- **The
> java.security.acl APIs are deprecated, for removal
> * The deprecated java.security.acl APIs are now marked with forRemoval=true 
> and
> are subject to removal in a future version of Java SE.
> 
> JDK-8175091  *- The
> java.security.{Certificate,Identity,IdentityScope,Signer} APIs are deprecated,
> for removal*
> The deprecated java.security.{Certificate, Identity, IdentityScope, Signer}
> classes are now marked with forRemoval=true and are subject to removal in a
> future version of Java SE.
> 
> JDK 10 Schedule, Status & Features are available [1]
> 
> 
>  Notes
> 
>  * OpenJDK EA binaries will be available at a later date.
>  * Oracle has proposed: Newer version-string scheme for the Java SE
>    Platform and the JDK
>  o Please see Mark Reinhold's proposal [2]
> 
> *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*
> 
> 
> 
> *Feedback* - If you have suggestions or encounter bugs, please submit them 
> using
> the usual Java SE bug-reporting channel.
> Be sure to include complete version information from the output of the |java
> --version| command.
> 
> Regards,
> Rory
> 
> [1] http://openjdk.java.net/projects/jdk/10/
> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html
> 

Re: Impact of the new Java release policy on Debian

[Matthias Klose]

On 24.11.2017 11:05, Emmanuel Bourg wrote:
> Hi all,
> 
> Oracle has recently announced a new release policy for Java [1][2], to
> sum it up:
> - new major Java revisions will now be released every 6 months
> - there will be non-LTS releases supported for 6 months, and LTS
> releases supported 5+ years
> - LTS releases will be cut every 3 years
> - Java 9 is *not* a LTS release, the next one will be Java 11
> (previously named Java 18.9), to be released in September 2018
> 
> This is of course the policy for Oracle Java, not OpenJDK. It's not
> clear at this point if other players like Red Hat intend to support
> non-LTS OpenJDK releases longer than 6 months.

yes, and I think there is the wrong conclusion that *OpenJDK* LTS releases will
get five years of support.  What I am reading is that OpenJDK source releases
will be made for 18 months (three updates), not more, and that the sources for
those Oracle releases are not made public.

> Assuming that Debian will stick to the LTS releases as defined by Oracle
> I can see the following consequences:
> - openjdk-9 will not be part of Buster, and we should aim for openjdk-11
> instead.
> - If the freeze for buster starts in December 2018, we'll barely have 2
> months to complete the transition. Ideally we should start testing
> sooner with pre-release builds.
> - If we keep openjdk-8 as the default JRE until openjdk-11 is ready we
> may not catch runtime issues with the latest JREs and fix them in time
> for the freeze. This means we should probably change the default JRE as
> soon as possible to openjdk-9/10 but keep openjdk-8 in the archive as a
> possible fallback if we can't complete the transition to openjdk-11
> before the freeze.
> - After Java 11 the next LTS would be Java 17 to be released in
> September 2021, probably after the Debian 11 release which would thus
> ship the same JRE than Debian 10.

having an unsupported OpenJDK version in a release which is only used for
building packages could be an option, yes.

Matthias

Re: OpenJFX 9 integration

[Matthias Klose]

On 12.10.2017 13:13, Emmanuel Bourg wrote:
> Hi all,
> 
> I started working on OpenJFX 9 this week. The good news is that it
> builds fine in Debian now [1]. The bad news is that it's going to be
> significantly more challenging to integrate it with our OpenJDK package.
> 
> With OpenJDK 8 the integration was just a matter of installing extra jar
> files and native libraries under /usr/lib/jvm/java-8-openjdk-amd64. With
> Java 9 and the modularization of the JDK it's another story:
> 1. The class files for the JRE and JavaFX are merged into a huge binary
> blob (lib/modules) using a custom format.
> 2. The javadocs are also merged into a unique src.zip archive.
> 3. The JDK contains new .jmod files for each module, and the ones for
> JavaFX are built by OpenJDK, not OpenJFX.
> 4. The JRE modules have to be patched to allow JavaFX classes to use
> internal JRE classes.
> 
> According to the build instructions of OpenJFX [1] we have to build
> OpenJFX first and then build OpenJDK with an extra configuration
> parameter (--with-import-modules) pointing to the OpenJFX build directory.
> 
> In this context it appears nearly impossible to package OpenJFX
> independently of OpenJDK. Here are the options I can see so far:
> 
> A. Merge the openjfx package into openjdk.
> 
> B. Keep the packages separate and attempt to overcome the issues (1) and
> (2) with postinst hooks or triggers merging the files, (3) by patching
> the OpenJFX build, and (4) by patching the module-info.java files in
> OpenJDK.
> 
> C. Generate an intermediary package containing the build result of
> OpenJFX and used as a build dependency of OpenJDK.
> 
> (A) is problematic because the openjdk package is already quite complex,
> and since openjdk is in the hands of the OpenJDK Team I won't be able to
> maintain OpenJFX there. (B) involves a lot of work, merging lib/modules
> is the biggest issue. (C) requires a rebuild of OpenJDK every time
> OpenJFX is updated, but is by far the easiest solution to implement.

(A) is also problematic, because it adds yet another build tool, which never
should have been invented: gradle.  The OpenJDK package should be cross
buildable to (re-)bootstrap architectures.  We can't rely anymore on gcj for the
bootstrap.  Gradle is a mess when it comes to cross build support, hard coding
target architectures everywhere (at least that's when I looked at it two years
ago).  So independent of any maintainership, I don't like option (A).

(B) is something which should be addressed upstream independently.  Currently
upstream's thinking seems to be to ship everything in one place without caring
how the result is built, and only then providing some ways to build a minimal
JRE for some specific application.  That's not something distributions can use.

Are you aware if upstream is aware of these issues, and if they intend to stop
using internal OpenJDK APIs? Any plans to get rid off the single file approach
for the database files?

(C) looks like the best workaround for now.  Looking at at least four security
releases per year, and maybe the double amount of package uploads, the OpenJDK
package has a higher upload frequency anyway.  There is however a risk that an
OpenJDK (security) update won't build anymore with a prebuilt OpenJFX (not sure
if that is a real issue).  In any case, the OpenJDK package should have a build
profile to build without OpenJFX support.

(D) seems to be forgotten here: Don't build OpenJFX in the distro.  That might
be an option if OpenJFX can't keep up with security updates.

Matthias

Re: CDBS regression affecting Java packages

[Matthias Klose]

On 14.10.2017 11:29, Emmanuel Bourg wrote:
> Hi all,
> 
> FYI many Java packages are currently failing to build due to a
> regression in CDBS 0.4.143 (#878510). The DEB_UPSTREAM_VERSION variable
> now contains the Debian revision and the builds typically break during
> the install phase because the path of the jars to install becomes wrong.

I see that many packages are now converted to use plain debhelper.  Should that
be a soft release goal for all java packages?

Matthias

Fwd: A lot of packages fixed to build with jdk9

[Matthias Klose]

Fyi,

 Forwarded Message 
Subject: A lot of packages fixed to build with jdk9
Date: Thu, 12 Oct 2017 08:42:29 +0200
From: Fridrich Strba 
To: IcedTea 

Hello, good people,

In openSUSE Tumbleweed, our rolling distribution, we switched to
OpenJDK9 as a default Java since a week before the official OpenJDK9
release. I spent a considerable time going over different Java packages
to make sure they build with OpenJDK9. The big chunk of the work is to
be found here:

https://build.opensuse.org/project/show/Java:packages

Some are really easy, just to bump the source and target levels, but
some are result of reading thoroughly the code and understanding
different problems.

So, if you are a distro packager and have to port packages to Java 9,
before you waste you life, check there for eventual patches. They are
all contributed under the license of the underlying project.

Just a heads-up

Cheers

Fridrich

Re: ca-certificates-java_20170930_source.changes ACCEPTED into unstable

[Matthias Klose]

On 30.09.2017 16:18, Emmanuel Bourg wrote:
> Hi Matthias,
> 
> Le 30/09/2017 à 02:35, Debian FTP Masters a écrit :
> 
>>  - Stop fiddling around with jvm-*.cfg files. ca-certificates-java
>>has no business with providing an initial cacerts file. This is
>>implemented in the openjdk packages. We are not 2008 anymore.
> 
> Are you suggesting that we should drop ca-certificates-java and just
> rely on the root certificates from OpenJDK instead? I would welcome this
> simplification, the certificates in OpenJDK are frequently updated
> anyway, and that would improve the consistency with the Oracle JDK.

No. Why should we?

Re: Why dependency on both default-jre and java-runtime

[Matthias Klose]

On 23.08.2017 20:11, Carnë Draug wrote:
> Hi
> 
> I was going through the pkg-java policy and found this [1]:
> 
> Programs must depend on the needed runtime environment
> (default-jre or default-jre-headless if need a GUI or not, and
> java-runtime or java-runtime-headless as provided by
> alternative Java environments).
> 
> However, java-runtime packages are virtual packages provided by
> default-jre so I don't understand why.  Could anyone clarify?

others explained already, here is another reason for the

  default-jre | *-runtime

dependency:  If you have multiple openjdk versions in the archive, during
transition periods and as backports, then this dependency makes sure that you
always get the default dependency.  I have seen a lot of users complaining about
packages pulling in openjdk-9 unintended, which only use *-runtime as a 
dependency.

Matthias

Re: Notes from the DebConf 17 Java BOF

[Matthias Klose]

On 11.08.2017 20:49, Carnë Draug wrote:
> On 11 August 2017 at 23:06, Emmanuel Bourg  wrote:
>> [...]
>> On 08/09/2017 02:50 AM, Tom Marble wrote:
>>> [...]
>>> 6. Autopkgtest
>>>- We should use this more
>>>- Can include built-in tests
>>>- We can (or autopkgtest already does) use 'ratt' to test reverse deps
>>
>> My understanding of autopkgtest was that it wasn't meant to execute the
>> test suite already run at build time (i.e. mvn test). Maybe it could be
>> used to run the Maven integration tests instead?
>>
> 
> The perl team default autopkgtest reruns the test suite with the
> installed package.  The only difference is that it removes all the
> non-test units from the build tree to ensure that it uses the
> installed library.

it very much depends on the quality of the testsuite.  I'm trying to run the
testsuite for the pythonx.y packages with the installed package, however this is
some kind of fight with updating the testsuite itself to be run not in the build
tree.

> This could pick up packaging mistakes, but also picks up regressions
> caused by dependencies since the tests would be rerun when anything in
> the dependency chain is updated.

fyi, Ubuntu is doing that for migrations from the proposed to the release pocket
(Debian: unstable -> testing).  However it can be a pain ...
http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html

Matthias

Re: Advice regarding Java packages for SimpleITK

[Matthias Klose]

On 10.08.2017 09:09, tony mancill wrote:
>   Java bindings to the GDCM DICOM library. It allows developers to use
>   GDCM from Java environment.
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/lib/
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/
> drwxr-xr-x root/root 0 2017-08-07 07:28 
> ./usr/lib/x86_64-linux-gnu/jni/
> -rw-r--r-- root/root862712 2017-08-07 07:28 
> ./usr/lib/x86_64-linux-gnu/jni/libgdcmjni.so
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/doc/
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/
> -rw-r--r-- root/root  7698 2017-08-07 07:28 
> ./usr/share/doc/libgdcm-java/changelog.Debian.gz
> -rw-r--r-- root/root 24031 2017-08-07 07:28 
> ./usr/share/doc/libgdcm-java/copyright
> drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/java/
> -rw-r--r-- root/root330154 2017-08-07 07:28 ./usr/share/java/gdcm.jar
> 
> 
> This has the result of building a separate .deb for every architecture
> [0], which will function as expected up until the time that a user needs
> multi-arch, at which point the libgdcm-java:amd64 and libgdcm-java:i386
> (or whatever arch) packages will fail to co-install because they both
> contain the same JAR file in /usr/share/java/.

no, if the package is marked M-A: same and the gdcm.jar is bit-by-bit identical
across architectures, then the package can be installed. However I'm not sure
that we enforce such jar archives.

> That is, this approach "works" in the non-multi-arch case, but should be
> avoided.
> 
> Cheers,
> tony
> 
> [0] https://packages.debian.org/unstable/libgdcm-java
> 

Re: Java BoF at DebConf?

[Matthias Klose]

On 07.08.2017 14:13, Matthias Klose wrote:
> On 06.08.2017 07:13, Matthias Klose wrote:
>> On 18.07.2017 19:14, Matthias Klose wrote:
>>> Hi,
>>>
>>> not sure how many people will visit DebConf. Would it make sense to have a
>>> buster BoF? I'll be there, and would like helping organizing such a BoF if 
>>> there
>>> is interest.
>>
>> There is only adHoc scheduling 24h before.  So I'm trying to schedule the
>> meeting for Tue, 14:30 local time, and if that doesn't work, Thu, 12:30.  It
>> should be evening for Europeans to attend, hwoever we won't have a camera or
>> micro as I am told.
> 
> Now scheduled for Tue, 14:30, in the "potato" room.

Looks like the BoF was canceled without giving notice.  Now aiming for Thu,
12:30.  I'll try to confirm that on Thursday.

Matthias

Re: Java BoF at DebConf?

[Matthias Klose]

On 06.08.2017 07:13, Matthias Klose wrote:
> On 18.07.2017 19:14, Matthias Klose wrote:
>> Hi,
>>
>> not sure how many people will visit DebConf. Would it make sense to have a
>> buster BoF? I'll be there, and would like helping organizing such a BoF if 
>> there
>> is interest.
> 
> There is only adHoc scheduling 24h before.  So I'm trying to schedule the
> meeting for Tue, 14:30 local time, and if that doesn't work, Thu, 12:30.  It
> should be evening for Europeans to attend, hwoever we won't have a camera or
> micro as I am told.

Now scheduled for Tue, 14:30, in the "potato" room.

Re: Java BoF at DebConf?

[Matthias Klose]

On 18.07.2017 19:14, Matthias Klose wrote:
> Hi,
> 
> not sure how many people will visit DebConf. Would it make sense to have a
> buster BoF? I'll be there, and would like helping organizing such a BoF if 
> there
> is interest.

There is only adHoc scheduling 24h before.  So I'm trying to schedule the
meeting for Tue, 14:30 local time, and if that doesn't work, Thu, 12:30.  It
should be evening for Europeans to attend, hwoever we won't have a camera or
micro as I am told.

Matthias

Java BoF at DebConf?

[Matthias Klose]

Hi,

not sure how many people will visit DebConf. Would it make sense to have a
buster BoF? I'll be there, and would like helping organizing such a BoF if there
is interest.

Matthias

Re: Looking at an archive rebuild with opendjk-9-jdk

[Matthias Klose]

On 29.06.2017 15:16, Chris West wrote:
> I rebuilt ~300 packages[1] which build-depend on default-jdk in a
> hacked-up[2] "chroot" which uses openjdk-9-jdk, in place of openjdk-8-jdk.
> (i.e. custom java-common build + some Provides: hacks.)

thanks for doing that!  Usually java9 support comes in new upstream versions, so
updating packages in unstable to at least the first version supporting java9
would be nice.

> Most things fail: 87% failures.
> 
> 
> ~41% are hitting a bug in Maven, e.g. argparse4j:
>dh_auto_build -O--buildsystem=maven
> /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/[...]
> [ERROR] Error executing Maven.
> [ERROR] java.lang.IllegalStateException: Unable to load cache item
> [ERROR] Caused by: Unable to load cache item
> [ERROR] Caused by: Could not initialize class
>   com.google.inject.internal.cglib.core.$ReflectUtils
> 
> There's an old mailing list post about this, but it doesn't seem to have
> a resolution beyond "works for me!":
> https://www.mail-archive.com/jigsaw-dev@openjdk.java.net/msg06073.html
> 
> Someone more aware of what versions of things we're running, and how
> they were built, should investigate this.

I assume a lot more issues are hiding here once the build system is fixed.

> ~30% are using an outdated -source or -target, e.g. dom4j:
> [javac] error: Source option 1.3 is no longer supported. Use 1.6 or later.
> [javac] error: Target option 1.3 is no longer supported. Use 1.6 or later.
> 
> We discussed on IRC perhaps patching javac (or ant/maven) to just use
> 1.6 here, and pray. Annoying to try, as neither ant nor maven build in
> my "chroot".

That sounds ok. But why not using 1.7? should be fine for even oldstable.

> Does anyone have a less horrifying suggestion, beyond patching 30% of
> the libraries in Debian?

For the future we maybe could add these defaults in a common package.

> ~8% are hitting a bug in gradle, e.g. gant:
> Caused by: java.lang.reflect.InaccessibleObjectException:
>   Unable to make protected java.lang.Package[]
> java.lang.ClassLoader.getPackages() accessible:
>   module java.base does not "opens java.lang" to unnamed module @14fc5f04
> 
> https://github.com/gradle/gradle/issues/1095 suggests it's fixed in 4.1
> nightly, as of a fortnight ago.
> 
> I guess we just wait for upstream to fix this one, and the new gradle to
> make it into sid.
> 
> 
> 
> 
> The remaining failures are much more random:
>  * eclipse stuff has weird failures, e.g. eclipse-cdt fails to find some 
> files[3]

eclipse is so outdated, maybe better remove it.

Matthias

Re: java outlook for stretch and buster

[Matthias Klose]

On 10.09.2016 12:28, Andrew Haley wrote:
> On 10/09/16 11:09, Matthias Klose wrote:
> 
>> The ARM32 port already is in an upstream repository, and I'm told
>> that the s390x is on it's way.  Even if these ports will not be
>> merged before openjdk-10, it's my intent to build these from their
>> branches, as done in the past with the AArch64 and PPC64 port.
> 
> We should perhaps be looking at proper stable release branches for these,
> as we have for AArch64.
> 
> http://hg.openjdk.java.net/aarch64-port/jdk8u/ is a clone against a
> tag of the upstream stable jdk8u, but with AArch64 added.  The diffs
> from upstream are as small as we can possibly make them.

It would be nice if the branch could be kept up to date. Usually it's only
updated after a security update, however I'd like to see the merge for the base
of the next security update (in this case jdk8u112-b04) be done before the
security update.  It would not be a problem, if providers of security updates
would be allowed to share their work, but my understanding is this is yet not
allowed.

Matthias

java outlook for stretch and buster

[Matthias Klose]

As part of an overview of different toolchains [1], I looked at java as well
(re-posted here):

"""
Java/OpenJDK


For the stretch release openjdk-8 will be fine as the default java
implementation.  For buster, gcj (to be removed in GCC 7) won't be available
anymore, and we'll end up with architectures without a java implementation.  At
the same time I'd like to consider to stop providing OpenJDK zero builds,
leaving powerpc and mips* without a java implementation as well (currently not
building for openjdk-9).  armhf (not armel) and s390x have Hotspot ports 
underway.
"""

The ARM32 port already is in an upstream repository, and I'm told that the s390x
is on it's way.  Even if these ports will not be merged before openjdk-10, it's
my intent to build these from their branches, as done in the past with the
AArch64 and PPC64 port.

Looking at the zero based ports at [2] isn't very encouraging.  If you feel that
it's worth keeping these, please send patches to get them built.

Matthias

[1] https://lists.debian.org/debian-devel/2016/09/msg00193.html
[2] https://buildd.debian.org/status/package.php?p=openjdk-9=experimental

Re: OpenJDK 8...

[Matthias Klose]

On 05.02.2016 07:59, Emmanuel Bourg wrote:

...is now the default Java runtime in unstable! I just uploaded
java-common/0.55 to unstable and it switched the default-jre/jdk to
openjdk-8 for all the architectures previously defaulting to openjdk-7.

I expect a few packages to FTBFS after this update (most notably
eclipse) but the main compatibility issues have already been fixed.


https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openjdk-8-transition;users=debian-java@lists.debian.org

now lists the packages hardcoding openjdk-7.  This need to get fixed to remove 
openjdk-7.

Re: Packages not supported in wheezy-lts

[Matthias Klose]

On 25.01.2016 14:47, Raphael Hertzog wrote:

Hello,

On Mon, 25 Jan 2016, Raphael Hertzog wrote:

But there are still multiple open questions... I have added the most important 
ones
that I remembered in https://wiki.debian.org/LTS/TODO and I seek your help
to find a proper answer to those questions:

- what to do with openjdk-6?


CCing the Java team and Matthias Klose to have their input.

Matthias, until when is OpenJDK 6 supported upstream?
For how long do you plan to continue to provide backportable updated
packages in experimental?


I don't plan to update that beyond the EOL for Ubuntu 12.04 LTS.

Re: Bug#801683: ITP: gradle-debian-helper -- Helper tools for building Debian packages with Gradle

[Matthias Klose]

On 13.10.2015 15:20, Emmanuel Bourg wrote:

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: gradle-debian-helper
   Version : 1.0
   Upstream Author : Emmanuel Bourg 
* URL : 
http://anonscm.debian.org/cgit/pkg-java/gradle-debian-helper.git
* License : Apache-2.0
   Programming Lang: Java
   Description : Helper tools for building Debian packages with Gradle

gradle-debian-helper contains helper tools to ease the packaging of Gradle
based projects in Debian. It consists in:

  * a Gradle plugin resolving the dependencies against the system Maven
repository (/usr/share/maven-repo). The resolver uses the same Maven
rule files that maven-debian-helper and maven-repo-helper employ
(debian/maven.rules, debian/maven.ignoreRules).
  * a debhelper class detecting Gradle build files, initializing the plugin
and running Gradle in offline mode.



if gradle is the next big thing, please make sure that it works with zero as 
well.  It looks like gradle is so slow that it times out on the zero 
architectures.  A simple mode emitting a dot or a line every 15min or so if no 
other output happens would be fine to let the builds finish.


Also, please make sure that your helper is able to skip architecture independent 
bits for arch-only builds.

Re: Default JRE and Java plugin

[Matthias Klose]

On 07.10.2015 11:34, Emmanuel Bourg wrote:

Hi all,

I'm still rounding the corners for the switch to OpenJDK 8 and there is
a remaining issue regarding the Java plugin. The src:icedtea-web package
provides the icedtea-plugin package which pulls icedtea-7-plugin.
Matthias would like to split src:icedtea-web and have one version per
JRE supported. That would give a src:icedtea-8-web package building
icedtea-8-plugin.


we have some duplicated code, but we don't want to release with two java 
versions anyway.



The question is what do we do with the versionless icedtea-plugin
package? It cannot remain in src:icedtea-web since the package will
eventually go away. Since the package basically selects the default
plugin its role could be taken over by src:java-common (the source of
the default-jre/jdk packages).

I see different solutions:

1. Move icedtea-plugin as is to src:java-common and make it select the
default plugin (icedtea-7-plugin now, icedtea-8-plugin after the switch).

2. Move icedtea-plugin to src:java-common and rename it to
default-java-plugin or default-jre-plugin (so if we switch to another
implementation some day we don't have to rename the package).

3. Don't move icedtea-plugin but make default-jre recommends the default
plugin.

4. Solution 1 + make default-jre recommends icedtea-plugin

5. Solution 2 + make default-jre recommends default-java-plugin

I tend to favor the solution 3. With default-jre recommending the plugin
we mimic the behaviour of the Oracle JRE since it includes the plugin by
default, but the weak dependency makes it possible to uninstall the
plugin afterward.

What do you think?


Not moving/or renaming the iceded-plugin to java-defaults would need rebuilds of 
the icedtea-web package on the version change. Not a big deal, but that's why I 
don't like 3. Whether recommends or suggests I don't care, but these should 
match with the ones in the versioned packages.


Matthias

Re: Default JRE and Java plugin

[Matthias Klose]

On 07.10.2015 12:28, Emmanuel Bourg wrote:

Le 07/10/2015 11:47, Matthias Klose a écrit :


Not moving/or renaming the iceded-plugin to java-defaults would need
rebuilds of the icedtea-web package on the version change. Not a big
deal, but that's why I don't like 3.


I'm not sure to understand the rebuild issue. If we split
src:icedtea-web, we'll have:

- src:icedtea-web producing icedtea-7-plugin
- src:icedtea-8-web producing icedtea-8-plugin
- src:icedtea-9-web producing icedtea-9-plugin (in the future)

With an intermediate package we would have this dependency chain:

 default-jre -> default-java-plugin -> icedtea-8-plugin

and with the solution 3 we would have:

 default-jre -> icedtea-8-plugin


as a recommends or as a suggests.


In both cases, a transition to Java 9 implies uploading
src:icedtea-9-web first and then switching the dependency in
src:java-common. Did I miss something?


when you remove icedtea-8-plugin, you cannot directly re-install it without 
relying on, or knowing the versioned name.

Re: Default JRE and Java plugin

[Matthias Klose]

On 07.10.2015 13:10, Emmanuel Bourg wrote:

We could probably make it provide icedtea-plugin too, so people using
old tutorials can still get the right plugin.


then introducing the need to rebuild the icedtea packages on a version change.

Re: OpenJDK 8 transition

[Matthias Klose]

On 09/03/2015 08:53 AM, Emmanuel Bourg wrote:
> Le 03/09/2015 00:39, Matthias Klose a écrit :
> 
>> I disagree. Please revert mips/mipsel back to gcj, or fix the mips/mipsel 
>> builds
>> for openjdk-8 (and for openjdk-9).  The other alternative would be not to 
>> build
>> the packages for mips/mipsel and file RC issues for packages building
>> binary-arch packages and unconditionally build-depending on default-jdk.
> 
> Hi Matthias,
> 
> I switched only the architectures supported by openjdk-8, the others
> were left as is [1]. So alpha, lpia, mips, mipsel, mips64el and sh4
> still default to openjdk-7 for now.

 - lpia should be removed.
 - openjdk-8 sh4 is "not-for-us", needing intervention from somebody
 - openjdk-7 m68k is "not-for-us", needing intervention from somebody
 - icedtea unfortunately started configuring sparc64 for zero,
   fixed for the next package upload.

> Should we switch them back to gcj now or wait until openjdk-7 is removed?

I don't see a reason to keep 7 for too long. Maybe somebody could identify the
packages which build binary arch packages besides jni bindings or other java
support? IMO we should be prepared to file these bug reports.

Matthias

Re: openjdk-*-jdk, depends on -jre instead of -jre-headless

[Matthias Klose]

On 07/05/2015 10:08 PM, Jan Henke wrote:
 Am 05.07.2015 um 20:18 schrieb Emmanuel Bourg:
 Le 05/07/2015 09:11, Jan Henke a écrit :

 I would like to open discussion, whether it is possible to make the jdk
 depend on the headless jre only. The full jre could be a recommends, so
 it does get install by default, but advanced users can choose to not
 install it.
 Hi Jan,

 I tend to agree but I wouldn't change the dependencies of the *-jdk
 package to avoid disrupting the current installations.

 We could probably add an openjdk-8-jdk-headless package depending on
 openjdk-8-jre-headless, and change openjdk-8-jdk to depend on
 openjdk-8-jdk-headless and openjdk-8-jre.

 I don't think it makes sense to changes the openjdk-7 packages at this
 point if we plan to remove them in Stretch.

 Emmanuel Bourg


 Hi Emmanuel,
 
 that sounds like a good plan! Please add the corresponding
 default-jdk-headless package as well.
 
 You are right about openjdk-7, I was more thinking about making this the
 default for opnejdk-8 and all following version.

plus an update/rewrite of update-java-alternatives is needed.



-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5591.6040...@debian.org

openjdk-9 available in experimental

[Matthias Klose]

Hi,

openjdk-9 is now available in experimental.  for now it just builds on amd64 and
i386.  However I'd like to evaluate if we can skip openjdk-8 for stretch and
default to openjdk-9 (the road map would still be to default to openjdk-8 first,
and then to -9).  Is there anybody who wants to volunteer for a test rebuild of
all java packages with openjdk-9?  Compared to openjdk-8, openjdk-9 provides
hotspot vm's upstream for more release architectures than openjdk-8 would do.
However, this is an early build, not near a feature freeze openjdk-9 upstream.

Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55777403.3060...@debian.org

Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7

[Matthias Klose]

On 05/27/2015 03:41 PM, Jan Henke wrote:
 Am 27.05.2015 um 15:04 schrieb Thorsten Glaser:
 On Wed, 27 May 2015, Rene Engelhard wrote:

 I know, there at least we need to kill gcj support. But until then. Or
 we decide we don't care ab out 1.5/gcj now. Explicitely.

 On Wed, 27 May 2015, Markus Koschany wrote:

 Niels and Emmanuel have already pointed out the most important facts why
 we can't support GCJ forever. My Java baseline is:

 OK, let me rephrase my intent again.

 I think it’s fair to drop GCJ support. But please do not so for
 as long as doing that breaks GCJ architectures. That means, for
 all affected packages, do maintainer uploads or NMUs *first*
 that:

 - change the B-D to require default-jdk only on an architecture
   whitelist (do not use a blacklist, that makes bootstrapping
   new architectures impossible_)

 - change d/rules, d/control to only build the *-java packages
   on those architectures

 - ensure these changes are in sid *first*

 Thanks!

 bye,
 //mirabilos
 Hi,
 
 even with just being someone lurking on the ML for some time I still
 would like to voice my opinion on this matter.
 
 I think gcj serves one single purpose only at this point in time:
 Bootstrapping during the OpenJDK build.

No.

It's a direct build dependency for pdftk (but doesn't affect jdk-default).

It is used to provide a natively compiled ecj (and I think still ant) to speed
up builds on OpenJDK architectures.

It is used for bootstrapping, however the replacement to build openjdk on a new
architecture without having gcj on that architecture isn't yet implemented:
cross-building of openjdk-8 (help would be welcome, it's a packaging task and
supposed to be supported upstream).

 I concur with the voiced
 opinion, that gcj is from a piratical perspective not a working JVM any
 more. As unfortunate it is for the architectures without OpenJDK, I also
 think gcj does not work as default-jdk either on those architectures.
 
 As much as it is sad to write this, I fully agree at this point Java
 should be dropped from those architectures without an OpenJDK build. It
 is better to have no installable default-jdk, than a silently broken JVM
 that is not really usable with current Java applications.

sure, then please let's drop the mips and mipsel binaries too.  These are
currently not built anymore for openjdk-8, and I don't see any feedback to
improve the situation.

The next question is how to define OpenJDK build. There are the Hotspot VM's,
the Zero VM and JamVM. The Hotspot VM's and Zero are upstream, however being
upstream doesn't mean that these are always buildable (e.g. sparc HotSpot became
unbuildable in 7, looks buildable in 8 now; e.g. mips/mipsel based on Zero
doesn't build/work).

Learning from the attempt to keep a Hotspot port in the packaging (KFreeBSD),
it's required to have this maintained upstream. Things rot too fast in the
packaging.

Other release architectures based on the Zero port are armel, armhf, powerpc, 
s390x.

So the bigger question is, which Zero ports should be removed. From my point of
view these are mips and mipsel, and probably others.  In any case we will end up
with release architectures having no java support -- which is fine, other
languages don't provide this either).

I didn't look at JamVM for a long time, so maybe somebody else could figure out
if this is an option for the current Zero ports.

Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55660174.4000...@debian.org

Re: Help with Java package needed

[Matthias Klose]

On 04/26/2015 07:20 AM, Andreas Tille wrote:
 Hi,
 
 I intent to package mauve[1] and prepared the package in Git[2].

Please rename the package. We already have a mauve package in the archive.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553d0d1c.1090...@debian.org

Re: Stretch Roadmap

[Matthias Klose]

On 04/24/2015 03:19 PM, Miguel Landaeta wrote:
 On Fri, Apr 24, 2015 at 01:36:05PM +0200, Markus Koschany wrote:

 my personal goals for Stretch are:

 
 Hi,
 
 From my side I'd like to add:
 
 * Update jruby to 1.7.x soon and release Stretch with 9.x.

yes, would like to see 9.x as well. At least this version will have all the
different HotSpot versions merged.  Planning to upload once the AArch64 port is
merged.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553a7622.9050...@debian.org

Re: Stretch Roadmap

[Matthias Klose]

On 04/24/2015 12:55 PM, Emmanuel Bourg wrote:
 Hi all,
 
 I'd like to share my goals for the next release, feel free to comment
 and add yours as well so we can coordinate our efforts on the
 overlapping topics.
 
 * Java Runtime:
   - Provide Java 8 backports for Jessie and Wheezy

these should be relatively easy, the packaging is prepared for that.

   - Ensure our openjdk-8 package passes the TCK

which architectures?


Also we should consider stopping to build using the zero VM. At least on some
architectures where the builds are failing, one of the reason why jessie isn't
shipped with the latest security updates.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553a77f1.1070...@debian.org

Re: RFS: jffi-1.2.7 and jenkins-1.565.3-4

[Matthias Klose]

On 04/04/2015 05:22 AM, tony mancill wrote:
 Hi Tim,
 
 the jffi update looks pretty good, lots of great work, but I have a
 question about the -jni package.  The current packaging creates a
 libjffi-jni binary package that installs an arch:any file under /usj.
 That's going to break on multi-arch systems because it won't be possible
 to co-install libjffi-jni:amd64 and libjffi-jni:i386, etc. on the same
 system.  The following is the output of debc for libjffi-jni:
 
 libjffi-jni_1.2.7-1_amd64.deb
 -
  new debian package, version 2.0.
  size 34522 bytes: control archive=741 bytes.
  668 bytes,17 lines  control  
  215 bytes, 3 lines  md5sums  
  Package: libjffi-jni
  Source: jffi
  Version: 1.2.7-1
  Architecture: amd64
  Maintainer: Debian Java Maintainers 
 pkg-java-maintain...@lists.alioth.debian.org
  Installed-Size: 66
  Recommends: libjffi-java
  Section: java
  Priority: optional
  Homepage: http://github.com/wmeissner/jffi
  Description: Java Foreign Function Interface (JNI library)
   JFFI is a wrapper for libffi, the foreign function interface library. A 
 foreign
   function interface is the popular name for the interface that allows code
   written in one language to call code written in another language.
   Java-based codings helper classes for Joni and JRuby
   .
   This package ships the Java native interface library.
 drwxr-xr-x root/root 0 2015-04-02 21:41 ./
 drwxr-xr-x root/root 0 2015-04-02 21:41 ./usr/
 drwxr-xr-x root/root 0 2015-04-02 21:41 ./usr/share/
 drwxr-xr-x root/root 0 2015-04-02 21:41 ./usr/share/java/
 -rw-r--r-- root/root 30195 2015-04-02 21:41 
 ./usr/share/java/jffi-native.jar
 drwxr-xr-x root/root 0 2015-04-02 21:41 ./usr/share/doc/
 drwxr-xr-x root/root 0 2015-04-02 21:41 ./usr/share/doc/libjffi-jni/
 -rw-r--r-- root/root  7057 2015-04-02 20:56 
 ./usr/share/doc/libjffi-jni/copyright
 -rw-r--r-- root/root  1413 2015-04-02 20:56 
 ./usr/share/doc/libjffi-jni/changelog.Debian.gz
 
 So, I'm not sure about shipping this file in /usj.  Java Policy [0] says
 that the jni artifacts should be shipped under /usr/lib/jni/, but those
 are typically .so files.  And the previous version of the package ships
 the -native.jar in /usr/lib/jffi/ (also not in a multi-arch folder).  So
 it's not fundamentally different from what the package does now.  I'm
 going to upload it to experimental to get the ball rolling, and then we
 can discuss further.

but shipping native code in /usr/share is a policy violation.

Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/551fcf17.8050...@debian.org

Re: Correct dependency for package needing Java 6?

[Matthias Klose]

On 01/27/2015 05:35 PM, Thorsten Glaser wrote:
 On Tue, 27 Jan 2015, Jan Niehusmann wrote:
 
 Yes, sure - I missed that, because I tried the builds in clean chroots,
 where only one JDK was installed.
 
 Right, of course.
 
 But debian java policy states Packages must be built with default-jdk.
 
 Well at least on some of the gcj architectures, the package can be
 compiled if openjdk is installed (and gcj is not). So I'd prefer to not
 
 No. The packages must be built with the default JDK, so if
 gcj and OpenJDK are available but gcj is the default¹, the
 packages must be built with gcj.
 
 ① I don’t think we’ll ever have this if the OpenJDK is at
   all usable on that platform.
 
 
 On Tue, 27 Jan 2015, Emmanuel Bourg wrote:
 
 Yes, that would prevent failing builds, as well. But it will also exclude
 gcj architectures, as on these, this dependency is not available.

 Indeed, but gcj doesn't run Java 6 code, so that's normal.
 
 Another point for that.
 
 Architectures with gcj as default have that for a reason…
 and one reason alone… OpenJDK is not really usable there.

You should start working on cross-building openjdk-8 then, and fix bugs for 
m68k ...

there are a lot of recipies on the net, just add these to the packages.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c7cb82.8000...@debian.org

Re: OpenJDK 8 vs Zulu

[Matthias Klose]

On 01/19/2015 03:41 PM, Andrew Haley wrote:
 On 19/01/15 11:35, Emmanuel Bourg wrote:
 I've requested an access to the TCK for Java 8 in June to
 run it on the Debian packages but I haven't heard back from Oracle yet.
 
 I'd ping them again.

this is a problem.  I now got access to the TCK for Java 8, however it took
about 14 months for me.  Just publicly pinging doesn't help unfortunately.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c0318e.9020...@debian.org

Re: OpenJDK 8 vs Zulu

[Matthias Klose]

On 01/18/2015 11:21 PM, Jonathan Yu wrote:
 Hey everyone,
 
 Awhile back, there was a question on the Mechanical Sympathy mailing list
 (if you haven't heard of it before, it's a group for discussing development
 of high-performance programs, mainly focussing on Java).
 
 Gil Tene (CTO and Co-Founder of Azul Systems) provided a critical
 comparison of Azul's build of OpenJDK (Zulu) as compared to the package
 currently in Debian.
 
 Quoting from his post:
 
 To my knowledge, Zulu is currently the only OpenJDK 8 binary build
 available that is actually fully tested. When I say actually fully
 tested, I mean that someone actually states that the specific binary
 package has passed the full set of OpenJDK TCK tests, and is verified to be
 a compatible and complaint implementation of the Java SE 8 spec. Azul
 certifies this for each Zulu binary package.
 
 So for Java 8 (right now) your choices are OpenJDK (via the Zulu binary
 distros) or Oracle JDK. Both are well tested, compatibility-verified JDK 8
 binaries. And both are available for Linux, Windows, and MacOS.
 
 And no, that thing called openjdk-8-jdk that you would unfortunately get
 when you do an apt-get from the experimental or sid debian repos is not a
 good OpenJDK build. It currently appears shows as 8u40, which is something
 that doesn't actually exist yet. OpenJDK 8u40 is schedule to come out in
 March, and anything called 8u40 right now (without clear early access
 indicators) is certainly not a good release of anything.
 
 
 I wonder if there's anything that can (or should) be done to address Gil's
 criticisms. I love Debian and would always prefer to install things via
 apt-get from the official repositories rather than download/install
 third-party packages, so it would be nice to address these issues.
 
 Here's a link to the full thread:
 https://groups.google.com/forum/#!topic/mechanical-sympathy/jQGahuzJKM4

most of this is ranting, and marketing.

please ask azul to post jtreg test results (and/or compare these for yourself)
and find out that the Debian packages are on par or better than the azul
packages.  Debian doesn't have access to the TCK, and Debian shouldn't go into
any defensive mode to compare to any non-publically available test suite.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c032b8.8010...@debian.org

Re: Openjdk-8 in Debian/backports?

[Matthias Klose]

On 12/31/2014 04:23 PM, Emmanuel Bourg wrote:
 Le 31/12/2014 11:19, Thomas Zlika a écrit :
 
 Thanks for the tip and the pre-built binaries.
 However, the version is sid is a beta release (I think 8u40 will not be 
 released
 before spring) so I would prefer a more stable version.
 Btw, I don't understand why sid has a so cutting edge version.
 As I understand the purpose for the different Debian repositories, this 
 would better fit
 in the experimental repo.
 
 Not sure, but I believe Matthias packaged a more recent build to get a
 better compatibility on the architectures supported by Debian. The
 updates will probably follow the Oracle releases in the future.

Thomas, if you have the resources, then you can surely pack another openjdk-8
version.  Maybe you don't care about AArch64 and ppc64le, but building for these
architectures some backports are required. Feel free to address these. Unstable
is perfectly fine for a package like openjdk-8, which is not released with 
jessie.

And if you have time to kill, there are still a lot of outstanding issues to
build the archive with java8 ...

Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b9219a.9010...@debian.org

test rebuild with openjdk-8, build log analysis and bug filings needed

[Matthias Klose]

results from a test rebuild with openjdk-8 as the default can be found at

  https://people.debian.org/~doko/logs/20140912/

using the packages from

  deb https://people.debian.org/~doko/tmp/20140820 ./

I won't have time to analyse the results and file bug reports until mid October,
so please go ahead.  plus I'm not sure if the transition would be a good thing
for jessie. See #760984.  Having openjdk-8 in backports without any commitment
on security updates seems to be the better option.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412e269.7080...@debian.org

Re: Bug#759558: gcj-4.9-jdk: broken symlinks for j{awt,ni}{,_md}.h

[Matthias Klose]

Am 28.08.2014 um 18:08 schrieb Steven Chamberlain:
 reassign 759558 gcj-4.9-jdk
 found 759558 gcc-4.9/4.9.1-9
 thanks
 
 gcj-4.9-jdk isn't a source package, so the BTS seems a little confused
 about who to mail about this bug;  I don't think the maintainers were
 notified.  The original bug report is here:
 https://bugs.debian.org/759558#5

fixed in the VCS.

 Thanks, nice to know about this.  FWIW I'd prefer openjdk-7 as
 kfreebsd's default JDK.

 We may see kfreebsd-specific issues in openjdk-7 or gcj-4.9-jdk from
 time to time, but increasingly, if other architectures have switched
 over to openjdk-7, we'll see more issues like this which are
 FTBFS/broken on kfreebsd but actually due to gcj and not the
 architecture itself.

 And AIUI gcj is sort of deprecated within the GCC project now?

The good thing about gcj is that it doesn't break with upgrades, while openjdk-7
does on KFreeBSD. We had several months periods where the debian-bsd maintainers
didn't care about updating their patches and were blocking the Debian project
with this kind of attitude. See several emails from my side to the debian-bsd
and debian-java ML's.  Apparently this didn't change with OpenJDK-8, the current
packages fail to build. No effort was made to get the kfreebsd port upstream.  I
agree it would be good to switch to OpenJDK-7 for kfreebsd as well, but I can't
see any action from the KfreeBSD people how to bring the kfreebsd changes
upstream and keep up with the openjdk packages in Debian, and not blocking
current Debian development instead.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ffada0.7080...@debian.org

Re: jessie: Problems upgrading openjdk-7-jdk with openjdk-7-source installed

[Matthias Klose]

Am 27.07.2014 21:33, schrieb Felix Natter:
 Sylvestre Ledru sylves...@debian.org writes:
 
 Hello Felix,

 On 27/07/2014 19:42, Felix Natter wrote:
 hello,

 I get this:

 Preparing to unpack .../openjdk-7-jdk_7u65-2.5.1-2_amd64.deb ...
 Unpacking openjdk-7-jdk:amd64 (7u65-2.5.1-2) over (7u55-2.4.7-2) ...
 dpkg: error processing archive
 /var/cache/apt/archives/openjdk-7-jdk_7u65-2.5.1-2_amd64.deb (--unpack):
  trying to overwrite '/usr/lib/jvm/java-7-openjdk-amd64/src.zip', which
 is also in package openjdk-7-source 7u55-2.4.7-2
 This is an RC bug. Could you report it?
 
 Done: #756226

the advice was bad, and the bug filing too. The advice is missing an after you
checked the bug tracker for existing bugs, and you would have found #755126.
And the severity for the newly filed bug is wrong too, there is no
functionality bug.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d60cc3.8000...@debian.org

Re: jessie: Problems upgrading openjdk-7-jdk with openjdk-7-source installed

[Matthias Klose]

Am 28.07.2014 um 19:25 schrieb Felix Natter:
 Sylvestre Ledru sylves...@debian.org writes:
 
 On 28/07/2014 10:41, Matthias Klose wrote:
 Am 27.07.2014 21:33, schrieb Felix Natter:
 Sylvestre Ledru sylves...@debian.org writes:

 Hello Felix,

 On 27/07/2014 19:42, Felix Natter wrote:
 hello,

 I get this:

 Preparing to unpack .../openjdk-7-jdk_7u65-2.5.1-2_amd64.deb ...
 Unpacking openjdk-7-jdk:amd64 (7u65-2.5.1-2) over (7u55-2.4.7-2) ...
 dpkg: error processing archive
 /var/cache/apt/archives/openjdk-7-jdk_7u65-2.5.1-2_amd64.deb (--unpack):
  trying to overwrite '/usr/lib/jvm/java-7-openjdk-amd64/src.zip', which
 is also in package openjdk-7-source 7u55-2.4.7-2
 This is an RC bug. Could you report it?

 Done: #756226

 the advice was bad, and the bug filing too. The advice is missing an after 
 you
 checked the bug tracker for existing bugs, and you would have found 
 #755126.
 And the severity for the newly filed bug is wrong too, there is no
 functionality bug.
 
 Just to understand this: Which severity level do I use for package
 dependency problems? Is the 'important' from #755126 correct?
 To me, the bug makes the package unusable (but I guess not in the sense
 of https://www.debian.org/Bugs/Developer...).

this issue was filed with severity normal, then raised to serious (appropriate),
and then downgraded by myself to important, because I did value to reach the
security updates testing first. this was far more important than installability
of the -src package.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6971d.6050...@debian.org

Re: RFS: openjdk-8/8u5-b13-1 (NEW)

[Matthias Klose]

Am 11.07.2014 22:47, schrieb Emmanuel Bourg:
 Le 11/07/2014 20:09, Matthias Klose a écrit :
 
 To be clear, there was nothing restarted.  It is done the way I recommended
 Emmanuel before he did start, and which he did ignore.
 
 Matthias again I don't understand what you are referring to. You
 recommended to start from the openjdk-7 package and not from scratch and
 that's exactly what I've done. You can check it from the change history:
 
 http://anonscm.debian.org/gitweb/?p=pkg-java/openjdk-8.git;a=shortlog;pg=1

Even before you did start, I was telling you on irc that I'll keep the openjdk-8
package as one package, and not splitting it up into different source packages
depending on the hotspot version specific for that architecture. You did
continue your own way. The hotspot for ppc64 and ppc64el is now integrated in
8u20, that's the reason you don't see a separate hotspot for these 
architectures.

Asking please give my VCS write access so that I can commit my remaining
changes is not going to work for me, giving the history of this packaging and
the current situation with ecj.

 It contains all your openjdk-7 commits up to 2014-03-05, and I even
 tracked and merged the changes you made later like the GCC 4.9 switch.

I did walk though the committ diffs and applied relevant patches. If I did miss
any patches, please submit these as bug reports (preferred) or send these as 
email.

Please don't send any patches which drop the build support for squeeze or
wheezy, or any Ubuntu LTS. Please don't drop disabled build support which isn't
yet re-enabled for openjdk-8. Please don't drop the icedtea-sound tarball, which
makes backporting this package to earlier releases just easier.

There is still a lot of work to do,

 - build tzdata using openjdk-8

 - update the ARM assembler interpreter to work with 8 (maybe
   something you don't want to start).

 - get the remaining linux zero ports working (and tested). Note
   that your sponsors are able to get you access to Debian porter
   machines. See https://dsa.debian.org/doc/guest-account/
   It may be easier to default to zero on amd64, and start testing
   there.

 - look at the jtreg test results, decide which tests need fixes,
   which can be ignored (and added to the exclude list). The info
   for the failing tests is found in the -jdk package.

 - get the kfreebsd patches updated (Steven Chamberlain is currently
   working on this).

 - once kfreebsd is working, keep hotspot and jdk tarballs for
   kfreebsd, so that further updates won't break things without
   updating the patches. submit the kfreebsd patches upstream.

Thanks, Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c54861.3040...@debian.org

java for jessie

[Matthias Klose]

At least for past releases some support of java is available on every
architecture, not only for release architectures. A big advantage is that you
don't have to use architecture specific build dependencies, but usually packages
building architecture specific binary packages just work.  That did change for
the hurd recently, but hopefully is fixable.  I would like to keep it this way,
because it makes the work for porters easier. GCJ still seems to be good enough
to build jni bindings.

Providing security updates for released versions is tedious, and not many people
are working on getting these updates into the oldstable and stable releases.
oldstable had only one openjdk version, stable unfortunately has two openjdk
versions which need updates four times a year.  For jessie there should be only
one openjdk version in the release.

Looking at the current state, this is openjdk-7, so what needs to be done, if we
want to only ship openjdk-8?

 - build openjdk-8 on the architectures that openjdk-7 builds on.
   I don't think that dropping java support on some architecture
   for the release will be an option, this affects some more
   source packages in the archive.

 - have a test rebuild with openjdk-8, preferable using the zero
   interpreter so we may catch issues on the majority of release
   architectures.

 - make sure that at least the openjdk jtreg test results look
   reasonable and we don't see any regressions between 7 and 8.
   It would be interesting to compare test TCK results for those
   who have access to this testsuite.

I would like to avoid having openjdk-8 in unstable until we have answers to
these questions. It seems to be too easy to upload packages to unstable built
using openjdk-8.

I'll be at Debconf for the java BoF, but maybe most of the issues can be
resolved even before Debconf.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c54d31.2080...@debian.org

Re: Java 9 dropping support for source/target level 1.5

[Matthias Klose]

Am 15.07.2014 23:08, schrieb Emmanuel Bourg:
 This was expected but now it's effective, Java 9 no longer supports
 source/target level 1.5:
 
 http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/000972.html
 
 So if you update a package and see these settings please bump them to 1.6.
 
 It might be interesting to add a Lintian warning when a jar with the
 class format = 49 is detected, that would mean the package was compiled
 with a target = 1.5 and will probably fail to build with Java 9.

No. Don't do it. This is complete bullshit for Debian at this point.  We are
trying to prepare a release, working on a possible update to Java 8, and we
don't have the resources to work on Java 9 at this time.

You seem to have your own agenda, but it doesn't seem to match Debian's agenda.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c5a351.3090...@debian.org

Re: RFS: openjdk-8/8u5-b13-1 (NEW)

[Matthias Klose]

Am 11.07.2014 17:47, schrieb Miguel Landaeta:
 On Thu, Jul 10, 2014 at 11:11:29AM +0200, Emmanuel Bourg wrote:
 Matthias has restarted the packaging from the latest version of openjdk-7
 and merged some of my changes.

To be clear, there was nothing restarted.  It is done the way I recommended
Emmanuel before he did start, and which he did ignore.

 The repository is on Launchpad:
 
 http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files

Yes, the location used by the OpenJDK maintainers.

 Is there an easy way to rebuild what was just uploaded?

The package builds for me in a clean unstable environment. There are some
pending fixes in the VCS to fix builds on some architectures.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c02857.4000...@debian.org

Re: ecj_3.10.0+3.9.0-2_amd64.changes ACCEPTED into unstable

[Matthias Klose]

Am 07.07.2014 15:55, schrieb Emmanuel Bourg:
 Le 07/07/2014 15:34, Debian FTP Masters a écrit :
 
 Maintainer: Debian Java Maintainers 
 pkg-java-maintain...@lists.alioth.debian.org
 Changed-By: Matthias Klose d...@debian.org
 Description:
  ecj- standalone version of the Eclipse Java compiler
  ecj-gcj- standalone version of the Eclipse Java compiler (native 
 version)
  ecj1   - java byte code compiler used by gcj
  libecj-java - Eclipse Java compiler (library)
  libecj-java-gcj - Eclipse Java compiler (native library)
 Changes:
  ecj (3.10.0+3.9.0-2) unstable; urgency=medium
  .
* Disable the source build and build the architecture dependent packages
  from the libecj-java in the archive.
 
 Hi Matthias,
 
 Could you commit your changes to the Git repository please?

sure, as soon as there is a subversion repository available. Let me know if I
should create one with the current state of the package.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53baaa3c.3070...@debian.org

Re: RFS: ecj/3.10.0-1 - [UPLOADED]

[Matthias Klose]

Am 05.07.2014 20:20, schrieb Emmanuel Bourg:
 Le 05/07/2014 18:13, Matthias Klose a écrit :
 
 You should use the ecj from the eclipse package, if you
 need the exact upstream version, you should use org.eclipse.jdt.core from the
 eclipse-platform-data package, and maybe split out the jar file into it's own
 package.
 
 Thank you for the advice but that's a lot of work for a library that
 could be simply shared between GCJ, Tomcat, Gradle, Scilab, Plexus,
 Commons JCI, Spring and JasperReports. Also note that upgrading the
 whole Eclipse platform is much more difficult than just upgrading the
 compiler.
 
 I'd rather wait for upstream to fix the bug we identified and re-upload
 ecj 3.10.0 to unstable.

sorry, this is not an advice but a request.  I had to spend some time this
weekend to undo this upload, which I don't want to see repeated.

ecj is part of the java toolchain on some architectures, and from my point of
view it is more important to keep these working instead of updating to a new ecj
version.

I did point out a way forward to use a new org.eclipse.jdt.core by updating
eclipse.  If you don't have the time to do this, fine, but please don't mess
around with *my* time.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53baac6b.8010...@debian.org

Re: Bug#753791: simgrid: FTBFS on hurd-i386

[Matthias Klose]

Am 06.07.2014 19:06, schrieb Samuel Thibault:
 Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
 It FTBFS on hurd

 [...]
 cd /home/user/port/simgrid/simgrid-3.11.1/doc  /usr/bin/javadoc -quiet -d 
 /home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/ 
 /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*.java 
 /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*/*.java
 Segmentation fault (core dumped)
 
 Well, we have been seeing gcj-4.9 crashes in various packages recently.
 I don't think it's up to simgrid maintainers to look for the bug...

#753791 and #753604 are two java related build failures on the Hurd, reported on
July 3 and July 5.  I'm not aware of any changes in GCJ-4.9 itself, which is
used since May 5.  Is anybody aware of uploads which cause these packages to
fail to build?

candidates are the over-eager update of ecj-3.10, and maybe uploaded class files
built with java8.

I'm not that much amused to spend time on this.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b98b4c.5030...@debian.org

Re: RFS: ecj/3.10.0-1 - [UPLOADED]

[Matthias Klose]

Am 01.07.2014 00:09, schrieb Emmanuel Bourg:
 Le 30/06/2014 14:52, Matthias Klose a écrit :
 
 This breaks the gcj builds configured with --enable-java-maintainer mode. I
 filed an RC issue, and planning to revert that upload next weekend.
 
 If we can't get gcc and ecj 3.10 to work together I'd rather split ecj
 into an older version dedicated to gcc and an up to date version used by
 Tomcat and others. Simply reversing the update would hamper the
 integration of Java 8.

No, relying on ecj for Tomcat is the wrong thing.  This package has been there
for GCJ all the time.  You should use the ecj from the eclipse package, if you
need the exact upstream version, you should use org.eclipse.jdt.core from the
eclipse-platform-data package, and maybe split out the jar file into it's own
package.

Reverted back to 3.9 in unstable and uploaded 3.10 to experimental.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b82410.3070...@debian.org

Re: RFS: ecj/3.10.0-1 - [UPLOADED]

[Matthias Klose]

Am 30.06.2014 23:12, schrieb Emmanuel Bourg:
 Thank you for the log Matthias. Could you also detail the steps to
 reproduce this error please? I tried to build gcc with
 --enable-java-maintainer-mode but I didn't see this error (but my
 configure args were probably incomplete).

see libjava/HACKING.

 - you need the ecj1 and gjavah scripts

 - From Import a new release, do Remove the generated
   class and header files

I configured with

# to install:
# libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libgconf2-dev 
libqt4-dev

triplet=x86_64-linux-gnu

#PATH=/scratch/packages/gcc/svn:$PATH
#export PATH
branch=gcc-4_9-branch
#branch=trunk
ecjjar=/home/packages/gcc/svn/ecj-4.9.jar
ecjjar=/usr/share/java/ecj.jar

../$branch/configure \
--prefix=/home/packages/gcc/svn/jinstall \
--enable-languages=c,c++,java \
--disable-multilib \
--enable-java-maintainer-mode \
--with-ecj-jar=$ecjjar \
--enable-gjdoc \
--enable-gconf-peer \
--enable-gstreamer-peer \
--enable-java-awt=gtk,qt,xlib \
--enable-gtk-cairo \
--build=$triplet \
--host=$triplet \
--target=$triplet \


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b26b10.8010...@debian.org

Re: Bug#708350: transition: java7

[Matthias Klose]

Am 30.06.2014 01:03, schrieb Emilio Pozuelo Monfort:
 Control: block -1 by 750640 720911
 Control: block 720911 by 750640
 
 On 30/06/14 00:56, Emilio Pozuelo Monfort wrote:
 Hi Steven,

 On 29/06/14 18:58, Steven Chamberlain wrote:
 Hi,

 On 24/06/14 16:11, Emilio Pozuelo Monfort wrote:
 Is there anything left to do here?

 I presume openjdk-6 removal is the last thing to be done here.
 ftpmaster can't do that until icedtea-web stops building
 icedtea-6-plugin I think:  https://bugs.debian.org/720911#36

 Is it as easy as just removing that binary package? Or is it more complicated
 than that? Is there a bug report about it? Any progress on that?
 
 Alright, that is #750640. Apparently src:icedtea-web just needs to stop 
 building
 the icedtea-6-plugin binary.
 
 Matthias, can you do that? Then we can finally drop openjdk-6 from the 
 archive.

done.

I would like to keep openjdk-6 in unstable (with a RC issue so that it doesn't
migrate) to prepare and test security updates.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b2746e.2050...@debian.org

Re: RFS: ecj/3.10.0-1 - [UPLOADED]

[Matthias Klose]

Am 28.06.2014 06:33, schrieb tony mancill:
 On 06/26/2014 09:10 AM, Emmanuel Bourg wrote:
 Hi all,
 
 I packaged the latest version of the Eclipse Compiler for Java and I'm 
 looking for a sponsor to upload it. This is the first release supporting 
 the new Java 8 syntax. This update will fix 4 build failures with OpenJDK
 8 (eclipse-egit, eclipse-emf, eclipse-wtp and eclipse-xsd. Unfortunately
 eclipse and eclipse-cdt are still broken).
 
 This package wasn't managed in a VCS yet, so I created a new repository:
 
 https://alioth.debian.org/anonscm/git/pkg-java/ecj.git
 
 Uploaded and tagged in git.

This breaks the gcj builds configured with --enable-java-maintainer mode. I
filed an RC issue, and planning to revert that upload next weekend.  Such
uploads should go to experimental first if at all.  I told Emmanuel about this
weeks before on irc, so I'm surprised about this upload.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b15da7.20...@debian.org

Re: RFS: ecj/3.10.0-1 - [UPLOADED]

[Matthias Klose]

Am 30.06.2014 15:05, schrieb Emmanuel Bourg:
 Le 30/06/2014 14:52, Matthias Klose a écrit :
 
 This breaks the gcj builds configured with --enable-java-maintainer mode. I
 filed an RC issue, and planning to revert that upload next weekend.  Such
 uploads should go to experimental first if at all.  I told Emmanuel about 
 this
 weeks before on irc, so I'm surprised about this upload.
 
 Hi Matthias,
 
 Do you have a log of the build failure please?
 
 Emmanuel Bourg
 

../../../gcc-4_9-branch/libjava/jni.cc: In function '_Jv_Method*
_Jv_JNI_GetAnyMethodID(JNIEnv*, jclass, const char*, const char*)':
../../../gcc-4_9-branch/libjava/jni.cc:760:36: error: call of overloaded
'append(jchar)' is ambiguous
   name_sig-append ((jchar) ' ');
^
../../../gcc-4_9-branch/libjava/jni.cc:760:36: note: candidates are:
In file included from ../../../gcc-4_9-branch/libjava/jni.cc:34:0:
../../../gcc-4_9-branch/libjava/java/lang/StringBuffer.h:90:40: note: virtual
java::lang::AbstractStringBuffer* java::lang::StringBuffer::append(jdouble)
   ::java::lang::AbstractStringBuffer * append(jdouble);
^
../../../gcc-4_9-branch/libjava/java/lang/StringBuffer.h:91:40: note: virtual
java::lang::AbstractStringBuffer* java::lang::StringBuffer::append(jfloat)
   ::java::lang::AbstractStringBuffer * append(jfloat);
^
../../../gcc-4_9-branch/libjava/java/lang/StringBuffer.h:92:40: note: virtual
java::lang::AbstractStringBuffer* java::lang::StringBuffer::append(jlong)
   ::java::lang::AbstractStringBuffer * append(jlong);
^
../../../gcc-4_9-branch/libjava/java/lang/StringBuffer.h:93:40: note: virtual
java::lang::AbstractStringBuffer* java::lang::StringBuffer::append(jint)
   ::java::lang::AbstractStringBuffer * append(jint);
^
../../../gcc-4_9-branch/libjava/java/lang/StringBuffer.h:97:40: note: virtual
java::lang::AbstractStringBuffer* java::lang::StringBuffer::append(jboolean)
   ::java::lang::AbstractStringBuffer * append(jboolean);
^
Makefile:9930: recipe for target 'jni.lo' failed
make[3]: *** [jni.lo] Error 1

which differs when using the ecj 3.10 jar to regenerate the header files

$ svn diff libjava/java/lang/StringBuffer.h
Index: libjava/java/lang/StringBuffer.h
===
--- libjava/java/lang/StringBuffer.h(revision 212141)
+++ libjava/java/lang/StringBuffer.h(working copy)
@@ -91,11 +91,8 @@
   ::java::lang::AbstractStringBuffer * append(jfloat);
   ::java::lang::AbstractStringBuffer * append(jlong);
   ::java::lang::AbstractStringBuffer * append(jint);
-  ::java::lang::Appendable * append(::java::lang::CharSequence *, jint, jint);
   ::java::lang::AbstractStringBuffer *
AbstractStringBuffer$append(::java::lang::CharSequence *, jint, jint);
-  ::java::lang::Appendable * append(::java::lang::CharSequence *);
   ::java::lang::AbstractStringBuffer *
AbstractStringBuffer$append(::java::lang::CharSequence *);
-  ::java::lang::Appendable * append(jchar);
   ::java::lang::AbstractStringBuffer * AbstractStringBuffer$append(jchar);
   ::java::lang::AbstractStringBuffer * append(jboolean);
   ::java::lang::AbstractStringBuffer * append(JArray jchar  *, jint, jint);


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b16cc0.3010...@debian.org

Re: RFS: openjdk-8/8u5-b13-1 (NEW)

[Matthias Klose]

Am 25.06.2014 14:51, schrieb Miguel Landaeta:
 On Sun, May 25, 2014 at 09:17:09AM +0200, Emmanuel Bourg wrote:
 Le 25/05/2014 03:06, Miguel Landaeta a écrit :
 Is there any news on this?
 
 No, Matthias told me he was working on it but he hasn't committed 
 anything yet. The package has been on hold for 3 weeks now :/
 
 
 It's me again.
 
 I'm still wondering why after so many weeks we don't have an openjdk-8 
 package available in sid if Emmanuel already prepared it and is actively
 working in the associated transition.
 
 IMO, it's not fair to block this.

it is not blocked, it is work in progress.  Emmanuel did decide to change the
packaging, and did decide to drop support for most Debian architectures.
Dropping support for Debian architectures will automatically block this
package later on.  I'm still in progress looking at his commits and applying
these to a source package which builds on all architectures currently
supported by openjdk-7.

Afaics, fixing build failures with openjdk-8 as the default is not blocked.

 I have simpler packages than this one waiting for NEW processing for weeks
 so at this point I really wonder if a more complex package like openjdk-8
 will be accepted in before the freeze.

debian-java is not the place to speculate about NEW processing.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53aad2f4.7080...@debian.org

Re: openjdk-8 package available for review

[Matthias Klose]

Am 02.05.2014 06:36, schrieb tony mancill:
 On 05/01/2014 10:05 AM, Emmanuel Bourg wrote:
 Le 01/05/2014 18:27, Felix Natter a écrit :
 
 Another question: Is it sufficient to point update-java-alternatives 
 to openjdk-8 in order to use it to build and run subsequent packages 
 (that build-depend on default-jdk and depend on default-jre)?
 
 To build with Java 8 you have to change the JAVA_HOME variable. It's 
 defined in every debian/rules file and usually points to 
 /usr/lib/jvm/default-java. update-java-alternatives doesn't change the VM
 linked to this path, you have to change debian/rules or install a 
 modified version of default-jdk:
 
 http://87.98.165.193/debian/java-common/
 
 Given that we're 6 months from the freeze, and just 4 months from the 
 deadline for any new transitions [1], is it reasonable to target uploading
 a new java-common to experimental that depends on openjdk-8 in the next
 month or so?

The first priority should be to ship with only one version of OpenJDK.
OpenJDK 8 is an option, but not a must have.  If you can make it work on all
architectures currently supported by OpenJDK 7, fine.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5363997b.4000...@debian.org

Re: RFS: openjdk-8/8u5-b13-1 (NEW)

[Matthias Klose]

Am 02.05.2014 12:40, schrieb Emmanuel Bourg:
 Hi all,
 
 Here we go, I prepared the openjdk-8 package and I'm looking for a
 sponsor to upload it. There are several issues pending but the package
 is already usable to work on the Java 8 transition.

Please don't sponsor this package.  I'm preparing an upload myself.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53639a27.6050...@debian.org

Re: RFS: openjdk-8/8u5-b13-1 (NEW)

[Matthias Klose]

Am 02.05.2014 15:19, schrieb Sylvestre Ledru:
 On 02/05/2014 15:14, Matthias Klose wrote:
 Am 02.05.2014 12:40, schrieb Emmanuel Bourg:
 Hi all,

 Here we go, I prepared the openjdk-8 package and I'm looking for a
 sponsor to upload it. There are several issues pending but the package
 is already usable to work on the Java 8 transition.

 Please don't sponsor this package.  I'm preparing an upload myself.
 Hu? That is not very fair...
 You are aware that Emmanuel has been working on this for the last month
 and you
 won't even use his work... What a waste of his time.
 
 So, in the future, stop complaining about the lack of contributors on
 OpenJDK packaging...

I didn't say that I won't use his work. And yes, it's a waste of my time to
start this work within a new vcs which is neither used by upstream or the
current maintainers.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53639dad.3090...@debian.org

Re: Bug#743131: FTBFS if default-jdk is gcj-jdk

[Matthias Klose]

Am 31.03.2014 19:50, schrieb Steven Chamberlain:

tags 743131 + patch jessie sid
clone 743131 -1
reassign -1 src:eclipse-cdt
found -1 eclipse-cdt/8.3.0-1
thanks

Hi,

On 31/03/14 17:49, Sébastien Villemot wrote:

Therefore, would that be an acceptable course of action for you if I
restrict the architecture set of glpk-java to those were the default JDK
is openjdk, and then downgrade the present bug to severity important?


A better way seems to be:
Build-Depends: default-jdk (= 2:1.6)

which is satisfied only by arches having openjdk-6 or openjdk-7 as
default currently.

That way, if kfreebsd (or any other architecture) switches to openjdk as
default in the future, your package can be built again without changes.
  (Although - I'm hoping kfreebsd, along with all release architectures,
might be able to use openjdk-7 for jessie, greatly simplifying things
and making this change unnecessary).

In the meantime, the outdated kfreebsd binaries could be removed by
ftpmaster if you'd like the package to migrate.


Steven, the kfreebsd port was backported from OpenJDK 8 by Damien. In the past 
we had to wait for several months for updated kfreebsd patches to get the 
openjdk-7 built again on these architectures, despite pinging the kfreebsd 
porters.  How did that change?  How can you make sure that this won't repeat 
again?  I'm not in favour defaulting that again to openjdk-7 or openjdk-6.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5339b169.10...@debian.org

Re: zookeeper FTBFS with gcj as default-jdk

[Matthias Klose]

Am 23.03.2014 22:12, schrieb Tim Retout:

Hi all,

What's the right thing to do when Java packages can only build against
openjdk-7-jdk, and not gcj?

Since the latest default-jdk upload, zookeeper now fails to build on
kfreebsd-amd64, kfreebsd-i386 and sparc:
https://bugs.debian.org/742405

I guess fixing it to build with gcj will be quite difficult (but I've
not tried) - digging around the internet, I can see that there used to
be similar problems for zookeeper on mips, before openjdk worked
there.


instead of hard-coding the list of architectures, get it from

  /usr/share/java/java_defaults.mk

and use java7_architectures to generate the list of architectures.  However you 
are not allowed to change the control file during the build, so make sure that 
you fail the build when it changes.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53329285.3000...@debian.org

Bug#732282: stop building java for sparc, sparc64, s390, kfreebsd-any

[Matthias Klose]

Am 16.12.2013 11:34, schrieb Matthias Klose:
 Package: java-common
 Version: 0.50
 Severity: serious
 Tags: jessie, sid
 
 openjdk-7 currently ftbfs on sparc, sparc64, s390, kfreebsd-any. So please
 either remove the default-* packages on these archs, or fall back to gcj.
 
  - the hotspot port for linux sparc isn't maintained anymore
by upstream.  If a porter is interested, maybe investigate
how to build the zero vm on these architectures.
 
  - s390 needs an update of the s390 debian specific patch. Not
working on this myself.
 
  - the debian kfreebsd patches need an update.  I don't think
it's feasible to burden the openjdk maintainers or the
security team with patch maintenance.  I understand that
the bsd support is found upstream in openjdk-8, so maybe
try that again for the next upstream version.

ia64, sparc, sparc64, kfreebsd-i386 and kfreebsd-amd64 are now demoted to gcj on
the VCS.  Had to demote ia64 too, and don't want to investigate anymore.

I'll upload java-common later this week.

The good news is that arm64, mips, mipsel, powerpcspe, ppc64el and x32 are now
promoted to use openjdk-7.

  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/52d24e65.5000...@debian.org