Bug#944738: [Openjdk] Bug#944738: openjdk-11: diff for NMU version 11.0.8+10-1.1

[Tiago Daitx]

On Mon, Sep 28, 2020 at 12:24 PM tony mancill  wrote:
>
> On Mon, Sep 28, 2020 at 02:05:24PM +0200, Matthias Klose wrote:
> > On 9/24/20 7:47 PM, tony mancill wrote:
> > > Control: tags 944738 + pending
> > >
> > > Hello Matthias,
> > >
> > > I've prepared an NMU for openjdk-11 (versioned as 11.0.8+10-1.1) and
> > > uploaded it to DELAYED/15. Please feel free to tell me if I should delay
> > > it longer or remove the upload from the queue.
> >
> > please could you stop doing these NMUs? There's no reason to fast-track 
> > those
> > before the next regular updates.  Disappointed about that communication 
> > style,
> > after your words at FOSDEM, nothing happened and then suddenly you start 
> > NMUing.
>
> Hi Matthias,
>
> Yes, I will both cease and also remove these NMUs from the upload queue
> if you would prefer that.  Regarding communication, we have been
> discussing the bug in the BTS since September 18th and I announced my
> intention to NMU on September 20th:
>
> > Once the upload is ready (see below), I will upload it as an NMU to
> > the delayed queue if we haven't heard back from Matthias.
>
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738#79)
>
> I assumed that you saw the traffic - after all, you did see the nmudiff
> email - but would you prefer a direct cc: in the future?
>
> Regarding the sudden activity - in my opinion, the jlink bug is serious.
> Part of the functionality of the JDK was broken in order to support
> reproducible builds - and so I was trying to help address that.  I'm
> grateful that Julian discovered the root cause.

Disclaimer: I am not involved in Debian and not very familiar with how
NMUs are done and how they affect the package/distro, I'm just stating
my opinion as an Ubuntu maintainer for the OpenJDK security releases
regarding the patch itself.

I agree with Tony's statement that this is a serious issue - and I'm
also very glad that Julian found the root cause. The next security
update comes out on Oct 20th and we should have it packaged in the
same week, so while waiting until then seems ok, I believe it could be
very useful to have the jlink patch out now so users can report back
if they see any issues on the current fix.

cheers!

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[Tiago Daitx]

Hi Tony,

Matthias is the actual Debian Maintainer, but in my opinion the patch
is great and should be ok to go do an upload including it.

Thanks Julian for the investigation and figuring out how to fix this
problem, I really appreciate it. =)

Best regards,
Tiago

On Fri, Sep 18, 2020 at 11:12 AM tony mancill  wrote:
>
> On Fri, Sep 18, 2020 at 11:15:13AM +0100, Julian Gilbey wrote:
> > tags 944738 patch
> > thanks
> >
> > On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote:
> > > affects 944738 openjdk-14-jdk
> > > thanks
> > >
> > > The same problem is still present in openjdk-14 - see
> > > https://bugs.debian.org/968991
> >
> > I have located the source of the bug and have a patch to fix it.
> >
> > The cause is the use of dh_strip_nondeterminism late in the build
> > process.  This reorganises the jmod files, which in turn changes their
> > SHA256 checksums.  This would not be a problem, except that the
> > checksums are saved in java.base.jmod *before* the use of
> > dh_strip_nondeterminism.  Performing this stripping immediately after
> > each jmod file is created results in the checksums being consistent
> > throughout.
>
> Thank you for digging into this bug Julian!
>
> Matthias or Tiago, any concerns with me preparing an upload that
> includes this patch?
>
> Thank you,
> tony
> ___
> Mailing list: https://launchpad.net/~openjdk
> Post to : open...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openjdk
> More help   : https://help.launchpad.net/ListHelp



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#965047: jtreg won't run as it can't locate its own jar file

[Tiago Daitx]

Please consider the attached debdiff to fix this issue.


jtreg-5.1-b01-1_5.1-b01-2.debdiff
Description: Binary data

Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

[Tiago Daitx]

On Thu, 9 Apr 2020 16:35:13 +0200 Sebastian Andrzej Siewior
 wrote:
> I suggested already something in [0]. Back then we were hoping for some
> feedback from the debhelper team.
> Now I was just asking if Jonathan is handling this and/or if we could
> also bump to current upstream version while at it.
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10

As Dimitri pointed out we have also been affected by this but in
Ubuntu - we found it out recently when doing archive rebuilds on
Focal. The proposed fix in #10 does workaround the issue and it is not
necessary to change the build-arch rules as Dimitri suggested.

I do wonder if this is in fact a regression in debhelper. I tracked it
down to debhelper 12.4 to 12.5 and while I haven't been able to
pinpoint exactly what particular change there is causing it I believe
it is in how double colon rules are being interpreted. It seems the
debhelper changes somehow fail to detect the build-arch rules.

Unless someone knows enough perl to dig into debhelper changes between
12.4 and 12.5 and check if that is in fact a regression, I would
suggest to simply apply the proposed change in comment #10.

Thanks for your help =)

Tiago Daitx

Bug#938969: python-packaging: test failures due to wrong arch check

[Tiago Daitx]

Please consider the following debdiff to fix this issue.
diff -Nru python-packaging-19.1/debian/changelog python-packaging-19.1/debian/changelog
--- python-packaging-19.1/debian/changelog	2019-08-17 08:49:26.0 -0300
+++ python-packaging-19.1/debian/changelog	2019-08-29 18:58:34.0 -0300
@@ -1,3 +1,11 @@
+python-packaging (19.1-2) unstable; urgency=medium
+
+  * debian/patches/update-platform-for-pybuild.patch: use amd64 instead
+of x86_64 during the build as pybuild forcefully sets get_platform()
+to return linux-amd64.
+
+ -- Tiago Stürmer Daitx   Thu, 29 Aug 2019 21:58:34 +
+
 python-packaging (19.1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-packaging-19.1/debian/patches/series python-packaging-19.1/debian/patches/series
--- python-packaging-19.1/debian/patches/series	2015-10-28 11:18:13.0 -0200
+++ python-packaging-19.1/debian/patches/series	2019-08-29 18:58:34.0 -0300
@@ -1 +1,2 @@
 # empty
+update-platform-for-pybuild.patch
diff -Nru python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch
--- python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch	1969-12-31 21:00:00.0 -0300
+++ python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch	2019-08-29 18:58:34.0 -0300
@@ -0,0 +1,84 @@
+Description: update x86_64 references to amd64
+ pybuild sets the _PYTHON_HOST_PLATFORM environment variable which
+ causes distutils.util.get_platform() to return linux-amd64 instead
+ of linux-x86_64. This causes 2 tests in test/test_tags.py to fail.
+ This patch updates the test_tags.py file to expect amd64 instead
+ of x86_64. Meanwhile packaging/tags.py needs to be updated to
+ support both linux-x86_64 (for runtime) and linux-amd64 (for build
+ time).
+Author: Tiago Stürmer Daitx 
+Bug-Debian: http://bugs.debian.org/938969
+Forwarded: not-needed
+Last-Update: 2019-08-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/test_tags.py
 b/tests/test_tags.py
+@@ -487,18 +487,18 @@ def test_have_compatible_glibc(monkeypat
+ 
+ 
+ def test_linux_platforms_64bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=False)[-1]
+-assert linux_platform == "linux_x86_64"
++assert linux_platform == "linux_amd64"
+ 
+ 
+ def test_linux_platforms_32bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=True)[-1]
+ assert linux_platform == "linux_i686"
+@@ -509,9 +509,9 @@ def test_linux_platforms_manylinux1(monk
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux1"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-assert platforms == ["manylinux1_x86_64", "linux_x86_64"]
++assert platforms == ["manylinux1_amd64", "linux_amd64"]
+ 
+ 
+ def test_linux_platforms_manylinux2010(monkeypatch):
+@@ -519,9 +519,9 @@ def test_linux_platforms_manylinux2010(m
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux2010"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-expected = ["manylinux2010_x86_64", "manylinux1_x86_64", "linux_x86_64"]
++expected = ["manylinux2010_amd64", "manylinux1_amd64", "linux_amd64"]
+ assert platforms == expected
+ 
+ 
+@@ -531,7 +531,7 @@ def test_sys_tags_linux_cpython(monkeypa
+ monkeypatch.setattr(tags, "_cpython_abi", lambda py_version: "cp33m")
+ if platform.system() != "Linux":
+ monkeypatch.setattr(platform, "system", lambda: "Linux")
+-monkeypatch.setattr(tags, 

Bug#938969: python-packaging: test failures due to wrong arch check

[Tiago Daitx]

Please consider the following debdiff to fix this issue.
diff -Nru python-packaging-19.1/debian/changelog python-packaging-19.1/debian/changelog
--- python-packaging-19.1/debian/changelog	2019-08-17 08:49:26.0 -0300
+++ python-packaging-19.1/debian/changelog	2019-08-29 18:58:34.0 -0300
@@ -1,3 +1,11 @@
+python-packaging (19.1-2) unstable; urgency=medium
+
+  * debian/patches/update-platform-for-pybuild.patch: use amd64 instead
+of x86_64 during the build as pybuild forcefully sets get_platform()
+to return linux-amd64.
+
+ -- Tiago Stürmer Daitx   Thu, 29 Aug 2019 21:58:34 +
+
 python-packaging (19.1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-packaging-19.1/debian/patches/series python-packaging-19.1/debian/patches/series
--- python-packaging-19.1/debian/patches/series	2015-10-28 11:18:13.0 -0200
+++ python-packaging-19.1/debian/patches/series	2019-08-29 18:58:34.0 -0300
@@ -1 +1,2 @@
 # empty
+update-platform-for-pybuild.patch
diff -Nru python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch
--- python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch	1969-12-31 21:00:00.0 -0300
+++ python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch	2019-08-29 18:58:34.0 -0300
@@ -0,0 +1,84 @@
+Description: update x86_64 references to amd64
+ pybuild sets the _PYTHON_HOST_PLATFORM environment variable which
+ causes distutils.util.get_platform() to return linux-amd64 instead
+ of linux-x86_64. This causes 2 tests in test/test_tags.py to fail.
+ This patch updates the test_tags.py file to expect amd64 instead
+ of x86_64. Meanwhile packaging/tags.py needs to be updated to
+ support both linux-x86_64 (for runtime) and linux-amd64 (for build
+ time).
+Author: Tiago Stürmer Daitx 
+Bug-Debian: http://bugs.debian.org/938969
+Forwarded: not-needed
+Last-Update: 2019-08-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/test_tags.py
 b/tests/test_tags.py
+@@ -487,18 +487,18 @@ def test_have_compatible_glibc(monkeypat
+ 
+ 
+ def test_linux_platforms_64bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=False)[-1]
+-assert linux_platform == "linux_x86_64"
++assert linux_platform == "linux_amd64"
+ 
+ 
+ def test_linux_platforms_32bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=True)[-1]
+ assert linux_platform == "linux_i686"
+@@ -509,9 +509,9 @@ def test_linux_platforms_manylinux1(monk
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux1"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-assert platforms == ["manylinux1_x86_64", "linux_x86_64"]
++assert platforms == ["manylinux1_amd64", "linux_amd64"]
+ 
+ 
+ def test_linux_platforms_manylinux2010(monkeypatch):
+@@ -519,9 +519,9 @@ def test_linux_platforms_manylinux2010(m
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux2010"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-expected = ["manylinux2010_x86_64", "manylinux1_x86_64", "linux_x86_64"]
++expected = ["manylinux2010_amd64", "manylinux1_amd64", "linux_amd64"]
+ assert platforms == expected
+ 
+ 
+@@ -531,7 +531,7 @@ def test_sys_tags_linux_cpython(monkeypa
+ monkeypatch.setattr(tags, "_cpython_abi", lambda py_version: "cp33m")
+ if platform.system() != "Linux":
+ monkeypatch.setattr(platform, "system", lambda: "Linux")
+-monkeypatch.setattr(tags, 

Bug#926180: scilab: FTBFS on all - New trouble

[Tiago Daitx]

On Tue, 14 May 2019 00:39:07 +0200 Alexis Murzeau  wrote:
> Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit :
> >
> > On 12/05/2019 22:10, Julien Puydt wrote:
> >> Hi,
> >>
> >> On 12/05/2019 11:46, Alexis Murzeau wrote:
> >>
> >>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
> >> I had started to package 6.0.2 on salsa already in february. I removed
> >> the patch about Linenum as that was supposed to have been reworked and
> >> fixed, and it now fails with :
> >>
> >> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I
> >> ./src/xml2modelica  nums.cmxa ./src/xml2modelica/xMLTree.ml
> >> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml
> >> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml
> >> ./src/xml2modelica/xMLLexer.ml
> >> ./src/xml2modelica/modelicaCodeGenerator.ml
> >> ./src/xml2modelica/xML2Modelica.ml
> >> File "./src/xml2modelica/xML2Modelica.ml", line 1:
> >> Error: Files ./src/xml2modelica/xMLParser.cmx
> >>and ./src/xml2modelica/linenum.cmx
> >>make inconsistent assumptions over implementation Linenum
> >>
> >> ie : it looks like upstream's fix isn't correct.
> >
> > + upstream
> >
> > S
> >
> >
>
> Reversing the order of the includes parameters when compiling
> XML2Modelica fix the build for me, ie. including xml2modelica first:
> `-I ./src/xml2modelica -I ./src/modelica_compiler`
>
> I think ocamlopt prefer to use a part of Linenum from
> ./src/modelica_compiler and the other one from ./src/xml2modelica which
> lead to the error.
>
> But I'm not sure this is the way to handle it cleanly.
> The files "linenum.mll" are almost the same between both directories.
> The only difference is the comment at the beginning of the file.
>
> Maybe some of these "linenum.mll" file can be removed to keep only one ?

Ubuntu has packaged 6.0.2 for Disco and Eoan, please see
https://launchpad.net/ubuntu/+source/scilab
or fetch the DSC directly from
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/scilab/6.0.2-0ubuntu2/scilab_6.0.2-0ubuntu2.dsc

>
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
>
>

Bug#925320: [Android-tools-devel] Bug#925320: Acknowledgement (android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError)

[Tiago Daitx]

On Thu, Mar 28, 2019 at 7:24 AM Hans-Christoph Steiner  wrote:
>
>
> The "--release 8" fix seems fine, my only concern is that someone needs
> to test this, since it is different than what upstream does.  I suppose
> that the autopkgtest is complete enough to test this.  I'm not really
> aware of whether there are security concerns of compiling with different
> source/target/release versions.  Do you know?
>
> .hc

I am also not aware of any security issues related to providing
backwards compatibility for compiled java classes. The --release flag
(and the -source/-target pair) is and has been used on other packages
for quite some time so there are no known drawbacks of using it, on
the contrary, they are required so we can provide java 8 bytecode when
compiling with a java 9+ compiler.

Regards,
Tiago

Bug#925320: [Android-tools-devel] Bug#925320: Acknowledgement (android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError)

[Tiago Daitx]

Indeed, openjdk-8 is planned to be removed from buster, but any user
that tries to run apksigner with a java 8 level binary (from openjdk,
oracle, or other vendors) will be unable to do so. In addition to that
Debian derivatives might be affected: Ubuntu is keeping openjdk-8
available for users and to avoid such simply delta I am proposing the
patch to Debian.

The early changelog entry related to the "-source 8" change stated
that this was done to support java 8 level, but it missed the fact
that it should actually have added "-target 8" at the least. I am
aiming to fix that with the "--release 8" flag which is the proper way
to set source/target since OpenJDK 9.

Please note that the jh_build tool from javatools package has a bug
that causes this package to currently FTBFS (with or without my change
as the bug forces -source 7 -target 7 to be used which is incompatible
with the level 8 source code): https://bugs.debian.org/925617

Regards,
Tiago

On Mon, Mar 25, 2019 at 4:52 PM Hans-Christoph Steiner  wrote:
>
>
> Can you tell me more about the use case for this?  my understanding is
> that openjdk-8 will not be supported in buster.
>
> .hc
>
> Tiago Daitx:
> > Hi,
> >
> > Please consider my upload to mentors as a fix for this issue
> > https://mentors.debian.net/package/android-platform-tools-apksig
> > https://mentors.debian.net/debian/pool/main/a/android-platform-tools-apksig/android-platform-tools-apksig_0.8-3.dsc
> >
> > Regards,
> > Tiago
> >
> > ___
> > Android-tools-devel mailing list
> > android-tools-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/android-tools-devel
> >



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#925320: Acknowledgement (android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError)

[Tiago Daitx]

Hi,

Please consider my upload to mentors as a fix for this issue
https://mentors.debian.net/package/android-platform-tools-apksig
https://mentors.debian.net/debian/pool/main/a/android-platform-tools-apksig/android-platform-tools-apksig_0.8-3.dsc

Regards,
Tiago

Bug#925225: gradle: Fix gradle compatibility with OpenJDK 8

[Tiago Daitx]

I uploaded a proposed solution to mentors, it is available at
https://mentors.debian.net/package/gradle and dsc at
https://mentors.debian.net/debian/pool/main/g/gradle/gradle_4.4.1-6.dsc

That one involves using the actual upstream patch for
https://github.com/gradle/gradle/commit/028548460bd929fd034a552704798ad7f689493a

Regards,
Tiago

Bug#920534: openjdk-11: jlink creates very large runtime images

[Tiago Daitx]

There is an open bug report on the OpenJDK side about this issue:
https://bugs.openjdk.java.net/browse/JDK-8214796 and discussions on
the fix are on the way.

When this get implemented it could be backported into opendk-11 to
enable the stripping of debug symbols from the java.base.jmod files.

Bug#914424: openjdk-11: mismatched cacert format

[Tiago Daitx]

ca-certificates-java needs to be backported to stretch as well.

On Fri, Nov 23, 2018 at 7:33 AM Robert Lemmen  wrote:
>
> Source: openjdk-11
> Severity: normal
>
> hi folks,
>
> I was using the brand new openjdk-11 packages in stretch-backports.
> thanks for providing these! they generally seem to work for me, but I
> found that I cannot make TS connections. some googling revealed that the
> default format for the cacert files jdk reads changed from jks to pkcs12
> or so. there seem to be plenty of reports aboutthis problem e.g. [0].
>
> I managed to work around it by doing this:
>
> +echo "javax.net.ssl.trustStorePassword=changeit" \
> +>> /etc/java-11-openjdk/management/management.properties && \
> +/usr/bin/printf 
> '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92'
>  > /etc/ssl/certs/java/cacerts && \
> +/var/lib/dpkg/info/ca-certificates-java.postinst configure
>
> but I guess a better solution is needed
>
> regards  robert
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15), 
> LANGUAGE=en_GB:en (charmap=ISO-8859-15)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>


--
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#912527: [Openjdk] Bug#912527: openjdk-8-jdk: please update to support class file version 64

[Tiago Daitx]

On Wed, Oct 31, 2018 at 11:57 PM Norbert Preining  wrote:
> $ java -jar myprog.jar
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
> javafx/event/EventTarget has been compiled by a more recent version of the 
> Java Runtime (class file version 54.0), this version of the Java Runtime only 
> recognizes class file versions up to 52.0
> ...

Please note that differently from Oracle JDK the OpenJDK project does
not contain any classes for javafx. In Debian these classes are
provided by the openjfx package.
In particular the class javafx/event/EventTarget can be found in the
libopenjfx-java binary package inside the
/usr/share/java/javafx-base-11.jar file.

>From your system informaton I can see you are running sid. The openjfx
version in sid is 11+26-5, which is not compatible with openjdk-8 [see
https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md].
It depends and is only usable with openjdk-10 or openjdk-11.

> OTOH, if I use jdk8 from upstream:
> $ which java
> /home/norbert/Java/jdk1.8.0_192/bin/java
> $ java -version
> java version "1.8.0_192-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode)
> $ java -jar myprog.jar
> ...
>
> There are no problems.

This is because the Oracle JDK packages JavaFX in its binary, it is
not using the openjfx package from Debian, thus it works.

>
> Would it be possible to update jdk8 in Debian to support that?

The only way for Debian to support that would be for it to have
something like a separated openjfx-8 package that was compiled with
openjdk-8. Somebody would have to be willing to support that but I am
not sure if openjdk-8 will even be included in buster. The openjfx
maintainer can probably provide a more insights into that.


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#913853: jtreg fails to run under openjdk-8 due to api incompatibility with openjdk-9 or later

[Tiago Daitx]

I have also proposed it as a merge request in salsa. The url is
https://salsa.debian.org/java-team/jtreg/merge_requests/1

I am still getting used to salsa and packages in git, hopefully I got
the merge request right. And let me know if the it is any
better/easier for you if I do it through mentors.debian.net instead.
;-)
On Thu, Nov 15, 2018 at 10:33 PM Tiago Daitx  wrote:
>
> Please consider the following debdiff patch to fix this issue.



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#913853: jtreg fails to run under openjdk-8 due to api incompatibility with openjdk-9 or later

[Tiago Daitx]

Please consider the following debdiff patch to fix this issue.
diff -Nru jtreg-4.2-b13/debian/changelog jtreg-4.2-b13/debian/changelog
--- jtreg-4.2-b13/debian/changelog	2018-08-02 04:16:44.0 -0300
+++ jtreg-4.2-b13/debian/changelog	2018-11-01 02:36:28.0 -0300
@@ -1,3 +1,9 @@
+jtreg (4.2-b13-2) UNRELEASED; urgency=medium
+
+  * Use release instead of source/target. (Closes: #913853, LP: #1803628)
+
+ -- Tiago Stürmer Daitx   Thu, 01 Nov 2018 05:36:28 +
+
 jtreg (4.2-b13-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru jtreg-4.2-b13/debian/patches/series jtreg-4.2-b13/debian/patches/series
--- jtreg-4.2-b13/debian/patches/series	2018-08-02 04:06:17.0 -0300
+++ jtreg-4.2-b13/debian/patches/series	2018-11-01 02:35:53.0 -0300
@@ -1,2 +1,3 @@
 launchers.patch
 add-jcommander-to-classpath.patch
+use-release-instead-of-source-target.patch
diff -Nru jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch
--- jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch	1969-12-31 21:00:00.0 -0300
+++ jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch	2018-11-01 02:36:28.0 -0300
@@ -0,0 +1,22 @@
+Description: use 'release' instead of 'target' and 'source'
+ When running jtreg with openjdk-8 and the agentvm it will fail to run with
+ "java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer".
+ An easy fix is to replace "source=1.7 target=1.7" with "release=7" in the
+ ant build script.
+Author: Tiago Stürmer Daitx 
+Bug-Debian: https://bugs.debian.org/913853
+Bug-Ubuntu: https://launchpad.net/bugs/1803628
+Last-Update: 2018-11-01
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/make/build.xml
 b/make/build.xml
+@@ -172,7 +172,7 @@
+ 
+ 
+ 
+-

Bug#910773: clojure1.8: clojure fails to run with openjdk-11

[Tiago Daitx]

Please consider the attached debdiff which basically applies the
upstream fix and adds a dep3 header to it.
diff -Nru clojure1.8-1.8.0/debian/changelog clojure1.8-1.8.0/debian/changelog
--- clojure1.8-1.8.0/debian/changelog	2018-08-04 17:56:45.0 -0300
+++ clojure1.8-1.8.0/debian/changelog	2018-10-10 13:47:36.0 -0300
@@ -1,3 +1,11 @@
+clojure1.8 (1.8.0-8) cosmic; urgency=medium
+
+  * debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch:
+Add hint type to toArray method to resolve ambiguity introduced by
+JDK 11. (Closes: #910773, LP: #1796985).
+
+ -- Tiago Stürmer Daitx   Wed, 11 Oct 2018 02:12:55 +
+
 clojure1.8 (1.8.0-7) unstable; urgency=medium
 
   * Update Vcs-* links to point to the clojure-team repo.
diff -Nru clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch
--- clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch	1969-12-31 21:00:00.0 -0300
+++ clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch	2018-10-10 13:45:50.0 -0300
@@ -0,0 +1,37 @@
+Description: Add hint to overloaded toArray method
+ OpenJDK 11 added a new overload to the toArray method that
+ causes a slight API breakage. This requires calls to toArray
+ to set a type hint in order to prevent the exception
+ java.lang.IllegalArgumentException.
+Origin: https://github.com/clojure/clojure/commit/68d8b83138437c18f1d5cf9ba46c056aa2701d23
+Bug: https://dev.clojure.org/jira/browse/CLJ-2374
+Bug-Ubuntu: https://launchpad.net/bugs/1796985
+Applied-Upstream: https://github.com/clojure/clojure/commit/68d8b83138437c18f1d5cf9ba46c056aa2701d23
+Last-Update: 2018-10-10
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 68d8b83138437c18f1d5cf9ba46c056aa2701d23 Mon Sep 17 00:00:00 2001
+From: Alex Miller 
+Date: Mon, 1 Oct 2018 09:29:37 -0500
+Subject: [PATCH] CLJ-2374 Add type hint to toArray to resolve ambiguity in JDK
+ 11
+
+Signed-off-by: Stuart Halloway 
+---
+ src/clj/clojure/gvec.clj | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/clj/clojure/gvec.clj b/src/clj/clojure/gvec.clj
+index 3c4007379..6208f5539 100644
+--- a/src/clj/clojure/gvec.clj
 b/src/clj/clojure/gvec.clj
+@@ -397,7 +397,7 @@
+   (containsAll [this c] (every? #(.contains this %) c))
+   (isEmpty [_] (zero? cnt))
+   (toArray [this] (into-array Object this))
+-  (toArray [this arr]
++  (^objects toArray [this ^objects arr]
+ (if (>= (count arr) cnt)
+   (do
+ (dotimes [i cnt]
diff -Nru clojure1.8-1.8.0/debian/patches/series clojure1.8-1.8.0/debian/patches/series
--- clojure1.8-1.8.0/debian/patches/series	2018-03-19 16:31:31.0 -0300
+++ clojure1.8-1.8.0/debian/patches/series	2018-10-10 13:46:55.0 -0300
@@ -1 +1,2 @@
 02-modify-cli-usage.patch
+03-add-toarray-hint-type-68d8b83138437c18.patch

Bug#910246: [ebo...@apache.org: Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro]

[Tiago Daitx]

On Wed, Oct 3, 2018 at 11:57 PM Bruno Haible  wrote:
> Then, please apply the 2 patches from September 2018:
>
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=bd09403f71a792b4e5c482c7ebb29d26c129dbe6
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=0782fa4dc036a709d5501a8712c5331489c28be9

I just saw this now, so someone might want to review/rework my patch
in light of that. It's late and I will only review this tomorrow, but
on a quick look they had a better and shorter conftest/conftestfail
implementation. I also didn't add any support for openjdk 12+.

cheers!

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro

[Tiago Daitx]

I updated the existing debian/patches/06-java9-support.patch to
include support for openjdk 11, please see the attached debdiff.
On Wed, Oct 3, 2018 at 9:45 PM Emmanuel Bourg  wrote:
>
> Package: gettext
> Version: 0.19.8.1-7
> Severity: important
> Tags: sid buster
> User: debian-j...@lists.debian.org
> Usertags: default-java11
>
> gettext fails to build with Java 11 because the configuration script
> doesn't recognize the new version. During the build the following warning
> can be seen:
>
>   configure: WARNING: unknown target-version 11, please update gt_JAVACOMP 
> macro
>   checking for Java compiler... no
>
> The build later fails with:
>
>   rm -f debian/gettext/usr/share/gettext/libintl.jar
>   mv debian/gettext/usr/share/gettext/gettext.jar 
> debian/gettext/usr/share/java
>   mv: cannot stat 'debian/gettext/usr/share/gettext/gettext.jar': No such 
> file or directory
>   make[1]: *** [debian/rules:139: gettext] Error 1
>


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gettext-0.19.8.1/debian/changelog gettext-0.19.8.1/debian/changelog
--- gettext-0.19.8.1/debian/changelog	2018-08-12 21:00:10.0 +0100
+++ gettext-0.19.8.1/debian/changelog	2018-10-04 00:10:11.0 +0100
@@ -1,3 +1,10 @@
+gettext (0.19.8.1-8) UNRELEASED; urgency=medium
+
+  * debian/patches/06-java9-support.patch: update to support
+openjdk 11. Closes: #910246.
+
+ -- Tiago Stürmer Daitx   Wed, 03 Oct 2018 23:10:11 +
+
 gettext (0.19.8.1-7) unstable; urgency=medium
 
   * Use dh_autoreconf to regenerate autoconf stuff. New automake
diff -Nru gettext-0.19.8.1/debian/patches/06-java9-support.patch gettext-0.19.8.1/debian/patches/06-java9-support.patch
--- gettext-0.19.8.1/debian/patches/06-java9-support.patch	2018-08-12 20:06:00.0 +0100
+++ gettext-0.19.8.1/debian/patches/06-java9-support.patch	2018-10-04 00:10:11.0 +0100
@@ -29,7 +29,7 @@
  dnl Copyright (C) 2001-2003, 2006-2007, 2009-2016 Free Software Foundation,
  dnl Inc.
  dnl This file is free software; the Free Software Foundation
-@@ -15,7 +15,14 @@
+@@ -15,7 +15,15 @@
  #   1.3 inner classes
  #   1.4 assert keyword
  #   1.5 generic classes and methods
@@ -39,13 +39,14 @@
 +#   1.8 lambdas
 +#   9   private interface methods
 +#  10   type inference for local variables
++#  11   type inference for lambda parameters
 +# Instead of source-version 1.6, use 1.5, since Java 6 did not introduce any
 +# language changes. See
 +# http://docs.oracle.com/javase/8/docs/technotes/guides/language/enhancements.html
  #
  # target-version can be:  classfile version:
  #   1.1 45.3
-@@ -24,6 +31,10 @@
+@@ -24,6 +31,11 @@
  #   1.4 48.0
  #   1.5 49.0
  #   1.6 50.0
@@ -53,10 +54,11 @@
 +#   1.8 52.0
 +#   9   53.0
 +#  10   54.0
++#  11   55.0
  # The classfile version of a .class file can be determined through the "file"
  # command. More portably, the classfile major version can be determined through
  # "od -A n -t d1 -j 7 -N 1 classfile".
-@@ -33,12 +44,18 @@
+@@ -33,12 +44,19 @@
  #   1.1 JDK 1.1, jview
  #   1.2 JDK/JRE 1.2
  #   1.3 JDK/JRE 1.3, gij 3.3, 3.4
@@ -70,6 +72,7 @@
 +#   1.8 JDK/JRE 8
 +#   9   JDK/JRE 9
 +#  10   JDK/JRE 10
++#  11   JDK/JRE 11
  # Note: gij >= 3.3 can in some cases handle classes compiled with -target 1.4,
  # and gij >= 4.1 can in some cases partially handle classes compiled with
 -# -target 1.5, but I have no idea how complete this support is.
@@ -79,7 +82,7 @@
  #
  # Specifying target-version is useful when building a library (.jar) that is
  # useful outside the given package. Omitting target-version is useful when
-@@ -47,14 +64,20 @@
+@@ -47,14 +64,21 @@
  # It is unreasonable to ask for:
  #   - target-version < 1.4 with source-version >= 1.4, or
  #   - target-version < 1.5 with source-version >= 1.5, or
@@ -90,6 +93,7 @@
 +#   - target_version < 1.8 with source_version >= 1.8, or
 +#   - target_version < 9 with source_version >= 9, or
 +#   - target_version < 10 with source_version >= 10,
++#   - target_version < 11 with source_version >= 11,
 +# because even Sun's/Oracle's javac doesn't support these combinations.
  #
  # It is redundant to ask for a target-version > source-version, since the
@@ -110,11 +114,11 @@
 }`
 case "$target_version" in
 - 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6) ;;
-+ 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 | 1.7 | 1.8 | 9 | 10) ;;
++ 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 

Bug#910098: groovy: improve doc linking and add missing dependencies

[Tiago Daitx]

Please consider this patch and disregard the old one.

I have dropped the ignore rule - it does not even use the
debian/docs.gradle file - and replaced the default-jdk-doc/api with
default-jdk/api as previously discussed in bug #896439 (ie. do not use
the -doc paths according to Debian Policy 3.9.7).
On Tue, Oct 2, 2018 at 6:41 PM Tiago Daitx  wrote:
>
> Please consider the attached patch.
>
> It includes one additional "fix" from the Ubuntu delta to get
> groovydoc to ignore a file which was causing groovydoc to output a NUL
> char to stdout, that in turn caused the archive builders to fail -
> something about the python script giving up due to the output. I
> believe the debian builders are not affected, but in case you see any
> value on it, please use it. And if you really don't care about this
> patch let me know and I will send another debdiff without it.
>
> Note: for the Ubuntu side we have discussed cleaning up the output
> from sbuild, it's on my todo list, I consider the exclude list to be a
> temporary fix.



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru groovy-2.4.15/debian/changelog groovy-2.4.15/debian/changelog
--- groovy-2.4.15/debian/changelog	2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/changelog	2018-09-27 18:46:07.0 +0100
@@ -1,3 +1,14 @@
+groovy (2.4.15-4) cosmic; urgency=medium
+
+  * Replace HTTP URLs with local files: (Closes: #910098)
+- debian/control: build depends on -doc packages so javadoc can
+  properly link the apis.
+- debian/patches/10_fix_javadoc_links.patch: include javadoc apis
+  locally, since openjdk 10 any invalid, unreacheable, or
+  nonexistent doc link causes the build to fail.
+
+ -- Tiago Stürmer Daitx   Mon, 24 Sep 2018 12:19:05 +
+
 groovy (2.4.15-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru groovy-2.4.15/debian/control groovy-2.4.15/debian/control
--- groovy-2.4.15/debian/control	2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/control	2018-09-24 13:33:43.0 +0100
@@ -1,6 +1,7 @@
 Uploaders: Felix Natter 
 Build-Depends:
  ant,
+ ant-doc,
  ant-optional,
  antlr,
  bnd (>= 2.1.0),
@@ -14,6 +16,7 @@
  gradle-debian-helper,
  ivy,
  junit4,
+ junit4-doc,
  libasm-java (>= 6.0~alpha-2~),
  libbsf-java,
  libcommons-cli-java,
@@ -24,6 +27,7 @@
  libjline2-java,
  libqdox-java,
  libservlet3.1-java,
+ libservlet3.1-java-doc,
  libxstream-java,
  locales-all | language-pack-en,
  maven-repo-helper,
@@ -75,7 +79,7 @@
 Section: doc
 Architecture: all
 Depends: ${misc:Depends}
-Recommends: default-jdk-doc
+Recommends: default-jdk-doc, juni4-doc, libservlet3.1-java-doc
 Suggests: groovy
 Description: Agile dynamic language for the Java Virtual Machine (documentation)
  Groovy is an agile dynamic language for the JVM combining lots of great
diff -Nru groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch
--- groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch	2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch	2018-09-24 13:32:01.0 +0100
@@ -3,18 +3,20 @@
 Forwarded: not-needed
 --- a/gradle/docs.gradle
 +++ b/gradle/docs.gradle
-@@ -33,9 +33,7 @@
+@@ -33,9 +33,9 @@ def javadocSpec = {
  overview = rootProject.file('src/main/overviewj.html')
  footer = doc.footer
  source = rootProject.useIndy()?'1.7':'1.6'
 -links('http://docs.oracle.com/javase/8/docs/api/', 'http://docs.oracle.com/javaee/7/api/',
 -'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'http://junit.org/junit4/javadoc/latest/',
 -'http://docs.oracle.com/javaee/6/api/', 'http://www.antlr2.org/javadoc/')
-+links('file:/usr/share/doc/default-jre/api/')
++links('file:///usr/share/doc/ant/api/', 'file:///usr/share/doc/default-jdk/api/',
++  'file:///usr/share/doc/libservlet3.1-java-doc/api',
++  'file:///usr/share/doc/junit4/api/')
  }
  }
  
-@@ -53,12 +51,7 @@
+@@ -53,12 +53,10 @@ def groovydocSpec = {
  overviewText = resources.text.fromFile(rootProject.file('src/main/overview.html'))
  }
  includePrivate = false
@@ -24,7 +26,10 @@
 -link 'http://junit.org/junit4/javadoc/latest/', 'org.junit.', 'junit.'
 -link 'http://www.antlr2.org/javadoc/', 'antlr.'
 -link 'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'org.apache.commons.cli.'
-+link 'file:/usr/share/doc/default-jre/api/', 'java.', 'org.xml.', 'javax.', 'org.w3c.'
++link 'file:///usr/share/doc/libservlet3.1-java-doc/api', 'javax.servlet.', 'javax.management.'
++link 'file:///usr/share/doc/default-jdk/api/', 'java.', 'org.xml.', 'jav

Bug#910098: groovy: improve doc linking and add missing dependencies

[Tiago Daitx]

Please consider the attached patch.

It includes one additional "fix" from the Ubuntu delta to get
groovydoc to ignore a file which was causing groovydoc to output a NUL
char to stdout, that in turn caused the archive builders to fail -
something about the python script giving up due to the output. I
believe the debian builders are not affected, but in case you see any
value on it, please use it. And if you really don't care about this
patch let me know and I will send another debdiff without it.

Note: for the Ubuntu side we have discussed cleaning up the output
from sbuild, it's on my todo list, I consider the exclude list to be a
temporary fix.
diff -Nru groovy-2.4.15/debian/changelog groovy-2.4.15/debian/changelog
--- groovy-2.4.15/debian/changelog	2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/changelog	2018-09-27 18:46:07.0 +0100
@@ -1,3 +1,18 @@
+groovy (2.4.15-4) cosmic; urgency=medium
+
+  * Replace HTTP URLs with local files: (Closes: #910098)
+- debian/control: build depends on -doc packages so javadoc can
+  properly link the apis.
+- debian/patches/10_fix_javadoc_links.patch: include javadoc apis
+  locally, since openjdk 10 any invalid, unreacheable, or
+  nonexistent doc link causes the build to fail.
+  * debian/patches/11_exclude_groovydoc.patch: exclude file
+org/codehaus/groovy/runtime/EncodingGroovyMethodsSupport.java from
+groovydoc because groovydoc complains about a NUL char and throws
+it to the build log, this causes the archive builders to fail.
+
+ -- Tiago Stürmer Daitx   Mon, 24 Sep 2018 12:19:05 +
+
 groovy (2.4.15-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru groovy-2.4.15/debian/control groovy-2.4.15/debian/control
--- groovy-2.4.15/debian/control	2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/control	2018-09-24 13:33:43.0 +0100
@@ -1,6 +1,7 @@
 Uploaders: Felix Natter 
 Build-Depends:
  ant,
+ ant-doc,
  ant-optional,
  antlr,
  bnd (>= 2.1.0),
@@ -14,6 +16,7 @@
  gradle-debian-helper,
  ivy,
  junit4,
+ junit4-doc,
  libasm-java (>= 6.0~alpha-2~),
  libbsf-java,
  libcommons-cli-java,
@@ -24,6 +27,7 @@
  libjline2-java,
  libqdox-java,
  libservlet3.1-java,
+ libservlet3.1-java-doc,
  libxstream-java,
  locales-all | language-pack-en,
  maven-repo-helper,
@@ -75,7 +79,7 @@
 Section: doc
 Architecture: all
 Depends: ${misc:Depends}
-Recommends: default-jdk-doc
+Recommends: default-jdk-doc, juni4-doc, libservlet3.1-java-doc
 Suggests: groovy
 Description: Agile dynamic language for the Java Virtual Machine (documentation)
  Groovy is an agile dynamic language for the JVM combining lots of great
diff -Nru groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch
--- groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch	2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch	2018-09-24 13:32:01.0 +0100
@@ -3,18 +3,20 @@
 Forwarded: not-needed
 --- a/gradle/docs.gradle
 +++ b/gradle/docs.gradle
-@@ -33,9 +33,7 @@
+@@ -33,9 +33,9 @@ def javadocSpec = {
  overview = rootProject.file('src/main/overviewj.html')
  footer = doc.footer
  source = rootProject.useIndy()?'1.7':'1.6'
 -links('http://docs.oracle.com/javase/8/docs/api/', 'http://docs.oracle.com/javaee/7/api/',
 -'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'http://junit.org/junit4/javadoc/latest/',
 -'http://docs.oracle.com/javaee/6/api/', 'http://www.antlr2.org/javadoc/')
-+links('file:/usr/share/doc/default-jre/api/')
++links('file:///usr/share/doc/ant/api/', 'file:///usr/share/doc/default-jdk-doc/api/',
++  'file:///usr/share/doc/libservlet3.1-java-doc/api',
++  'file:///usr/share/doc/junit4/api/')
  }
  }
  
-@@ -53,12 +51,7 @@
+@@ -53,12 +53,10 @@ def groovydocSpec = {
  overviewText = resources.text.fromFile(rootProject.file('src/main/overview.html'))
  }
  includePrivate = false
@@ -24,7 +26,10 @@
 -link 'http://junit.org/junit4/javadoc/latest/', 'org.junit.', 'junit.'
 -link 'http://www.antlr2.org/javadoc/', 'antlr.'
 -link 'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'org.apache.commons.cli.'
-+link 'file:/usr/share/doc/default-jre/api/', 'java.', 'org.xml.', 'javax.', 'org.w3c.'
++link 'file:///usr/share/doc/libservlet3.1-java-doc/api', 'javax.servlet.', 'javax.management.'
++link 'file:///usr/share/doc/default-jdk-doc/api/', 'java.', 'org.xml.', 'javax.', 'org.w3c.'
++link 'file:///usr/share/doc/ant/api/', 'org.apache.tools.ant.'
++link 'file:///usr/share/doc/junit4/api/', 'org.junit.'
  }
  
  allprojects {
diff -Nru groovy-2.4.15/debian/patches/11_exclude_groovydoc.patch groovy-2.4.15/debian/patches/11_exclude_groovydoc.patch
--- 

Bug#910093: maven-compiler-plugin: tests fail due to hardcoded junit jar path and missing JAVA_HOME

[Tiago Daitx]

Please consider the attached patch.
diff -Nru maven-compiler-plugin-3.8.0/debian/changelog maven-compiler-plugin-3.8.0/debian/changelog
--- maven-compiler-plugin-3.8.0/debian/changelog	2018-07-30 09:26:41.0 +0200
+++ maven-compiler-plugin-3.8.0/debian/changelog	2018-09-21 14:45:48.0 +0200
@@ -1,3 +1,12 @@
+maven-compiler-plugin (3.8.0-2) UNRELEASED; urgency=low
+
+  * Fix tests: (Closes: #910093)
+- debian/rules: set JAVA_HOME to prevent compiler test failure.
+- debian/patches/01-fix-wrong-junit-path.patch: patch wrong junit path in
+  compiler test.
+
+ -- Tiago Stürmer Daitx   Fri, 21 Sep 2018 12:45:48 +
+
 maven-compiler-plugin (3.8.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch
--- maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch	1970-01-01 01:00:00.0 +0100
+++ maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch	2017-09-08 20:32:01.0 +0200
@@ -0,0 +1,21 @@
+Description: Fix wrong junit patch in Compiler test.
+ The compiler testcase sets an absolute path to junit's jar file
+ version 3.8.1 even though the pom.xml file now depends on 4.12
+ (4.x on Debian).
+ .
+ This patch fixes it and set the fixed path to a current junit jar
+ file.
+Author: Tiago Stürmer Daitx 
+Last-Update: 2017-09-08
+
+--- maven-compiler-plugin-3.6.2.orig/src/test/java/org/apache/maven/plugin/compiler/CompilerMojoTestCase.java
 maven-compiler-plugin-3.6.2/src/test/java/org/apache/maven/plugin/compiler/CompilerMojoTestCase.java
+@@ -397,7 +397,7 @@ public class CompilerMojoTestCase
+ String localRepository = System.getProperty( "localRepository" );
+ if ( localRepository != null )
+ {
+-artifactFile = new File( localRepository, "junit/junit/3.8.1/junit-3.8.1.jar" );
++artifactFile = new File( localRepository, "junit/junit/4.x/junit-4.x.jar" );
+ }
+ else
+ {
diff -Nru maven-compiler-plugin-3.8.0/debian/patches/series maven-compiler-plugin-3.8.0/debian/patches/series
--- maven-compiler-plugin-3.8.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ maven-compiler-plugin-3.8.0/debian/patches/series	2017-09-08 20:32:01.0 +0200
@@ -0,0 +1 @@
+01-fix-wrong-junit-path.patch
diff -Nru maven-compiler-plugin-3.8.0/debian/rules maven-compiler-plugin-3.8.0/debian/rules
--- maven-compiler-plugin-3.8.0/debian/rules	2018-07-30 01:26:57.0 +0200
+++ maven-compiler-plugin-3.8.0/debian/rules	2018-07-30 18:57:55.0 +0200
@@ -1,4 +1,5 @@
 #!/usr/bin/make -f
+export JAVA_HOME=/usr/lib/jvm/default-java
 
 %:
 	dh $@

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[Tiago Daitx]

Updated patch to include the missing DEP-3 headers and to remove the test files.
On Mon, Oct 1, 2018 at 9:52 PM Tiago Daitx  wrote:
>
> I have updated the patch to include 3 additional commits from
> upstream, this fixes the build with openjdk-11 and stops gradle from
> FTBFS.
>
> The last applied patch [1], which actually gets rid of the
> "NoSuchMethodError: sun.misc.Unsafe.defineClass" error, required me to
> remove the kotlin classes and then put the new classes under
> subprojets/base-services/ instead of subprojects/base-services-java9/
> in order to get them to compile - the logic of handling the
> subprojects has been moved to kotlin and I didn't check if there was a
> way to get it working with separated directories under gradle's 4.4
> build structure.
>
> For now I kept the openjdk-11 version check patch as it was
> originally, having the full JEP-223 might actually be a good thing - I
> will let the decision to someone who understands gradle better than I
> do.
>
> Of course, always bootstrap with openjdk-10 first, after that the
> generated binaries are good enough to get it to build with openjdk-11.
>
> [1] 
> debian/patches/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.patch
>
> On Mon, Oct 1, 2018 at 8:39 PM Emmanuel Bourg  wrote:
> >
> > Le 01/10/2018 à 19:37, shirish शिरीष a écrit :
> >
> > > So are we going to have gradle 4.8 in either experimental or unstable 
> > > soonish.
> >
> > Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and
> > we are nowhere near having Kotlin in Debian. It's more likely we'll
> > instead patch Gradle 4.4 and fix the Java 11 incompatibilities.
> >
> >
> > > I'm sure you may have read the freeze time-table which was shared few 
> > > days ago.
> > >
> > > It would be nice to have all the components in debian tested etc. well
> > > before freeze.
> >
> > Sure but this won't happen magically, we need more contributors.
> >
> > Emmanuel Bourg
> >
>
>
> --
> Tiago Stürmer Daitx
> Software Engineer
> tiago.da...@canonical.com
>
> PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
> Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog
--- gradle-4.4/debian/changelog	2018-10-01 14:12:33.0 +0100
+++ gradle-4.4/debian/changelog	2018-10-01 20:05:23.0 +0100
@@ -1,3 +1,17 @@
+gradle (4.4-4) UNRELEASED; urgency=medium
+
+  * Enable support for openjdk-11 (Closes: #909905)
+- debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch:
+  enable support for openjdk-11.
+- d/p/use-lookup-to-invoke-defineclass-java-9-028548460bd929fd.patch:
+  Use Lookup to invoke defineClass on Java 9+.
+- d/p/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch:
+  Don't use ClassLoader.getDefinedPackages() on Java 9.
+- d/p/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.path:
+  Use Lookup instead of reflection on Java 9+.
+
+ -- Tiago Stürmer Daitx   Mon, 01 Oct 2018 21:12:00 +
+
 gradle (4.4-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch
--- gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	2018-10-01 20:05:23.0 +0100
@@ -0,0 +1,149 @@
+Description: Don't use ClassLoader.getDefinedPackages() on Java 9
+ Prior to this change, FilteringClassLoader invokes
+ ClassLoader.getSystemClassLoader().getParent().getDefinedPackages()
+ to get all system packages on Java 9, which is not correct.
+ ClassLoader.getDefinedPackages() only fetches packages defined by
+ the ClassLoader itself, not including its parent's. The consequence is,
+ on Java 9, most Java SE and JDK packages (e.g. java.lang) are not included in
+ FilteringClassLoader.SYSTEM_PACKAGES.
+ 
+ This PR fixes this problem by using ClassLoader.getPackages() all the time.
+Origin: upstream, https://github.com/gradle/gradle/commit/50eababaa25230abc73899eda768dd0646ddcdb4
+Bug: https://github.com/gradle/gradle/pull/5477
+Bug-Debian: https://bugs.debian.org/909905
+Forwarded: not-needed
+Applied-Upstream: 50eababaa25230abc73899eda768dd0646ddcdb4
+Last-Update: 2018-10-01
+---
+This patch 

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[Tiago Daitx]

I have updated the patch to include 3 additional commits from
upstream, this fixes the build with openjdk-11 and stops gradle from
FTBFS.

The last applied patch [1], which actually gets rid of the
"NoSuchMethodError: sun.misc.Unsafe.defineClass" error, required me to
remove the kotlin classes and then put the new classes under
subprojets/base-services/ instead of subprojects/base-services-java9/
in order to get them to compile - the logic of handling the
subprojects has been moved to kotlin and I didn't check if there was a
way to get it working with separated directories under gradle's 4.4
build structure.

For now I kept the openjdk-11 version check patch as it was
originally, having the full JEP-223 might actually be a good thing - I
will let the decision to someone who understands gradle better than I
do.

Of course, always bootstrap with openjdk-10 first, after that the
generated binaries are good enough to get it to build with openjdk-11.

[1] 
debian/patches/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.patch

On Mon, Oct 1, 2018 at 8:39 PM Emmanuel Bourg  wrote:
>
> Le 01/10/2018 à 19:37, shirish शिरीष a écrit :
>
> > So are we going to have gradle 4.8 in either experimental or unstable 
> > soonish.
>
> Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and
> we are nowhere near having Kotlin in Debian. It's more likely we'll
> instead patch Gradle 4.4 and fix the Java 11 incompatibilities.
>
>
> > I'm sure you may have read the freeze time-table which was shared few days 
> > ago.
> >
> > It would be nice to have all the components in debian tested etc. well
> > before freeze.
>
> Sure but this won't happen magically, we need more contributors.
>
> Emmanuel Bourg
>


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog
--- gradle-4.4/debian/changelog	2018-10-01 14:12:33.0 +0100
+++ gradle-4.4/debian/changelog	2018-10-01 20:05:23.0 +0100
@@ -1,3 +1,17 @@
+gradle (4.4-4) UNRELEASED; urgency=medium
+
+  * Enable support for openjdk-11 (Closes: #909905)
+- debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch:
+  enable support for openjdk-11.
+- d/p/use-lookup-to-invoke-defineclass-java-9-028548460bd929fd.patch:
+  Use Lookup to invoke defineClass on Java 9+.
+- d/p/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch:
+  Don't use ClassLoader.getDefinedPackages() on Java 9.
+- d/p/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.path:
+  Use Lookup instead of reflection on Java 9+.
+
+ -- Tiago Stürmer Daitx   Mon, 01 Oct 2018 19:05:23 +
+
 gradle (4.4-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch
--- gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	2018-09-29 21:25:43.0 +0100
@@ -0,0 +1,130 @@
+From 50eababaa25230abc73899eda768dd0646ddcdb4 Mon Sep 17 00:00:00 2001
+From: Bo Zhang 
+Date: Wed, 23 May 2018 16:24:05 +0800
+Subject: [PATCH] Don't use ClassLoader.getDefinedPackages() on Java 9 (#5477)
+
+Prior to this change, FilteringClassLoader invokes
+ClassLoader.getSystemClassLoader().getParent().getDefinedPackages()
+to get all system packages on Java 9, which is not correct.
+ClassLoader.getDefinedPackages() only fetches packages defined by
+the ClassLoader itself, not including its parent's. The consequence is,
+on Java 9, most Java SE and JDK packages (e.g. java.lang) are not included in
+FilteringClassLoader.SYSTEM_PACKAGES.
+
+This PR fixes this problem by using ClassLoader.getPackages() all the time.
+---
+ .../classloader/ClassLoaderUtils.java |  4 ++--
+ .../classloader/FilteringClassLoader.java | 22 +--
+ .../FilteringClassLoaderTest.groovy   |  6 +
+ .../fixtures/executer/LogContent.java |  2 +-
+ ...ConsoleJvmTestLoggingFunctionalTest.groovy |  3 ++-
+ 5 files changed, 17 insertions(+), 20 deletions(-)
+
+diff --git a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java b/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
+index 3995ad38be55..cdd68af5f905 100644
+--- a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
 b/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
+@@ -39,7 +39,8 @@
+ 
+ static {
+ CLASS_DEFINER = 

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[Tiago Daitx]

Please consider the attached patch which applies the upstream patch [1].

References:
[1] 
https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782
On Sat, Sep 29, 2018 at 8:33 PM Tiago Stürmer Daitx
 wrote:
>
> Package: gradle
> Version: 4.4-2
> Severity: normal
>
> Dear Maintainer,
>
> gradle 4.4-2 currently FTBFS when build with openjdk-11.
>
> * Exception is:
> java.lang.IllegalArgumentException: Could not determine java version from 
> '11'.
> at org.gradle.api.JavaVersion.toVersion(JavaVersion.java:72)
> at org.gradle.api.JavaVersion.current(JavaVersion.java:82)
> at 
> org.gradle.internal.jvm.UnsupportedJavaRuntimeException.assertUsingVersion(UnsupportedJavaRuntimeException.java:42)
> at 
> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:32)
> at 
> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
> at 
> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
> at 
> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
> at 
> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:257)
> at 
> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:191)
> at org.gradle.launcher.Main.doAction(Main.java:33)
> at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
> at 
> org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
> at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
>
> it needs either to be updated to 4.7 or have the upstream patch [1]
> applied.
>
> References:
> [1] 
> https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782#diff-1992c69962eb418e832c020dd61b2f1b.diff
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers cosmic
>   APT policy: (500, 'cosmic'), (400, 'cosmic-proposed')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog
--- gradle-4.4/debian/changelog	2018-09-17 10:15:05.0 +0100
+++ gradle-4.4/debian/changelog	2018-09-29 18:50:56.0 +0100
@@ -1,3 +1,10 @@
+gradle (4.4-3) UNRELEASED; urgency=medium
+
+  * debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch: enable
+support for openjdk-11. (Closes: #909905)
+
+ -- Tiago Stürmer Daitx   Sat, 29 Sep 2018 17:50:56 +
+
 gradle (4.4-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch
--- gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch	2018-09-29 18:50:56.0 +0100
@@ -0,0 +1,560 @@
+Description: make JavaVersion support JDK 11 and JEP-223
+ Add JavaVersion.VERSION_11 and support JEP223
+Origin: upstream, https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782
+Bug-Debian: http://bugs.debian.org/909905
+Forwarded: not-needed
+Applied-Upstream: ac15612d41b43c39c8e39d12fdd6621589b0f782
+Last-Update: 2018-09-29
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From ac15612d41b43c39c8e39d12fdd6621589b0f782 Mon Sep 17 00:00:00 2001
+From: Bo Zhang 
+Date: Wed, 21 Mar 2018 16:08:44 +0800
+Subject: [PATCH] Make JavaVersion support JDK 11 and JEP-223 (#4759)
+
+Add JavaVersion.VERSION_11 and support JEP223
+---
+ .../main/java/org/gradle/api/JavaVersion.java | 123 ++
+ .../org/gradle/api/JavaVersionSpec.groovy | 212 --
+ .../changes/accepted-public-api-changes.json  |  20 ++
+ .../cli/BuildActionsFactoryTest.groovy|   8 +-
+ 4 files changed, 199 insertions(+), 164 deletions(-)
+
+--- 

Bug#906411:

[Tiago Daitx]

The underlying cause seems to be a fix in maven-shared-utils 3.2,
which was uploaded recently. The fix MSHARED-610 [1] seems to have
exposed IOException that were previously being ignored, so surefire
now needs to be updated to handle those.

I have opened a bug report upstream (SUREFIRE-1558 [2]) to let them
know about it.

References:
[1] https://issues.apache.org/jira/browse/MSHARED-610
[2] https://issues.apache.org/jira/browse/SUREFIRE-1558

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#905675: testng missing dependency on guava causes tests to fails

[Tiago Daitx]

Dear maintainer,

Please consider the following patch which applies the PR 1096 [1] change.

thanks
On Tue, Aug 7, 2018 at 8:09 PM Tiago Stürmer Daitx
 wrote:
>
> Package: testng
> Version: 6.9.12-3
> Severity: normal
>
> Dear Maintainer,
>
> While running OpenJDK 10 tests I noticed that quite a few tests that
> depend on testng fail due to a missing guava class.
>
> The package libguava-java has the class but it is not declared as a
> dependency.
>
> The bug has been reported upstream back in 2016 [1] and fixed a few days
> after that [2]. The guava class import was replaced with a new internal
> class [3].
>
> testng should be updated to a newer version or that particular patch [3]
> should be applied to the existing package.
>
> References:
> [1] https://github.com/cbeust/testng/issues/1085
> [2] https://github.com/cbeust/testng/pull/1086
> [3] 
> https://github.com/cbeust/testng/pull/1086/commits/deeb5847282ae3b5b185c046a8146814bf98b124
>
>
> Error output example:
>
> java.lang.NoClassDefFoundError: com/google/common/primitives/Ints
> at 
> org.testng.internal.annotations.JDK15TagFactory.createDataProviderTag(JDK15TagFactory.java:335)
> at 
> org.testng.internal.annotations.JDK15TagFactory.createTag(JDK15TagFactory.java:59)
> at 
> org.testng.internal.annotations.JDK15AnnotationFinder.findAnnotation(JDK15AnnotationFinder.java:217)
> at 
> org.testng.internal.annotations.JDK15AnnotationFinder.findAnnotation(JDK15AnnotationFinder.java:111)
> at 
> org.testng.internal.Parameters.findDataProvider(Parameters.java:326)
> at 
> org.testng.internal.Parameters.findDataProvider(Parameters.java:261)
> at 
> org.testng.internal.Parameters.handleParameters(Parameters.java:418)
> at org.testng.internal.Invoker.handleParameters(Invoker.java:1240)
> at org.testng.internal.Invoker.createParameters(Invoker.java:980)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1070)
> at 
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.
>
> Regards,
> Tiago Daitx
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers cosmic
>   APT policy: (500, 'cosmic'), (400, 'cosmic-proposed')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-23-generic (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages testng depends on:
> ii  libbsh-java 2.0b4-19
> pn  libjcommander-java  
>
> Versions of packages testng recommends:
> ii  ant 1.10.4-2
> ii  junit4  4.12-7
> pn  libyaml-snake-java  
>
> testng suggests no packages.



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru testng-6.9.12/debian/changelog testng-6.9.12/debian/changelog
--- testng-6.9.12/debian/changelog	2018-07-30 12:53:55.0 -0300
+++ testng-6.9.12/debian/changelog	2018-08-07 20:16:34.0 -0300
@@ -1,3 +1,10 @@
+testng (6.9.12-4) UNRELEASED; urgency=medium
+
+  * d/p/remove-guava-dependency-pr1086.patch: apply upstream patch to
+remove guava dependency (Closes: #905675, LP: #1785896)
+
+ -- Tiago Stürmer Daitx   Tue, 07 Aug 2018 23:16:34 +
+
 testng (6.9.12-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch
--- testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch	1969-12-31 21:00:00.0 -0300
+++ testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch	2018-08-07 20:16:34.0 -0300
@@ -0,0 +1,56 @@
+From deeb5847282ae3b5b185c046a8146814bf98b124 Mon Sep 17 00:00:00 2001
+From: Julien Herr 
+Date: Thu, 7 Jul 2016 23:04:24 +0200
+Subject: [PATCH] Fix #1085 Remove Guava dependency
+
+---
+ .../internal/annotations/JDK15TagFactory.java |  2 +-
+ .../org/testng/internal/collections/Ints.java | 19 +++
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+ create mode 100644 src/main/java/org/testng/internal/collections/Ints.java
+
+diff --git a/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java b/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java
+index 7e79166d1..7ed9cc19e 100755
+--- a/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java
 b/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java
+@@ -6,7 +6,6 @@
+ import java.util.List;
+ import java.util.Set;
+ 
+-impo

Bug#900912: Incident Report 9127367 : Java atk wrapper does not load any more

[Tiago Daitx]

On Thu, Jul 19, 2018 at 6:22 PM Samuel Thibault  wrote:
>
> Samuel Thibault, le jeu. 19 juil. 2018 23:13:26 +0200, a ecrit:
> > Samuel Thibault, le jeu. 19 juil. 2018 23:00:04 +0200, a ecrit:
> > > What I think is still missing is "to be loaded by
> > > java.util.ServiceLoader".  How is that supposed to happen?
> > >
> > > To make it work, Fridrich Strba says in
> > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-November/038927.html
> > > that he is apparently relinking jdk itself to include
> > > java-atk-wrapper.jar as a module. Are we really supposed to be doing
> > > that in Debian?  That's mean a circular dependency between openjdk
> > > and java-atk-wrapper... But otherwise, how are we supposed to make
> > > the jvm know that for that accessibility provider it should load
> > > java-atk-wrapper.jar?
> >
> > Or put another way: how are we supposed to make the
> > module contained in java-atk-wrapper.jar ("provides
> > javax.accessibility.AccessibilityProvider with
> > org.GNOME.Accessibility.AtkProvider;") visible to the JVM?  Is there a
> > directory where it looks for them?
>
> Of course there is the -p option and alike, but the goal is that it just
> works without the user having to specify anything. Or should Debian
> define a module path were the java-atk-wrapper package should put its
> module?  I'd be surprised that openjdk doesn't already define one, just
> like it used to define the ext/ directory for the older mechanism.
>
> Samuel

Hi Samuel,

Thanks for the quick work on this! I have seen the changes in the git
repo [1] and will build the package to see if I can get it to work
with openjdk like it used to with older ext mechanism - for now all
module examples I have seem need to be directly loaded with -p as you
stated.

It is just a guess at this time, but we might need to patch openjdk to
load mods from other locations so debian packages can use that. I
report back after doing some testing.

I'm still working on the openjdk security updates, so might take a
while to get my hands down on this.

Regards,
Tiago

[1] https://salsa.debian.org/a11y-team/java-atk-wrapper/commits/master

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#900912: [Openjdk] Bug#900912: openjdk-10: Accessibility does not get loaded

[Tiago Daitx]

The ATK was updated to use the new interface last year by Fridrich
Strba [1,2], but it seems that upstream never updated it to include
those patches - the bugs he reported and attached patches remain open.

Might be worth to check if we can apply these to our packages.

[1] 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-November/038927.html
[2] http://mail.openjdk.java.net/pipermail/awt-dev/2017-November/013344.html

On Mon, Jul 16, 2018 at 10:15 AM Matthias Klose  wrote:
>
> On 13.07.2018 12:39, Samuel Thibault wrote:
> > Hello,
> >
> > Matthias Klose, le ven. 13 juil. 2018 12:04:42 +0200, a ecrit:
> >> this issue now has two patches, one to install the properties file, and the
> >> other to extend the class path.  Are both needed?
> >
> > Yes.
> >
> >> Can you see any compatibility issues when the accessibility stuff
> >> isn't used?
> >
> > I didn't see any.
>
> hmm, I'm not sure. the upstream issue asks instead about
>
> """
> This is a consequence of the JPMS. ATK will need to be reimplemented as a
> Service Provider, to be
> loaded by java.util.ServiceLoader. In order to do this it must provide an SPI
> which extends
> javax.accessibility.AccessibilityProvider
> See
> https://docs.oracle.com/javase/10/docs/api/java/awt/Toolkit.html#getDefaultToolkit()
> and
> https://docs.oracle.com/javase/10/docs/api/javax/accessibility/AccessibilityProvider.html
> """
>
> ___
> Mailing list: https://launchpad.net/~openjdk
> Post to : open...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openjdk
> More help   : https://help.launchpad.net/ListHelp



--
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895274: octave and OpenJDK 10

[Tiago Daitx]

On Thu, 19 Apr 2018 18:27:44 -0700 Mike Miller  wrote:
> I posted the attached patch to the Ubuntu bug tracker. This is an
> upstream patch that enables octave configure to detect and build with
> OpenJDK 10 and 11.

Thanks for that!

> I can add this to the octave packaging repo if we expect to have a
> 4.2.2-3 source upload, and if that would be helpful for testing OpenJDK
> transitions.

> We already have 4.4 release candidates (not yet in experimental) and
> expect Octave 4.4 to be stamped in the next week or so, at which point
> the patch won't be needed.

Octave 4.4.0-1 has been uploaded to experimental. I checked debian's build
logs and it seems the build used openjdk-9, so that doesn't tell if fix is
in place.

Just a heads up in case someone else can confirm that the build actually
works with openjdk-10 and then get this closed.

thanks

Bug#896439: gradle-debian-helper points to an invalid java api directory

[Tiago Daitx]

Markus and Emmanuel,

Thanks for the replies, I got the feedback that I needed.

On Sat, Apr 21, 2018 at 3:16 PM, Markus Koschany  wrote:
>
> Am 21.04.2018 um 19:57 schrieb Emmanuel Bourg:
>> Hi Tiago,
>>
>> I don't think gradle-debian-helper should depend on default-jdk-doc by
>> default, this is a rather big dependency and it's preferable to keep it
>> optional to speed up the builds a bit. I think the packages using
>> gradle-debian-helper should instead depend on default-jdk-doc if they
>> build a javadoc package. That's what most packages building a javadoc
>> already do.

Indeed, the package size is indeed pretty big. Given that it's better
to preserve the current behavior.

>> As for changing the path to the JDK doc why not, but I don't really
>> understand the benefit. It seems both URLs are currently in use, with
>> /usr/share/doc/default-jdk-doc/api being more popular than
>> /usr/share/doc/default-jdk/api despite the longer path.
>
> By the way since Debian Policy 3.9.7 it is recommended to install
> additional documentation via -doc packages into /usr/share/doc/pkg and
> no longer /usr/share/doc/pkg-doc. This is also enforced with
> debhelper/compat >= 11. If we were consequent then we should use
> /usr/share/doc/default-jdk/api everywhere.

If that is enforced for debhelper/compat >=11 than java-common does
not seems to be following the rules. What about updating java-common
to use the /usr/share/doc/default-jdk path? If so, should we keep
links (for the existing files) in the /usr/share/doc/default-jdk-doc/
or drop that path altogether?


Thanks for the review!


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Daitx]

On Mon, Apr 30, 2018 at 9:02 AM, Emmanuel Bourg  wrote:
> Thank you fo the update. I'm attaching the revised patch since it wasn't
> sent to the bug log.

Thanks!

> I suggest also setting the -release parameter when the VM is forked.
> Since the plexus-compiler package is only used to build Debian packages
> with the default JDK there is no risk of calling a JDK that doesn't
> support the new parameter.

Right, I was not sure if that was the case - that is:
1) used only by debian builds and
2) that the default-jdk would be used for a fork.

In particular, when setting "fork" the user also has the option to set
a few other properties, such as "executable", "compilerArgs",
"compilerVersion", etc which can change the behavior quite a lot.


Do we have packages that are currently setting the fork option? I
would like to take a look at a few examples to get on overview of what
else is being set (and maybe why) before committing any changes to the
way the patch deals with a fork.

> Also no need to print the deprecation message for the source/target
> parameters, this is Debian specific and we aren't going to reconfigure
> all upstream projects ourself anyway.

Ack.


Thanks for the help and for the review.


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

[Tiago Daitx]

I just realized that the existing patch debian/patches/docs.patch was
the one modifying the javaApiUrl to point to the default-jdk api, I
updated it to point to default-jdk-doc.

Please consider the new debdiff and ignore the old one.

thanks

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/changelog	2018-04-20 19:03:01.0 -0300
@@ -1,3 +1,13 @@
+gradle (3.4.1-8) UNRELEASED; urgency=medium
+
+  * debian/patches/gnu-style-release-flag-jdk9.patch: Use GNU-style release
+flag for Java 9 compiler. (Closes: #895616)
+  * debian/patches/docs.patch: use default-jdk-doc instead of default-jdk
+path for javaApiUrl in subprojects/docs/docs.gradle. LP: #1765866.
+(Closes: #896436)
+
+ -- Tiago Stürmer Daitx   Fri, 20 Apr 2018 22:03:01 +
+
 gradle (3.4.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/docs.patch gradle-3.4.1/debian/patches/docs.patch
--- gradle-3.4.1/debian/patches/docs.patch	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/patches/docs.patch	2018-04-20 19:03:01.0 -0300
@@ -100,7 +100,7 @@
  
 -def javaApiUrl = "https://docs.oracle.com/javase/7/docs/api;
 -def groovyApiUrl = "http://docs.groovy-lang.org/docs/groovy-${versions.groovy}/html/gapi;
-+def javaApiUrl = "file:///usr/share/doc/default-jdk/api/"
++def javaApiUrl = "file:///usr/share/doc/default-jdk-doc/api/"
 +def groovyApiUrl = "file:///usr/share/doc/groovy/api/"
  def mavenApiUrl = "http://maven.apache.org/ref/${versions.maven}/maven-model/apidocs;
  
diff -Nru gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
--- gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	1969-12-31 21:00:00.0 -0300
+++ gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	2018-04-20 19:03:01.0 -0300
@@ -0,0 +1,97 @@
+Description: Use GNU-style release flag for Java 9 compiler
+ Since JDK 9 b135, only the new GNU-style option with double-dashes is
+ supported for the "--release" flag (see
+ https://bugs.openjdk.java.net/browse/JDK-8160851).
+Author: Yannick Welsch 
+Origin: upstream, https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Bug-Debian: https://bugs.debian.org/895616 
+Forwarded: not-needed
+Applied-Upstream: https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 142f2f5233e77ba33146efe3815cd3b4b1245993 Mon Sep 17 00:00:00 2001
+From: Yannick Welsch 
+Date: Mon, 17 Jul 2017 15:53:17 +0200
+Subject: [PATCH] Use GNU-style release flag for Java 9 compiler (#2474)
+
+Since JDK 9 b135, only the new GNU-style option with double-dashes is supported for the "--release" flag
+(see https://bugs.openjdk.java.net/browse/JDK-8160851).
+---
+ design-docs/jdk9-support.md | 6 +++---
+ .../api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java| 2 +-
+ .../src/main/java/org/gradle/api/tasks/compile/CompileOptions.java  | 6 +++---
+ .../internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy  | 6 +++---
+ .../org/gradle/java/compile/BasicJavaCompilerIntegrationSpec.groovy | 4 ++--
+ 5 files changed, 12 insertions(+), 12 deletions(-)
+
+
+--- a/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
 b/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
+@@ -227,7 +227,7 @@ public class JavaCompilerArgumentsBuilde
+ }
+ 
+ private boolean releaseOptionIsSet(List compilerArgs) {
+-return compilerArgs != null && compilerArgs.contains("-release");
++return compilerArgs != null && compilerArgs.contains("--release");
+ }
+ 
+ private void addClasspath() {
+--- a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
 b/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
+@@ -315,10 +315,10 @@ public class CompileOptions extends Abst
+  * Defaults to the empty list.
+  *
+  * Compiler arguments not supported by the DSL can be added here. For example, it is possible
+- * to pass the {@code -release} option of JDK 9:
+- * compilerArgs.addAll(['-release', '7'])
++ * to pass the {@code --release} option of JDK 9:
++ * compilerArgs.addAll(['--release', '7'])
+  *
+- * Note that if {@code -release} is added then 

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

[Tiago Daitx]

Please consider the attached debdiff as a fix.

Note: it includes the fix for bug #895616 as well, if that is not
wanted simply fully remove the chunk for the new file
gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
and modify the series and changelog accordingly.

thanks
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/changelog	2018-04-20 19:03:01.0 -0300
@@ -1,3 +1,13 @@
+gradle (3.4.1-8) UNRELEASED; urgency=medium
+
+  * debian/patches/gnu-style-release-flag-jdk9.patch: Use GNU-style release
+flag for Java 9 compiler. (Closes: #895616)
+  * debian/patches/use-local-artifacts.patch: use default-jdk-doc instead
+of default-jdk path for javaApiUrl in subprojects/docs/docs.gradle.
+(Closes: #896436)
+
+ -- Tiago Stürmer Daitx   Fri, 20 Apr 2018 22:03:01 +
+
 gradle (3.4.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
--- gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	1969-12-31 21:00:00.0 -0300
+++ gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	2018-04-12 18:01:22.0 -0300
@@ -0,0 +1,97 @@
+Description: Use GNU-style release flag for Java 9 compiler
+ Since JDK 9 b135, only the new GNU-style option with double-dashes is
+ supported for the "--release" flag (see
+ https://bugs.openjdk.java.net/browse/JDK-8160851).
+Author: Yannick Welsch 
+Origin: upstream, https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Bug-Debian: https://bugs.debian.org/895616 
+Forwarded: not-needed
+Applied-Upstream: https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 142f2f5233e77ba33146efe3815cd3b4b1245993 Mon Sep 17 00:00:00 2001
+From: Yannick Welsch 
+Date: Mon, 17 Jul 2017 15:53:17 +0200
+Subject: [PATCH] Use GNU-style release flag for Java 9 compiler (#2474)
+
+Since JDK 9 b135, only the new GNU-style option with double-dashes is supported for the "--release" flag
+(see https://bugs.openjdk.java.net/browse/JDK-8160851).
+---
+ design-docs/jdk9-support.md | 6 +++---
+ .../api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java| 2 +-
+ .../src/main/java/org/gradle/api/tasks/compile/CompileOptions.java  | 6 +++---
+ .../internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy  | 6 +++---
+ .../org/gradle/java/compile/BasicJavaCompilerIntegrationSpec.groovy | 4 ++--
+ 5 files changed, 12 insertions(+), 12 deletions(-)
+
+
+--- a/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
 b/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
+@@ -227,7 +227,7 @@ public class JavaCompilerArgumentsBuilde
+ }
+ 
+ private boolean releaseOptionIsSet(List compilerArgs) {
+-return compilerArgs != null && compilerArgs.contains("-release");
++return compilerArgs != null && compilerArgs.contains("--release");
+ }
+ 
+ private void addClasspath() {
+--- a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
 b/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
+@@ -315,10 +315,10 @@ public class CompileOptions extends Abst
+  * Defaults to the empty list.
+  *
+  * Compiler arguments not supported by the DSL can be added here. For example, it is possible
+- * to pass the {@code -release} option of JDK 9:
+- * compilerArgs.addAll(['-release', '7'])
++ * to pass the {@code --release} option of JDK 9:
++ * compilerArgs.addAll(['--release', '7'])
+  *
+- * Note that if {@code -release} is added then {@code -target} and {@code -source}
++ * Note that if {@code --release} is added then {@code -target} and {@code -source}
+  * are ignored.
+  */
+ @Input
+--- a/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
 b/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
+@@ -79,14 +79,14 @@ class JavaCompilerArgumentsBuilderTest e
+ builder.build() == ["-target", "1.4"] + defaultOptions
+ }
+ 
+-def "removes -source and -target option if -release is present"() {
++def "removes -source and -target option if --release is present"() {
+ when:
+-spec.compileOptions.compilerArgs += ['-release', '7']
++spec.compileOptions.compilerArgs += 

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

As per LP: #1765570 [1] I have been able to simplify the required
build steps to 3 simpler steps:

1) Apply the newly attached debdiff that includes the required patches
and overrides build/test/install targets, rebuild
2) Rebuild surefire, make sure the debian binary from step #1 is used
during build time
3) Rebuild this package without the 3 build/test/install overrides,
make sure the debian binaries from steps #1 and #2 are included during
build time

cheers!

References:
[1] https://bugs.launchpad.net/bugs/1765570
diff -Nru libcommons-lang3-java-3.5/debian/changelog libcommons-lang3-java-3.5/debian/changelog
--- libcommons-lang3-java-3.5/debian/changelog	2018-04-16 09:30:12.0 -0300
+++ libcommons-lang3-java-3.5/debian/changelog	2018-04-19 22:43:40.0 -0300
@@ -1,3 +1,16 @@
+libcommons-lang3-java (3.5-3) UNRELEASED; urgency=medium
+
+  * debian/patches/fix-openjdk-10-nullpointer-lang-1365.diff: calls to
+org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast cause
+NullPointerException when running under openjdk-10 which in turn causes
+other packages to FTBFS with the message "Execution default-cli of goal
+groupId:artifactId:version:jar failed.: NullPointerException -> [Help 1]".
+LP: #1765570. (Closes: #895234)
+  * debian/patches/fix-numeric-3-area-code-support-lang-1312.diff: pull
+upstream fix for numeric-3 area code support. (Closes: #895583)
+
+ -- Tiago Stürmer Daitx   Fri, 20 Apr 2018 01:43:40 +
+
 libcommons-lang3-java (3.5-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff
--- libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	1969-12-31 21:00:00.0 -0300
+++ libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	2018-04-19 22:43:40.0 -0300
@@ -0,0 +1,65 @@
+Description: Fix UN M.49 numeric-3 area code support.
+ LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3
+ area code. 
+Author: pascalschumacher 
+Origin: upstream, https://github.com/apache/commons-lang/pull/239
+Bug: https://issues.apache.org/jira/browse/LANG-1312
+Bug-Debian: https://bug.debian.org/895234
+Forwarded: not-needed
+Applied-Upstream: https://github.com/apache/commons-lang/commit/4bd982d1a1df87724682c17c39bf27b5cbe389be
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 4bd982d1a1df87724682c17c39bf27b5cbe389be Mon Sep 17 00:00:00 2001
+From: pascalschumacher 
+Date: Sun, 19 Feb 2017 20:39:05 +0100
+Subject: [PATCH] LANG-1312: LocaleUtils#toLocale does not support language
+ followed by UN M.49 numeric-3 area code (closes #239)
+
+---
+ src/main/java/org/apache/commons/lang3/LocaleUtils.java | 4 +++-
+ src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java | 7 +++
+ 3 files changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/src/main/java/org/apache/commons/lang3/LocaleUtils.java b/src/main/java/org/apache/commons/lang3/LocaleUtils.java
+index a3126ebf4..f13b52f38 100644
+--- a/src/main/java/org/apache/commons/lang3/LocaleUtils.java
 b/src/main/java/org/apache/commons/lang3/LocaleUtils.java
+@@ -67,6 +67,7 @@ public LocaleUtils() {
+  *   LocaleUtils.toLocale("")   = new Locale("", "")
+  *   LocaleUtils.toLocale("en") = new Locale("en", "")
+  *   LocaleUtils.toLocale("en_GB")  = new Locale("en", "GB")
++ *   LocaleUtils.toLocale("en_001") = new Locale("en", "001")
+  *   LocaleUtils.toLocale("en_GB_xxx")  = new Locale("en", "GB", "xxx")   (#)
+  * 
+  *
+@@ -134,7 +135,8 @@ public static Locale toLocale(final String str) {
+ case 1:
+ if (StringUtils.isAllLowerCase(split[0]) &&
+ (split[0].length() == 2 || split[0].length() == 3) &&
+- split[1].length() == 2 && StringUtils.isAllUpperCase(split[1])) {
++ (split[1].length() == 2 && StringUtils.isAllUpperCase(split[1])) ||
++  (split[1].length() == 3 && StringUtils.isNumeric(split[1]))) {
+ return new Locale(split[0], split[1]);
+ }
+ throw new IllegalArgumentException("Invalid locale format: " + str);
+diff --git a/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java b/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
+index 4a867bab1..79198af5b 100644
+--- a/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
 b/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
+@@ -505,6 +505,13 @@ public void testLang328() {
+ assertValidToLocale("fr__POSIX", "fr", "", "POSIX");
+ }
+ 
++   

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Daitx]

Please consider the attached debdiff for review.

On why it is important to use --release instead of the usual -source/-target:
any package that is not build with it can run into those
incompatibilities at runtime when run with an older (but targeted)
release. As a lot of libraries are being build with only
-source/-target set any package that depend on those won't run on
older (but targeted) jdk. It can also affect builds in case the
compiled tool is run during build time with the same old targeted jdk
- see bug #895234 where it was impossible to build
libcommons-lang3-java with openjdk-8 because bnd would fail. In fact,
for the affected packages (ie. use of flip()Ljava/nio/ByteBuffer),
since the build works but runtime fails the current scenario is the
same as setting -target 1.9.

This is already happening with the transition from openjdk-8 to 9 and,
although there's no such indication, it could also affect the
transition from 9/10 to 11 if they do similar changes to the JDK.

Another alternative to using --release is fixing the code that uses
the incompatible API, such as was done for gradle [1], but that does
not scale as well and it is reactive since errors are only detected
during runtime.

Regards,
Tiago

References:
[1] 
https://sources.debian.org/src/gradle/3.4.1-7/debian/patches/java8-compatibility.patch

On Fri, Apr 13, 2018 at 12:14 PM, Tiago Stürmer Daitx
<tiago.da...@canonical.com> wrote:
> Source: plexus-compiler
> Version: 2.8.2-5
> Severity: normal
>
> Dear Maintainer,
>
> plexus-compiler currently will default -source and/or -target to 1.7
> whenever the following occours:
> 1) whenever either has not being set
> 2) whenever either has been set to 1.6 or earlier
>
> This patch modifies the detection logic in order to be able to set the
> '--release' flag when (and only when):
> - the '--release' is *not* set
> - AND both -source and -target are being set to a default value
> - AND the running jvm is jdk9 or newer
>
> This prevents errors such as the infamous "Method
> flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
> that is caused by building with openjdk-9 with -source set without
> setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
> --release to prevent such issues and should be used instead of -source
> whenever the javac being used is jdk9 or higher.
>
>
> I have tested and I can confirm it works fine, but I would like some
> review to make sure it is sane and get opinions on other (better?) ways
> to do this - specially concerning the detection of the jvm being run.
>
> Also, fork and an alternative javac compiler might be set, thus I would
> like to discuss as to what behavior it should default it in that case.
>
> Regards,
> Tiago Daitx
>
> References:
> [1] https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1760359
> [2] https://github.com/plasma-umass/doppio/issues/497
> [3] http://openjdk.java.net/jeps/247
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru plexus-compiler-2.8.2/debian/changelog plexus-compiler-2.8.2/debian/changelog
--- plexus-compiler-2.8.2/debian/changelog	2017-09-18 10:31:35.0 -0300
+++ plexus-compiler-2.8.2/debian/changelog	2018-04-12 11:35:44.0 -0300
@@ -1,3 +1,10 @@
+plexus-compiler (2.8.2-6~01) UNRELEASED; urgency=medium
+
+  * Use a default --release instead of defaults -source/-target in order to
+have the right bootclasspath set as per JEP 247. (Closes: #895619)
+
+ -- Tiago Stürmer Daitx <tiago.da...@ubuntu.com>  Thu, 12 Apr 2018 14:35:44 +
+
 plexus-compiler (2.8.2-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch
--- plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch	2017-07-04 03:58:08.0 -0300
+++ plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch	2018-04-12 11:35:44.0 -0300
@@ -3,40 +3,81 @@
 Forwarded: not-needed
 --- a/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
 +++ b/plexus-compilers/plexus-compiler-javac/src/main/java/org

Bug#895616: gradle: fix support for openjdk-9 --release flag

[Tiago Daitx]

Please consider the attached debdiff for fixing this bug.

thanks

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/changelog	2018-04-12 18:01:31.0 -0300
@@ -1,3 +1,10 @@
+gradle (3.4.1-8) UNRELEASED; urgency=medium
+
+  * d/p/gnu-style-release-flag-jdk9.patch: Use GNU-style release flag for
+Java 9 compiler.
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 21:01:31 +
+
 gradle (3.4.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
--- gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	1969-12-31 21:00:00.0 -0300
+++ gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	2018-04-12 18:01:22.0 -0300
@@ -0,0 +1,97 @@
+Description: Use GNU-style release flag for Java 9 compiler
+ Since JDK 9 b135, only the new GNU-style option with double-dashes is
+ supported for the "--release" flag (see
+ https://bugs.openjdk.java.net/browse/JDK-8160851).
+Author: Yannick Welsch 
+Origin: upstream, https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Bug-Debian: https://bugs.debian.org/895616
+Forwarded: not-needed
+Applied-Upstream: https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 142f2f5233e77ba33146efe3815cd3b4b1245993 Mon Sep 17 00:00:00 2001
+From: Yannick Welsch 
+Date: Mon, 17 Jul 2017 15:53:17 +0200
+Subject: [PATCH] Use GNU-style release flag for Java 9 compiler (#2474)
+
+Since JDK 9 b135, only the new GNU-style option with double-dashes is supported for the "--release" flag
+(see https://bugs.openjdk.java.net/browse/JDK-8160851).
+---
+ design-docs/jdk9-support.md | 6 +++---
+ .../api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java| 2 +-
+ .../src/main/java/org/gradle/api/tasks/compile/CompileOptions.java  | 6 +++---
+ .../internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy  | 6 +++---
+ .../org/gradle/java/compile/BasicJavaCompilerIntegrationSpec.groovy | 4 ++--
+ 5 files changed, 12 insertions(+), 12 deletions(-)
+
+
+--- a/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
 b/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
+@@ -227,7 +227,7 @@ public class JavaCompilerArgumentsBuilde
+ }
+ 
+ private boolean releaseOptionIsSet(List compilerArgs) {
+-return compilerArgs != null && compilerArgs.contains("-release");
++return compilerArgs != null && compilerArgs.contains("--release");
+ }
+ 
+ private void addClasspath() {
+--- a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
 b/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
+@@ -315,10 +315,10 @@ public class CompileOptions extends Abst
+  * Defaults to the empty list.
+  *
+  * Compiler arguments not supported by the DSL can be added here. For example, it is possible
+- * to pass the {@code -release} option of JDK 9:
+- * compilerArgs.addAll(['-release', '7'])
++ * to pass the {@code --release} option of JDK 9:
++ * compilerArgs.addAll(['--release', '7'])
+  *
+- * Note that if {@code -release} is added then {@code -target} and {@code -source}
++ * Note that if {@code --release} is added then {@code -target} and {@code -source}
+  * are ignored.
+  */
+ @Input
+--- a/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
 b/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
+@@ -79,14 +79,14 @@ class JavaCompilerArgumentsBuilderTest e
+ builder.build() == ["-target", "1.4"] + defaultOptions
+ }
+ 
+-def "removes -source and -target option if -release is present"() {
++def "removes -source and -target option if --release is present"() {
+ when:
+-spec.compileOptions.compilerArgs += ['-release', '7']
++spec.compileOptions.compilerArgs += ['--release', '7']
+ spec.sourceCompatibility = '1.7'
+ spec.targetCompatibility = '1.7'
+ 
+ then:
+-builder.build() == defaultOptions + ['-release', '7']
++builder.build() == defaultOptions + 

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

This fix (or testing it) might be blocked by bug #895587.

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895587: openjdk-10: exclude element-list from being compressed

[Tiago Daitx]

Please consider the attached patch to fix this issue.

On Fri, Apr 13, 2018 at 1:51 AM, Tiago Stürmer Daitx
 wrote:
> Package: openjdk-10
> Version: 10~46-5
> Severity: important
>
> Dear Maintainer,
>
> The file element-list has replaced package-list in the javadoc api
> directory is now used by the javadoc binary. As it is not currently
> excluded when calling dh_compress it will be gzip and that causes
> javadoc to fail to recognize the /usr/share/doc/openjdk-10-jre-headless/api/
> directory. This causes quite a few packages to FTBFS, the most proeminent
> being gradle and groovy.
>
> thanks
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru openjdk-10-10~46/debian/changelog openjdk-10-10~46/debian/changelog
--- openjdk-10-10~46/debian/changelog	2018-04-02 12:39:54.0 -0300
+++ openjdk-10-10~46/debian/changelog	2018-04-13 01:42:02.0 -0300
@@ -1,3 +1,11 @@
+openjdk-10 (10~46-5) UNRELEASED; urgency=medium
+
+  * debian/rules: do not compress the element-list api docs as javadoc expects
+this file to be uncompressed when using '-link' or '-linkoffline'.
+(Closes: #895587)
+
+ -- Tiago Stürmer Daitx   Fri, 13 Apr 2018 04:42:02 +
+
 openjdk-10 (10~46-4) unstable; urgency=medium
 
   * Fix installation of japanese manual pages.
diff -Nru openjdk-10-10~46/debian/rules openjdk-10-10~46/debian/rules
--- openjdk-10-10~46/debian/rules	2018-04-02 12:25:57.0 -0300
+++ openjdk-10-10~46/debian/rules	2018-04-13 01:41:44.0 -0300
@@ -1789,7 +1789,7 @@
 	-dh_icons -i $(nodocs) || dh_iconcache -i $(nodocs)
 #	dh_installdebconf -i $(nodocs)
 	dh_link -i $(nodocs)
-	dh_compress -i $(nodocs) -Xexamples -Xdemo -Xpackage-list
+	dh_compress -i $(nodocs) -Xexamples -Xdemo -Xpackage-list -Xelement-list
 	dh_fixperms -i $(nodocs)
 	dh_installdeb -i $(nodocs)
 	dh_gencontrol -i $(nodocs) -- $(control_vars)

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

> 1) libcommons-lang3-java must be rebuild using openjdk-9 with docs and
> tests disabled
Then install the resulting deb binary.

> 2) rebuild with openjdk-10, keep doc and tests disabled
Or maybe with just tests disabled, I might have run with docs disabled
just to get a binary a bit faster. Tests must be disabled because for
some reason surefire seems to embed those classes into it's own jars
instead of using them from libcommons-lang3-java (otherwise installing
the deb binary from step #1 should have fixed it). And then, again,
install the resulting deb binary.

> 3) rebuild surefire with the new libcommons-lang3-java
It might also require the tests to be disabled IIRC. And then install
the deb binary.

> 4) rebuild libcommons-lang3-java with openjdk-10 with tests and docs enabled 
> (just to be sure it works)

surefire needs to be rebuild after uploading the deb binary from step #4.

Bug#895583: libcommons-lang3-java FTBFS due to unsupported locale type

[Tiago Daitx]

A debdiff with the fix has been provided in bug #895234 [1].

thanks

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895234

On Fri, Apr 13, 2018 at 12:32 AM, Tiago Stürmer Daitx
 wrote:
> Package: libcommons-lang3-java
> Version: 3.5-1
> Severity: normal
>
> Dear Maintainer,
>
> With bug #895234 [1] fixed, libcommons-lang3-java will FTBFS as bellow:
>
> [INFO] Running org.apache.commons.lang3.LocaleUtilsTest
> [ERROR] Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 0.007 s <<< FAILURE! - in org.apache.commons.lang3.LocaleUtilsTest
> [ERROR] testParseAllLocales(org.apache.commons.lang3.LocaleUtilsTest)  Time 
> elapsed: 0.004 s  <<< ERROR!
> java.lang.IllegalArgumentException: Invalid locale format: ji_001
> at 
> org.apache.commons.lang3.LocaleUtilsTest.testParseAllLocales(LocaleUtilsTest.java:578)
>
> Which has been fixed upstream by LANG-1312 [2]. The patch provided in
> the bug report applies cleanly.
>
> A debdiff will be provided shortly.
>
>
> References:
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895234
> [2] https://issues.apache.org/jira/browse/LANG-1312
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libcommons-lang3-java depends on:
> ii  libcommons-parent-java  43-1
>
> libcommons-lang3-java recommends no packages.
>
> Versions of packages libcommons-lang3-java suggests:
> pn  libcommons-lang3-java-doc  
>
> -- no debconf information



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

On Sun, 8 Apr 2018 19:03:14 +0200 Matthias Klose  wrote:
> Package: src:libcommons-lang3-java
> Version: 3.5-1
> Severity: important
> Tags: patch sid buster
>
> Please either apply the following patches for 10 and 11, or update to the
> upstream 3.6 release, and only apply the latter patch for 11 (which will be in
> 3.7 upstream).
>
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=commitdiff_plain;h=a618b844c5a261ced37385ab3947de6e215d46f7
>
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=patch;h=50ce8c44e1601acffa39f5568f0fc140aade0564
>

After applying the openjdk-10 patch libcommons-lang3-java will FTBFS
due to a NullPointerException in the surefire plugin:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
(default-test) on project commons-lang3: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
failed.: NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
(default-test) on project commons-lang3: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)

at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:145)

at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.NullPointerException
at 
org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast
(SystemUtils.java:1626)


and then another FTBFS due to a failing locale test as reported in bug #895583.

The current bug also affects libmaven-javadoc-plugin-java.

In order to get the build working some additional steps are required
due to the circular runtime dependency between libcommons-lang3-java,
libmaven-javadoc-plugin-java (doc generation), and libsurefire-java
(tests):
1) libcommons-lang3-java must be rebuild using openjdk-9 with docs and
tests disabled
2) rebuild with openjdk-10, keep doc and tests disabled
3) rebuild surefire with the new libcommons-lang3-java
4) rebuild libcommons-lang3-java with openjdk-10

I believe it is easier to do a binary upload after the last step than
trying to get the builds to do that correctly. Note that it can't be
rebuild with openjdk-8 in step #1 due to a "Method
flip()Ljava/nio/ByteBuffer" error in bnd.

Hopefully I described all the required steps above without missing any
- I got sidetracked checking the openjdk-8 failure and testing the fix
in a few other packages, so it took me a while to remember everything
I had to run and install.

Please consider the attached debdiff as it fixes both this bug as well
as bug #895583.

thanks
Tiago
diff -Nru libcommons-lang3-java-3.5/debian/changelog libcommons-lang3-java-3.5/debian/changelog
--- libcommons-lang3-java-3.5/debian/changelog	2016-10-20 15:08:15.0 -0200
+++ libcommons-lang3-java-3.5/debian/changelog	2018-04-12 10:14:49.0 -0300
@@ -1,3 +1,16 @@
+libcommons-lang3-java (3.5-2) UNRELEASED; urgency=medium
+
+  * debian/patches/fix-openjdk-10-nullpointer-lang-1365.diff: calls to
+org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast cause
+NullPointerException when running under openjdk-10 which in turn causes
+other packages to FTBFS with the message "Execution default-cli of goal
+groupId:artifactId:version:jar failed.: NullPointerException -> [Help 1]".
+(Closes: #895234)
+  * debian/patches/fix-numeric-3-area-code-support-lang-1312.diff: pull
+upstream fix for numeric-3 area code support. (Closes: #895583)
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 13:14:49 +
+
 libcommons-lang3-java (3.5-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff
--- libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	1969-12-31 21:00:00.0 -0300
+++ libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	2018-04-12 10:14:49.0 -0300
@@ -0,0 +1,65 @@
+Description: Fix UN M.49 numeric-3 area code support.
+ LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3
+ area code. 
+Author: pascalschumacher 
+Origin: upstream, https://github.com/apache/commons-lang/pull/239
+Bug: https://issues.apache.org/jira/browse/LANG-1312
+Bug-Debian: https://bug.debian.org/

Bug#893739: gettext: FTBFS with openjdk-9 as default-jdk

[Tiago Daitx]

Dear Maintainer,

Sorry for confusing initial report.
I'm copying the original message bellow and attaching the debdiff for
review again.


Currently gettext FTBFS when building with openjdk-9 due to:

cp: cannot stat 'debian/tmp/usr/share/gettext/libintl.jar': No such
file or directory

which in turn is caused by a configure failing to detect openjdk:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 9, please update gt_JAVACOMP macro
checking for Java compiler... no


For comparison, the above message, when compiling with OpenJDK 8 is:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 1.8, please update gt_JAVACOMP macro
checking for Java compiler... /usr/lib/jvm/default-java/bin/javac
-target 1.1 -source 1.3


The attached debdiff, copied from opensuse and modified to include
support for source/target 1.7 and 1.8, fixes this issue.

The configure message, with the patch applied, is:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 9, please update gt_JAVACOMP macro
checking for Java compiler... no


Please consider applying it to enable the work for transitioning
default-jdk from openjdk-8 to openjdk-9.

thanks
Tiago Daitx
diff -Nru gettext-0.19.8.1/debian/changelog gettext-0.19.8.1/debian/changelog
--- gettext-0.19.8.1/debian/changelog	2018-03-04 09:24:05.0 +0100
+++ gettext-0.19.8.1/debian/changelog	2018-03-20 19:47:19.0 +0100
@@ -1,3 +1,10 @@
+gettext (0.19.8.1-4ubuntu5~02) UNRELEASED; urgency=medium
+
+  * d/p/04-enable-jdk9-compatibility.patch: enable building with
+source and target flags set to 1.8; update gt_JAVACOMP macro.
+
+ -- Tiago Stürmer Daitx <tiago.da...@ubuntu.com>  Tue, 20 Mar 2018 18:47:19 +
+
gettext (0.19.8.1-4) unstable; urgency=medium

  * Avoid extraneous NUL bytes in .mo files. Closes: #872869.
diff -Nru gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch
--- gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch	1970-01-01 01:00:00.0 +0100
+++ gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch	2018-03-20 19:47:19.0 +0100
@@ -0,0 +1,235 @@
+Description: Enable compatibility with JDK 9+
+ According to JEP-182 OpenJDK 9 will only support 1.6 or later for source and
+ target flags. This patch adds supports for 1.6, 1.7, and 1.8 flags for
+ detecting and building gettext java.
+ Modified from opensuse to include support for 1.7 and 1.8.
+Origin: opensuse, https://build.opensuse.org/package/view_file/openSUSE:Factory/gettext-runtime/gettext-0.19.8.1-jdk9.patch
+Bug-Debian: 
+Forwarded: no
+Last-Update: 2018-03-21
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: gettext-0.19.8.1/gettext-runtime/configure.ac
+===
+--- gettext-0.19.8.1.orig/gettext-runtime/configure.ac
 gettext-0.19.8.1/gettext-runtime/configure.ac
+@@ -35,7 +35,7 @@ AC_PROG_YACC
+ 
+ gt_JAVA_CHOICE
+ 
+-gt_JAVACOMP([1.3], [1.1])
++gt_JAVACOMP([1.6], [1.6])
+ AC_CHECK_PROG([JAR], [jar], [jar])
+ if test -n "$HAVE_JAVACOMP" && test -n "$JAR" && test "$JAVA_CHOICE" != no; then
+   BUILDJAVA=yes
+Index: gettext-0.19.8.1/gettext-runtime/gnulib-m4/javacomp.m4
+===
+--- gettext-0.19.8.1.orig/gettext-runtime/gnulib-m4/javacomp.m4
 gettext-0.19.8.1/gettext-runtime/gnulib-m4/javacomp.m4
+@@ -16,6 +16,8 @@ dnl with or without modifications, as lo
+ #   1.4 assert keyword
+ #   1.5 generic classes and methods
+ #   1.6 (not yet supported)
++#   1.7 (not yet supported)
++#   1.8 (not yet supported)
+ #
+ # target-version can be:  classfile version:
+ #   1.1 45.3
+@@ -24,6 +26,8 @@ dnl with or without modifications, as lo
+ #   1.4 48.0
+ #   1.5 49.0
+ #   1.6 50.0
++#   1.7 51.0
++#   1.8 52.0
+ # The classfile version of a .class file can be determined through the "file"
+ # command. More portably, the classfile major version can be determined through
+ # "od -A n -t d1 -j 7 -N 1 classfile".
+@@ -36,6 +40,8 @@ dnl with or without modifications, as lo
+ #   1.4 JDK/JRE 1.4, gij 4.0, 4.1
+ #   1.5 JDK/JRE 1.5
+ #   1.6 JDK/JRE 1.6
++#   1.7 JDK/JRE 7
++#   1.8 JDK/JRE 8
+ # Note: gij >= 3.3 can in some cases handle classes compiled with -target 1.4,
+ # and gij >= 4.1 can in some cases partially handle classes compiled with
+ # -target 1.5, but I have no idea how complete this support is.
+@@ -47,7 +53,9 @@ dnl with or 

Bug#875336: FTBFS with Java 9: _ as identifier

[Tiago Daitx]

On Tue, 20 Mar 2018 23:07:13 +0800
=?UTF-8?B?5q635ZWf6IGwIHwgS2FpLUNodW5nIFlhbg==?= 
wrote:
> I just tried building it and Groovy was fine enough, but now Gradle 
> complains
>
> Theoretically, ALL Gradle packages FTBFS since the current version is too old 
> to play with Java 9's fancy version number.

Please take a look at the debdiff I attached to #873227 [1]. I would
like to get some feedback if it fixes these additional FTBFS.

[1] https://bugs.debian.org/873227

Bug#873227: Please upgrade to 4.1: Java 9 support

[Tiago Daitx]

Please see the attached debdiff to enable some basic OpenJDK 9 support
for gradle 3.4.1. The patches were downloaded from gradle upstream to
prevent the dreadful "Could not determine java version from '9.0.x'".

After applying the patches and rebuilding with OpenJDK 8, gradle can
then build itself with openjdk 9. I have also rebuild groovy, gant,
spock (FTBFS due to source/target 1.5), and dom4j (FTBFS due to
failing tests) which all previously failed.

Hopefully this should unblock #875336.

Please note that the debdiff includes the fix for #893487 for convenience.

thanks

On Fri, 25 Aug 2017 17:01:23 +0100 Chris West
 wrote:
> Source: gradle
> Version: 3.2.1-1
> Severity: normal
> User: debian-j...@lists.debian.org
> Usertags: default-java9
>
> Gradle doesn't officially support running under Java 9 until 4.1, which
> was released a fortnight ago.
>
> The version in Debian seems to actually be much better at surviving real
> builds than other random versions of Gradle I have lying around, but it
> would still be nice totally eliminate this as a java-9 blocker.
>
> Cheers,
> Chris.
>
>
>
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2017-11-29 16:09:02.0 +0100
+++ gradle-3.4.1/debian/changelog	2018-03-19 12:19:49.0 +0100
@@ -1,3 +1,15 @@
+gradle (3.4.1-3) UNRELEASED; urgency=medium
+
+  * d/p/cast-estimated-runtime-to-long.patch: fix FTBFS due to missing cast.
+(Closes: #893487)
+  * d/p/support-running-gradle-on-jdk-10-500485df3a18.patch,
+d/p/add-test-case-for-10-internal_c1fe5e40a76b.patch,
+d/p/support-zulu9-version-number_d9c35cf9d74c.patch: prevent failures when
+building projects with openjdk 9.
+
+
+ -- Tiago Stürmer Daitx   Mon, 19 Mar 2018 11:19:49 +
+
 gradle (3.4.1-2) experimental; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch
--- gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch	2018-03-19 12:19:49.0 +0100
@@ -0,0 +1,21 @@
+From c1fe5e40a76b79a98e8916c2ce3b4e1e6ed3f343 Mon Sep 17 00:00:00 2001
+From: Cedric Champeau 
+Date: Thu, 13 Jul 2017 16:16:46 +0200
+Subject: [PATCH] Add test case for `10-internal`
+
+---
+ .../base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy  | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy b/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
+index 75459ed3f06..fbb243ba992 100644
+--- a/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
 b/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
+@@ -65,6 +65,7 @@ public class JavaVersionSpec extends Specification {
+ JavaVersion.toVersion("9-ea") == JavaVersion.VERSION_1_9
+ 
+ JavaVersion.toVersion("10-ea") == JavaVersion.VERSION_1_10
++JavaVersion.toVersion("10-internal") == JavaVersion.VERSION_1_10
+ }
+ 
+ def convertClassVersionToJavaVersion() {
diff -Nru gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch
--- gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch	2018-03-19 12:15:47.0 +0100
@@ -0,0 +1,22 @@
+Description: gradle 3.4.1 FTBFS with a missing cast to long
+ estimatedRuntime must be cast to long otherwise gradle 3.4.1 FTBFS with
+ buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy:
+ 134: [Static type checking] - Cannot assign value of type java.math.BigDecimal
+ to variable of type long.
+Author: Tiago Stürmer Daitx 
+Bug-Debian: https://bugs.debian.org/893487
+Forwarded: no
+Last-Update: 2018-03-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy
 b/buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy
+@@ -131,7 +131,7 @@ class DistributedPerformanceTest extends
+ def scenarios = scenarioList.readLines()
+ .collect { line ->
+ def parts = Splitter.on(';').split(line).toList()
+-new Scenario(id : parts[0], estimatedRuntime: new BigDecimal(parts[1]), templates: parts.subList(2, parts.size()))
++new Scenario(id : parts[0], estimatedRuntime: new BigDecimal(parts[1]) as long, templates: parts.subList(2, parts.size()))
+ }
+ .sort{ 

Bug#892760: antlr3: FTBFS with Java 9

[Tiago Daitx]

I am attaching a simple fix to get rid of the FTBFS when building with
openjdk-9.

BTW, I didn't mention this before, but the reason that javadoc goals
worked with openjdk-8 is because openjdk-8's javadoc binary ignored
the missing packages/files instead of failing to run - the
documentation for the generated sources was never included.

thanks

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru antlr3-3.5.2/debian/changelog antlr3-3.5.2/debian/changelog
--- antlr3-3.5.2/debian/changelog	2017-08-02 11:53:56.0 +0200
+++ antlr3-3.5.2/debian/changelog	2018-03-14 15:21:31.0 +0100
@@ -1,3 +1,11 @@
+antlr3 (3.5.2-9) UNRELEASED; urgency=medium
+
+  * Add generate-sources to docs goals to activate antlr before javadoc's
+goals, otherwise javadoc:jar fails because the sourcepath is incomplete.
+(Closes: #892760)
+
+ -- Tiago Stürmer Daitx   Wed, 14 Mar 2018 14:21:31 +
+
 antlr3 (3.5.2-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru antlr3-3.5.2/debian/rules antlr3-3.5.2/debian/rules
--- antlr3-3.5.2/debian/rules	2017-06-30 11:10:45.0 +0200
+++ antlr3-3.5.2/debian/rules	2018-03-14 15:20:48.0 +0100
@@ -8,7 +8,7 @@
 
 DEB_MAVEN_INSTALL_TO_USJ := false
 DEB_MAVEN_BUILD_TARGET := package install
-DEB_MAVEN_DOC_TARGET := javadoc:jar javadoc:aggregate
+DEB_MAVEN_DOC_TARGET := generate-sources javadoc:jar javadoc:aggregate
 PACKAGE  := $(DEB_SOURCE_PACKAGE)
 VERSION  := $(shell echo $(DEB_UPSTREAM_VERSION) | cut -d'+' -f1 -)
 JAVA_HOME:= /usr/lib/jvm/default-java

Bug#892760: antlr3: FTBFS with Java 9

[Tiago Daitx]

After reviewing this again I found out that the problem is caused by
the direct calling of javadoc's jar goal - note that this is specific
to cdbs, antlr4 relies on dh and calls the 3 goals "package
javadoc:jar javadoc:aggregate" together, which causes generate-sources
to be run before both javadoc goals.

When direct calling a goal, maven won't have a phase/lifecycle
associated to it, thus it won't activate any other plugins except for
the ones in the command line.

For antlr3 this causes a problem because javadoc:jar won't be able to
add the generated sources paths from antlr to javadoc's option
'sourcepath' as well as fail to properly accounting for the
org.antlr.gunit.swingui.parsers package.

Without the antlr3:antlr goal, javadoc:jar will set sourcepath as
'/build/antlr3/antlr3-3.5.2/gunit/src/main/java',
while if the antlr3:antlr goal is run before javadoc's goals the
sourcepath is set as
'/build/antlr3/antlr3-3.5.2/gunit/src/main/java:/build/antlr3/antlr3-3.5.2/gunit/target/generated-sources/antlr3'

And easy fix is to add generate-sources to the DEB_MAVEN_DOC_TARGET in
debian/rules, as such:
-DEB_MAVEN_DOC_TARGET := javadoc:jar javadoc:aggregate
+DEB_MAVEN_DOC_TARGET := generate-sources javadoc:jar javadoc:aggregate

thanks

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#887785: javacc-maven-plugin and build-rdeps FTBFS with jtb 1.4.12-1

[Tiago Daitx]

This is caused by a groupId change in 1.4.12-1 where it was changed
from "edu.ucla.cs.compilers" [1] to "edu.purdue.cs" [2].

Please see bug #891893 [3] for more information.

Regards,
Tiago

[1] 
https://anonscm.debian.org/cgit/collab-maint/jtb.git/tree/debian/pom.xml?id=cffddde94d57ef60f7415f8c8d400a75ba4c0f30
[2] 
https://anonscm.debian.org/cgit/collab-maint/jtb.git/tree/pom.xml?id=19bafc71af2bdb92a0abe47b01a0aa8504945cab
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891893

Bug#891893: jtb: groupId change in jtb-1.4.12-1 causes other packages to FTBFS

[Tiago Daitx]

patch attached

On Fri, Mar 2, 2018 at 2:43 AM, Tiago Stürmer Daitx
 wrote:
> Package: jtb
> Version: 1.4.12-1
> Severity: important
>
> Dear Maintainer,
>
> As per bug #887785 various packages were affected by jtb-1.4.12-1. I
> tracked the issue down to a groupId change after the pom was updated
> from upstream.
>
> The pom.xml groupId changed from "edu.ucla.cs.compilers" (original
> pom.xml [1]) to "edu.purdue.cs" (new pom.xml [2]).
>
> Adding a relocation to debian/jtb.poms fixes the FTBFS in the affected
> packages (tested on surefire, javacc-maven-plugin, hawtbuf, avro-java,
> and activemq-protobuf).
>
> Please see the attached debdiff for a suggested fix. You might want to
> change the relocate version.
>
> Regards,
> Tiago
>
> [1] 
> https://anonscm.debian.org/cgit/collab-maint/jtb.git/tree/debian/pom.xml?id=cffddde94d57ef60f7415f8c8d400a75ba4c0f30
> [2] 
> https://anonscm.debian.org/cgit/collab-maint/jtb.git/tree/pom.xml?id=19bafc71af2bdb92a0abe47b01a0aa8504945cab
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.13.0-32-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages jtb depends on:
> ii  default-jre [java8-runtime] 2:1.8-59ubuntu1
> pn  jarwrapper  
> ii  openjdk-10-jre [java9-runtime]  10~32-0ubuntu1
> ii  openjdk-8-jre [java8-runtime]   8u151-b12-1
> ii  openjdk-9-jre [java9-runtime]   9.0.1+11-1
>
> jtb recommends no packages.
>
> jtb suggests no packages.



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru jtb-1.4.12/debian/changelog jtb-1.4.12/debian/changelog
--- jtb-1.4.12/debian/changelog	2018-01-08 01:18:07.0 -0200
+++ jtb-1.4.12/debian/changelog	2018-03-02 01:13:00.0 -0300
@@ -1,3 +1,10 @@
+jtb (1.4.12-1ubuntu1~01) UNRELEASED; urgency=medium
+
+  * Relocate edu.ucla.cs.compilers:jtb:debian:
+- fix a few packages FTBFS due to groupId change. (Closes: #887785).
+
+ -- Tiago Stürmer Daitx   Fri, 02 Mar 2018 04:13:00 +
+
 jtb (1.4.12-1) unstable; urgency=medium
 
   [ Markus Koschany ]
diff -Nru jtb-1.4.12/debian/jtb.poms jtb-1.4.12/debian/jtb.poms
--- jtb-1.4.12/debian/jtb.poms	2018-01-07 16:46:40.0 -0200
+++ jtb-1.4.12/debian/jtb.poms	2018-03-02 01:12:38.0 -0300
@@ -1 +1 @@
-debian/pom.xml
+debian/pom.xml --relocate=edu.ucla.cs.compilers:jtb:debian

Bug#873976: [pkg-db-devel] Bug#873976: FTBFS with Java 9 due to -source/-target only

[Tiago Daitx]

On Thu, 07 Sep 2017 15:30:53 +0200 =?utf-8?Q?Ond=C5=99ej=20Sur=C3=BD?=
 wrote:
> Hi Chris,
>
> I would be happy to accept the patch. The email is one big jumbo/mumbo
> to me as I have never used java (and I don't intend to).

Hi Ondřej,

I will try to clarify the issue here.

There has been an ongoing investigation about moving the default-jdk
from OpenJDK 8 to OpenJDK 9 (and forward). In order to find issues an
automated tool was used to detect build failures when using OpenJDK 9
as the default-jdk and then report those back to the package
maintainers (thanks to Chris).

db5.3 has a build dependency on default-jdk, thus a viable candidate
for the test. Unfortunately the package currently sets
"JAVACFLAGS=-source 1.5 -target 1.5". The source flag is used to tell
the compiler what version of the java grammar to accept. The target
flag will set the minimum java runtime required to run the generated
binaries.

The both options are deemed too old to be used with OpenJDK 9 as it
only supports 1.6 or newer. A test was made where the package had it's
source and target set to 1.7, resulting in a good build, and this is
what Markus' patch does.

Could you please consider applying Markus' patch to the package?
Please let me know if you need further clarification.

Regards.
Tiago

>
> Cheers,
> --
> Ondřej Surý 
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
> fast DNS(SEC) resolver
> Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
> pečení chleba všeho druhu
>
> On Fri, Sep 1, 2017, at 21:40, Chris West wrote:
> > Source: db5.3
> > Version: 5.3.28
> > Severity: normal
> > User: debian-j...@lists.debian.org
> > Usertags: default-java9
> >
> > This package fails to build with default-jdk pointing to openjdk-9-jdk.
> > The wiki has some common problems and their solutions:
> > https://wiki.debian.org/Java/Java9Pitfalls
> >
> > An automated tool has decided that this package will build fine if the
> > -source and -target options are changed to 1.6; no additional changes
> > are required. This was done by building with a compiler that changed
> > the settings automatically, then the real compiler, and diffing the
> > results. This modified compiler will never be part of Debian.
> >
> > ant and Maven are supposed to do this for you, and I've tried to check
> > that this package is not using ant or Maven correctly, but I might have
> > messed up.
> >
> > Build log sample:
> >
> > configure:18523: checking for javac
> > configure:18539: found /usr/bin/javac
> > configure:18550: result: javac
> > configure:18608: checking if javac works
> > configure:18622: javac -source 1.5 -target 1.5 Test.java
> > warning: [options] bootstrap class path not set in conjunction with
> > -source 1.5
> > error: Source option 1.5 is no longer supported. Use 1.6 or later.
> > error: Target option 1.5 is no longer supported. Use 1.6 or later.
> > configure:18625: $? = 2
> > configure:18629: error: The Java compiler javac failed (see config.log,
> > check the CLASSPATH?)
> >
> >
> > Cheers,
> > Chris.
> >
> > ___
> > pkg-db-devel mailing list
> > pkg-db-de...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-db-devel
>
>

Bug#857003: #857003: ncurses: Build x32 packages

[Tiago Daitx]

On Mon, Mar 6, 2017 at 11:30 PM, Adam Borowski  wrote:
>> Please consider applying the attached patch to add x32 packages to
>> ncurses. This patch has been a part of Ubuntu since late 2012 [1].
>
> ncurses work fine on x32, natively and/or via multiarch.  Is there a real
> reason to add multi_lib_ packages?

Sorry, I forgot to add an extra comment about this particular patch.

I'm simply trying to reduce the diff between Ubuntu and Debian and
these patches have been carried on for a long while and these extra
pieces cause constant merge failures on the Ubuntu side.

In the case of x32 I'm really not sure if the patches are still
required, they have been added long ago. I'm actually interested in
your point of view as a maintainer - and this is the part I forgot to
ask you about: do you believe the x32 patches add any value to the
package nowadays? They seem to be no longer required.

Thanks!

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#856569: open-vm-tools: Depend on either libssl1.0-dev or libssl-dev

[Tiago Daitx]

Hi Bernd,

Thank you for the quick reply. =)

On Thu, Mar 2, 2017 at 5:42 PM, Bernd Zeimetz  wrote:
> Hi Tiago,
>
>> Please consider improving Build-depends to accept either
>> libssl1.0-dev or libssl-dev as that will make backporting easier.
>
> I'm not sure how Ubuntu handles these things, but in Debian the
> autobuilders only consider the first alternative of build dependencies
> to keep a build reproducible - so if you have  A | B as build-dep, they
> will always use A.

If A is not available then the builds will then try B, C, ... .

I did the a test build for Yakkety - which does not have libssl1.0-dev
(A) - and it picked libssl-dev (B) instead. On Zesty (our dev version)
the builders use libssl1.0-dev at that is available.

> I'm backporting the package to jessie and wheezy and you can find these
> sources in my git repository, too. Especially for wheezy there are some
> extra changes necessary.

Thanks for letting us know, should we need to backport this will
probably come in hand. =)

> Also a backport in the current state won't make upstream happy as the
> cgauth service won't be started. For jessie I might depend on systemd,
> but for older distributions an init script is necessary.
>
> btw, regarding the ubuntu package - its nice, that it is just taking my
> packaging these days - but why do you guys still build without
> xmlsecurity and xerces?

This is caused by the separation we have between Main and Universe.
Main is the stuff that is guaranteed to have security updates and all,
Universe not much so - there are other differences, but security is
what matters most in this case.

open-vm-tools is in Ubuntu Main archive, but xml-security-c and xerces
are in Universe. If they were only required for building it would be
fine, we have been allowed since Xenial to have packages in Main with
a Build-Depend on packages on Universe. The problem is that both
xml-security-c and xerces are also runtime dependencies, so a package
in Main can't have those [1]. To depend on those would require them to
be moved to Main, which didn't happen [2].

What I did, based on suggestions, was to build and test against
xmlsec1, which is in Main and accepted by open-vm-tools's configure.
The build turned out fine. I haven't done some real testing on it, I'm
now waiting for other folks to look into that if they have the time.

Is there a reason why Debian prefers xmlsecurity and xerces instead of
xmlsec1? If it were to depend on xmlsec1 then Ubuntu would be able to
use the exact same package. I'm not familiar with the functionality in
and security of open-vm-tools, xmlsecurity, xerces, and xmlsec1, so I
really have no idea what difference that would do.

Many thanks!


[1] 
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html
[2] https://bugs.launchpad.net/ubuntu/+source/xml-security-c/+bug/1482777

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

It turns out that  applets are failing because the security update in
S8155973 restricted MD5-based signatures in JAR files. It was
eventually backed out by S8166381 but that one didn't make to the
update.

One easy way to fix is to edit
/etc/java-7-openjdk/security/java.security and remove MD5 from the
list of "jdk.jar.disabledAlgorithms". By default this is a new setting
and should be the last line, just make sure it looks like:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024



For future reference, once can see when an applet is being affect by
looking for the following log line:
Codebase matches codebase manifest attribute, but application is
unsigned. Continuing.
The browser must be run with icedtea plugin debug enabled as in
"ICEDTEAPLUGIN_DEBUG=true firefox".

Also, please be aware that Oracle is planning to reintroduce the MD5
signature restriction back in January, see section "Restrict JARs
signed with weak algorithms and keys" in
http://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html

-thanks

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

While icedtea-web 1.6.2 does fixes a few bugs, this is not one of those.

Alain did reply to me in private saying that he was still seeing the
issue with the new icedtea-web and that downgrading to 7u111-2.6.7-1
got applets working again. So this is definitely a regression. Alain
also pointed me to a page with good applets to test this, the "Simple
upload" applet fails to run on the affected version:
http://demo.element-it.com/Examples/JavaPowUpload/index.htm

Meanwhile a new IcedTea release was out on experimental
(7u121-2.6.8-1), I tested it and I can confirm there is no regression
in it. It might take a while for a backport to show up, if you are
affected by this I recommend downgrading OpenJDK 7 as a workaround.


For future reference the actual error for the "Simple upload" applet is:

java.security.AccessControlException: access denied
("java.util.PropertyPermission" "java.net.preferIPv4Stack" "read")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:685)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at 
net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1298)
at java.lang.System.getProperty(System.java:708)
at com.elementit.JavaPowUpload.Manager.init(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90)
at java.lang.Thread.run(Thread.java:745)

java.security.AccessControlException: access denied
("java.util.PropertyPermission" "java.net.preferIPv4Stack" "read")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:685)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at 
net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1298)
at java.lang.System.getProperty(System.java:708)
at com.elementit.JavaPowUpload.Manager.init(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90)
at java.lang.Thread.run(Thread.java:745)

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

Hi Alain,

Please try out the deb files @
https://keybase.pub/tdaitx/icedtea-web-1.6.2/ and let me know if they
do solve the problem.

If they don't, I would need you to point me to a public online applet
that was known to work on the older openjdk version and is now failing
on the new one, otherwise I'm stuck as I have no way to reproduce the
issue.

-thanks

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

On Wed, Nov 9, 2016 at 4:30 PM, Alain Rpnpif  wrote:
> Thanks for your answer.
> Yes the applet on
> https://www.w3.org/People/mimasa/test/object/java/clock work fine but
> with a lot of popup dialog to accept.
>
> I have also always errors when I used my Lexmark network printer
> scanner.
> I can control remotely the scanner but it claims that it was
> disconnected when it should upload the picture file to the client. So it
> is unusable with this openjdk.
>
> Before that openjdk was updated, all work fine.
>
> Is it a new permission problem ?
>
> On the local computer, here are the errors from syslog with the
> scanner :
>
> IcedTea-Web java error - for more info see itweb-settings debug options
> or console. See
> http://icedtea.classpath.org/wiki/IcedTea-Web#Filing_bugs for help.
> IcedTea-Web java error manual log: java.io.IOException: Server returned
> HTTP response code: 501 for URL:
> http://192.168.1.201/cgi-bin/dynamic/printer/applets/applets.jar at

This indicates that the HTTP request failed on the server side, but
there's not enough information to understand why and I am unable to
reproduce it as I have no such scanner.

I need something that I can reproduce locally, could you please test a
publicly available applet that was known to work on the older openjdk
version and is now failing on the new one?


Also, I took another look at the default java applet test at
https://www.java.com/en/download/installed.jsp because it worked fine
from a newer distro running OpenJDK 8. The actual error was a
NullPointerException at
SecurityDialogs.showMatchingALACAttributePanel, as shown bellow:

[tdaitx][ITW-JAVAWS][ERROR_DEBUG][Wed Nov 09 17:11:40 BRST
2016][net.sourceforge.jnlp.AbstractLaunchHandler.printMessage(AbstractLaunchHandler.java:67)]
NETX Thread# 55b76aab, name Java Detection
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error:
Could not initialize applet. For more information click "more
information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:739)
at net.sourceforge.jnlp.Launcher.launchApplet(Launcher.java:640)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:907)
Caused by: java.lang.NullPointerException
at 
net.sourceforge.jnlp.security.SecurityDialogs.showMatchingALACAttributePanel(SecurityDialogs.java:299)
at 
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkApplicationLibraryAllowableCodebaseAttribute(ManifestAttributesChecker.java:341)
at 
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:83)
at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.(JNLPClassLoader.java:288)
at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)
at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)
at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:704)
... 2 more


I found a similar bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=1299976 (it's for a
different function), but the solution was to upgrade icedtea-web. I
built icedtea-web 1.6.2 for jessie and was able to get it working. Let
me know if you are willing to try it locally and see if it also fixes
your lexmark scanner client - I can then provide you with the deb
files for testing.

thanks

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

On Wed, Nov 9, 2016 at 1:26 PM, rpnpif  wrote:
> Package: openjdk-7-jre
> Version: 7u111-2.6.7-2~deb8u1
> Severity: normal
>
> Dear Maintainer,
>
> After the last security update, now java is unusable in Firefox with
> icedtea-7-plugin on all applets.

I was unable to reproduce this.

> On https://www.java.com/en/download/installed.jsp, an exception occurs :
>
> IcedTea-Web Plugin version: 1.5.3 (1.5.3-1)
> Wed Nov 09 16:16:49 CET 2016

Yes, this particular test fails, but the actual error is:
[tdaitx][ITW-APPLET][ERROR_ALL][Wed Nov 09 17:32:09 UTC
2016][net.sourceforge.jnlp.runtime.JNLPClassLoader.checkForMain(JNLPClassLoader.java:835)]
NETX Thread# 673fcb2c, name Applet: JAR
https://www.java.com/en/download/JavaDetection.jar not found.
Continuing.

or from the terminal console:
java.io.FileNotFoundException:
https://www.java.com/en/download/JavaDetection.jar

And indeed that jar file is not available at that location, so no
wonder that applet won't work.

I could get other applets to work on Jessie with IceWeasel, eg:
https://www.w3.org/People/mimasa/test/object/java/clock

-thanks

Bug#831081:

[Tiago Daitx]

GCC 6 abs to std::abs fix accepted and committed upstream:
https://github.com/timschmidt/repsnapper/commit/93dde1ef83c0c1c555f3f1ca8ff477d14d29a1e9

Original pull request: https://github.com/timschmidt/repsnapper/pull/119

Attached patch and a debdiff, the debdiff includes a workaround for
bug #810907 (avoids yet another FTBFS on powerpc/ppc64el).

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE


repsnapper_2.4a0-1_repsnapper_2.4a0-1ubuntu1.debdiff
Description: Binary data
Description: resnapper FTBFS due to mismathing headers in linux-libc-dev
 The headers in linux-libc-dev are different in powerpc/ppc64el compared
 to other archs, they seems to be missing include clauses to the 
 header under the asm-generic/ directory.
 This patch works around that by explicitly including both headers under
 asm-generic.
 Note that the include of arm/termbits.h had to be removed because it
 causes yet another conflict, this time due to the redefinition of types
 termios and ktermios, which also only affects powepc/ppc64el.
 
Author: Tiago Stürmer Daitx 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810907
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/repsnapper/+bug/1619100
Forwarded: https://bugs.launchpad.net/bugs/1619446
Last-Update: 2016-09-01
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/printer/custom_baud.cpp
+++ b/src/printer/custom_baud.cpp
@@ -6,7 +6,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #endif
 
 bool set_custom_baudrate( int device_fd, int baudrate ) {

Bug#810907: repsnapper: FTBFS on ppc64el: termios problems

[Tiago Daitx]

On Sun, 14 Feb 2016 18:39:49 +0100 Andreas Beckmann  wrote:
> Followup-For: Bug #810907
> Control: found -1 2.4a0-1
> Control: severity -1 serious
> Control: tag -1 patch
>
> the same issue happens on powerpc
>
> https://buildd.debian.org/status/fetch.php?pkg=repsnapper=powerpc=2.4a0-1=1455299926
> https://buildd.debian.org/status/fetch.php?pkg=repsnapper=ppc64el=2.4a0-1=1455299989
>

I have modified the original patch with a workaround that works for
all archs in Ubuntu [1].

Additionally, the attached debdiff also includes a fix for FTBFS that
happens when building with gcc 6 [2].

There is an open bug report against linux on Ubuntu due to the
mismatching headers between powerpc/ppc64el and the other archs, which
is the actual reason for this particular FTBFS.

Ubuntu bugs:
[1] https://bugs.launchpad.net/debian/+source/repsnapper/+bug/1619100
[2] https://bugs.launchpad.net/ubuntu/+source/repsnapper/+bug/1619289
[3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1619446

thanks


repsnapper_2.4a0-1_repsnapper_2.4a0-1ubuntu1.debdiff
Description: Binary data
Description: resnapper FTBFS due to mismathing headers in linux-libc-dev
 The headers in linux-libc-dev are different in powerpc/ppc64el compared
 to other archs, they seems to be missing include clauses to the 
 header under the asm-generic/ directory.
 This patch works around that by explicitly including both headers under
 asm-generic.
 Note that the include of arm/termbits.h had to be removed because it
 causes yet another conflict, this time due to the redefinition of types
 termios and ktermios, which also only affects powepc/ppc64el.
 
Author: Tiago Stürmer Daitx 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810907
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/repsnapper/+bug/1619100
Forwarded: not-needed
Last-Update: 2016-09-01
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/printer/custom_baud.cpp
+++ b/src/printer/custom_baud.cpp
@@ -6,7 +6,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #endif
 
 bool set_custom_baudrate( int device_fd, int baudrate ) {

Bug#833933: openjdk-7: jamvm is broken due to missing native methods in sun.misc.Unsafe

[Tiago Daitx]

Patch attached

On Wed, Aug 10, 2016 at 11:44 AM, Tiago Stürmer Daitx
 wrote:
> Source: openjdk-7
> Version: 7u111-2.6.7-1
> Severity: important
>
> Dear Maintainer,
>
> [Issue]
> The fix of OpenJDK's bug 8158260
> (http://icedtea.classpath.org/hg/release/icedtea7-forest-2.6/hotspot/rev/4f8cbd54a9c6)
> introduced 2 new native methods to the sun.misc.Unsafe class:
> isBigEndian0 and unalignedAccess0.
>
> This completely broke JamVM and as of now it is impossible to start a
> jamvm session.
>
> jtreg summary results for OpenJDK 7:
> hotspot - Test results: passed: 5; failed: 309; error: 7
> langtools - Test results: passed: 374; failed: 1,593; error: 1
>
> Error output from a hotspot testcase:
> --System.err:(6/344)--
> Error initialising VM (initialiseMainThread)
> Check the README for compatible class-libraries/versions
> Exception occurred while printing exception
> (java/lang/NullPointerException)...
> Original exception was java/lang/UnsatisfiedLinkError
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> result: Failed. Unexpected exit from test [exit code: 1]
>
> Running java -jamvm -version fails the same way.
>
> [Fix]
> The simple fix is to add both methods to the natives.c file in the
> classlib/openjdk directory.
>
> I have tested this with IcedTea 2.6.7 and now jtreg passes:
> hotspot - Test results: passed: 220; failed: 90; error: 11
> langtools - Test results: passed: 1,901; failed: 65; error: 2
>
> I have reported this upstream at
> https://sourceforge.net/p/jamvm/code/merge-requests/1/ and it is now
> waiting review.
>
> Also reported for IcedTea 2.6.7 at
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3134
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers xenial-updates
>   APT policy: (4000, 'xenial-updates'), (4000, 'xenial-security'), (4000, 
> 'xenial-backports'), (4000, 'xenial')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.4.0-31-generic (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
Description: Adds Unsafe methods from S8158260
 In order to fix the PPC64 bug S8158260 two new native methods were
 added to sun.misc.Unsafe: isBigEndian0 and unalignedAcces0.
 Both were added by the following commit:
 http://icedtea.classpath.org/hg/release/icedtea7-forest-2.6/hotspot/rev/4f8cbd54a9c6
 .
 This patch adds those methods to the JAMVM being used by IcedTea.
Author: Tiago Stürmer Daitx 
Bug: https://sourceforge.net/p/jamvm/code/merge-requests/1/
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833933
Bug-IcedTea: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3134
Bug-Ubuntu: https://bugs.launchpad.net/openjdk/+bug/1611598
Last-Update: 2016-08-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- /dev/null
+++ b/patches/jamvm/8158260-fix.patch
@@ -0,0 +1,36 @@
+--- jamvm.orig/jamvm/src/classlib/openjdk/natives.c	2014-03-24 21:34:58.0 -0300
 jamvm/jamvm/src/classlib/openjdk/natives.c	2016-08-09 19:26:36.205775539 -0300
+@@ -34,6 +33,7 @@
+ #include "reflect.h"
+ #include "natives.h"
+ #include "openjdk.h"
++#include "properties.h"
+ #include "trace.h"
+ 
+ int classlibInitialiseNatives() {
+@@ -470,6 +465,16 @@
+ return ostack;
+ }
+ 
++uintptr_t *isBigEndian0(Class *clazz, MethodBlock *mb, uintptr_t *ostack) {
++*ostack++ = IS_BIG_ENDIAN;
++return ostack;
++}
++
++uintptr_t *unalignedAccess0(Class *clazz, MethodBlock *mb, uintptr_t *ostack) {
++*ostack++ = FALSE;
++return ostack;
++}
++
+ VMMethod sun_misc_unsafe[] = {
+ {"registerNatives","()V", unsafeRegisterNatives},
+ {"objectFieldOffset",  "(Ljava/lang/reflect/Field;)J",
+@@ -569,6 +574,8 @@
+ {"fullFence",  "()V", fullFence},
+ {"loadFence",  "()V", loadFence},
+ {"storeFence", "()V", storeFence},
++{"isBigEndian0",   "()Z", isBigEndian0},
++{"unalignedAccess0",   "()Z", unalignedAccess0},
+ {NULL, NULL, NULL}
+ };
+ 
--- a/Makefile.am
+++ b/Makefile.am
@@ -404,7 +404,8 @@ endif
 if BUILD_JAMVM
 ICEDTEA_PATCHES += \
 	patches/jamvm/noexecstack.patch \
-	patches/jamvm/pr2665.patch
+	patches/jamvm/pr2665.patch \
+	patches/jamvm/8158260-fix.patch
 endif
 
 if ENABLE_NSS

Bug#793137: Also affects openscad - #797816

[Tiago Daitx]

The same issue has been reported in openscad for armhf. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797816

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

Bug#797816: Also affects tulip - #793137

[Tiago Daitx]

The same issue has been reported in tulip. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793137