Re: Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[tony mancill]

On Fri, May 03, 2024 at 09:13:09PM -0400, Chris Knadle wrote:
> Thank you this sounds promising.
> 
> Would you consider this option in debian/rules to be safe to deploy to all
> architectures?
> 
> i.e. would adding this globally be an acceptable bug fix?

Hi Chris,

Yes, I think this is suitable for all builds.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[tony mancill]

On Thu, May 02, 2024 at 01:54:51PM +1200, Vladimir Petko wrote:
> Unfortunately I do not have an armel box accessible, but maybe
> tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx'
> might help?
> I have tried with export GRADLE_OPTS=-Xmx512M and the package was
> built successfully.

Hi Chris,

If it saves you any time (it's a long build), I was able to build
zeroc-ice successfully on armel after adding Vladimir's suggestion to
debian/rules.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Removing freeplane 1.7.x from Debian?

[tony mancill]

On Sun, Mar 31, 2024 at 04:53:17PM +0200, Felix Natter wrote:
> Dear java team,
> 
> the current freeplane package only works with an old JRE [1].
> [1] https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/2034752
> 
> I think that not many users figure out how to set JAVA_CMD or
> FREEPLANE_JAVA_HOME, and even if they did, it would be a security risk
> due to an old JRE. I cannot package freeplane 1.11.x because it requires
> gradle >= 7.x.
> 
> Since it is easy to install the upstream .deb...
> - https://sourceforge.net/projects/freeplane/
> - select "Files"
> - select "freeplane stable"
> - select freeplane_1.11.11~upstream-1_all.deb
> - install with "sudo apt install
>   /path/to/freeplane_1.11.11~upstream-1_all.deb"
> 
> ... I wonder whether it is better to remove freeplane now?
> What do you think?

Hi Felix,

In my opinion we should be remove the outdated freeplane package from
Debian.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77

[tony mancill]

On Sat, Dec 09, 2023 at 12:50:33PM +0100, Andreas Tille wrote:
> I tried the latest upstream version of libitext5-java and commited the
> change to Git.  Unfortunately the problem persists.  Some Debian Med
> packages are depending from this package so I'd be happy if someone
> could have a look.  You can find the latest log in Salsa CI[1].

Hi Andreas,

Thank you for your efforts here.  I just pushed a patch that resolves
the FTBFS, and the tests are passing.  I plan to do a bit more poking
at the upstream tests to make sure that the patched classes are
exercised by the test cases, but will either update this bug or upload
in the 2-3 days.

Regards,
tony

Re: [RFC] Removing support for GCJ and GCJFLAGS from dpkg?

[tony mancill]

Hi Guillem,

On Thu, Aug 31, 2023 at 02:23:00AM +0200, Guillem Jover wrote:
> While going through the supported compilers and build flags recently,
> I noticed that dpkg-buildflags and the various dpkg Makefile fragment
> files still have support for gcj, but that compiler seems to have
> stopped being maintained some time ago. According to Wikipedia
> () the final
> release was in 2018, and we do not even have it in Debian anymore.
> 
> So I guess it should be fine to rip that off? A quick codesearch.d.n
> didn't reveal much of a usage. But I'd like to hear whether this would
> break or disrupt things, before I consider removing these.

No concerns from the Debian Java team.  I can't imagine any breakage,
but if there is any fall-out, it would be due to cruft that we should
clean up anyway.  The dependency on gcj-jdk was dropped from javahelper
(src:javatools) for buster [0].

Thanks for catching this.

Cheers,
tony

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


signature.asc
Description: PGP signature

Re: Re: jar missing in /usr/share/maven-repo/

[tony mancill]

On Wed, Jul 05, 2023 at 09:57:46PM +0200, Thorsten Glaser wrote:
> On Wed, 5 Jul 2023, Andreas B. Mundt wrote:
> 
> >after that.  However, when I try to start it, I get:
> >
> >  $ java -jar /usr/share/java/filius.jar
> >  Error: Unable to initialize main class filius.Main
> >  Caused by: java.lang.NoClassDefFoundError: 
> > ch/qos/logback/core/joran/spi/JoranException
> 
> I think you have to do:
> 
> java -cp /usr/share/java/logback.jar:/usr/share/java/foodependency.jar:… -jar 
> /usr/share/java/filius.jar
> 
> It’s common to put that into a tiny shell script in /usr/bin.

You can use java-wrappers for this. 

Here's an example of a wrapper script:

  https://salsa.debian.org/java-team/jabref/-/blob/master/debian/jabref-wrapper

Which needs to be installed in the binary package:

  https://salsa.debian.org/java-team/jabref/-/blob/master/debian/rules#L13

And be declared as a dependency of the binary package:

  https://salsa.debian.org/java-team/jabref/-/blob/master/debian/control#L55

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#1034059: marked as pending in zstd-jni-java

[tony mancill]

On Sat, Apr 08, 2023 at 09:13:00PM +, Markus Koschany wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #1034059 in zstd-jni-java reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/java-team/zstd-jni-java/-/commit/67b4cbfab56dc775db01963cae87ca223b969b4a

Hi Markus,

Thank you for fixing this, both in unstable and experimental, and to
Andreas for pinpointing the problem.

I wanted to ask you your thoughts on whether the fix should also include
updating debian/control to strictly depend on the version(s) specified
in the patched pom.  Without some explicit declaration of dependencies,
it seems like this is going to break again, right?

Thanks,
tony


signature.asc
Description: PGP signature

Re: RFS: zstd-jni-java/1.5.4-2+ds-1 [Team] -- JNI bindings for Zstd (Architecture-specific files)

[tony mancill]

Hi sun min,

On Fri, Mar 24, 2023 at 03:01:00AM +, sun min wrote:
> Hi, all
> 
> Could someone  have a look at the build status of zstd-jni-java[1] ?
> 
> It seems that the official build was failed while my local build is okay.

Yes, I will take a look.  I also built the package successfully before
sponsoring the upload.  However, I didn't build it in the exact way that
the autobuilders do.

> This patch "debian/patches/modify_pom.patch" defines maven-resources-plugin 
> use version 3.1.0, which is not the latest versin(3.3.0).
> 
> Should this be the problem to cause the build failure ?

I am able to reproduce the build failure when I force a build of
--arch-any in combination with --no-arch-all.  For example, this build
consistently fails:

sbuild --chroot=unstable --dist=unstable --arch-any --no-arch-all 

This build is always successful:

sbuild --chroot=unstable --dist=unstable --arch-any --arch-all

And this build is also successful:

sbuild --chroot=unstable --dist=unstable --no-arch-any --arch-all

Let me know if you have any problems reproducing this locally.  It might
be helpful to invoke the build with DH_VERBOSE=1.

Cheers,
tony


signature.asc
Description: PGP signature

Re: RFS: zstd-jni-java/1.5.4-2+ds-1 [Team] -- JNI bindings for Zstd (Architecture-specific files)

[tony mancill]

On Tue, Mar 21, 2023 at 01:13:35AM +, sun min wrote:
> Package: sponsorship-requests
> 
> zstd-jni-java (1.5.4-2+ds-1) unstable; urgency=medium
> .
>* Team upload.
>* New upstream release.
>* Update debian/libzstd-jni1.symbols.
 
Hello sun min,

Should this upload target unstable or experimental?  (Unless you plan to
file an unblock request with the release team for bookworm, I think it
should experimental.)

If that's okay with you, I will update the changelog before sponsoring
the upload.

Cheers,
tony 


signature.asc
Description: PGP signature

Re: reply: Bazel Removal from Debian

[tony mancill]

On Tue, Feb 21, 2023 at 03:15:18PM +, sun min wrote:
> > If the test passes regularly, and just sometimes fails under the same
> > conditions, I would consider disabling it in autopkgtest rather than have 
> > it not
> > make it into bookworm.  The perfect is the enemy of the good.
> 
> The autopkgtest always fails .
> 
> The maintainer added a “-XX:+UseParallelGC” for garbge collectors 
> param(target jdk16+) which can boost build performance for about 30% compared 
> with the default GC param “-XX:+UseG1GC”[1].
> 
> In fact all the CI stages can be passed if supplied with the default GC param.
> 
> I suspect If the “+UseParallelGC” should be used with some other jvm params 
> together.But I have no idea.

Hi sun min,

It sounds like premature optimization to configure or tune the GC
algorithm at all.  The JVM (any version) will be able to configure
itself, even if perhaps not optimally, without setting either
"+UseParallelGC" or "+UseG1GC".  Is that all we need to change?

We should be able to build and ship the package with conservative
(compatible) defaults and document tuning for better performance in a
wiki or similar.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#1031123: RFS: libcommons-collections4-java/4.4-1 [Team] -- Apache Commons Collections - Extended Collections API for Java

[tony mancill]

On Sun, Feb 12, 2023 at 03:43:05PM +0100, Hilmar Preuße wrote:
> Am 12.02.2023 um 07:54 teilte min sun mit:
> 
> Hi,
> 
> > To access further information about this package, please visit the 
> > following URL:
> > 
> >https://mentors.debian.net/package/libcommons-collections4-java/
> > 
> If you look at that link you'll see a few things, which should the
> resolved. At least the distribution name has to be changed from
> UNRELEASED to the desired value.

As a sponsor, I find it helpful when the distribution name is left as
UNRELEASED in a sponsor request.  It makes it easier to manipulate the
changelog with `dch` while preparing the package for a sponsored upload. 

But as Hilmar notes, the other checks on that page should be addressed.
Specifically:

- fix debian/watch so the local version 4.4 matches upstream 4.4
- update the standards version
- update the debhelper dependency

Cheers,
tony


signature.asc
Description: PGP signature

Re: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules

[tony mancill]

On Fri, Feb 03, 2023 at 07:55:08AM +, min sun wrote:
> 
> Hi mentors!
> 
> I packaged  new version of  libcommons-validator [1] and uploaded again to 
> debian mentors[2], please refer to Upload #2 .

Hi!

I will review and sponsor the upload soon.  Thank you for your
contribution to Debian!

Cheers,
tony

Re: OpenJDK package - jtreg: asmtools

[tony mancill]

On Tue, Jan 10, 2023 at 10:21:34AM +1300, Vladimir Petko wrote:
> Hi,
> 
> Thanks a lot for the reply!!! I am more than happy to try to package it,
> just wondering if I should  put
> "Owner: Debian Java team " and "The package
> will be team-maintained in the Debian Java team" or something else in the
> ITP bug?

That's great! (And I meant to mention that in my first response.)  It
definitely sounds like a good package for team maintenance, and the Java
Team is the right one.  Please let me know if I can help with reviews,
sponsoring, etc.

Thank you,
tony


signature.asc
Description: PGP signature

Re: OpenJDK package - jtreg: asmtools

[tony mancill]

Hello Vladimir,

On Tue, Jan 10, 2023 at 08:22:45AM +1300, Vladimir Petko wrote:
> Dear Maintainers,
> 
> A number of jtreg tests fail during OpenJDK testing with the following
> error:
> 
> `` compiler/c1/KlassAccessCheckTest.java
>  Error. can't find jasm``
> 
> I was wondering if asmtools (https://github.com/openjdk/asmtools) is
> available as a package or if it needs to be packaged?

Both `apt-file search -F jasm` and `apt-cache search asmtools` come up
empty, so it needs to be packaged.

I haven't tried it yet, but after a quick first glance at the source
tree, it appears that the packaging should be straight-forward.  For
example, I didn't notice any build dependencies that we would have to
package first.

Filing either an RFP [1] or ITP [2] bug would be a good next step.

Cheers,
tony

[1] https://wiki.debian.org/RFP 
[2] https://wiki.debian.org/ITP



signature.asc
Description: PGP signature

Re: RFS: stegosuite/0.9.0-1

[tony mancill]

On Fri, Oct 21, 2022 at 02:45:46PM -0400, stegosu...@gmx.net wrote:
> Dear Java packagers,
> 
> I am looking for a sponsor for package "stegosuite".
> 
> * Package name: stegosuite
>   Version : 0.9.0
>   Upstream Author : Stegosuite Developers 
> * URL : https://codeberg.org/tob/stegosuite
> * License : GPL3
>   Programming Lang: Java
>   Description : Steganography tool to hide information in image files

Hello Tobias,

I will sponsor this update.  Thank you for your contribution to Debian!

Cheers,
Tony


signature.asc
Description: PGP signature

Re: Bug#926714: Gradle packaging status update

[tony mancill]

Hi Phil,

On Sat, Aug 20, 2022 at 05:10:10PM +0100, Phil Morrell wrote:

> Feel free to chat with me in #debian-java on irc/matrix and if anyone
> has permissions to the Salsa java-team, please could you add me there.

Done.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#1014310: src:openjfx: fails to migrate to testing for too long: FTBFS on arm64 and armhf

[tony mancill]

Hi Paul,

On Sat, Aug 13, 2022 at 09:51:03PM +0200, Paul Gevers wrote:
> Hi,
> 
> On Sun, 3 Jul 2022 21:25:49 +0200 Paul Gevers  wrote:
> > Your package failed to build from source on arm64 and armhf while it
> > built there successfully in the past.
> 
> I just checked to see if there would be a commit upstream to fix the FTBFS,
> but it seems that upstream is active and is at release 20+1 (from 16 days
> ago), but in a new place (so the debian/watch file isn't working).
> 
> https://github.com/openjdk/jfx

For JDK 11, I believe we want https://github.com/openjdk/jfx11u
For JDK 17, it would be https://github.com/openjdk/jfx17u 
 
> You may want to look into this.

Agreed.  Java Team, should we be targeting OpenJFX 17 for bookworm, or
is an updated build of OpenJFX 11 of use?


signature.asc
Description: PGP signature

Re: service-wrapper-java 20 releases / 6 years behind

[tony mancill]

On Tue, Jun 07, 2022 at 11:12:24PM +0200, Pierre Gruet wrote:
> Hello,
> 
> Le 05/06/2022 à 18:27, zzz a écrit :
> > This is a dependency of the i2p project that I work on.
> > If there's any maintainer available to bring it up-to-date,
> > I'd really appreciate it.
> 
> I gave it a try tonight, packaging version 3.5.50. I guess it is OK, the
> main thing is probably that the src/bin/sh.script.in has been renamed to
> src/bin/App.sh.in, and a file src/bin/App.shconf.in has been added
> alongside. I felt like I could ignore it, do you have any opinion about it?
> 
> My packaging allows mpj and i2p to build successfully, so I guess I will
> upload the package soon.
> You can see my packaging work at [0].

Hello Pierre,

Thank you for the long overdue update!  I noticed the build failure on
s390x and volunteer to look into that if you would like.  (I recently
configured a local s390x QEMU environment for another project and so
have it ready to go.)

Regards,
tony


signature.asc
Description: PGP signature

Re: Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy

[tony mancill]

On Mon, Mar 28, 2022 at 07:17:46PM +0300, Andrius Merkys wrote:
> Hi Alexandre,
> 
> On 2022-03-23 16:33, Alexandre Rossi wrote:
> > Seems to work:
> > 
> >   $ ls -la /usr/share/java/htmlcleaner*
> >   lrwxrwxrwx 1 root root 15 18 mars  18:20 
> > /usr/share/java/htmlcleaner-2.26.jar -> htmlcleaner.jar
> >   -rw-r--r-- 1 root root 176219 18 mars  18:20 
> > /usr/share/java/htmlcleaner.jar
> >   $ sudo dpkg -i 
> > oss/debian/davmail/libhtmlcleaner-java_2.26-1+fix+bad+jar+name+1_all.deb
> >   [...]
> >   $ ls -la /usr/share/java/htmlcleaner*
> >   -rw-r--r-- 1 root root 176219 23 mars  15:27 
> > /usr/share/java/htmlcleaner-2.26.jar
> >   lrwxrwxrwx 1 root root 20 23 mars  15:27 
> > /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar
> 
> Many thanks for the proposed patch. It seems we need a decision now on
> which one is actually buggy: maven-debian-helper or java-policy. I would
> vote for upholding the java-policy if only the symlink placement switch
> does not break anything (neither reverse dependencies not the update
> mechanism). Having versionless symlinks parallels nicely lib*-dev shlib
> scheme and there might be situations where this is beneficial for Java
> too. Unluckily enough, there are >700 source packages now directly
> affected by this [1].
> 
> [1] https://lintian.debian.org/tags/bad-jar-name

Hello Andrius, hi Alexandre,

I can't speak to every reverse dependency, but I don't expect breakage
to occur with this change, assuming of course that the update mechanism
works consistently.  I also agree with you that a versionless symlink to
a versioned jar file seems preferable.  As you mention, if nothing else,
it is consistent with other languages in Debian.  So my vote is to
accept the change.

That fact that so many packages are affected does mean there will be a
lot of uploads, but ideally we will upload at least once per release
cycle (anyway), so the timing of this patch and proposal is reasonable.

I am interested to hear other opinions from the Debian Java Team.

Cheers,
tony


signature.asc
Description: PGP signature

Re: uscan: error: jh_repack --upstream-version 2.7 subprocess returned exit status 1

[tony mancill]

On Fri, Jan 21, 2022 at 01:37:10PM +0100, Mathieu Malaterre wrote:
> [cc me please]
> 
> Hi there,
> 
> I am trying to update xmlgraphics-commons but I fail to understand
> what is going on with:
> 
> % uscan --download --force-download --rename
> uscan: Newest version of xmlgraphics-commons on remote site is 2.7,
> local version is 2.6
> uscan:  => Newer package available from:
> => 
> https://www.apache.org/dist/xmlgraphics/commons/source/xmlgraphics-commons-2.7-src.tar.gz
> gpgv: Signature made Wed 12 Jan 2022 12:24:17 PM CET
> gpgv:using RSA key 5C9A30FF22B2C02F30261C305B93F1DF7CDB6DEA
> gpgv: Good signature from "Simon Steiner (CODE SIGNING KEY)
> "
> Successfully renamed ../xmlgraphics-commons-2.7-src.tar.gz to
> ../xmlgraphics-commons_2.7.orig.tar.gz.
> uscan: error: jh_repack --upstream-version 2.7 subprocess returned exit 
> status 1
> 
> Could someone comment on d/watch from xmlgraphics-commons vs jh_repack ?

Hi Mathieu,

This is my mistake for updating debian/watch to version=4.  From the
manpage for uscan in the "HISTORY AND UPGRADING" section:

> Version 3
>   • uscan invokes the custom script as "script --upstream-version version 
> ../spkg_version.orig.tar.gz".
>
> Version 4
>   • uscan invokes the custom script as "script --upstream-version version".

I have tested locally, updated debian/watch, and pushed this to the
Salsa repo.

My apologies for the confusion.
tony


signature.asc
Description: PGP signature

Re: libjpf-java

[tony mancill]

On Mon, Dec 20, 2021 at 10:22:04PM +0100, Sebastiaan Couwenberg wrote:
> libjpf-java is affected by an RC which in turn affects its rdepds like
> osmosis.
> 
> I've updated the package in git to modernize the packaging.
> 
> tony, do you want to make any changes before upload?

Hi Bas,

I pulled and built and the updates all look good to me.
Thank you for your help!

Cheers,
tony


signature.asc
Description: PGP signature

update of logback to 1.28

[tony mancill]

Hello Java Team,

I have prepared an update of logback to 1.2.8, which addresses the same
type of JNDI vulnerability recently announced for log4j2.

Additional details in https://jira.qos.ch/browse/LOGBACK-1591 and
https://github.com/qos-ch/logback/compare/v_1.2.7...v_1.2.8

A CVE has not yet been assigned, but it seems better to go ahead and
upload the updated package and then associate the CVE with the fixed
version in the archive once the CVE is assigned.  That is, I would
rather have code that addresses potential vulnerabilities sooner rather
than later.

Any concerns with an upload?  Since it addresses a security concern, I
am intending to set the urgency=high.  I have kicked off a ratt build
(133 reverse build dependencies) that is still underway, but everything
has been successful so far.  If there are any build failures, I can
follow-up on them sooner.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1001463: java-policy: Please retitle to "Java Policy for Debian"

[tony mancill]

On Sun, Dec 12, 2021 at 10:37:54AM +0100, Emmanuel Bourg wrote:
> Le 10/12/2021 à 15:20, Felix Lechner a écrit :
> 
> > Lintian cites your manual as supporting documentation for several
> > tags. [1][2][3][4][5][6][7][8] Such references help users when
> > grasping the conditions that provoke Lintian's recommendations. In our
> > view, your policy [9] should be named "Java Policy for Debian."
> 
> 
> "Debian Policy for Java" or "Java Policy for Debian", which one is correct?

Why not "Debian Java Policy" ?  That matches Perl [1] and Python [2].

[1] https://www.debian.org/doc/packaging-manuals/perl-policy/
[2] https://www.debian.org/doc/packaging-manuals/python-policy/


signature.asc
Description: PGP signature

jblas update to 1.2.5?

[tony mancill]

Hello Debian Med,

jblas (http://jblas.org/) is a Debian Java team package, but I think it
is more appropriate to ask about users here.  Upstream has released a
new version, 1.2.5; Debian currently packages 1.2.4.  From the upstream
release notes:

> Release 1.2.5 - Aug 20, 2020
> 
> It has been a while! Too long, maybe. In the meantime, GPUs and tensorflow 
> and pytorch have raised the bar when
> it comes to ML related computing. Adding automatic differentiation to compute 
> gradients has become a must-have feature
> jblas doesn't have. If you're interested in that for the JVM, have a look at 
> deeplearning4j.org.
> 
> It seems people are still using jblas, therefore here is a small update which 
> makes jblas work under ubuntu20.04 (amd64)
> and arm64. For these new versions, I switched to openblas, as performance 
> seems to be comparable, but compilation is
> much easier.
> 
> Major changes and updates:
> 
> - updated Linux amd64 to work on ubuntu20.04. Updated libgfortran from 
> version 3 to 4. Packaged libgfortran and
>   libquadmath into the JAR file so you don't have to install libgfortran.so.3 
> anymore.
> - Switched from ATLAS to openblas. Because openblas is so much easier to 
> compile and we can just use the libraries
>   that are installed. Hopefully the performance / errors are the same.
> - Added libraries for arm64 (Raspberry Pis for 64bit images like ubuntu 
> server) and AWS Graviton instances.

My first question is, do we have users?  Is the software useful to
maintain in Debian?  The popcon for the package is low (around 15) and
there haven't been recent bug reports.  If there are users, I will
gladly prepare an update.

And if we do update in Debian, I thought readers of this list might have
opinions about whether I should switch the Debian packaging from
building against lapack to openblas.

Thank you for your input!
tony


signature.asc
Description: PGP signature

Re: packaging Go runtime for ANTLR4

[tony mancill]

On Thu, Jul 29, 2021 at 01:06:11AM +0530, Nilesh Patra wrote:
> On Wed, Jul 28, 2021 at 08:41:46AM +0200, Emmanuel Bourg wrote:
> >> Hi Peymaneh,
> >>
> >> Le 2021-07-27 10:09, Peymaneh Nejad a écrit :
> >>
> >> > Is it intended or wished for that additional runtimes other than Java
> >> > are packaged in seperate source packages
> >>
> >> Yes it is, for several reasons:
> >> - The Java Team doesn't have the time and skills to maintain properly a
> >> multi-language package like ANTLR. The Java part is sufficiently complex on
> >> its own, we'd rather not have to care about the other languages.
> >> - Different language ecosystems often require distinct and slightly
> >> incompatible versions of ANTLR.
> >> - Handling several languages in the same package makes upgrades and
> >> regression testing much more difficult.
> >> - ANTLR is a core package of the Java ecosystems, including more languages
> >> increases the dependency tree of the Java packages and makes the
> >> bootstrapping harder.
> >>
> >> So it's preferable to have a clear separation of responsability with
> >> different source packages, each language team having the freedom to 
> >> maintain
> >> its version as needed without impacting the others.
> 
> > I don't disagree with Emmanuel's statements about the importance of
> > ANTLR and why it is helpful to maintain separation.  However, I don't
> > think introducing a separate source package each language ecosystem is
> > necessarily best for Debian.
> 
> > It causes additional work for the Security team when in the event there
> > vulnerabilities.  It potentially confuses users (and Debian developers)
> > by creating a distinction that does not exist upstream.  It also means
> > that we will release with different versions of ANTLR for different
> > languages, which feels very "non-distro" to me.  (What happens if the
> > version of the ANTLR parser for language X is subtly incompatible with
> > language Y, and a user runs a system on Debian that requires both
> > bindings?)
> 
> Chiming in here, since it was originally me who asked Peymaneh to contact
> this list, and I was sponsoring the same.
> I was initially of the same opinion that it should be unified into a
> single source package, but ebourg's points against doing that are pretty
> strong too.



> 2) Do "$something-else" for all these packages to stay in sync - again,
> probably bumping versions only when needed.
> With this approach, I do not see a problem in introducing a Go runtime
> source package there

100% agreed.  I don't mean to belabor the point.  Thank you for the
discussion and for the links to the other language packages.

Cheers,
tony

Re: packaging Go runtime for ANTLR4

[tony mancill]

On Wed, Jul 28, 2021 at 08:41:46AM +0200, Emmanuel Bourg wrote:
> Hi Peymaneh,
> 
> Le 2021-07-27 10:09, Peymaneh Nejad a écrit :
> 
> > Is it intended or wished for that additional runtimes other than Java
> > are packaged in seperate source packages
> 
> Yes it is, for several reasons:
> - The Java Team doesn't have the time and skills to maintain properly a
> multi-language package like ANTLR. The Java part is sufficiently complex on
> its own, we'd rather not have to care about the other languages.
> - Different language ecosystems often require distinct and slightly
> incompatible versions of ANTLR.
> - Handling several languages in the same package makes upgrades and
> regression testing much more difficult.
> - ANTLR is a core package of the Java ecosystems, including more languages
> increases the dependency tree of the Java packages and makes the
> bootstrapping harder.
> 
> So it's preferable to have a clear separation of responsability with
> different source packages, each language team having the freedom to maintain
> its version as needed without impacting the others.

I don't disagree with Emmanuel's statements about the importance of
ANTLR and why it is helpful to maintain separation.  However, I don't
think introducing a separate source package each language ecosystem is
necessarily best for Debian.

It causes additional work for the Security team when in the event there
vulnerabilities.  It potentially confuses users (and Debian developers)
by creating a distinction that does not exist upstream.  It also means
that we will release with different versions of ANTLR for different
languages, which feels very "non-distro" to me.  (What happens if the
version of the ANTLR parser for language X is subtly incompatible with
language Y, and a user runs a system on Debian that requires both
bindings?)

tony


signature.asc
Description: PGP signature

Re: packaging Go runtime for ANTLR4

[tony mancill]

On Tue, Jul 27, 2021 at 10:47:36AM -0400, Olek Wojnar wrote:
> On Tue, Jul 27, 2021, 04:09 Peymaneh Nejad  wrote:
> > Is it intended or wished for that additional runtimes other than Java are
> > packaged in seperate source packages, or would it be better to add another
> > binary package (that'd be golang-github-antlr-antlr4-dev) to the existing
> > source?
> >
> 
> In principle, if the same source is used for all of the binaries, I feel
> that we should maintain a single Debian source package. Unless there's some
> compelling reason to split them.
> 
> I can't think of a good reason to split source but I can definitely think
> of several good reasons to have a single source package! e.g. inter-binary
> compatibility, security updates, etc.

Agreed!  Thank you Peymaneh and Olek.


signature.asc
Description: PGP signature

Re: Request to join java-team on salsa

[tony mancill]

Hi Nilesh,

On Tue, Jul 06, 2021 at 08:25:08PM +0530, Nilesh Patra wrote:
> On Tue, 6 Jul 2021 at 20:22, Nilesh Patra  wrote:
> 
> > Hi,
> >
> > I am Nilesh and I am a Debian Developer, and work mostly with Debian
> > med.
> > I wante to work on java packages with common
> > intersection with the med team, for instance a target med-team java
> > packages
> > whose dependencies are in the java team.
> >
> > I also work on reproducible builds and cross-buildability, and joining
> > the team would make it easier for me to simply commit and do a team
> > upload when need be.
> >
> > I have already requested access on the salsa UI a few weeks ago. Please
> > consider to add me in.
> >
> 
> Ah, missed two things: My salsa username is "nilesh"
> And since I'd intend to enable salsa-ci for every package I'd work on,
> please consider to bump my access level to maintainer

I have added you to the team as a Maintainer.  Thank you for
contributing!

Be aware that there is not consensus among members of the Java Team
regarding use of salsa-ci, so please discuss on-list before enabling for
large numbers of team-maintained packages.

Cheers,
tony


signature.asc
Description: PGP signature

Re: New source package httpcomponents-client5

[tony mancill]

On Wed, Apr 14, 2021 at 04:34:18PM +0200, Markus Koschany wrote:
> Hi,
> 
> I intend to package the 5.x series of httpcomponents-client [1][2][3]. We
> already have the 4.x series in Debian packaged as src:httpcomponents-client. 
> Is
> there anything against packaging the 5.x series as src:httpcomponents-client5?

Hi Markus,

No objections from me.  It's nice the artifactId is httpclient5, so we
can name the JAR the same and the package should co-installable with the
the 4.x series.  (I only checked the main JAR, hopefully that holds true
for ancillary JARs as well.)

Thank you for packaging this.

Cheers,
tony


signature.asc
Description: PGP signature

Re: [RFS] eclipselink

[tony mancill]

Hi Pierre,

I reviewed the diff, built the package, and build the r-deps
(libspring-java) with ratt.

Thank you for the bug fix.  DM rights granted.

Cheers,
tony

On Wed, Jan 27, 2021 at 05:15:55PM +0100, Pierre Gruet wrote:
> Hello,
> 
> I have updated the package eclipselink, which FTBFS due to a recent change
> brought by the last upstream version of its build-dependency libjsonp-java.
> 
> Would you please review and upload it [0] or grant me DM rights?
> 
> dcut dm --uid "Pierre Gruet" --allow eclipselink
> 
> Thanks a lot in advance,
> Pierre
> 
> 
> [0] https://salsa.debian.org/java-team/eclipselink/


signature.asc
Description: PGP signature

Re: gs-collections vs eclipse-collections

[tony mancill]

On Thu, Jan 07, 2021 at 07:10:25PM +0100, Vincent Prat wrote:
> Hi Tony,
> 
> >> Should we package Eclipse Collections as a separate project (in which
> >> case I will submit an ITP bug), or update and rename the existing package?
> >> For your information, the package gs-collections has no reverse
> >> dependency and has not been updated since September 2017.
> > I see either choice as acceptable, but my suggestion is to update
> > the existing package (and rename it only if you think it is necessary).
> > It is the evolution of (and thus an update to) gs-collections.  This
> > approach means you don't have to go through NEW, we don't have to
> > introduce a new package to archive, and developers who know the software
> > by gs-collections will still find it.  Even if there aren't r-deps in
> > Debian, perhaps a downstream is using gs-collections and will benefit
> > from the update without a rename.
> 
> What about developers who do not know the software and need Eclipse
> Collections?
> Do they have to guess that the Java package is provided by the Debian
> package gs-collections?

Yes, this happens all of the time already.

> Eclipse Collections is indeed the evolution of GS Collections, but the
> latter still exists as such, even though only bug fixes are made.
> By the way, the version present in Debian is out-of-date.
> 
> > If you decide to create a new source package for eclipse-collections,
> > please also take the time to RM gs-collections.  We don't need to keep
> > the old package around if we have a compatible replacement.  (I'm
> > assuming that eclipse-collections is a drop-in replacement, or nearly so
> > - maybe just a Java package name change?)
> 
> Yes, the Java package name is different. So, even if the API is
> compatible, this would require downstream to change imports, classpaths,
> etc.

It sounds you're making the case for having both packages within
Debian?!?
 
> In any case, since Emmanuel Bourg was the one who packaged
> gs-collections in the first place, it would be nice to have his
> opinion on the question.

Sure.  I won't comment further.

tony


signature.asc
Description: PGP signature

Re: gs-collections vs eclipse-collections

[tony mancill]

Hi Vincent,

On Thu, Jan 07, 2021 at 01:56:41AM +0100, Vincent Prat wrote:
> Dear all,
> 
> The latest version of NatTable (2.0.0) depends on Eclipse Collections
> (https://www.eclipse.org/collections/).
> Originally, it was called GS Collections, and was renamed when it
> migrated to the Eclipse Foundation.
> GS Collections is present in Debian (as gs-collections:
> https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections.
> 
> Should we package Eclipse Collections as a separate project (in which
> case I will submit an ITP bug), or update and rename the existing package?
> For your information, the package gs-collections has no reverse
> dependency and has not been updated since September 2017.

I see either choice as acceptable, but my suggestion is to update
the existing package (and rename it only if you think it is necessary).
It is the evolution of (and thus an update to) gs-collections.  This
approach means you don't have to go through NEW, we don't have to
introduce a new package to archive, and developers who know the software
by gs-collections will still find it.  Even if there aren't r-deps in
Debian, perhaps a downstream is using gs-collections and will benefit
from the update without a rename.

If you decide to create a new source package for eclipse-collections,
please also take the time to RM gs-collections.  We don't need to keep
the old package around if we have a compatible replacement.  (I'm
assuming that eclipse-collections is a drop-in replacement, or nearly so
- maybe just a Java package name change?)

> Best wishes for the new year

Same to you!

Cheers,
tony


signature.asc
Description: PGP signature

Re: [RFS] libmiglayout-java

[tony mancill]

Hi Pierre,

On Thu, Dec 31, 2020 at 06:47:56PM +0100, Pierre Gruet wrote:
> Hi,
> 
> I have worked on libmiglayout-java and fixed its serious bug. Would you mind
> either reviewing [0] or giving me DM rights?

I took a quick look at the commits in the Salsa repo.  They look fine to
me.
 
> dcut dm --uid "Pierre Gruet" --allow libmiglayout-java

Done.

> With a bit of advance, best wishes for 2021!

Likewise!

Cheers,
tony


signature.asc
Description: PGP signature

Re: Joining the Java Team

[tony mancill]

On Tue, Dec 29, 2020 at 08:20:52PM -0500, Louis-Philippe Véronneau wrote:
> Hello folks!
> 
> I've started to work on packaging backport9 [1], a dependency for jruby
> 9.2.x and I would very much like to maintain in the Java Team. I think
> teams are great :)
> 
> Can I be added to the Salsa group? My username is pollo.


Hi Louis-Philippe Véronneau,

Welcome to the Java Team!

Cheers,
tony


signature.asc
Description: PGP signature

Re: Please add me to the group on Salsa

[tony mancill]

On Tue, Dec 29, 2020 at 01:25:19PM +0100, Philipp Huebner wrote:
> Hi,
> 
> could somebody please add me to the java-team on Salsa?
> 
> I would like to remove myself as uploader from the remaining freehep
> packages.

Hi Philipp,

You should have access now.  Please let me know if it didn't work.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#929530: libsis-base-java: unaligned access on armhf

[tony mancill]

On Wed, Dec 02, 2020 at 08:59:16PM +0100, Andreas Tille wrote:
> Control: tags -1 help
> 
> I wonder whether some Java expert might be able to clarify the
> situation in bug #929530.

Hi Andreas,

There is good news and bad news... :)  The good news is that the
unaligned access error is no longer an issue on armhf.  I am able
to compile without JVM crashing on the amdahl porter box:

Java VM: OpenJDK 64-Bit Server VM (v11.0.9.1+1-post-Debian-1)
CPU Architecture: aarch64
OS: Linux (v4.19.0-12-arm64)

I've run the build at least 6 times by now and not observed any issues
with the JVM.

The bad news is that tests are consistently failing.  Specifically, the
code [1] that runs after this test [2] fails consistently while trying
to clean up after the test with the error below:

[1] 
https://salsa.debian.org/med-team/libsis-base-java/-/blob/master/source/java/ch/systemsx/cisd/base/tests/AbstractFileSystemTestCase.java#L139
[2] 
https://salsa.debian.org/med-team/libsis-base-java/-/blob/master/sourceTest/java/ch/systemsx/cisd/base/unix/UnixTests.java#L121


Running testTouchSymLinkAndFileRealtimeTimer
Could not delete the directory 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 
exceptions: [java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink]
Could not delete the directory 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests in second try 
because: 1 exceptions: [java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink]
Exception in thread "main" org.apache.commons.io.IOExceptionList: 1 exceptions: 
[java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink]
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:345)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1206)
at 
ch.systemsx.cisd.base.tests.AbstractFileSystemTestCase.afterClass(AbstractFileSystemTestCase.java:139)
at ch.systemsx.cisd.base.unix.UnixTests.main(UnixTests.java:495)
at ch.systemsx.cisd.base.AllTests.main(AllTests.java:56)
Caused by: java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1425)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:338)
... 4 more
Caused by: java.nio.file.NoSuchFileException: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink
at 
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at 
java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at 
java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
at 
java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.base/java.nio.file.Files.readAttributes(Files.java:1763)
at java.base/java.nio.file.Files.size(Files.java:2380)
at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:361)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:304)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:280)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1423)
... 5 more

However the symlink *is* present after the build (I have to remove it from
the build tree manually), so I don't know yet whether this is an issue
with the code on this architecture or something about how I'm using the
schroot on the porterbox.

In any event, my inclination is to close the unaligned access bug and
open a new bug for the test failure on this architecture.  I can't
reproduce it on amd64.

Cheers,
tony

Re: Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

[tony mancill]

On Thu, Dec 03, 2020 at 05:34:25PM +, Adam D. Barratt wrote:
> On Thu, 2020-12-03 at 11:28 +, Adam D. Barratt wrote:
> > [adding d-java to Cc for greater visibility]
> > 
> > On Mon, 2020-11-30 at 09:21 +, Adam D. Barratt wrote:
> > > On Wed, 2020-11-25 at 20:23 -0800, tony mancill wrote:
> > > > I propose that openjdk-11 be updated to upstream 11.0.9.1+1 in
> > > > the
> > > > upcoming stable point release.  This update addresses a
> > > > regression
> > > > [1] introduced in upstream release 11.0.9+11, which is present in
> > > > buster via a security upload [2].  This keeps Debian on par with
> > > > other vendors - e.g. RedHat [3], Ubuntu [4], and AdoptOpenJDK [5]
> > > > -
> > > > and introduces the same upstream version currently available in
> > > > testing and unstable.
> > > 
> > > The versioning here appears to cause issues in at least Jenkins -
> > > see 
> > > https://issues.jenkins.io/projects/JENKINS/issues/JENKINS-64212
> > 
> > Have there been any further issues that people are aware of?
> > 
> > The Jenkins fix is not yet available to most users if I understand
> > correctly, so we need to consider the tradeoffs between the
> > regression on the OpenJDK side and requiring manual intervention on
> > Jenkins installations (and possibly other things confused by the
> > version string).
> 
> To tie up a couple of IRC conversations with Moritz, the fixed Jenkins
> versions have now been released, so we can probably just tell people
> they need to upgrade.

  I was trying to devise a moral calculus for the trade-off.

I haven't been able find any statistics about the prevalence of JVM
crashes due to the regression, and so reached out to the folks at
AdoptOpenJDK earlier today.  They said that they had seen a number of
occurrences prior to the patch.

Given that the JVM bug can affect any application seems to tilt the
scale towards proceeding with the JDK update, so the release of an
upgrade path for Jenkins is a relief.

Thank you to you and Moritz for your work on this.
tony

Re: 8u275?

[tony mancill]

On Mon, Nov 30, 2020 at 09:58:09PM +0100, Thorsten Glaser wrote:
> Hi *,
> 
> should we merge that to sid and stretch-security?
> 
> openjdk-8 (8u275-b01-0ubuntu1) hirsute; urgency=medium
> 
> If it’s just an “ok, do it, and we don’t require any extra changes”
> I can even do it to take the load off people.

+1, both for getting this into the Debian and I am also offering to help (if 
that helps).

Thank you for noticing this Thorsten.

Cheers,
tony

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

[tony mancill]

On Wed, Nov 25, 2020 at 09:26:13AM +0100, Moritz Muehlenhoff wrote:
> On Tue, Nov 24, 2020 at 03:05:26PM -0800, tony mancill wrote:
> > Hello Matthias, Tiago, and other members of the OpenJDK team,
> > 
> > Thank you for the recent uploads of 11.0.9.1 [1].  Given that it
> > addresses JDK-8250861 [2] (which is serious, although I'm unsure as to
> > whether it is DSA-worthy) and there are likely derivatives that would
> > benefit from the update, would you mind if I prepare an upload of
> > 11.0.9.1 for Debian stable?
> 
> This doesn't seem like a security issue, but a generic bug affecting
> 11.0.9?
> 
> If this can't wait until the next CPU in January, fixing this
> via the upcoming 10.7 point release is an option:
> https://lists.debian.org/debian-live/2020/11/msg0.html
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

I agree that it's a generic bug affecting 11.0.9 (albeit a serious one).
I will prepare an upload for stable-proposed-updates that will replace
yours from a few weeks ago [1].

Since we have stacked proposed updates, do you know whether the debdiff
for the release.debian.org bug should be against 11.0.9+11-1~deb10u1
(current proposed update) or 11.0.8+10-1~deb10u1 (current version in
stable)?  I suppose I can attach them both.

Thank you both for the responses,
tony

[1] 
https://tracker.debian.org/news/1188653/accepted-openjdk-11-110911-1deb10u1-source-amd64-all-into-proposed-updates-stable-new-proposed-updates/


signature.asc
Description: PGP signature

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

[tony mancill]

Hello Matthias, Tiago, and other members of the OpenJDK team,

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

Thank you,
tony

[1] https://tracker.debian.org/pkg/openjdk-11  
[2] https://bugs.openjdk.java.net/browse/JDK-8250861


signature.asc
Description: PGP signature

Re: [RFS] libdsiutils-java

[tony mancill]

On Mon, Oct 19, 2020 at 11:31:26PM +0200, Pierre Gruet wrote:
> Hello,
> 
> libdsiutils-java has just exited NEW; I have prepared a source-only
> upload, additionally fixing missing elements in the classpath.
> 
> 
> Would you mind either reviewing [0] or giving me DM rights?
> 
> 
> dcut dm --uid "Pierre Gruet" --allow libdsiutils-java

Hi Pierre,

The package looks good to me.  Thanks!

> Action: dm
> Fingerprint: C63DBBEF21427CE249DBD96B061212944647A411
> Allow: libdsiutils-java
>
Fingerprint: C63DBBEF21427CE249DBD96B061212944647A411
Uid: pgtdeb...@free.fr
Allowed: libdsiutils-java

Cheers,
tony


signature.asc
Description: PGP signature

Re: Solr version

[tony mancill]

On Sun, Sep 27, 2020 at 01:47:06PM +0100, Sudip Mukherjee wrote:
> On Sun, Sep 27, 2020 at 12:01 PM Emmanuel Bourg  wrote:
> >
> > On 27/09/2020 00:23, Markus Koschany wrote:
> >
> 
> >
> > > Why don't we just create more or less official (even though not really
> > > perfect) Debian packages for netbeans, eclipse, solr, hadoop, etc. by
> > > using tools like jdeb [1] for ant and maven projects or
> > > gradle-ospackage-plugin for gradle [2].
> >
> > I fully share Markus' analysis. Packaging these huge projects isn't
> > viable without more regular, dedicated, contributors.
> 
> +1
> 
> I had been trying to package #943552 and it took me almost one year to
> have it working (still all the features not working). I dont know yet
> if it can really be maintained properly with that huge number of
> dependencies (upstream packaging had 287 jars).

I feel the same way.  

We offer our users a 4 year old copy of JabRef that builds from source,
transitively, all the way down, and so they have little choice but to go
install the "insecure" bundle from upstream.

I like the idea of focusing on a toolchain to make it easier to build
these packages.  We should be able to offer them via contrib [1].

Cheers,
tony

[1] 
https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area


signature.asc
Description: PGP signature

Re: Solr version

[tony mancill]

On Sat, Sep 26, 2020 at 03:40:39PM +0200, Markus Koschany wrote:
> In short: 3.6.2 will not be released again, 8.x could make it into
> Debian 11 but there is a big question mark at the moment, more help is
> appreciated.

Hi Markus,

Can you post a list of what others can help with?

Cheers,
tony 


signature.asc
Description: PGP signature

Re: incomplete manifest in jar files

[tony mancill]

On Sun, Sep 20, 2020 at 01:01:43AM +0100, Sudip Mukherjee wrote:
> On Sat, Sep 19, 2020 at 11:34 PM tony mancill  wrote:
> >
> > On Fri, Sep 18, 2020 at 12:40:44PM +0100, Sudip Mukherjee wrote:
> > > Hi All,
> > >
> > > While working on #943552 I faced few problems with manifest files and
> > > as a result I am unable to list them in the bundles.info file.
> > >
> > > <--snip-->
> > >
> > > If no-one has any problem with my suggested changes then I can go
> > > ahead and team-upload them. All the changes are only in the
> > > MANIFEST.MF and nothing in the code.
> >
> > Hi Sudip,
> >
> > Sounds reasonable to me.
> 
> Thanks Tony. And, I have a doubt about another package, maybe you can
> tell me about it. I noticed that there was a "lucene" which was
> removed when "lucene2" was introduced,  then that was removed and
> "lucene4.10" package was added. Now, I am looking at upstream v8.6.2,
> so I need to package it as "lucene8" ? And I am mostly puzzled about
> why instead of updating the original "lucene" source package, separate
> source was packaged for each version? for transition?

Hi Sudip,

Good question.  I don't think it is for transition but probably because
lucene3 and lucene4 aren't API-compatible and we weren't able to port
the packages that depend on them.  (Although I don't recall specifically
and haven't checked.)

You can use japi-compliance-checker or clirr to assess compatibility
between lucene4.10 and version 8.  Maybe we can port forward this time
around.  But I am not familiar with lucene, so maybe it's easier to
introduce a new lucene8 source package.

$ reverse-depends -b liblucene4.10-java
Reverse-Build-Depends
* derby
* h2database
* openjfx
* scilab

$ reverse-depends -b liblucene3-java   
Reverse-Build-Depends
* netbeans
* omegat

Cheers,
tony


signature.asc
Description: PGP signature

Re: incomplete manifest in jar files

[tony mancill]

On Fri, Sep 18, 2020 at 12:40:44PM +0100, Sudip Mukherjee wrote:
> Hi All,
> 
> While working on #943552 I faced few problems with manifest files and
> as a result I am unable to list them in the bundles.info file.
> 
> <--snip-->
> 
> If no-one has any problem with my suggested changes then I can go
> ahead and team-upload them. All the changes are only in the
> MANIFEST.MF and nothing in the code.

Hi Sudip,

Sounds reasonable to me.

Cheers,
tony


signature.asc
Description: PGP signature

Re: JDK Mission Control

[tony mancill]

On Sat, Sep 12, 2020 at 04:40:43PM +0200, Florian Weimer wrote:
> Is anyone working on packaging this tool?  Upstream is here:
> 
>   
>   

Not yet, but I do use it regularly (currently using the binaries
published by AdoptOpenJDK: https://adoptopenjdk.net/jmc.html) and
think it would be nice to have a .deb if the build-dependencies are too
much of a hassle.

I'd be happy to collaborate and help with testing if you'd like to have
a go at it.

IMO, I don't see any need to package version 7.x.  Debian can start with
8.x from the sources here: https://github.com/openjdk/jmc

Cheers,
tony 


signature.asc
Description: PGP signature

Re: Packaging of Zstd JNI bindings

[tony mancill]

Hello Olek,

On Wed, Sep 09, 2020 at 10:44:35AM -0400, Olek Wojnar wrote:
> Hello fellow Java developers,
> 
> Has anyone been looking at packaging the JNI bindings for Zstd? [1][2]
> Seems like a very useful piece of software and a fairly simple package. I
> didn't see anything on WNPP but I wanted to check here as well before
> filing an RFP.

I would interpret the silence as "no."  The library looks useful,
although having a build-dependency on sbt could be a drawback.  At the
same time, perhaps it will further our capabilities more generally.  :)

> Thanks and I hope everyone is having a great week!

Same to you!

Cheers,
tony

Re: Building r-cran-rcdk with cdk [Was: Re: Upgrading freehep to latest upstream (needed by cdk and probably others)]

[tony mancill]

On Tue, Jul 28, 2020 at 11:56:24AM +0300, mer...@debian.org wrote:
> Hi Tony,
> 
> On 2020-07-27 16:50, tony mancill wrote:
> > On Mon, Jul 27, 2020 at 08:51:49AM +0300, mer...@debian.org wrote:
> >> What is more, the subtree tool/smsd/ contains only pom.xml, what might
> >> be the reason of codeless jar. It seems to me that cdk-smsd is legacy
> >> now, and I would suggest asking the upstream for advice how to port code
> >> depending on it.
> > I still plan to take a look at what it would take to compile the
> > legacy/pom.xml.
> 
> Sure, please do. However, I would not count too much on this pom, as it
> may get removed in the upcoming cdk releases.

Fair enough...  In the long run, it is likely that porting r-cran-rcdk
is a better use of time.  However, I got interested in it and here is
the status so far:

1) I updated jgrapht0.6 to install a pom file and uploaded a new
package to unstable. 

2) I updated the cdk source package to build-dep on the javacc maven
plugin and re-enabled the legacy pom.

3) I used ratt to build packages that build-depend on cdk.  The
new package addresses the issue with r-cran-rcdk, but cinfony fails:

2020/07/28 20:27:10 PASSED: r-cran-rcdklibs
2020/07/28 20:27:10 FAILED: cinfony (see buildlogs/cinfony_1.2-4)

However, the cinfony failure on my system is for:

  unsat-dependency: python-indigo:amd64

And it also fails when built against cdk_2.3.134.g1bb9a64587-1, so I
don't think this is related to my change.

I created a merge request [1] so you can take a look.  I'm happy to
prepare an upload if it looks okay to you.

Cheers,
tony

[1] https://salsa.debian.org/java-team/cdk/-/merge_requests/4


signature.asc
Description: PGP signature

Re: Building r-cran-rcdk with cdk [Was: Re: Upgrading freehep to latest upstream (needed by cdk and probably others)]

[tony mancill]

Hi Andrius,

On Mon, Jul 27, 2020 at 08:51:49AM +0300, mer...@debian.org wrote:
> Hello,
> 
> On 2020-07-27 08:38, tony mancill wrote:
> >> It actually seems that org/openscience/cdk/smsd/Isomorphism is not
> >> part of the currently packaged CDK.  Any idea how to solve this?
> > I am just starting to take a look a this, but I think we need to spend
> > some more time with CDK.  That class is found in the "legacy" directory
> > of the sources:
> > 
> > ➜  cdk-2.3.134.g1bb9a64587 find . -name Isomorphism.java
> > ./legacy/src/main/java/org/openscience/cdk/smsd/Isomorphism.java
> > 
> > But the legacy pom is ignored:
> > 
> >   
> > https://salsa.debian.org/java-team/cdk/-/blob/master/debian/libcdk-java.poms#L91
> 
> Indeed, cdk-smsd pom is ignored (I made that so). However, if I remove
> the '--ignore' instruction, the built jar is codeless:

Based upon the sources layout, I wouldn't expect the cdk-smsd.pom in the
root project to include that class anyway.

> W: libcdk-java: codeless-jar usr/share/java/cdk-smsd.jar
> 
> What is more, the subtree tool/smsd/ contains only pom.xml, what might
> be the reason of codeless jar. It seems to me that cdk-smsd is legacy
> now, and I would suggest asking the upstream for advice how to port code
> depending on it.

I still plan to take a look at what it would take to compile the
legacy/pom.xml.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Upgrading freehep to latest upstream (needed by cdk and probably others)

[tony mancill]

Hi Andreas,

On Sun, Jul 26, 2020 at 10:34:07AM +0200, Andreas Tille wrote:
> Hi Andrius,
> 
> On Fri, Jul 24, 2020 at 08:11:29AM +0300, mer...@debian.org wrote:
> > On 2020-07-23 17:55, Andreas Tille wrote:
> > > Would you mind to update cdk package (which was the original issue
> > > I stumbled upon freehep)?
> > 
> > I have updated cdk yesterday. The cdk-depict module is built now.
> 
> Thanks a lot.  Unfortunately I have remaining issues with r-cran-rcdk.
> If I try to build it I get:
> 
> 
> Executing test function test.mcs2  ... Error in 
> .jcall("org.guha.rcdk.util.Misc", 
> "Lorg/openscience/cdk/interfaces/IAtomContainer;",  :.
>   java.lang.NoClassDefFoundError: org/openscience/cdk/smsd/Isomorphism
> Timing stopped at: 0.022 0 0.007
>  done successfully.
>  
> 
> It actually seems that org/openscience/cdk/smsd/Isomorphism is not
> part of the currently packaged CDK.  Any idea how to solve this?

I am just starting to take a look a this, but I think we need to spend
some more time with CDK.  That class is found in the "legacy" directory
of the sources:

➜  cdk-2.3.134.g1bb9a64587 find . -name Isomorphism.java
./legacy/src/main/java/org/openscience/cdk/smsd/Isomorphism.java

But the legacy pom is ignored:

  
https://salsa.debian.org/java-team/cdk/-/blob/master/debian/libcdk-java.poms#L91

I'll look into the discrepancy with libjgrapht0.6-java, which doesn't
include maven metadata.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Providing GraalVM Community Edition Debian package

[tony mancill]

Hi Dongjin,

On Tue, Jul 14, 2020 at 07:43:20PM +0900, Dongjin Lee wrote:
> Hi Tony,
> 
> > In this case, given that Graal is GPLv2 with the CPE, it feels like we
> should be building it from source.
> 
> Thanks for the comprehensive explanation. It was the very answer I needed.
> 
> Then, if I create the Debian package in the way you described(i.e., built
> from the source), may I contact the mailing list again?

Yes, please do!  And also feel free to reach out to the list if you have
questions, suggestions, or would like to work on other Java packages for
Debian.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Providing GraalVM Community Edition Debian package

[tony mancill]

Hello Dongjin,

On Thu, Jul 09, 2020 at 06:45:43PM +0900, Dongjin Lee wrote:
> Hello Debian Java community,
> 
> It seems like there was a discussion about providing GraalVM community
> edition (aka GraalVM CE) Debian package years ago, but it is still not
> offered yet:
> 
> https://www.mail-archive.com/debian-java@lists.debian.org/msg23951.html
> 
> I have built and maintained GraalVM CE's Debian package (link below) and
> hope to contribute to the community. Could anyone help me? I am a total
> layman to Debian package maintenance.
> 
> https://github.com/dongjinleekr/graalvm-ce-deb
> 
> All kinds of feedbacks and advice are greatly appreciated.

I took a look at the repo, which takes prebuilt binaries and creates a
.deb from them.  This sort of binary-only package is not suitable for
Debian "main" - the package would need to build the Graal CE compiler
from its sources [1] in order to comply with the DFSG (Debian Free
Software Guidelines).  Furthermore, and this can be the difficult part,
all components in the tool chain used to compile that package must also
be packaged for Debian and build from source within Debian.  There are
occasionally exceptions made for bootstapping, but that's a different
topic.

Sometimes software is packaged and is available via non-free [2], but it
is not part of Debian.  Is that what you are asking about?  In this
case, given that Graal is GPLv2 with the CPE, it feels like we should be
building it from source.

If you are interested, here is a link to the DFSG and an excellent FAQ
about [3,4].

Cheers,
tony

[1] https://github.com/oracle/graal
[2] https://www.debian.org/doc/debian-policy/ch-archive#s-non-free
[3] https://www.debian.org/social_contract.html#guidelines
[4] https://people.debian.org/~bap/dfsg-faq.html


signature.asc
Description: PGP signature

Re: ITP: eclipse-wtp -- Eclipse Web Tools Platform

[tony mancill]

On Thu, Jul 09, 2020 at 11:22:16AM +0100, Sudip Mukherjee wrote:
> Hi All,
> 
> On Tue, Jun 23, 2020 at 07:50:17PM +0100, Sudip Mukherjee wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sudip Mukherjee 
> > Control: block 943552 by -1
> > 
> > * Package name: eclipse-wtp
> 
> So, one of the plugin has the name:
> org.eclipse.wst.common.emfworkbench.integration which generates a package:
> libeclipse-wst-common-emfworkbench-integration-java and lintian is giving
> a warning about "very long filename".
> What is the preferred solution for this? Can I rename the plugin to:
> org.eclipse.wst.common.emfworkbench ? or just ignore the lintian warning?

In my opinion, you should prefer consistent naming and ignore (or
override) the lintian warning.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Maven packages in Debian (was Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up))

[tony mancill]

On Mon, Jun 29, 2020 at 07:29:33AM +0100, Sudip Mukherjee wrote:
> Hi Olek,
> 
> On Mon, Jun 29, 2020 at 5:09 AM Olek Wojnar  wrote:
> >
> > On Sun, May 24, 2020 at 4:09 AM Emmanuel Bourg  wrote:
> >>
> >> Le 23/05/2020 à 21:10, Thorsten Glaser a écrit :
> >>
> >> > Ouch, 33M… methinks this is more suited as a web application.
> >> > Not all that easy… due to sheer size, at least.
> >>
> >> +1, an online search engine similar to codesearch.debian.net would be
> >> awesome (and more useful than a package I think).
> >>
> >> In the same vein, I dream of a search.maven.org like web service
> >> restricted to the Maven artifacts in Debian.
> >
> >
> > So has there been any more progress on this? For the record, I *LOVE* the 
> > original page [1] and it is now one of three pinned tabs on my browser. 
> > However, the data is getting stale. The expanded version proposed by Sudip 
> > would be great but, in the meantime, would it be possible to script a 
> > periodic update of the current page?
> 
> I made a python script which saves the information in a sqlite
> database and that same script can search for a class or can list the
> classes in a package. Also, has an option to update the database. Tony
> (added in Cc) had been testing it. But I have not made any attempt to
> package it yet, as the preference was for a web application.

I find Sudip's script to create, update, and search a local sqlite
database quite useful.  We could make the script available to developers
who want to use it locally; it doesn't even need to be packaged in my
opinion - we simply make the script available in a repo on Salsa.

It seems like it could also be used to build the sqlite backend for
a web version.  It just needs a machine with a little bit of horsepower
and access to a mirror (or a caching proxy).

Cheers,
tony


signature.asc
Description: PGP signature

Re: Possible Bug in Maven Debian Helper

[tony mancill]

On Sun, Jun 28, 2020 at 11:03:37PM -0400, Olek Wojnar wrote:
> Hi tony,
> 
> On Sun, Jun 28, 2020 at 9:48 PM tony mancill  wrote:
> 
> >
> > I attempted to reproduce this but the package depends on
> > libchecker-framework-java and the sources checked into the Salsa repo
> > [3] don't match what I see uploaded NEW [4].  Do you mind pushing the
> > branch you used for the upload?
> >
> 
> Of course, sorry about that! I pushed the "master" branch which contains
> the upload I plan to make to unstable once the package clears NEW. I also
> pushed the "experimental" branch which adds an ephemeral experimental
> commit on top of "master." The "experimental" branch is presently in NEW.
> Please let me know if there's anything else that you need to examine this.
> Thanks!
> 
Hi Olek,

Thank you!  I was able to reproduce the problem you are experiencing and
used jmc to grab some stack traces while it is stuck spinning.  They
all are some variant of this - the common bit being that we're always in
somewhere in POMReader:

"main" #1 prio=5 os_prio=0 cpu=133878.15ms elapsed=135.64s 
tid=0x7f7224015000 nid=0x20a26 runnable  [0x7f722b037000]
   java.lang.Thread.State: RUNNABLE
at java.util.TreeMap.getEntry(java.base@11.0.7/TreeMap.java:357)
at java.util.TreeMap.get(java.base@11.0.7/TreeMap.java:277)
at org.debian.maven.repo.POMReader.expandString(POMReader.java:255)
at org.debian.maven.repo.POMReader.expandProperties(POMReader.java:239)
at org.debian.maven.repo.POMReader.readPom(POMReader.java:207)
at org.debian.maven.repo.POMReader.readPom(POMReader.java:57)
at 
org.debian.maven.repo.POMTransformer.keepPomVersion(POMTransformer.java:171)
at 
org.debian.maven.repo.POMTransformer$2.handlePOM(POMTransformer.java:162)
at org.debian.maven.repo.ListOfPOMs.foreachPoms(ListOfPOMs.java:102)
at 
org.debian.maven.repo.POMTransformer.keepPomVersions(POMTransformer.java:159)
at org.debian.maven.repo.POMTransformer.main(POMTransformer.java:770)

So we're definitely in the maven-repo-helper code, entering via [1] and
stuck in [2].  Specifically, my guess is that we're looping in [3].

However, I haven't found a fix yet.  I'm still picking through the pom files
in the patch to see if I can figure out why we're getting stuck.  It
seems like the code expands the pom, it refers to itself (or otherwise
creates a cycle).

We can probably add some more debugging to maven-repo-helper too... :)

Cheers,
tony

[1] 
https://salsa.debian.org/java-team/maven-repo-helper/-/blob/debian/1.9.4/src/main/java/org/debian/maven/repo/POMTransformer.java
[2] 
https://salsa.debian.org/java-team/maven-repo-helper/-/blob/debian/1.9.4/src/main/java/org/debian/maven/repo/POMReader.java
[3] 
https://salsa.debian.org/java-team/maven-repo-helper/-/blob/debian/1.9.4/src/main/java/org/debian/maven/repo/POMReader.java#L247-259


signature.asc
Description: PGP signature

Re: Possible Bug in Maven Debian Helper

[tony mancill]

Hi Olek,

On Wed, Jun 24, 2020 at 03:09:43PM -0400, Olek Wojnar wrote:
> Hi everyone,
> 
> I've been having some problems with a tweaked build and, before reporting a
> bug, I wanted to see if anyone had any insights as to what is going wrong
> here.
> 
> So flogger [1] and bazel have a circular build dependency therefore
> upstream helped me to create an alternate Maven build for flogger (which
> normally only builds with Bazel). Essentially, I have some POM files that
> are created using a patch. However, this build always freezes up during
> dh_auto_configure requiring me to manually abort the build. Specifically,
> it freezes when executing the Java command at [2]. I've pored through the
> code but I can't figure out what's wrong. More to-the-point, I can't
> determine if there's some problem with my packaging (and patched build
> system) or if this is an underlying bug in MDH.
> 
> I appreciate any insights any of you can provide. Thanks!
> 
> -Olek
> 
> [1] https://salsa.debian.org/java-team/google-flogger/-/tree/olek-temp1
> [2]
> https://salsa.debian.org/java-team/maven-repo-helper/-/blob/debian/1.9.4/src/main/bin/mh_patchpoms#L136

I attempted to reproduce this but the package depends on
libchecker-framework-java and the sources checked into the Salsa repo
[3] don't match what I see uploaded NEW [4].  Do you mind pushing the
branch you used for the upload?

Thanks,
tony

[3] https://salsa.debian.org/java-team/checker-framework.git
[4] 
https://ftp-master.debian.org/new/checker-framework_3.0.0+repack1-1~exp2.html#dsc


signature.asc
Description: PGP signature

Re: To build a java package with maven

[tony mancill]

On Sat, Jun 20, 2020 at 04:57:06PM +0200, Thorsten Glaser wrote:
> On Sat, 20 Jun 2020, Mechtilde Stehmann wrote:
> 
> > In the d/rules I did the entry
> > 
> > export CLASSPATH := /usr/share/java/jakarta.validation-api.jar
> 
> There is no file named jakarta.validation-api.jar in Debian,
> according to a file search on packages.debian.org.
> 
> Furthermore, for Maven dependency resolution, you must not
> set $CLASSPATH; only the information in the pom.xml file counts.
> 
> > In the pom.xml I found the entry.
> > 
> > 
> > javax.validation
> >  validation-api
> >  compile
> > 
> 
> You have to insert the correct coordinates here. Sadly, according
> to https://wiki.debian.org/Java/MavenPkgs/Unstable neither
> javax.validation nor jakarta.validation are packaged in Debian yet,
> so they have to be packaged.

javax.activation is found in geronimo-validation-1.1-spec.jar in the
libgeronimo-validation-1.1-spec-java package.

I believe we do need to package something for jakarta.validation. 

Cheers,
tony


signature.asc
Description: PGP signature

Re: libwoodstox-java: new upstream version available (#958512)

[tony mancill]

Hi Alex,

On Sun, May 03, 2020 at 05:30:38PM +0200, Alexandre Rossi wrote:
> Hi list,
> 
> On Thu, Apr 23, 2020 at 10:21 AM Alexandre Rossi  wrote:
> >
> > Package: libwoodstox-java
> > Version: 1:5.1.0-2
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > woodstox-core 6.1.1 is available.
> >
> > upstream of davmail is carrying out a patch and would like at least 5.2
> > available in Debian in order to drop an internal workaround[1] available
> > upstream in 5.2.
> >
> > 5.2.1 and 5.3 build fine using the existing packaging.
> >
> > 6.1.1 fails to build lacking at least some ant plugin and requires a bit 
> > more
> > work.
> >
> > Therefore, I can quickly prepare a 5.3 upload.
> >
> > Are there any blockers regarding uploading a newer version?
> 
> Should I prepare an upload? A merge request? Any known blockers?
> 
> $ apt-cache rdepends libwoodstox-java
> libwoodstox-java
> Reverse Depends:
>   davmail
>   libopsin-java
>   libmetro-policy-java
>   libsolr-java
>   libxstream-java
>   libxml-security-java
>   libjaxws-java
>   libjackson2-jaxrs-providers-java

Thanks for helping with the update.  A rebuild using ratt [1] is an easy
way to validate that the update won't cause an avalanche of FTBFS bugs.

Cheers,
tony

[1] https://tracker.debian.org/pkg/ratt

Re: Request for merging and Sponsoring the Update

[tony mancill]

On Wed, Apr 15, 2020 at 09:00:09PM +0530, Manas Kashyap wrote:
> Hola ,
> I am Manas Kashyap an active Debian contributor and i am currently working
> on updating of android and java team packages to new upstreams. I have made
> the upstream update for scala-tools-sbinary
> https://salsa.debian.org/java-team/scala-tools-sbinary and made a merge
> request accordingly,
> Can anyone kindly review it and can merge the Request and Sponsor this as
> upstream upload.
> Thank you
> Manas Kashyap
> 
> https://salsa.debian.org/java-team/scala-tools-sbinary/-/merge_requests/1

Hi Manas Kashyap,

Thank you for the contribution!  I have merged the request and uploaded
the package.

Cheers,
tony


signature.asc
Description: PGP signature

Re: #952103 - svnkit with FTBFS

[tony mancill]

On Fri, Apr 10, 2020 at 06:45:05PM +0100, Sudip Mukherjee wrote:
> Hi Mechtilde,
> 
> I have now raised a merge request for svnkit.
> https://salsa.debian.org/java-team/svnkit/-/merge_requests/1
> 
> <--snip-->
> 
> Changes since the last upload:
> 
>* Team upload.
>* Fix FTBFS. (Closes: #952103)
>* Update Standards-Version to 4.5.0
>* Use debhelper-compat.
>  - Update compat level to 12.
> 
> Usually Tony sponsors my java contributions. You might want to have a
> look before him. :)

Uploaded.  Thank you for the update Sudip!

Cheers,
tony

Re: OpenJDK 14 (ea) entering testing

[tony mancill]

On Thu, Feb 20, 2020 at 03:56:35PM +0100, Felix Natter wrote:
> Lilian BENOIT  writes:
> > Hello,
> 
> hello Lilian, Hans, Tony,
> 
> > In july, a message "OpenJDK 13 (ea) entering testing" has been sended on
> > this
> > mailing-list. (https://lists.debian.org/debian-java/2019/07/msg9.html)
> > There was a question : Would anybody be interested in setting up a machine
> > to check builds with interim OpenJDK versions?
> >
> > Please give more information for that ? What would be idea ?
> 
> I am the 'freeplane' package maintainer. Upstream has informed me that
> they will soon upgrade to groovy 3.1, because groovy 2.x supposedly (I
> cannot find supporting evidence) does not work with Java14.
> 
> @Hans, @Tony: Is there already a plan to bring groovy to 3.x?
> Can I help with some small tasks?

Hi Felix,

I haven't taken a look at it yet but will do so this weekend.  Would you
mind filing a wishlist bug against groovy regarding the update?

Thank you for bringing this up.
tony


signature.asc
Description: PGP signature

Re: OpenJDK 8u242 GA?

[tony mancill]

On Wed, Feb 05, 2020 at 04:20:40PM +0100, Thorsten Glaser wrote:
> Hi tony,
> 
> > on January 28th as a reminder).  I am in process of building the 8u242
> > source package uploaded to Debian unstable against stretch for a
> 
> thanks for the update, but… Debian unstable has not yet been updated
> to the GA release yet. Perhaps doing that first would be sensible?
> 
> If I can help in any way (I’m a DD) do tell. I regularily build the
> uploaded versions for $orkplace, see below, for precise, trusty,
> xenial (if not done by you), wheezy, jessie, and recently buster,
> locally, so I’m familiar with them.

Uhh... right (my bad; I blame jet-lag).  8u242-b04 is not what we
want.  We should start with an upload of the GA release to unstable.

I'm building on a personal laptop and not doing so as part of $dayjob,
so the builds take a bit longer for me.  Based on my chat with Matthias
at FOSDEM, we should go ahead with the Debian uploads JDK 8.

Thorsten, if you have cycles to handle the GA upload to unstable, please
go ahead and do so.  Otherwise, I will do it by the end of the week.

Thank you for the correction and pushing this forward,
tony


signature.asc
Description: PGP signature

Re: OpenJDK 8u242 GA?

[tony mancill]

On Wed, Feb 05, 2020 at 03:57:11PM +0100, Thorsten Glaser wrote:
> On Tue, 28 Jan 2020, Thorsten Glaser wrote:
> 
> > What I don’t understand is why the new version isn’t uploaded
> 
> It’s been over three weeks since the release, what (besides
> GCC breaking everything) gives?

Hi Thorsten,

I spoke with Matthias about 8u242 last weekend (thanks for your email
on January 28th as a reminder).  I am in process of building the 8u242
source package uploaded to Debian unstable against stretch for a
stretch-security upload.  I should be able to complete the builds and
smoke-tests by the end of the week and will upload once I get the
go-ahead from the Security Team.

Cheers,
tony


signature.asc
Description: PGP signature

Re: sponsorship request for tycho

[tony mancill]

On Fri, Nov 29, 2019 at 01:31:58PM +, Sudip Mukherjee wrote:
> Hi All,
> 
> I have been trying to update tycho to 1.2.0 and have raised a
> merge-request on salsa at [1]. Alternatvely it is also available at [2].
> 
> The latest upstream tycho is 1.5.1 but it needs 1.4.0 to build.
> tycho-1.2.0 is the first release which builds without any dependency on
> a previous version of tycho. tycho-1.5.1 is the final target but it can
> only be done step-by-step.
> 
> Can someone please have a look...

Hi Sudip,

The update looks good to me.  I will sponsor the upload.

Cheers,
tony  


signature.asc
Description: PGP signature

Re: darcula and dependency libiconloader-java

[tony mancill]

Hi Felix,

On Sat, Oct 19, 2019 at 08:13:34PM +0200, Felix Natter wrote:
> hello Tony,
> 
> as discussed, here are two more dependencies of freeplane-1.7.10
> (darcula and its dependency iconloader from the same author).
> 
> 1. https://salsa.debian.org/java-team/libiconloader-java
> 
> The upstream is at https://github.com/bulenkov/iconloader.git, which is
> not active and has no releases, so I packaged git HEAD (@Markus:
> unfortunately there is no alternative to this).
> 
> It uses a simple ant build system.
> 
> JDK11 does not have sun.reflect.ConstructorAccessor (at compile time),
> so I replaced it with new String(...) (which is used by upstream if
> ConstructorAccessor cannot be instantiated). Could you please review
> this patch [1]?
> I also disabled apple code (third patch).
> 
> [1] 
> https://salsa.debian.org/java-team/libiconloader-java/blob/master/debian/patches/02_replace_ConstructorAccessor.patch

In order to preserve the semantics of createShared(), maybe it's better
to go ahead and instantiate an array of char[] and then return that cast
to a String?  (I'm not sure what the original code was hoping to
accomplish.)  Then the underlying storage is mutable if some application
really expects the underlying bytes to be shared.  Or we could go with
your patch and adjust if we encounter any problems.

One other comment about libiconloader-java...  It would be nice to add
.idea to Files-Excluded in debian/copyright and regenerate the
orig.tar.gz.  The .idea files can be regenerated IntelliJ if needed.

> 2. https://salsa.debian.org/java-team/darcula

I haven't looked at this yet.

Cheers,
tony


signature.asc
Description: PGP signature

Re: RFS: libdata-url-java/1.0.1-1 [ITP] -- Support for data URLs according to RFC 2397

[tony mancill]

On Sat, Oct 19, 2019 at 05:18:33PM +0200, Felix Natter wrote:
> 
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libdata-url-java"

Hi Felix,

The initial review looks good.  I will sponsor this upload (probably
later this evening).

> @debian-java: Can I post the darcula package and its dependency
> (remaining two dependencies for freeplane-1.7.10) directly on d-java, or
> shall I do it via mentors?

Send me an email whenever you're ready and I will look at this one too.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Build Zxing-Core

[tony mancill]

On Sat, Oct 19, 2019 at 04:22:53PM +0200, Mechtilde Stehmann wrote:
> Hello Emmanuel
> 
> Am 19.10.19 um 15:10 schrieb Emmanuel Bourg:
> > Le 19/10/2019 à 13:16, Mechtilde Stehmann a écrit :
> > 
> >> Can someone give me hint how I can solve it.
> > 
> > Look at the substitution rules in debian/maven.rules, one of them is
> > malformed.
> 
> Thanks for the hint. I set s/.*/3.5.1/ instead of s/*/3.5.1/
> 
> Now I get the message:
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] 'groupId' is missing. @ line 17, column 202
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [FATAL] 'groupId' is missing. @ line 17, column 202
> 
> In the pom.xml at line 17 I found the doctype declaration. column 202 is
> the position after the last ">"
> 
> Does it want to read the groupID from the parent section which I mark as
> comments.
> 
> If I doesn't it it ask for the dependency  zxing-parent which isn't in
> Debian too.

Hi,

I haven't looked at zxing directly, and so your mileage may vary, but, I
think disabling the parent pom is the right approach.  If the pom you
are trying to build is dependent upon it, you should be able to patch it
to declare the groupId (and any other missing attributes).

Feel free to push a branch or repo to Salsa so others can take a look.
There is so much variation in upstreams; the exact steps required depend
on the details of how the library is packaged in the first place.

This is a good example of how packaging Java libraries can become
tedious... :)

Cheers,
tony



signature.asc
Description: PGP signature

Re: Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[tony mancill]

On Sat, Oct 12, 2019 at 06:29:08PM +0200, gregor herrmann wrote:
> On Thu, 10 Oct 2019 06:30:52 -0700, tony mancill wrote:
> 
> error: No member named $memberName 
>  at /usr/share/perl5/Archive/Zip/Archive.pm line 411.
>   
> Archive::Zip::Archive::contents(Archive::Zip::Archive=HASH(0x5622c68d6100), 
> "META-INF/MANIFEST.MF") called at /usr/bin/jh_manifest line 297
>   
> main::update_jar("/build/libquartz2-java-2.3.0/debian/libquartz2-java/usr/share"...,
>  undef) called at /usr/bin/jh_manifest line 147
> Could not read manifest from 
> /build/libquartz2-java-2.3.0/debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar
>  (2):  at /usr/bin/jh_manifest line 298.
> 
> 
> So the same error as above. What jh_manifest is doing is:
> 
> sub update_jar{
> my $jar = shift;
> my $merge = shift;
> my $zip = Archive::Zip->new();
> my $con;
> my $manifest;
> my $stat;
> my $dirty = 0;
> my $main;
> my $new_manifest = 0;
> # stringify or $zip will make a call back that fails.
> $zip->read( "$jar" ) == AZ_OK or error("Could not read $jar: $!");
> ($con, $stat) = $zip->contents( 'META-INF/MANIFEST.MF' );
> die("Could not read manifest from $jar ($stat): $!")
> unless(!defined($stat) || $stat == AZ_OK);
> 
> i.e. it tries to return META-INF/MANIFEST.MF from the jar file.
> 
> But:
> 
> # unzip -l debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar | grep -c 
> MANIFEST
> 0

Thank you Gregor!  I'll start rooting around in the Java toolchain.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[tony mancill]

On Tue, Oct 08, 2019 at 11:15:38PM +0200, gregor herrmann wrote:
> Control: tag -1 - fixed-upstream
> COntrol: notforwarded -1
> 
> On Tue, 08 Oct 2019 14:10:19 -0700, Chris Lamb wrote:
> 
> > This has apparently been fixed (again) upstream in version 1.67:
> > 
> >   
> > https://github.com/redhotpenguin/perl-Archive-Zip/issues/51#issuecomment-539679696
> 
> Thanks for the notice but I'm afraid this is a different issue, and
> "our" problem is not yet fixed.
> (I tried with some of the merge requests earlier, and Salvatore tried
> today with the 1.67 release.)
> 
> I guess now that 1.67 is out we should open a separate issue upstream
> …

Hi Gregor,

I have recently started observing build failures for packages that use
jh_manifest (which is part of Debian's javahelper).  All of the failures
I have seen so far have the same symptom, namely that the manifest
cannot be extracted from the JAR, which is actually a Zip archive.  An
example build error:

>jh_classpath
> error: No member named $memberName 
>  at /usr/share/perl5/Archive/Zip/Archive.pm line 411.
>   
> Archive::Zip::Archive::contents(Archive::Zip::Archive=HASH(0x55bbbdadedd0), 
> "META-INF/MANIFEST.MF") called at /usr/bin/jh_manifest line 297
>   main::update_jar("/<>/debian/li"..., undef) called at 
> /usr/bin/jh_manifest line 147
> Could not read manifest from 
> /<>/debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar (2): 
>  at /usr/bin/jh_manifest line 298.
> jh_classpath: jh_manifest -plibquartz2-java 
> --classpath=/usr/share/java/slf4j-api.jar 
> debian/libquartz2-java/usr/share/java/quartz2.jar returned exit code 255
> make: *** [debian/rules:4: binary] Error 255

I don't know if this is the same issue but wanted to mention it here,
since it seems potentially related.  I'd be glad to provide more
debugging information or testing if that would help.  libquartz2-java is
an example of a source package that exhibits this issue.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Prepared update libyaml-snake-java

[tony mancill]

On Sun, Sep 15, 2019 at 09:01:43PM +0200, Mechtilde Stehmann wrote:
> Hello
> 
> Am 15.09.19 um 14:05 schrieb Markus Koschany:
> > Simply put, a new upstream version should improve something and not
> > break other packages. Rebuilding reverse-dependencies is a good way to
> > check that or you can rebuild at least some packages that are known to
> > break easily. Just make sure that everything else continues to work and
> > not just your own packages.
> 
> This was the reason I put the updaated packages first in an own repo.
> 
> I know the problem but I can't ensure the functionality of
> reverse-dependencies. And therefore I ask for help on this list.

Hi Mechtilde,

One way to ensure that all of the reverse build dependencies still build
from your updated package is to `apt install ratt` and then invoke ratt
against the changes file for a local build of the package you are
updating.  ratt will then build all of the reverse dependencies using
sbuild.

There is a very good wiki page on configuring sbuild here:

   https://wiki.debian.org/sbuild

Cheers,
tony


signature.asc
Description: PGP signature

Re: Try to update jsoup

[tony mancill]

On Sun, Sep 15, 2019 at 02:08:54PM +0200, Markus Koschany wrote:
> 
> 
> Am 15.09.19 um 08:19 schrieb Mechtilde:
> > Good morning Markus,
> > 
> > a supplementary question
> > 
> > Can I split the patch into single patches for each file?
> 
> It is up to you and how you would like to maintain the package. I
> usually say "one patch for one problem" but some people like to make one
> big patch that includes every Debian change. Whatever makes it easier to
> maintain the package, I guess?

+1 for the "one patch for each problem" approach when it is feasible.
Occasionally this approach gets complicated during upstream version
updates because there are multiple patches against the same build system
or source files.  When that happens, I try to to refactor the patches
with the new version update.  But otherwise, I think it's better to keep
patches separated.

Cheers,
tony


signature.asc
Description: PGP signature

Re: jTDS driver horribly out of date

[tony mancill]

On Sun, Jun 16, 2019 at 08:24:17AM -0700, tony mancill wrote:
> On Thu, Jun 13, 2019 at 11:23:39PM +0200, Andreas Tille wrote:
> > Hi Ryan,
> > 
> > On Tue, Jun 11, 2019 at 11:55:59PM +, Ryan Morillo wrote:
> > > Hi guys,
> > > The jTDS driver has been at version 1.3.1 for a few years and we still
> > > have 1.2.5 in the testing repo (libjtds-java) Can we get the newer
> > > version packaged up and included?
> > > The biggest benefit is it makes it possible to connect to MS SQL Server
> > > (TSQL) on a windows domain successfully.
> > > The link is here:
> > > https://sourceforge.net/projects/jtds/files/jtds/1.3.1/
> >
> ...

Hi Ryan,

I have just uploaded a packaged version of 1.3.1.  Please give it a try
when you have a chance and let me know if there are any problems with
the update.

It didn't take much to update it, so it should be easy enough to
recompile it against buster if that's your target release.  If there's
enough interest, we could also do a proper backport.

Cheers,
tony


signature.asc
Description: PGP signature

Re: guava - updateable?

[tony mancill]

On Mon, Sep 02, 2019 at 02:18:02PM +0200, Steffen Möller wrote:
> Hi all,
> 
> On 02.09.19 13:14, Emmanuel Bourg wrote:
> > Le 30/08/2019 à 05:31, tony mancill a écrit :
> > 
> > > I use Guava often at my job, and in my experience guava updates are
> > > safe.  The updates don't cause regressions and only rarely include
> > > breaking API changes (which are trivial to port).
> > Actually, Guava updates are quite the anti-thesis of the safe upgrades.
> > Guava used to aggressively deprecate and remove features, and it broke
> > many packages in the past. The package is full of patches restoring
> > removed classes and methods. I spent so much time on these issues that I
> > basically stopped updating the package in Buster.
> > 
> > So to anyone planning to update it, please read the upstream changelog
> > carefully as it details all the breaking changes, evaluate if it impacts
> > the Debian package and be ready to restore the remove code or fix the
> > reverse dependencies.

We must have been lucky in avoiding the breaking parts during my
day-to-day work.  I still prefer the option of moving forward with the
library and patching reverse dependencies, although I haven't yet
evaluated the level of effort required and it could be significant.  I
see many invocations of ratt in my future... :)

> I had a first look and there are missing dependencies. It is not so very
> much fun to package. Also, I did not understand the motivation behind a
> few of the Debian patches. And some files to which these were applied to
> no longer exist. And there are additional (sub-)packages shipping with
> the source tree.

Sort of an aside, but the missing build-deps are the least fun part of
it for me too.  Since those packages have to go through NEW, the effort
will likely take multiple months.  And if I recall correctly from when I
last looked at this (for 23.6), the transitive build-deps tree for this
effort is non-trivial.
 
> On the other side, the current package is two years old. And the
> package I need it for happens to use the "Stream" class that was
> introduced only after the version currently in the archive. That does
> not sound to be a very exceptional idea. We should update that beast.
> Darn.

Agreed.
 
> What I had done in the past was to have the version as part of the
> package name. And there would be an additional package that has no
> version in its name that provides the symlinks to the versioned jar. The
> update would would then do would first update the existing package to
> provide a libguavac-java and a libguavac19.0-java package. And then
> there would be an update  to provide the packages libguavac-java and
> libguavac28?.0-java. Packages incompatible with the update would then
> need to explicitly reference the 19.0 version.

It would be nice if we could avoid this unless Guava 19 and Guava 28+
are completely incompatible with each other.  I think it's better to be
biased towards having a single, current version of the library in Debian
if we can.  But as Emmanuel alludes to, that's often easier said than
done.  And if there are significant differences in run-time behavior,
then I will reverse my position.

As a next step, how about we build a Guava 28 .deb locally (ignoring the
build-deps problem for the moment) to assess the state of the r-deps?
That should help inform us on which approach to take.  I can work on
this, although it likely will be about a week before I can start.

Cheers,
tony


signature.asc
Description: PGP signature

Re: guava - updateable?

[tony mancill]

On Tue, Aug 27, 2019 at 03:30:53PM +0200, Steffen Möller wrote:
> Hello,
> 
> I need an update for the guava libraries from
> 
> https://salsa.debian.org/java-team/guava-libraries/blob/master/debian/changelog
> 
> and don't really use them, yet. Is there anybody volunteering to update
> those libraries? Can I otherwise update them without risking anything?

Hello Steffen,

I use Guava often at my job, and in my experience guava updates are
safe.  The updates don't cause regressions and only rarely include
breaking API changes (which are trivial to port).

I'd glad to help with the update and/or with any breakage of reverse
dependencies.  It might take me a bit of time to get to it, so feel free
to go ahead with your update as soon as you're ready.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Freeplane 1.7.9 update

[tony mancill]

On Wed, Aug 21, 2019 at 04:25:33PM +0200, Felix Natter wrote:
> there is a simple new upstream release of freeplane (1.7.9):
>
> (...)
> 
> Could someone please consider uploading this?

Absolutely - thank you for the update!

Cheers,
tony


signature.asc
Description: PGP signature

Re: New here, NatTable repository push to master

[tony mancill]

On Sun, Aug 18, 2019 at 09:16:51AM +0200, Geert Stappers wrote:
> On Sat, Aug 17, 2019 at 02:31:45PM +0200, Vincent Prat wrote:
> > Le 17/08/2019 à 13:52, Geert Stappers a écrit :
> > > On Sat, Aug 17, 2019 at 01:34:43PM +0200, Vincent Prat wrote:
> > ...
> >
> > Now I get the following error when I try to push to master:
> > 
> > remote: GitLab: You are not allowed to push code to protected branches
> > on this project.
> > 
>  
> Strange. According 
> https://salsa.debian.org/java-team/nattable/-/project_members?page=3
> has vivi-guest the developer privilege.
> 
> I don't know how to fix this properly.
> Here I need help from a team member.
> 
> 
> > Pushes to other branches work.
>  
> 
> That allows to create a branch like "helpneeded" or "vivimaster".
> And work with that branch for the time being.

Looking at the settings for Protected Branches [1], we have:

> By default, protected branches are designed to:
> 
> * prevent their creation, if not already created, from everybody except 
> Maintainers
> * prevent pushes from everybody except Maintainers
> * prevent anyone from force pushing to the branch
> * prevent anyone from deleting the branch

And for the master branch of nattable, on Maintainers are allowed to
merge and push.

Looking at the hierarchy of user permissions for gitlab [2,3], the issue
is that Developer is not the same as Maintainer, and vivi-guest is
configured as a Developer (as are others).

As Geert suggests, pushing another branch and opening a merge request
should work fine for now.

The team can discuss what the default access level should be.

Cheers,
tony

[1] https://salsa.debian.org/java-team/nattable/-/settings/repository
[2] https://docs.gitlab.com/ee/development/permissions.html#members
[3] https://docs.gitlab.com/ee/user/permissions.html


signature.asc
Description: PGP signature

Re: Java 8 and 11 quarterly release tags

[tony mancill]

On Wed, Jul 17, 2019 at 01:51:17PM +0100, Martijn Verburg wrote:
> Hi all,
> 
> I've updated the info below - happy building!
> 
> On Tue, 16 Jul 2019 at 23:44, Martijn Verburg 
> wrote:
> 
> > Hi all,
> >
> > For this quarterly release the tags are:
> >
> > *Java 8 (all non-aarch64)*
> >
> > * jdk8u222-b10 (which matches jdk8u222-ga)
> >
> > *Java 8 (aarch64):*
> >
> > * aarch64-shenandoah-jdk8u222-b10
> >
> > *Java 11:*
> >
> > * jdk-11.0.4+11 (which matches jdk-11.0.4-ga)
> >
> > *Java 12*
> >
> 
>  * jdk-12.0.2+9 (which matches jdk-12.0.2-ga)
> 
> *Java 13*
> 
> Won't be released until Sept

Hi Martijn,

Thank you for the information.  Matthias has uploaded 11.0.4+11 to
unstable, which will let us get started on the security update and
backport efforts.  For OpenJDK 8, we're currently at 8u222-b07, but I'm
confident that we can get to 8u222-b10 soon.

Cheers,
tony


signature.asc
Description: PGP signature

Re: jTDS driver horribly out of date

[tony mancill]

On Thu, Jun 13, 2019 at 11:23:39PM +0200, Andreas Tille wrote:
> Hi Ryan,
> 
> On Tue, Jun 11, 2019 at 11:55:59PM +, Ryan Morillo wrote:
> > Hi guys,
> > The jTDS driver has been at version 1.3.1 for a few years and we still
> > have 1.2.5 in the testing repo (libjtds-java) Can we get the newer
> > version packaged up and included?
> > The biggest benefit is it makes it possible to connect to MS SQL Server
> > (TSQL) on a windows domain successfully.
> > The link is here:
> > https://sourceforge.net/projects/jtds/files/jtds/1.3.1/
> 
> Its probably a very good idea to file a bug report against this package
> severity wishlist with subject "New version available".
> 
> > If we just need someone to put the package stuff around it to make it
> > work I can write it up, but the complexities of version matching and
> > stuff are a little beyond my skill set.
> 
> May be you can provide a patch which increases the chances that this
> bug will be fixed.
> 
> Unfortunately its to late for Buster (and I agree its a shame).

Hi Ryan,

With so many Java packages and so few developers on the Debian Java
team, it is difficult to keep everything up to date or to determine
which old versions are affecting users.  So thank you for bringing this
up.

As Andreas suggests, please file a severity wishlist bug against the
package to help us keep track.  And if you have patches, you can attach
them to the bug.

Once buster is released, I'm willing to take a look at updating the
package.  Since the package is arch:all, it shouldn't be a problem to
use the updated package from unstable/testing on buster (assuming the
newer version doesn't pull in new dependencies not present in buster).

Cheers,
tony


signature.asc
Description: PGP signature

Re: Debian distributions of stable OpenJDK updates

[tony mancill]

On Sun, May 26, 2019 at 09:47:13PM +0200, Matthias Klose wrote:
> On 24.05.19 20:29, Martijn Verburg wrote:
> > On Fri, 24 May 2019 at 15:40, tony mancill  wrote:
> > 
> >> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> >>> Le 23/05/2019 à 19:04, Martijn Verburg a écrit :
> >>>
> >>>> What was the difficulty in grabbing the 11.0.3+7 tag directly?
> >>>
> >>> The difficulty is the policy that applies to backported packages. A
> >>> package that is backported from the Debian release n+1 to the release n
> >>> has to remain upgradable when the system is upgraded. For this to happen
> >>> the version backported must rank lower than the version in the next
> >>> release. That's why there are weird suffixes appended to the versions of
> >>> the backported packages (1.2.3-1~bpo9+1 is lower than 1.2.3-1).
> >>>
> >>> Currently Debian Buster has openjdk-11/11.0.3+1-1, so it isn't possible
> >>> to upload the version 11.0.3+7-1~bpo9+1 to stretch-backports. The only
> >>> solutions is to either upgrade openjdk-11 in testing to a version higher
> >>> than 11.0.3+7, or patch the existing version. Since testing is currently
> >>> frozen and difficult to update until the release of Buster, it leaves
> >>> only the patch solution.
> >>
> >> Emmanuel,
> >>
> >> It seems like we need to bring this up with the Release and Security
> >> teams.  Releasing Buster with mulitple critical open CVEs in the JVM
> >> isn't a good experience for our users.  My proposal is that we do what
> >> we need to get 11.0.3-ga-1 into Buster.
> >>
> >> From a versioning standpoint, this should work.  Am I missing something?
> >>
> >> $ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1
> >> is newer"
> >> 11.0.3-ga-1 is newer
> 
> I don't think that playing games with version numbers is a good thing to do.
> Version numbers should match the upstream source release, and the binary
> packages should not change that version.  Of course openjdk has a split
> personality to give even another version when called with java --version
> 
> The final 11.0.3 release:
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
> 
> does *not* contain the ea specifier.

Hi Matthias,

Thank you for weighing in on the thread.  I have been building openjdk
packages all weekend and now understand that the version number is
required to be numeric as per the upstream build system - i.e.,
VERSION_BUILD won't pass the test here [1] if it is arbitrarily changed
from from 7 to ga.  So 11.0.3+7 it is.  My bad for proposing otherwise
in this thread, before I got more familiar with the build system...

For the update to buster via testing-proposed-updates, I have prepared
11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
at buster via t-p-u and with the changelog updated to note that 11.0.3+7
is the GA release from OpenJDK.  This will address the CVEs currently
open against the version in buster.

Does that sound acceptable for upload to Debian?  Would you prefer a
different approach?

Thank you,
tony

[1] 
http://hg.openjdk.java.net/jdk-updates/jdk11u/file/175eb80c253a/make/autoconf/jdk-version.m4#l40
 
[2] 
https://tracker.debian.org/news/1038802/accepted-openjdk-11-11037-4-source-into-unstable/


signature.asc
Description: PGP signature

Re: Debian distributions of stable OpenJDK updates

[tony mancill]

On Fri, May 24, 2019 at 12:45:15AM +0200, Thorsten Glaser wrote:
> On Thu, 23 May 2019, Emmanuel Bourg wrote:
> 
> > than 11.0.3+7, or patch the existing version. Since testing is currently
> > frozen and difficult to update until the release of Buster, it leaves
> > only the patch solution.
> 
> That being said, it’s also not permitted to add in a patch anything
> to a backport that’s not in the base (n+1) version, except things
> necessary to do the backporting itself.

Emmanuel,

I see that openjdk-11 11.0.3+1-1~bpo9+2 has been accepted in stable
backports [1], so the (smallish) patch to bring the code up to the
+7/-ga tag was deemed allowable after all.  Thank you for driving this
for stable.

I think it is important to get a "-ga" versioned package into Buster
because 11.0.3+1 is potentially confusing - it seems like it's version
*after* 11.0.3, when in fact it's an EA release.  According to the
developer's reference for t-p-u [2], this case meets all of the
criteria.  And once that version is Buster, we can also update the
version number in stable backports.

Can folks think of any reasons why we shouldn't go ahead and upload to
testing-proposed-updates for Buster?  If there are any concerns, please
speak up.  Otherwise, I'll work on an upload this weekend.

Thanks,
tony

[1] 
https://tracker.debian.org/news/1040268/accepted-openjdk-11-11031-1bpo92-source-amd64-all-into-stretch-backports-backports-policy-stretch-backports/
[2] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u


signature.asc
Description: PGP signature

Re: Debian distributions of stable OpenJDK updates

[tony mancill]

On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> Le 23/05/2019 à 19:04, Martijn Verburg a écrit :
> 
> > What was the difficulty in grabbing the 11.0.3+7 tag directly?
> 
> The difficulty is the policy that applies to backported packages. A
> package that is backported from the Debian release n+1 to the release n
> has to remain upgradable when the system is upgraded. For this to happen
> the version backported must rank lower than the version in the next
> release. That's why there are weird suffixes appended to the versions of
> the backported packages (1.2.3-1~bpo9+1 is lower than 1.2.3-1).
> 
> Currently Debian Buster has openjdk-11/11.0.3+1-1, so it isn't possible
> to upload the version 11.0.3+7-1~bpo9+1 to stretch-backports. The only
> solutions is to either upgrade openjdk-11 in testing to a version higher
> than 11.0.3+7, or patch the existing version. Since testing is currently
> frozen and difficult to update until the release of Buster, it leaves
> only the patch solution.

Emmanuel,

It seems like we need to bring this up with the Release and Security
teams.  Releasing Buster with mulitple critical open CVEs in the JVM
isn't a good experience for our users.  My proposal is that we do what
we need to get 11.0.3-ga-1 into Buster.

From a versioning standpoint, this should work.  Am I missing something?

$ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1 is 
newer"
11.0.3-ga-1 is newer

Thanks,
tony


signature.asc
Description: PGP signature

Re: Debian distributions of stable OpenJDK updates

[tony mancill]

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

Ah, that's great if we can upload 11.0.3+7 without having to play
any games with the version string.  Also, I should have said explicitly
that I'm also volunteering to help with uploads - both this version and
going forward.

> > In general, I think it would be helpful for our users if we uploaded the
> > prereleases to experimental but stuck to GA releases for unstable,
> > testing, and backports.  I think it is easy to mistake, for example, an
> > 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
> > distributed by other projects.
> 
> It looks like upstream is going to append a -ea suffix to the version
> reported by the pre-releases [1]. This is a welcome clarification and we
> should ensure our builds do it as well.
> 
> [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009369.html
 
Excellent!  Let's see if Matthias has any concerns.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Debian distributions of stable OpenJDK updates

[tony mancill]

On Mon, May 20, 2019 at 03:15:13PM +0200, Aleksey Shipilev wrote:
> On 5/20/19 3:08 PM, Emmanuel Bourg wrote:
> > Le 20/05/2019 à 14:38, Aleksey Shipilev a écrit :
> > 
> >> Yes. Security fixes and Japanese epoch changes are delivered in 11.0.3+7, 
> >> after security embargo was
> >> lifted. The fixes are not in 11.0.3+6, which was tagged before the embargo 
> >> lifted. You are looking
> >> for these:
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/175eb80c253a
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2996b4523925
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f0d8b845de21
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1084d119236b
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c61b8801f0e4
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/59610bddd37a
> > 
> > Thank you. As I understand the rev 1084d119236b is the fix for
> > CVE-2019-2684, and 59610bddd37a is the fix for CVE-2019-2602. But I'm
> > not sure about c61b8801f0e4, is there a related CVE?
> 
> I don't think there is, but I am not the authoritative source on this. I just 
> listed the differences
> between +6 and +7 (which came from the security-related repo after the fork 
> for release).
> 
> See more here:
>   
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
>   https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html
> 
> -Aleksey
> 

Hello Aleksey,

Thank you for posting this to the list.  Reconciling the Debian version
numbers with those found in AdoptOpenJDK has been a recent topic of
discussion with several of my coworkers and so I was preparing to bring
up the issue here as well, but you beat me to it.

For reference for the list, the upstream tags can be seen here:

  http://hg.openjdk.java.net/jdk-updates/jdk11u/tags

So 11.0.3+7 == 11.0.3-ga.

For stable backports and buster, I agree that we should upload an
11.0.3-ga package, particularly given the vulnerabilities still present
in 11.0.3+1: CVE-2019-2698, CVE-2019-2684, and CVE-2019-2602

  https://security-tracker.debian.org/tracker/source-package/openjdk-11

It would be nice to do the same for buster, although now that 11.0.4+x
has been introduced to unstable, I believe we'll have to be creative
with the naming, either by introducing an epoch or using the
"11.0.4+1_really11.0.3-ga" trick.

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

Matthias, since you've been handling all of the recent uploads, do you
have specific thoughts or concerns about an upload of 11.0.3-ga?

Thank you,
tony


signature.asc
Description: PGP signature

Re: Javadoc -link makes broken links if module name matches package name

[tony mancill]

On Sun, Feb 17, 2019 at 05:48:30PM +0100, Markus Koschany wrote:
> Hi Ingo,
> 
> Am 17.02.19 um 16:45 schrieb Ingo Bauersachs:
> > Tony, Markus
> > 
> >> [...]
> >> Any thoughts on whether we should focus on fixing javadoc generation or
> >> look at other ways to mitigate the FTBFS?
> > 
> > I've been notified that weupnp [1] has been marked for autoremoval [2]
> > because of this Javadoc thing, while other packages are not, e.g.
> > servlet-api [3].
> > Following the discussions and the merges/splits/reassignments of the
> > original bug, I'm not quite sure what action to take, if any. I'd like to
> > avoid that weupnp is being removed. Is disabling the Javadoc
> > generation/installation and looking for a sponsor the best way to go?
> 
> ...Just reading tony's email.
> 
> Yes, I'm absolutely fine with that. I don't think you have to request
> any binNMUs because those existing -doc packages should just work at the
> moment. I don't know if there is any downside to our approach but my
> general feeling is it can't be that severe. We should reassign all RC
> bugs of affected packages to maven-javadoc-plugin, then the automatic
> removal messages will stop as well.

Hi Markus,

I've created a "buster" branch from the debian/3.0.1-2 tag and applied
a patch that changes the default.  So far packages are building
successfully.  However, I'm less than 10% through the set of
r-build-deps; it's going to take a while yet [2].  I see that Ole
addressed #919831 via an upload earlier this week, so I'll update that
patch to refer to #919798 [1], and perhaps we can link the discussions
somehow.

Assuming the rest of my ratt build is successful, any concerns with an
upload to unstable referring to 919798?  (Are there any other suitable
options at this point?)

Cheers,
tony

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919798
[2] ratt rebuild in progress...

tony@lark:/data/debian/sponsor/maven-javadoc-plugin/build-area/rebuild$ ratt 
-sbuild_dist unstable-jdk -dist sid 
../maven-javadoc-plugin_3.0.1-3_amd64.changes
2019/02/17 11:09:47 Loading changes file 
"../maven-javadoc-plugin_3.0.1-3_amd64.changes"
2019/02/17 11:09:47  - 1 binary packages: libmaven-javadoc-plugin-java
2019/02/17 11:09:47 Corresponding .debs (will be injected when building):
2019/02/17 11:09:47 ../libmaven-javadoc-plugin-java_3.0.1-3_all.deb
2019/02/17 11:09:47 Figuring out reverse build dependencies using dose-ceve(1). 
This might take a while
2019/02/17 11:10:11 Building package 1 of 242: maven-archiver 
2019/02/17 11:13:29 Building package 2 of 242: libwoodstox-java 
2019/02/17 11:14:41 Building package 3 of 242: javawriter 
2019/02/17 11:16:23 Building package 4 of 242: doxia-sitetools 
2019/02/17 11:23:25 Building package 5 of 242: jmdns 
2019/02/17 11:24:55 Building package 6 of 242: libminlog-java 
2019/02/17 11:25:55 Building package 7 of 242: uima-as 
2019/02/17 11:35:38 Building package 8 of 242: libcommons-discovery-java 
2019/02/17 11:38:02 Building package 9 of 242: plexus-cipher 
2019/02/17 11:39:56 Building package 10 of 242: undertow 
2019/02/17 11:44:03 Building package 11 of 242: libcommons-codec-java 
2019/02/17 11:45:23 Building package 12 of 242: jts 
2019/02/17 11:48:32 Building package 13 of 242: joda-convert 
2019/02/17 11:50:45 Building package 14 of 242: metainf-services 
2019/02/17 11:52:09 Building package 15 of 242: qdox2 
2019/02/17 12:06:49 Building package 16 of 242: httpcomponents-client 
2019/02/17 12:09:06 Building package 17 of 242: servlet-api 
2019/02/17 12:10:43 Building package 18 of 242: maven-dependency-tree 
2019/02/17 12:13:12 Building package 19 of 242: felix-gogo-command 
2019/02/17 12:15:26 Building package 20 of 242: libcommons-compress-java 
...


signature.asc
Description: PGP signature

Re: Javadoc -link makes broken links if module name matches package name

[tony mancill]

On Fri, Feb 15, 2019 at 08:22:14PM +0100, Markus Koschany wrote:
> Am 15.02.19 um 15:42 schrieb tony mancill:
> [...]
> > Any thoughts on whether we should focus on fixing javadoc generation or
> > look at other ways to mitigate the FTBFS?
> 
> Like burning all those -doc packages? :)
> 
> In my opinion we could ask Robert Scholte for advice. He is chairman of
> Apache Maven and directly involved in fixing this bug. If he doesn't
> know
> 
> However I think I have found a workaround, and we all love workarounds,
> don't we.
> 
> In your initial post you pointed to a related bug report. [1] That made
> me think and also read the fine Maven Javadoc documentation. There is an
> option called detectJavaApiLink
> 
> https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#detectJavaApiLink
> 
> If I add
> 
> detectJavaApiLink=false to debian/maven.properties in libparanamer-java,
> the package builds from source again.
> 
> Maybe we should patch our tools and set this property to false and move
> on for now? Hopefully in a few months this will just work again without
> changing this option, when maven-javadoc-plugin et al. have been
> catching up?

Hi Markus,

Very nice find about detectJavaApiLink!  I'll try patching the
default value in current maven-javadoc-plugin here [1] and kick off as
large of a ratt build as I can see about coverage.  Assuming that is
successful, we could then look into what it would take to schedule a
binary NMU all packages that depend on maven-javadoc-plugin.  (Or maybe
someone on the list has a better idea?)

Do we know if there is any downside to disabling this by default?

Thanks!
tony

[1] 
https://salsa.debian.org/java-team/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L569


signature.asc
Description: PGP signature

Re: Javadoc -link makes broken links if module name matches package name

[tony mancill]

On Wed, Feb 13, 2019 at 10:07:34PM +0100, Markus Koschany wrote:
> Hi,
> 
> Am 26.01.19 um 20:07 schrieb tony mancill:
> [...]
> > I'm trying to peel the onion and believe that this is a problem in the
> > maven-javadoc-plugin package.  I found the same issue for a project
> > outside of Debian, for example [1], which refers to a JIRA ticket for that
> > plugin [2].  There is a commit [3] referencing that JIRA on the master
> > branch of maven-javadoc-plugin.
> > 
> > I would like to try cherry-picking the fix onto our current version of
> > maven-javadoc-plugin to see if it resolves our issue.  Or if that gets
> > too complicated, we could look into updating to a snapshot of 3.1.0 (our
> > version would 3.1.0~foo), since it looks like all of these commits will
> > be part of 3.1.0 [4].
> > 
> > I'm not sure how much time I'll have to dedicate to this over the
> > weekend and so would be happy if someone fixes it before I get to it.
> 
> I have updated the maven-javadoc-plugin package to the latest Git
> snapshot and pushed the changes. An update of libplexus-languages-java
> was also necessary (currently in experimental) and tony already took
> care of it. I also had to add a compatibility patch for Debian's version
> of maven-artifact-transfer. A new upstream release just because of some
> minor refactoring seemed to be not the best way forward during the freeze.
> 
> Now I would have expected that libparanamer-java (#920750) just built
> fine again but it doesn't. According to README.source in
> maven-javadoc-plugin maven2-core (should be src:maven?) must be updated
> as well. I'm not sure what button I have to press to make this work
> right now. Any ideas?

Hi Markus,

We independently executed identical experiments, which I'm glad for,
because I would have wanted some external verification before uploading
any of this to unstable.  (I started building the r-build-deps of
libplexus-languages-java using ratt, but my laptop isn't the best place
to build 559 packages and many packages are FTBFS right now anyway due
to the javadoc problems.)

I believe the comment in debian/README.source about updating src:maven
is simply out of date.  I don't see any (obvious) versioned references
to maven-javadoc-plugin in the current maven source package.

So I'm not sure what the next step is, other than continuing to watch
commits to upstream maven-javadoc-plugin and see if I can figure out why
3.1.0~pre0-$foo doesn't work in our environment. 

Or now that we're into the freeze, do we want to talk about actions with
more far-reaching consequences?

Any thoughts on whether we should focus on fixing javadoc generation or
look at other ways to mitigate the FTBFS?

Thanks,
tony


signature.asc
Description: PGP signature

Re: Buster soft freeze question

[tony mancill]

On Sun, Feb 03, 2019 at 04:24:02PM +0100, Felix Natter wrote:
> Markus Koschany  writes:
> 
> > Hi,
> 
> hello Markus,
> hello Tony,
> 
> > Am 30.01.19 um 20:55 schrieb Felix Natter:
> >> hi Debian-java,
> >> 
> >> I would like to get freeplane-1.7.5-1 into buster, because it contains
> >> important fixes. Unfortunately, upstream is still fixing regressions.
> >> 
> >> For stretch, a soft freeze is described as:
> >> "no new packages, no re-entry, normal migrations" [1]
> >> 
> >> I think that means that I can get freeplane-1.7.5-1 into buster until
> >> beginning of March (by full freeze)?
> >> 
> >> [1] https://wiki.debian.org/DebianStretch
> >> 
> >> Many Thanks and Best Regards,
> >
> > The important part for our soft freeze is:
> 
> Many thanks for the explanation!
> 
> I was lucky, freeplane-1.7.5 was just released, and I prepared the
> update:
> 
> freeplane (1.7.5-1) unstable; urgency=medium
> 
>   * New upstream release
>   * Add new dependency ivy
>   * Declare conformance with standards version 4.3.0 (no changes)
>   * Update man page
> 
>  -- Felix Natter   Sun, 03 Feb 2019 15:47:47 +0100
> 
> This is the repo:
>   https://salsa.debian.org/java-team/freeplane
> 
> There is one thing worth noting: The 1.7.2 uploads's .orig tarball
> contains class files, because the upstream build system did not take
> into account that the lead developer now uses the IntelliJ IDE, which
> puts classes into /out/**.class. This is fixed now, so
> 1.7.5[-1] will not contain class files in the orig tarball.
> 
> @Tony: Would you consider sponsoring freeplane-1.7.5-1?

Hello Felix,

I am able to build the updated package from the repo without any
problems, and desk-testing looks good.  Thank you for cleaning up the
issue with the class files in the upstream tarball.

Uploading now.

Cheers,
tony


signature.asc
Description: PGP signature

Re: How to replace javax.xml.bind in milib

[tony mancill]

On Sun, Jan 27, 2019 at 12:25:35AM +0100, Andreas Tille wrote:
> Hi Tony,
> 
> On Sat, Jan 26, 2019 at 10:52:46AM -0800, tony mancill wrote:
> > On Sat, Jan 26, 2019 at 11:11:36AM +0100, Andreas Tille wrote:
> > > [INFO] 
> > > 
> > > [ERROR] Failed to execute goal on project milib: Could not resolve 
> > > dependencies for project com.milaboratory:milib:jar:1.9: The following 
> > > artifacts could not be resolved: javax.xml.bind:jaxb-core:jar:debian, 
> > > javax.xml.bind:jaxb-runtime:jar:debian: Cannot access central 
> > > (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> > > javax.xml.bind:jaxb-core:jar:debian has not been downloaded from it 
> > > before. -> [Help 1]
> > > [ERROR] 
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with the 
> > > -e switch.
> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > > [ERROR] 
> > > [ERROR] For more information about the errors and possible solutions, 
> > > please read the following articles:
> > > [ERROR] [Help 1] 
> > > http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> > > 
> > > 
> > > Am I missing something?
> > 
> > Based on that error message, the build system is trying to find the
> > jaxb-core and jaxb-runtime JARs locally (since the Debian toolchain
> > doesn't allow it pull things from the Internet - this is why all of
> > these builds "just work" outside of the Debian context).
> > 
> > Therefore, you should add libjaxb-java as a build-dep, which will add
> > the following JARs to the local maven repo during the build:
> 
> Hmmm, the Build-Depends was set in the build creating the error above.
>  
> > /usr/share/java/jaxb-core.jar
> > /usr/share/java/jaxb-jxc-jdk9.jar
> > /usr/share/java/jaxb-jxc.jar
> > /usr/share/java/jaxb-runtime.jar
> > /usr/share/java/jaxb-xjc-jdk9.jar
> > /usr/share/java/jaxb-xjc.jar
> > /usr/share/java/jaxb-impl.jar
> > 
> > You might also want to include libjaxb-java as a dependency of your
> > binary package.
> 
> I added this but there must be another trick to get the package built.

Hello Andreas,

Sorry, I should have provided more information.  The maven coordinates
for the jaxb-core and jaxb-runtime don't have the same group id as
jaxb-api.  Or put another way, the path for the jaxb-runtime in the local
maven repo is different than it is for jaxb-api.

$ find /usr/share/maven-repo | grep jaxb-runtime/
/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/debian
/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/debian/jaxb-runtime-debian.jar
/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/debian/jaxb-runtime-debian.pom
/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/2.3.0.1
/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/2.3.0.1/jaxb-runtime-2.3.0.1.pom
/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/2.3.0.1/jaxb-runtime-2.3.0.1.jar
  ^^  ^^^   
  groupIdartifactId   version

As compared to jaxb-api, which has groupId javax.xml.bind:

$ find /usr/share/maven-repo | grep jaxb-api/
/usr/share/maven-repo/javax/xml/bind/jaxb-api/debian
/usr/share/maven-repo/javax/xml/bind/jaxb-api/debian/jaxb-api-debian.jar
/usr/share/maven-repo/javax/xml/bind/jaxb-api/debian/jaxb-api-debian.pom
/usr/share/maven-repo/javax/xml/bind/jaxb-api/2.3.1
/usr/share/maven-repo/javax/xml/bind/jaxb-api/2.3.1/jaxb-api-2.3.1.jar
/usr/share/maven-repo/javax/xml/bind/jaxb-api/2.3.1/jaxb-api-2.3.1.pom


By looking at this error message:

> [ERROR] Failed to execute goal on project milib: Could not resolve 
> dependencies for project com.milaboratory:milib:jar:1.9: The following 
> artifacts could not be resolved: javax.xml.bind:jaxb-core:jar:debian, 
> javax.xml.bind:jaxb-runtime:jar:debian: Cannot access central 
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> javax.xml.bind:jaxb-core:jar:debian has not been downloaded from it before. 
> -> [Help 1]

We see that maven was looking for jaxb-runtime in the local repo here:

/usr/share/maven-repo/javax/xml/bind/jaxb-runtime/debian/...
 |---groupId---| |-artifact-| |ver-| 

When in fact the libjaxb-java package installs the maven metadata here:

/usr/share/maven-repo/org/glassfish/jaxb/jaxb-runtime/debian/...
 |-groupId-| |-artifact-| |ver-| 

I pushed a commit to master (also attached) that updates the patch you
created and the package is building for me locally.  So you almost had
it

Re: Javadoc -link makes broken links if module name matches package name

[tony mancill]

Hi Ole,

On Fri, Jan 25, 2019 at 08:50:29PM +0100, Ole Streicher wrote:
> Hi Matthias,
> 
> on a number of packages, javadoc now fails, which is reported by a
> number of bugs. Since you mentioned that this is not a bug in the JDK,
> could you give a hint what the problem is? The error message is a bit
> mystic, at least to me. And the openjdk commit also does not enlighten me.
> 
> It a bug in the individual packages or one in javahelper? And what
> should be done to fix it?
> 
> Best
> 
> Ole
> 
> On 25.01.19 09:26, Matthias Klose wrote:
> > so this is not an openjdk error, and should be fixed in the pacakges 
> > itself. See
> > 
> > 8211916: Javadoc -link makes broken links if module name matches package 
> > name
> > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/66a53d6047d1
> > 
> > see the -source 8 passed in the tests.

I'm trying to peel the onion and believe that this is a problem in the
maven-javadoc-plugin package.  I found the same issue for a project
outside of Debian, for example [1], which refers to a JIRA ticket for that
plugin [2].  There is a commit [3] referencing that JIRA on the master
branch of maven-javadoc-plugin.

I would like to try cherry-picking the fix onto our current version of
maven-javadoc-plugin to see if it resolves our issue.  Or if that gets
too complicated, we could look into updating to a snapshot of 3.1.0 (our
version would 3.1.0~foo), since it looks like all of these commits will
be part of 3.1.0 [4].

I'm not sure how much time I'll have to dedicate to this over the
weekend and so would be happy if someone fixes it before I get to it.

Cheers,
tony

[1] https://github.com/oracle/opengrok/issues/2629
[2] https://issues.apache.org/jira/browse/MJAVADOC-555
[3] 
https://github.com/apache/maven-javadoc-plugin/commit/c3e96e622d4ce0ea6e3ba7fcff9cbd2c555ae716
[4] 
https://github.com/apache/maven-javadoc-plugin/commit/8e6622f39392577298fa71b02b0194ade70fceb9


signature.asc
Description: PGP signature

Re: How to replace javax.xml.bind in milib

[tony mancill]

On Sat, Jan 26, 2019 at 11:11:36AM +0100, Andreas Tille wrote:
> Hi Tony,
> 
> On Fri, Jan 25, 2019 at 08:23:55PM -0800, tony mancill wrote:
> > I recently patched the jhove package for a similar issue,
> >  ...
> > --- /dev/null
> > +++ b/debian/patches/jhove_javax.patch
> > @@ -0,0 +1,22 @@
> > +Description: Add javax.xml.bind as a dependency
> > + java.xml.bind is removed since Java 10 and is now available as an
> > + external library.
> > +Author: Abdelhakim Qbaich 
> > +Bug-Debian: https://bugs.debian.org/917482
> > +Bug: https://github.com/openpreserve/jhove/pull/381
> > +Last-Update: 2019-01-19
> > +
> > +--- jhove-1.20.1.orig/jhove-modules/pom.xml
> >  jhove-1.20.1/jhove-modules/pom.xml
> > +@@ -23,6 +23,11 @@
> > +   ${project.version}
> > + 
> > + 
> > ++  javax.xml.bind
> > ++  jaxb-api
> > ++  2.3.1
> > ++
> > ++
> > +   junit
> > +   junit
> > + 
> 
> Thanks for the hint.  I tried to implement this[1] but the issue
> remains:
> 
> [WARNING] The POM for javax.xml.bind:jaxb-runtime:jar:debian is missing, no 
> dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  0.408 s
> [INFO] Finished at: 2019-01-26T09:56:14Z
> [INFO] 
> 
> [ERROR] Failed to execute goal on project milib: Could not resolve 
> dependencies for project com.milaboratory:milib:jar:1.9: The following 
> artifacts could not be resolved: javax.xml.bind:jaxb-core:jar:debian, 
> javax.xml.bind:jaxb-runtime:jar:debian: Cannot access central 
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> javax.xml.bind:jaxb-core:jar:debian has not been downloaded from it before. 
> -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> 
> 
> Am I missing something?

Hi Andreas,

Based on that error message, the build system is trying to find the
jaxb-core and jaxb-runtime JARs locally (since the Debian toolchain
doesn't allow it pull things from the Internet - this is why all of
these builds "just work" outside of the Debian context).

Therefore, you should add libjaxb-java as a build-dep, which will add
the following JARs to the local maven repo during the build:

/usr/share/java/jaxb-core.jar
/usr/share/java/jaxb-jxc-jdk9.jar
/usr/share/java/jaxb-jxc.jar
/usr/share/java/jaxb-runtime.jar
/usr/share/java/jaxb-xjc-jdk9.jar
/usr/share/java/jaxb-xjc.jar
/usr/share/java/jaxb-impl.jar

You might also want to include libjaxb-java as a dependency of your
binary package.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Bug#917655: biojava4-live: FTBFS (cannot find symbol JAXBContext)

[tony mancill]

On Fri, Jan 11, 2019 at 10:26:58PM +0100, Andreas Tille wrote:
> Control: tags -1 help upstream
> 
> Hi,
> 
> I've commited a new minor upstream version to Git but the problem exists
> also in this version.  I've asked at debian-java list for help[1]

Hello Andreas,

I took a quick look at this and was able to resolve the build problems
by dropping the references to the java.se.ee. module and adding
jaxb-impl and jaxb-api JARs to the classpath.

It might not be the cleanest way - strictly speaking, you should only
need the jaxb-api JAR during the build and only the jaxb-impl on the
classpath while running tests.

Attached are a set of commits that let the package build for me locally.

Cheers,
tony
From f8f5c72b866718e05811b33f8445ee311228da12 Mon Sep 17 00:00:00 2001
From: tony mancill 
Date: Fri, 11 Jan 2019 20:17:27 -0800
Subject: [PATCH 1/3] Add build-dep on libjaxb-api-java and libjaxb-java

---
 debian/control | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 1f6cc04..71257a0 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,9 @@ Build-Depends-Indep: libcommons-dbcp-java,
  liblog4j2-java,
  libslf4j-java,
  libxmlunit-java,
- libjgrapht-java
+ libjgrapht-java,
+ libjaxb-api-java,
+ libjaxb-java
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/biojava4-live
 Vcs-Git: https://salsa.debian.org/med-team/biojava4-live.git
-- 
2.20.1

From ac9fad6e89d9d5ff8501a05da46b26bd158af5f8 Mon Sep 17 00:00:00 2001
From: tony mancill 
Date: Fri, 11 Jan 2019 20:25:49 -0800
Subject: [PATCH 2/3] Add jaxb-api and jaxb-impl JARs to classpaths in
 debian/build.xml

---
 debian/build.xml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/build.xml b/debian/build.xml
index 250c143..fae837d 100644
--- a/debian/build.xml
+++ b/debian/build.xml
@@ -28,7 +28,7 @@
 	
 		
 	
-	
+	
 
 	
 
@@ -52,6 +52,8 @@
 
 
 
+
+
 			
 			
 
-- 
2.20.1

From c25549fd76d3378cad50029a6718353858f6cce4 Mon Sep 17 00:00:00 2001
From: tony mancill 
Date: Fri, 11 Jan 2019 20:36:27 -0800
Subject: [PATCH 3/3] Drop --add-modules java.se.ee from javadoc task

---
 debian/build.xml | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/debian/build.xml b/debian/build.xml
index fae837d..406f208 100644
--- a/debian/build.xml
+++ b/debian/build.xml
@@ -75,18 +75,9 @@
 	
 
 		
-
-
-
-http://java.sun.com/j2se/1.6.0/docs/api/"/>
-
-
-
-
-http://java.sun.com/j2se/1.6.0/docs/api/"/>
-
-
-
+
+http://java.sun.com/j2se/1.6.0/docs/api/"/>
+
 	
 	
 	
@@ -130,7 +121,6 @@
 
 
 
-  
   
   
   
-- 
2.20.1



signature.asc
Description: PGP signature

Re: Bug#917576: stegosuite: depends on libswt-gtk2 which is no longer built

[tony mancill]

owner -1 tmanc...@debian.org
thanks

On Fri, Dec 28, 2018 at 04:40:24PM -0500, Jeremy Bicha wrote:
> Source: stegosuite
> Version: 0.8.0-1
> Severity: serious
> 
> stegosuite depends on libswt-gtk2-4-jni but that package is no longer
> built by swt4-gtk.
> 
> Please switch to using libswt-gtk-4-jni instead (which uses gtk3
> instead of gtk2).

Hi Jeremy,

Thank you for the bug report; I am working on the update, (which is
thankfully trivial).

The issue I am running into is that ${maven:Depends} is injecting an
unresolvable dependency on "libswt-gtk-4-java (>= 4.x)" and so the
resulting binary package fails to install with:

dpkg: dependency problems prevent configuration of stegosuite:
 stegosuite depends on libswt-gtk-4-java (>= 4.x); however:
  Version of libswt-gtk-4-java on system is 4.10.0-1.

A temporary hack would be to drop ${maven:Depends} from the control file
and specify a resolvable dependency on libswt-gtk-4-java directly, but
this sidesteps what I believe is a more general issue with
maven-debian-helper and the swt4-gtk packaging.

For Debian Java, could this be resolved by having swt4-gtk install a pom
that specifies 4.10.1 as the debian.originalVersion?  Or could we get way with 
specifying simply "4" for the version?

Here's the current pom:

$ cat 
/usr/share/maven-repo/org/eclipse/swt/org.eclipse.swt/4.x/org.eclipse.swt-4.x.pom
 

http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4_0_0.xsd;>
4.0.0
org.eclipse.swt
org.eclipse.swt
4.x
jar


4.x
libswt-gtk-4-java



Any tips on how to resolve this for packages that have runtime
dependences on swt4-gtk's binary packages?

Thank you,
tony


signature.asc
Description: PGP signature

Re: Please sponsor Freeplane fix

[tony mancill]

On Sat, Dec 22, 2018 at 09:28:04AM +0100, Felix Natter wrote:
> hello debian-java,
> 
> I have a trivial bug fix for a Freeplane FTBFS (thanks to Emmanuel for
> the maven.rules hint!):
> 
> freeplane (1.7.2-2) unstable; urgency=medium
> 
>   * Add maven rule for pulling javax.servlet:javax.servlet-api:3.1
> instead of javax.servlet:javax.servlet-api:debian (Closes: #915889)
> 
>  -- Felix Natter   Fri, 21 Dec 2018 21:31:46 +0100
> 
> The repo is here:
>   https://salsa.debian.org/java-team/freeplane/
> 
> Could someone please sponsor this? Tony, since you sponsored 1.7.2-1?

Sure thing!  Thank you for the update.

Cheers,
tony



signature.asc
Description: PGP signature

Re: Please sponsor freeplane-1.7.2

[tony mancill]

On Sat, Nov 24, 2018 at 07:10:15PM +0100, Felix Natter wrote:
> hello Debian-java,
> 
> there is a new major release of freeplane (1.7.2), which among many
> other things has an API layer and full support for Java11.

Hi Felix,

Built, tagged, and uploaded - thank you for your contribution!

Cheers,
tony


signature.asc
Description: PGP signature

Re: OpenJDK 8u191 ready for upload but it needs jtreg fix

[tony mancill]

On Wed, Nov 21, 2018 at 01:57:56AM -0200, Tiago Daitx wrote:
> Hi,
> 
> I have prepared an openjdk-8 update to 8u191, which will fix bugs
> 911925 [1] and 911847 [2].

Hi Tiago,

I haven't done many uploads of openjdk, so I don't know if the following
lintian errors are expected or not:

E: openjdk-8-dbg: library-in-debug-or-profile-should-not-be-stripped 
usr/lib/debug/.build-id/50/81506253722bd2ed23f7c30c47d5e4f6ca4f6c.debug
E: openjdk-8-dbg: library-in-debug-or-profile-should-not-be-stripped 
usr/lib/debug/.build-id/a4/990ded0dc0bf378d9fc7d2b0d9b04b04d923f8.debug

I built locally against the updated jtreg and gone ahead and sponsored
the upload to experimental.  Please let me know if you need any
subsequent uploads.

Cheers,
tony


signature.asc
Description: PGP signature

Re: OpenJDK 8u191 ready for upload but it needs jtreg fix

[tony mancill]

On Wed, Nov 21, 2018 at 01:57:56AM -0200, Tiago Daitx wrote:
> Hi,
> 
> I have prepared an openjdk-8 update to 8u191, which will fix bugs
> 911925 [1] and 911847 [2].
> 
> Before this upload is done it would be very good to have the fix for
> jtreg's bug 913853 [3] in place.

Uploaded.  Thank you for the patch.

> This is required/important because I have fixed openjdk-8's
> autopkgtests and they will run the exact same tests as the ones that
> run during the build. After that they execute jtdiff against both the
> saved results from build time and from the autopkgtest results. This
> allows the autopkgtest to catch possible regressions but all is this
> benefit is gone if the build time tests are run with jtreg 4.2-b13-1
> where most of the tests fail to execute.
> 
> Note: take the new autopkgtests with a grain of salt. As of now there
> are still some flaky tests in the 3 testsuites - I hope to either fix
> or filter them out when I have more data on them.
> 
> On a side note, I am not sure how autopkgtests work on the debian
> infrastructure, but the ones in Ubuntu required me to request a bigger
> machine [4]. If anyone knows whether I need to request a similar
> exception on Debian, please let me know.
> 
> The openjdk-8 for experimental has been uploaded to mentors [5,6].

I will take a look at uploading this as well (assuming I can build it
locally).

Cheers,
tony


signature.asc
Description: PGP signature

Re: Importing new pristine tar into git ?

[tony mancill]

On Thu, Oct 25, 2018 at 03:58:32PM +0200, Andreas Tille wrote:
> On Wed, Oct 24, 2018 at 02:20:49PM +0200, Mathieu Malaterre wrote:
> > 
> > gbp import-orig ../fop_2.3.orig.tar.gz
> 
> Please add --pristine-tar to update pristine-tar branch.

You can also add this to your ~/.gbp.conf file.  I do this because I
always want the import to occur.  The option can appear either in the
[DEFAULT] section or the [import-orig] section of the file.  For
example:

$ cat ~/.gbp.conf 
[DEFAULT]
postbuild = lintian $GBP_CHANGES_FILE
upstream-branch = upstream
builder = /usr/bin/git-pbuilder
pristine-tar = True

[buildpackage]
export-dir = ../build-area/
tarball-dir = ../tarballs/

[import-orig]
dch = False

Re: jh_exec strangeness : doing chmod -x?

[tony mancill]

On Wed, Oct 10, 2018 at 12:10:50AM +0200, Alexandre Rossi wrote:
> Hi,
> 
> I'm not familiar with perl but the rewrite[1] of jh_exec reads "chmod
> -x" while the tool is expected to make some jars executable. My
> debhelper log shows "chmod -x" while I would expect "chmod +x".
> 
> [1] 
> https://salsa.debian.org/java-team/javatools/commit/4d3e2123f5e747014a0d060416f7f3283e6c31fa#d2b7ab9ed402b6a9b218217d3cd746e7a1d34f0d_38_59
> 
> This seems too obvious to be the culprit of my package build broken
> but I felt like asking. Am I missing something?

Hi Alex,

I don't think you're missing anything.  It looks like the sense of that
chmod argument was inadvertently flipped during the jh_exec rewrite.

Thank you for finding the issue and tracking it all the back to the
commit that changed the behavior.

I'll prepare a patched upload soon (if Niels doesn't beat me to it).

Cheers,
tony


signature.asc
Description: PGP signature

Re: Fwd: Bug#910327: RFS: javapoet/1.11.1-1 [ITP]

[tony mancill]

Hello Miroslav,

Thank you for packaging javapoet.  I was looking at doing this as a
dependency for some of the OpenHFT libraries.

One minor change I think we need to make to debian/copyright is to
explicitly list the files that have Google and not Square as the
copyright holder, but otherwise the package looks good.

Just as you suggest below, I will push the packaging into a repo on
salsa.debian.org (so the same as with picocli) and bring the package
under Debian Java Maintainers with you as an Uploader.

Cheers,
tony

On Thu, Oct 04, 2018 at 10:25:04PM +0200, Miroslav Kravec wrote:
> Dear package maintainers,
> 
> I'm looking for a sponsor for javapoet (see details of forwarded message).
> 
> The package can be moved under Debian Java Maintainers, as was done for:
> 
> * https://tracker.debian.org/pkg/picocli ,
> * https://tracker.debian.org/pkg/gradle-apt-plugin .
> 
> Or, you can leave me as maintainer, if you wouldn't like to move it
> under Debian Java Maintainers.
> 
> Kind regards,
> Miroslav Kravec
> 
> -- Forwarded message -
> From: Miroslav Kravec 
> Date: Thu, Oct 4, 2018 at 10:09 PM
> Subject: Bug#910327: RFS: javapoet/1.11.1-1 [ITP]
> To: 
> 
> 
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "javapoet":
> 
>  * Package name: javapoet
>Version : 1.11.1-1
>Upstream Author : Square, Inc.
>  * URL : https://github.com/square/javapoet
>  * License : Apache-2.0
>Section : java
> 
> It builds those binary packages:
> 
> libjavapoet-java - Java API for generating .java source files
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/javapoet
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/j/javapoet/javapoet_1.11.1-1.dsc
> 
> Changes since the last upload:
> 
>   * Initial release (Closes: #910313)
> 
> Kind regards,
> Miroslav Kravec


signature.asc
Description: PGP signature

Re: Please sponsor freeplane-1.6.15-1

[tony mancill]

On Thu, May 31, 2018 at 07:47:25PM +0200, Felix Natter wrote:
> hello debian-java,
> 
> there is a minor update for freeplane (among others export fixes):
> 
> freeplane (1.6.15-1) unstable; urgency=medium

Hi Felix,

Uploaded and tagged in the repo...

Cheers,
tony


signature.asc
Description: PGP signature