Bug#819186: javaws on armhf doesn't seem to work with ASRock Rack remote console
Control: tags -1 wontfix Control: close -1 Closing since this is caused by a missing native library for arm in the jviewer application. Emmanuel Bourg
Bug#668177: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application
Control: fixed -1 1.7.1-1 Control: close -1 I'm unable to reproduce this issue with the version 1.7.1, the main class is found and started. It has probably been fixed upstream. Emmanuel Bourg
Bug#696890: icedtea-netx: Unable to create locks directory (/tmp/rbrito/netx/locks)
Control: tags -1 + wontfix Control: close -1 The plugin is no longer built since 1.7.1-1. Emmanuel Bourg
Bug#738632: icedtea-netx: split javaws 6 & 7 to different packages
Control: tags -1 + wontfix Control: close -1 Since the version 1.7.1-1 icedtea-netx is no longer integrated with a specific version of OpenJDK, so there is no point splitting the package anymore. Emmanuel Bourg On Tue, 11 Feb 2014 13:48:37 +0100 Charles Malaheenee wrote: > Package: icedtea-netx > Version: 1.4.2-1 > Severity: wishlist > Tags: upstream > > Dear Maintainer, > > I suggest to split package to icedtea-6-netx and icedtea-7-netx (or similar) > to > avoid have 2 different versions of javaws on the user's machines. I use now > openjdk-7, but until I run update-alternatives (yes, I don't use default-jre), > javaws by default sets to version 6. On top of everything, why I must have > unused version on my desktop? > > Best regards, > Malaheenee > > > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'testing'), > (500, 'stable'), (1, 'experimental') > Architecture: i386 (i686) > > Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) > Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages icedtea-netx depends on: > ii icedtea-netx-common 1.4.2-1 > ii openjdk-7-jre7u51-2.4.5-2 > > icedtea-netx recommends no packages. > > icedtea-netx suggests no packages. > >
Bug#855686: icedtea-web: FTBFS: configure: error: Package requirements (mozilla-plugin) were not met
Control: tags -1 - pending Control: tags -1 + wontfix Control: close -1 The browser plugin has been removed in 1.7.1-1.
Bug#889553: icedtea-netx-common: missing L10n in itweb-settings desktop file
Control: fixed -1 1.7.1-1 Control: close -1 Thank you for the contribution Ronny. This has been fixed in the version 1.7.1-1. Emmanuel Bourg
Bug#806283: icedtea-netx: Inconsistent handling of deployment properties which contain '='
Control: tags -1 + wontfix Control: close -1 The plugin is no longer built since 1.7.1-1. Emmanuel Bourg
Bug#675082: icedtea-netx-common: dependency issue wrt itweb-settings
Control: fixed -1 1.7.1-1 Control: close -1 This has been fixed in 1.7.1-1 when icedtea-netx-common and icedtea-netx were merged. Emmanuel Bourg
Bug#673415: icedtea-netx:amd64: hangs when starting a Java Web Start program and proxy auto-configuration is enabled
Control: fixed -1 1.7.2-1 Control: close -1 Rhino has been added to the dependencies in the version 1.7.2-1
Bug#924706: icedtea-netx: javaws symlink is broken
On 16/03/2019 05:08, Jon DeVree wrote: > The files in /usr/share/icedtea-web/bin have the wrong file names in the > new package and this breaks javaws. itweb-settings and policyeditor are > also broken. Hi Jon, Thank you for reporting this issue. I'll upload a fix shortly. Emmanuel Bourg
Bug#924635: libactivemq-java depends on the removed libspring-jms-java
On 15/03/2019 09:56, Matthias Klose wrote: > Package: libactivemq-java > Version: 5.15.8-2 > Severity: serious > Tags: sid buster > > libactivemq-java depends on the removed libspring-jms-java. > Errr why was libspring-jms-java removed? That seems wrong, this will cause the removal of activemq. Emmanuel Bourg
Bug#912549: icedtea-web FTBFS with OpenJDK 11
On 13/03/2019 17:47, Matthias Klose wrote: > please look at the new upstream 1.7.2 and 1.8 releases. I got a quick look at these new versions released this week, IcedTea Web 1.7.2 is rather close to the version in unstable since October and has a few extra Java 9+ fixes, it's probably worth considering for Buster. The version 1.8 doesn't seem to improve the Java 9+ compatibility and the new Rust based launcher looks like a big change I'd rather see in Bullseye. The upcoming version 1.9 looks interesting since it removes the applet code that is causing the FTBFS with Java 11 we are discussing here, but that will be too late for Buster. Emmanuel Bourg
Bug#912549: icedtea-web FTBFS with OpenJDK 11
On 13/03/2019 21:30, Markus Koschany wrote: >>>> Michael Crusoe has suggested a workaround[1]. What do you think about >>>> this? >>> >>> In case there is no answer to this question I assume it is OK to >>> upload the workaround. Hope you agree with this. >> >> please look at the new upstream 1.7.2 and 1.8 releases. >> > > In https://bugs.debian.org/855686 Emmanuel wrote that icedtea-web will > be removed. I don't have a strong opinion in this case. If Michael's > workaround works, why not. However I think it is too late now for new > upstream releases as doko seems to imply. > > Please note there are several other RC issues that are marked as pending > but I believe the "fix" is to remove the package from Debian. FYI I'm working on a fix, I plan to upload it next week if it works, or the Michael's patch if it doesn't. Emmanuel Bourg
Bug#923941: libmaven3-core-java has a typo in the libmaven-parent-java dependency
Le 07/03/2019 à 15:04, Matthias Klose a écrit : > So I assume that is a typo, loosening the dependency instead of tightening it. Not a typo but a bug in maven-debian-helper when the dependencies are resolved. The source package has the right version constraint on the build dependency. Emmanuel Bourg
Bug#923709: svgsalamander: FTBFS with Java 11.0.2 (The code being documented uses packages in the unnamed module)
Source: svgsalamander Severity: serious Tags: buster sid svgsalamander fails to build with Java 11.0.2 due to javadoc changes: -javadoc-build: [mkdir] Created dir: /build/svgsalamander-1.1.1+dfsg/svg-core/dist/javadoc [javadoc] Warning: Leaving out empty argument '-windowtitle' [javadoc] Generating Javadoc [javadoc] Debian build on Java 9+ detected: Adding the --ignore-source-errors option [javadoc] Javadoc execution [javadoc] Loading source file /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/A.java... [javadoc] Loading source file /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/Circle.java... [javadoc] Loading source file /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/ClipPath.java... [javadoc] Loading source file /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/Defs.java... ... [javadoc] Constructing Javadoc information... [javadoc] javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are in named modules. [javadoc] Standard Doclet version 11.0.3 [javadoc] Building tree for all the packages and classes... [javadoc] /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/app/beans/SVGIcon.java:383: warning - @return tag cannot be used in method with void return type. [javadoc] /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/app/beans/SVGPanel.java:257: warning - @return tag cannot be used in method with void return type. [javadoc] /build/svgsalamander-1.1.1+dfsg/svg-core/src/main/java/com/kitfox/svg/SVGElement.java:236: warning - @return tag cannot be used in method with void return type. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Building index for all classes... [javadoc] Generating /build/svgsalamander-1.1.1+dfsg/svg-core/dist/javadoc/help-doc.html... [javadoc] 1 error [javadoc] 3 warnings BUILD FAILED /build/svgsalamander-1.1.1+dfsg/svg-core/nbproject/build-impl.xml:1262: Javadoc returned 1
Bug#923564: FTBFS: Could not resolve org.codehaus.plexus:plexus-classworlds:2.5.2
Le 02/03/2019 à 09:24, Sebastiaan Couwenberg a écrit : > And that point was preferably in January when plexus was updated, not 10 > days before the full freeze. The timing of this RC bug is very unfortunate. Relax, the freeze is meant to stabilize things and that's what we're doing here. If osmosis doesn't transition before the full freeze the Release Team will accept an unblock request to fix a FTBFS. Emmanuel Bourg
Bug#923564: FTBFS: Could not resolve org.codehaus.plexus:plexus-classworlds:2.5.2
Le 02/03/2019 à 08:07, Sebastiaan Couwenberg a écrit : > In the future I would prefer if reverse dependencies of updated java > packages where tested when they are updated, like people do for transitions. Thank you for applying the patch. libplexus-classworlds2-java is to be removed, FTBFS or not osmosis had to be updated at some point anyway. Emmanuel Bourg
Bug#923564: FTBFS: Could not resolve org.codehaus.plexus:plexus-classworlds:2.5.2
Package: osmosis Version: 0.47-3 Severity: serious Hi, osmosis currently fails to build in unstable, that was probably caused by the upgrade of plexus-classworlds in January. Here is a patch fixing the issue. Emmanuel Bourg diff --git a/debian/control b/debian/control index 4ff5eb5..90019ea 100644 --- a/debian/control +++ b/debian/control @@ -27,7 +27,7 @@ Build-Depends: debhelper (>= 9), libspring-transaction-java, libstax2-api-java, libosmpbf-java, - libplexus-classworlds2-java, + libplexus-classworlds-java, libprotobuf-java (>= 3.6.1), libwoodstox-java, libxerces2-java, @@ -57,7 +57,7 @@ Depends: default-jre-headless | java8-runtime-headless, libspring-jdbc-java, libspring-transaction-java, libosmpbf-java, - libplexus-classworlds2-java, + libplexus-classworlds-java, libprotobuf-java, libxerces2-java, libxz-java, diff --git a/debian/maven.rules b/debian/maven.rules index 3898b15..8fd7b9f 100644 --- a/debian/maven.rules +++ b/debian/maven.rules @@ -1,6 +1,5 @@ junit junit * s/.*/4.x/ * * -org.codehaus.plexus plexus-classworlds * s/.*/2.x/ * * org.springframework spring-jdbc * s/.*/debian/ * * #s/org.jboss.netty/io.netty/ netty * s/.*/debian/ * * s/org.postgis/net.postgis/ postgis-jdbc * s/.*/debian/ * * diff --git a/debian/patches/01-fix_launcher.patch b/debian/patches/01-fix_launcher.patch index cda6abe..fc58210 100644 --- a/debian/patches/01-fix_launcher.patch +++ b/debian/patches/01-fix_launcher.patch @@ -28,7 +28,7 @@ Forwarded: not-needed # Build up the classpath of required jar files via classworlds launcher. -MYAPP_CLASSPATH=$MYAPP_HOME/lib/default/plexus-classworlds-*.jar -+MYAPP_CLASSPATH=$LIBRARIES_HOME/plexus-classworlds2.jar ++MYAPP_CLASSPATH=$LIBRARIES_HOME/plexus-classworlds.jar MAINCLASS=org.codehaus.classworlds.Launcher -EXEC="$JAVACMD $JAVACMD_OPTIONS -cp $MYAPP_CLASSPATH -Dapp.home=$MYAPP_HOME -Dclassworlds.conf=$MYAPP_HOME/config/plexus.conf $MAINCLASS $OSMOSIS_OPTIONS"
Bug#919638: solr-tomcat: Permission problems after update to tomcat9
Le 01/03/2019 à 18:29, Markus Koschany a écrit : > I have never extended security permissions of > another systemd service. How is this supposed to work? I'm not used to this either, but I think we just have to install a /etc/systemd/system/tomcat9.d/solr-permissions.conf file with theses lines: [Service] ReadWritePaths=/var/lib/solr/ A call to 'systemctl daemon-reload' is probably needed in the postinst script (but maybe there is a trigger taking care of that already).
Bug#919638: solr-tomcat: Permission problems after update to tomcat9
Le 01/03/2019 à 18:19, Markus Koschany a écrit : > I think just creating /var/lib/solr with tomcat9.dirs is sufficient. I > tested both cases, installing tomcat9 first and then solr-tomcat and > vice versa, and the server always started correctly. SystemD just > requires an existing directory. Do you agree with this change? > > https://salsa.debian.org/java-team/tomcat9/commit/fc31e79f1c5f94cfcef0c75c3133654edf00a28e It looks a bit odd to put solr specific stuff in tomcat9. I'd rather investigate a solution involving a /etc/systemd/system/tomcat9.d/ file installed by solr-tomcat and extending the write permissions. Emmanuel Bourg
Bug#923219: ITP: eclipse-package -- Utility for creating Eclipse Debian packages
Hi Philipp, On Mon, 25 Feb 2019 09:10:40 +0100 Philipp Meisberger wrote: > This package provides the capability to build a Debian package from an > Eclipse binary distribution by running make-eclipsepkg file>. Download the archive file from > https://www.eclipse.org/downloads/eclipse-packages/ > > This package is a good addition to Debian since there seems no such > application. I often use it. The package is no dependency for other packages. > I am looking for a sponsor. This would be a good fit for the Java Team. I'll be happy to sponsor it. Emmanuel Bourg
Bug#893244: jruby FTBFS with openjdk-9
Le 26/02/2019 à 15:05, Markus Koschany a écrit : > The FTBFS bug got fixed yesterday. I should complain more often. Andrej > uploaded version 9.1.17 to unstable. This is not the latest one but I > guess better than nothing? The original bug has not been closed yet. > Andrej, can we close it now and Debian bug #917702 too? Any hope to package JRuby 9.2.x? AFAIK it supports Java 11 better. Emmanuel Bourg
Bug#923284: Seemingly miscompiles with jdk-11
Le 26/02/2019 à 12:22, Sjoerd Simons a écrit : > ASM7 mode seems to have been introduced in the gradle v5.x series. Not > sure if it makes sense for buster to upgrade to that (I really don't > know much about java, so no idea about the impact)? We can't upgrade to Gradle 5 unfortunately, not until Kotlin is packaged (#892842). This will be a key issue in the next development cycle. > That said making all gradle dependencies target pre-Java 11 probably > doens't scale either? If it's just the Gradle dependencies it's doable, and the severity of the bug can be downgraded because the issue only appears if the dependencies are rebuilt. If the issue also appears when project dependencies use Java 11 this is a more important issue. Emmanuel Bourg
Bug#923317: FTBS: fails to build after libjaxp1.3-java is rebuild on buster
Le 26/02/2019 à 11:23, Sjoerd Simons a écrit : > This may or may not be related to 923284 This is the same issue. Gradle breaks when its dependencies use Java 11 bytecode. Emmanuel Bourg
Bug#923284: Seemingly miscompiles with jdk-11
Le 26/02/2019 à 10:20, Sjoerd Simons a écrit : > I've atteched the output of running docker build on the DockerFile i > attached to reproduce the issue; The relevant part in the gradle build > seems to be: Thank you! The "Malformed jar" message is just a warning. The actual issue is: > Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7 > at org.objectweb.asm.ClassVisitor.visitNestHost(ClassVisitor.java:150) > at org.objectweb.asm.ClassReader.accept(ClassReader.java:541) > at org.objectweb.asm.ClassReader.accept(ClassReader.java:391) > at > org.gradle.api.internal.tasks.compile.incremental.asm.ClassDependenciesVisitor.analyze(ClassDependenciesVisitor.java:75) Most likely triggered because the recompiled bsh uses Java 11 bytecode. This can be fixed either by targeting a pre Java 11 release in the bsh build, or by patching Gradle to use Opcodes.ASM7. Emmanuel Bourg
Bug#919638: solr-tomcat: Permission problems after update to tomcat9
Control: reopen -1 Control: notfixed -1 9.0.16-2 Le 17/02/2019 à 12:38, Markus Koschany a écrit : > Thank you for the confirmation. Then I think reassigning this issue to > src:tomcat9 and fixing it there is sensible. Unfortunately the modification broke tomcat9 installations when solr isn't installed (#923299) and I had to revert it in the version 9.0.16-3. We have to figure out another solution. Either: 1. abandon the idea of restricting tomcat9 write access 2. change solr-tomcat so that it modifies the tomcat9 permissions on install 3. drop solr-tomcat, upstream recommends using Jetty after all. Emmanuel Bourg
Bug#923284: Seemingly miscompiles with jdk-11
Thank you for the report Sjoerd. What error did you get when compiling gradle with the rebuilt bsh? Emmanuel Bourg
Bug#923245: unblock: procyon/0.5.32-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package procyon The package was removed from testing due to an incompatibility with Java 11 which has just been fixed (#909259). Procyon is the only Java decompiler packaged in Debian, it was part of Stretch and it would be nice to have it in Buster. Thank you, Emmanuel Bourg unblock procyon/0.5.32-5
Bug#923041: Scala interpreter cannot interpret files
Control: forwarded -1 https://github.com/scala/bug/issues/10603 Thank you for reporting this issue Fabian. It seems to be a known upstream bug. The current workaround is to run 'scala -nc test.scala'. Emmanuel Bourg
Bug#922347: maven cannot be executed on Java7
Control: reassign -1 libwagon-http-shaded-java Le 14/02/2019 à 21:18, Martin Monperrus a écrit : > Exception in thread "main" java.lang.UnsupportedClassVersionError: > org/apache/maven/wagon/providers/http/httpclient/HttpException : Unsupported > major.minor version 52.0 Thank you for reporting this issue Martin. wagon needs to be rebuilt with libhttpcore-java >= 4.4.11-1, this version was compiled to preserve the compatibility with Java 7. I'll take care of that. Emmanuel Bourg
Bug#922245: src:cava: Please rename the source package
Hi Nicolas, Le 13/02/2019 à 18:54, Nicolas Braud-Santoni a écrit : > There is a name colision on cava, which is also an audio visualisation tool > for > which a RFP bug was open (#829287). By using the same name for the source > package, you caused the RFP for a completely-unrelated piece of software to be > closed. I fail to see why the name of the source package causes a problem. The Cava audio visualisation tool could be packaged with a source package named cava-audio-visualisation or cava-audio. Feel free to use the 'cava' name for the binary package, I don't think the Java package will ever need that. > Please consider changing the source package's name to cava-java (which seem to > be the idiom for java packages) or libcava-java. > > Considering that we entered freeze for the Buster release, I would definitely > understand holding off until after the release. If the Java package was to be renamed I'd rather suggest consensys-cava. And not during the freeze of course. Emmanuel Bourg
Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8
Le 05/02/2019 à 15:05, Emmanuel Bourg a écrit : > The real issue is lombok, it needs both Java 8 and 11 to build (and even > 6 and 7! But we managed do to without that). Erratum: I've just figured out how to build lombok with Java 11 only. Once ivyplusplus is taught about the new javac 'release' option it's easy. Uploads will follow soon. Emmanuel Bourg
Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8
Hi all, Le 05/02/2019 à 14:24, Per Lundberg a écrit : > is this the correct list of packages which can only be built w/ openjdk-8 That's almost correct: - jzmq and openjfx are built with openjdk-11 already - openjdk-8-jre-dcevm has just been removed, replaced by openjdk-11-jre-dcevm (not in testing yet) - leiningen-clojure is about to be updated with Java 11 compatibility - uwsgi builds with openjdk-11, but supports openjdk-8 on kfreebsd. The Java 8 plugin can probably be dropped. - virtualbox switched to openjdk-11 a few days ago - icedtea-web should support Java 11 in the next upstream release The real issue is lombok, it needs both Java 8 and 11 to build (and even 6 and 7! But we managed do to without that). This is a complicated package that is now a key part of the Java ecosystem in Debian, and we can't really do without it. It looks like the latest releases have improved the Java 11 support but I doubt it can build without Java 8. Note that we'll still need OpenJDK 8 as part of the SBT packaging effort (which is required to build Scala 2.12). I wouldn't be surprised to see it required as well to bootstrap Kotlin. So even if we managed to ship Buster without openjdk-8, the package should remain in unstable until this is sorted out. Emmanuel Bourg
Bug#921419: openjdk-11: Add support for DCEVM
Package: openjdk-11-jre-headless Version: 11.0.2+9-3 Severity: wishlist User: debian-j...@lists.debian.org Usertags: default-java11 openjdk-11-jre-dcevm has just landed in unstable, this means the jvm.cfg file installed by openjdk-11 can now include dcevm as an alternative VM like openjdk-7 and openjdk-8 before. https://sources.debian.org/src/openjdk-8/8u191-b12-2/debian/rules/?hl=1430#L1430
Bug#921217: RM: openjdk-8-jre-dcevm -- ROM; Replaced by openjdk-11-jre-dcevm
Package: ftp.debian.org Severity: normal User: debian-j...@lists.debian.org Usertags: default-java11 Hi, Please remove the the openjdk-8-jre-dcevm package, it's being replaced by openjdk-11-jre-dcevm as part of the transition to OpenJDK 11. Thank you, Emmanuel Bourg
Bug#897945: #897945 still present/breaks with Java 8
Le 01/02/2019 à 09:17, Per Lundberg a écrit : > I think that risk is significant. If we go that route, I would suggest a > postinst/debhelper message saying that "OpenJDK 8 is included but > unsupported. Many packages will not work with it. Use at your own risk." > or something similar. This is an excellent suggestion. We should file a bug for openjdk-8 to implement that. Emmanuel Bourg
Bug#897945: #897945 still present/breaks with Java 8
Le 29/01/2019 à 14:19, Per Lundberg a écrit : > Another question: if this is the case, should the openjdk-8-jdk package > (and friends) be removed altogether in sid? We can't remove openjdk-8 yet, it's still required to build some convoluted packages. But Buster will only support OpenJDK 11, this will be documented in the release notes. Emmanuel Bourg
Bug#920802: ITP: caffeine-cache -- High performance caching library
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: caffeine-cache Version : 2.6.2 Upstream Author : Ben Manes * URL : https://github.com/ben-manes/caffeine * License : Apache-2.0 Programming Lang: Java Description : High performance caching library Caffeine provides an in-memory cache using a Google Guava inspired API. The improvements draw on the experience designing Guava's cache and ConcurrentLinkedHashMap. Caffeine provides flexible construction to create a cache with a combination of the following features: * Automatic loading of entries into the cache, optionally asynchronously * Size-based eviction when a maximum is exceeded based on frequency and recency * Time-based expiration of entries, measured since last access or last write * Asynchronously refresh when the first stale request for an entry occurs * Keys automatically wrapped in weak references * Values automatically wrapped in weak or soft references * Notification of evicted (or otherwise removed) entries * Writes propagated to an external resource * Accumulation of cache access statistics This library is a new dependency of Apache JMeter (packaged as jakarta-jmeter). It'll be maintained by the Java Team.
Bug#897945: #897945 still present/breaks with Java 8
Le 29/01/2019 à 10:40, Per Lundberg a écrit : > FWIW, version 1.4.2-1 works correctly with openjdk-11-jdk version > 11.0.2+7-1, but it _does not_ work correct any more with Java 8 > (openjdk-8-jdk version 8u191-b12-2) Thank you for the feedback Per. What issue did you see when using visualvm with Java 8? You tried running visualvm with Java 8 or you tried attaching visualvm to a Java 8 VM? Emmanuel Bourg
Bug#920771: ITP: jodd -- Java utility library and set of frameworks
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jodd Version : 3.8.6 Upstream Author : Igor Spasić and contributors * URL : https://jodd.org * License : BSD-2-clause Programming Lang: Java Description : Java utility library and set of frameworks Jodd is an open-source Java utility library and set of frameworks. Jodd tools enriches JDK with many powerful and feature rich utilities. It helps with everyday task, makes code more robust and reliable. Jodd frameworks is set of lightweight application frameworks, compact yet powerful. Designed following the CoC, DRY and SCS principles, it makes development simple, but not simpler. This library is a new dependency of Apache JMeter (packaged as jakarta-jmeter). It'll be maintained by the Java Team.
Bug#920714: lombok: Build-Depends on openjdk-8-jdk which will no be in buster
Control: severity -1 wishlist Hi Andreas, Actually lombok is the exception that is forcing us to ship (but not support) openjdk-8-jdk in Buster. It's a build time only dependency, lombok works with OpenJDK 11 at runtime. Emmanuel Bourg
Bug#893227: libbluray FTBFS with openjdk-9
Le 22/01/2019 à 23:26, Reinhard Tartler a écrit : > Since openjdk-8 is going to be kept in Buster, I don't think > we need to keep this bug at RC severity. I'm concerned that keeping > this bug at RC severity might risk having libbluray being removed > from testing, which I don't think is in the best interest of our > users. Well, the issue remains critical, because the package doesn't work with the default JRE the users are going to use in Buster. OpenJDK 8 is not to be used at runtime in Buster. Emmanuel Bourg
Bug#919064: scala FTBFS: java.lang.NoClassDefFoundError: com/tonicsystems/jarjar/asm/commons/ModuleHashesAttribute
Control: reassign -1 libjarjar-java Control: affects -1 src:scala Control: retitle -1 jarjar: ASM class ModuleHashesAttribute is missing Le 20/01/2019 à 08:06, Andreas Tille a écrit : > I've seen that there is a new upstream > version (2.12.8) - may be I should give it a try but I have no idea > about consequences of exchanging a package that has lots or rdepends > currently and whether this would qualify as "transition". It definitely would, but I doubt any human being is able to package SBT and Scala 2.12 in time before the freeze anyway (I'm offering a bottle of Champagne if someone does). The good news is, we won't have to go that route, because this issue isn't caused by Scala but by jarjar. It embeds a subset of the ASM classes and at least one is missing. I'll upload a fix today. Emmanuel Bourg
Bug#893227: libbluray FTBFS with openjdk-9
Hi Reinhard, Le 22/01/2019 à 12:14, Reinhard Tartler a écrit : > Can you please give us an update on the roadmap for Java? > What's the status on removing openjdk-8 from buster? OpenJDK 8 will be kept in Buster but it should be used in exceptional cases (for example the lombok package requires both OpenJDK 8 and 11 to build). The default Java runtime for Buster is OpenJDK 11 and the packages have to work properly with it. @Petri: Thank you for fixing the OpenJDK 11 issues. I suggest ignoring the JDK 9 and 10 issues since these versions are now EOL. The general consensus in the Java community is to support only the LTS releases (Java 8, 11, 17, etc). Emmanuel Bourg
Bug#914466: RM: icu4j-49 -- ROM; Obsolete, no longer used
Control: tags -1 - moreinfo Le 27/11/2018 à 08:20, Scott Kitterman a écrit : > Checking reverse dependencies... > # Broken Build-Depends: > lucene4.10: libicu4j-49-java Good catch, thank you. It's now removed in lucene4.10/4.10.4+dfsg-4
Bug#919638: solr-tomcat: Permission problems after update to tomcat9
Hi Michael, Le 18/01/2019 à 07:19, Michael Welsh Duggan a écrit : > I have no idea why it fails to write the lock file. It probably happens because tomcat9 is sandboxed to write only into its own directory. You'll have to tweak the systemd configuration to allow Tomcat to write into the solr directory (with the ReadWritePaths directive). The solr-tomcat package is rather old now, I'm tempted to remove it. Upstream has moved away from supporting deployments as a web application, Solr now embeds it own web server (Jetty). We wouldn't have this kind of issue with the latest versions. Emmanuel Bourg
Bug#912476: libapache-poi-java FTBFS with OpenJDK 11
Adding JAXB to the classpath isn't enough, the build also fails due to this upstream bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=62187 So we have to upgrade to the version 4.x to fix the compatibility with Java 11. I plan to build temporarily with Java 8 and upgrade to the version 3.17 first. That'll allow us to upgrade tika. I'll then proceed to upgrade POI to the version 4.x. Emmanuel Bourg
Bug#919092: Bug#919095: Bug#919092: fixed in mongo-java-driver 3.6.3-2
Le 12/01/2019 à 21:31, tony mancill a écrit : > Should I revert > https://salsa.debian.org/java-team/apache-log4j2/commit/4d8cf4493ad9f63a8cf8d24ae463bd18a12ed1a1 > and restore support for that logging adapter? You can revert the commit but don't bother uploading again now, this can wait the next package update. I don't think the mongodb module is actually used. Emmanuel Bourg
Bug#919095: (no subject)
Control: tags -1 + wontfix Control: close -1 log4j doesn't depend on mongodb.
Bug#903428: deduplicating jquery/
Le 07/01/2019 à 23:02, Samuel Thibault a écrit : > I'd rather cripple the documentation a bit than removing it :) The issue is, we keep getting more and more javadoc related issues with each OpenJDK upgrade. This jquery "issue" is a bit the straw that breaks the camel's back, and we would rather cut the loss now than investing even more time on these low popcon packages. The Java Team is understaffed, we struggle to keep up with the JDK upgrades and update the important packages, so the documentation issues are really low priority items. > Could jh_build perhaps just drop the embedded jquery copy to just avoid > the issue? AFAIK, jquery is only used to implement the "search" feature, > which can sometimes be convenient, but can be done by users with greps & > such. jh_build is only part of the picture. Most javadoc packages are generated by Maven, so the maven-javadoc-plugin would have to be patched as well. Emmanuel Bourg
Bug#850798: tika: FTBFS: Could not resolve dependencies for project org.apache.tika:tika-parsers:jar:1.5
Control: reassign -1 libvorbis-java Control: affects -1 src:tika I'm reassigning the bug to vorbis-java because the tika module should be enabled there to fix this dependency issue. I'll look at the other compilation errors separately. Emmanuel Bourg
Bug#906398: projectreactor: FTBFS in buster/sid
Control: reassign -1 libjarjar-java Control: affects -1 src:projectreactor This is an issue with the jarjar Ant task that no longer works but I fail to understand exactly why. The classes in the disruptor jar should be relocated to reactor.jarjar.com.lmax.disruptor but it doesn't happen and this leads to compilation errors. It looks like the error was triggered by the upload of disruptor/3.4.2-1, projectreactor builds fine with the version 3.3.11-1. Rebuilding jarjar with ASM 7 instead of 5 fixes the issue. I guess something specific to Java 9+ was introduced when building disruptor 3.4.2-1 and it derailed the jarjar processing. Emmanuel Bourg
Bug#873341: SBT is uninstallable; depends on nonexistent packages
Hi Antonio, Le 03/01/2019 à 10:59, Antonio Ospite a écrit : > Are there any plans to improve the situation? We lack contributors to maintain the Scala ecosystem in Debian and some help would be really welcome. I spent some time updating our scala package but I'm not a Scala developer and I don't have the time to look into this anymore. If someone wants to pick the ball the next steps are to: 1. build SBT 1.0 without the embedded libraries 2. build Scala 2.12 Emmanuel Bourg
Bug#917727: openhft-lang: FTBFS: [ERROR] /<>/lang/src/main/java/net/openhft/lang/io/IOTools.java:[85, 13] cannot find symbol
Le 30/12/2018 à 17:29, tony mancill a écrit : > Given that there aren't many (or any?) r-deps for the openhft libraries, > I'm tempted to pull the versions in experimental into unstable so we > have the libraries in buster. It's either that, or not include these > packages in buster at all. > > Thoughts? The OpenHFT libraries are used by Spring (libspring-java), and if I remember well I had to pick very specific versions to have a consistent set of compatible libraries. I plan to upgrade Spring to the version 5.1 before the freeze, I'll see at this moment what versions of the OpenHFT libraries are required. Emmanuel Bourg
Bug#917576: stegosuite: depends on libswt-gtk2 which is no longer built
Le 30/12/2018 à 15:45, tony mancill a écrit :
> 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.
Hi Tony,
There is an issue with the Maven artifacts for SWT, they are installed
with the versions 'debian' and '4.x', and we've set the
--has-package-version flag stating that the pom and the package have the
same version, which is wrong.
I've fixed that in swt4-gtk/4.10.0-2
Emmanuel Bourg
Bug#917600: puppetlabs-ring-middleware-clojure: FTBFS (failing tests)
On 29/12/2018 18:47, Cyril Brulebois wrote: > I've been contacted by Elana, and an MR is in progress for this package; > if it passes review, I'll submit other MRs for the remaining packages > (as fixes are almost identical), or I can push to the Java repositories > directly, as you folks prefer. Great, for the clojure packages it's good to have Elana to review them first. For the other Java packages you can send a MR or push directly to the repositories if you feel confident. Emmanuel Bourg
Bug#917600: puppetlabs-ring-middleware-clojure: FTBFS (failing tests)
On 29/12/2018 02:43, Cyril Brulebois wrote: > Please find attached a patch similar to those submitted in #907765, > #880320, #880351. I intend to NMU this package in a few days, as for > other packages, even if that bug report is rather recent. Thanks a lot for the patches Cyril. Feel free to upload the fixes, but preferably with a team upload rather than a NMU. I can grant you write access to the java-team repositories on Salsa. Emmanuel Bourg
Bug#912231: bnd FTBFS with OpenJDK 11
Le 20/12/2018 à 18:35, Markus Koschany a écrit : > Thanks for fixing this bug. I believe others will be affected by it too > in the future. Shouldn't that be fixed in gradle-debian-helper instead? > I mean it's not obvious that one has to export HOME now. I'm not sure, this seems very specific to bnd since, as I understand, it uses its own Gradle plugin to build itself. That's quite non standard. Usually for a build using gradle-debian-helper the poms land in /generated/debian/ and not under the home directory.
Bug#912231: bnd FTBFS with OpenJDK 11
Le 29/10/2018 à 23:32, Markus Koschany a écrit : > The OpenJDK 11 issue is rather simple to fix, however the build fails > later on with this error message, a Gradle issue? I've figured out what is causing the second issue, the poms are installed into .gradle/daemon/4.4.1/debian/.m2/ instead of debian/.m2/. Due to the way gradle-debian-helper 2.0.1 injects its code in the Gradle classpath the Gradle daemon is always started, and the daemon uses a different working directory (.gradle/daemon/4.4.1/). Since the location of the Maven repository where the artifacts are installed is specified as a relative path, it's shifted under the daemon working directory and maven-repo-helper no longer finds the artifacts at the expected path. This can be fixed by setting the repository location with an absolute path (the HOME variable in debian/rules). Emmanuel Bourg
Bug#916840: groovy: FTBFS with Java 11 due to polymorphic signature calls & SecurityManager changes
Package: src:groovy Version: 2.4.15-3 Severity: serious User: debian-j...@lists.debian.org Usertags: default-java11 groovy fails to build with Java 11, there are two different errors. The first one: groovy-2.4.15/src/main/org/codehaus/groovy/vmplugin/v7/IndyInterface.java:236: error: polymorphic signature calls are not supported in -target 1.6 return call.invokeExact(arguments); ^ (use -target 1.7 or higher to enable polymorphic signature calls) and the second one: groovy-2.4.15/subprojects/groovy-console/src/main/groovy/groovy/ui/text/StructuredSyntaxResources.java:44: error: cannot find symbol mgr.checkSystemClipboardAccess(); ^ symbol: method checkSystemClipboardAccess() location: variable mgr of type SecurityManager
Bug#915509: scala ftbfs: The repository system could not be initialized
Control: reassign -1 libaether-ant-tasks-java Control: affects -1 src:scala Control: severity -1 important This is actually an issue with libaether-ant-tasks-java, the classpath of aether-ant-tasks.jar is missing slf4j-api.jar. This issue was probably triggered by the update of Maven to the version 3.6. Emmanuel Bourg
Bug#916659: nailgun 1.0.0 depends on JUnit5
Le 17/12/2018 à 01:02, Hideki Yamane a écrit : > Just note, nailgun 1.0.0 depends on JUnit5 that is not packaged yet. > So, I cannot update nailgun from 0.9.3 to 1.0.0... Hi Hideki, You could maybe update nailgun but disable the unit tests until JUnit 5 is packaged? Emmanuel Bourg
Bug#915889: freeplane FTBFS: Could not resolve javax.servlet:javax.servlet-api:3.1.
Le 16/12/2018 à 12:00, Felix Natter a écrit : > True, the 3.1 pom is installed, but the debian pom isn't, and I think > that maven-repo-helper usually creates/links > .../javax.servlet-api/debian/javax.servlet-api-debian.(pom,jar) > as well. libservlet3.1-java never contained the 'debian' version, but the new libservlet-api-java which will arrive soon does have it. > One important question: How can I prevent the AUTORM from happening? Either wait for libservlet-api-java to hit unstable, or add this rule to debian/maven.rules: javax.servlet javax.servlet-api * s/.*/3.1/ * *
Bug#915889: freeplane FTBFS: Could not resolve javax.servlet:javax.servlet-api:3.1.
Le 16/12/2018 à 07:11, Felix Natter a écrit : > The problem is that the javax.servlet:javax.servlet-api:3.1 artifact > (src:tomcat8/bin:libservlet3.1-java) does not install a > debian/javax.servlet-api-debian.pom, so the resolution fails during > freeplane compilation. libservlet3.1-java does install the Maven pom for the Servlet API though: ebourg@icare:~$ wget http://ftp.us.debian.org/debian/pool/main/t/tomcat8/libservlet3.1-java_8.5.35-3_all.deb --2018-12-16 10:32:57-- http://ftp.us.debian.org/debian/pool/main/t/tomcat8/libservlet3.1-java_8.5.35-3_all.deb Resolving ftp.us.debian.org (ftp.us.debian.org)... 128.61.240.89, 128.30.2.26, 64.50.233.100, ... Connecting to ftp.us.debian.org (ftp.us.debian.org)|128.61.240.89|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 245100 (239K) [application/octet-stream] Saving to: ‘libservlet3.1-java_8.5.35-3_all.deb’ libservlet3.1-java_8.5.35-3_all.deb 100%[=>] 239.36K 609KB/sin 0.4s 2018-12-16 10:32:58 (609 KB/s) - ‘libservlet3.1-java_8.5.35-3_all.deb’ saved [245100/245100] ebourg@icare:~$ dpkg -c libservlet3.1-java_8.5.35-3_all.deb drwxr-xr-x root/root 0 2018-12-12 16:48 ./ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/doc/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/doc/libservlet3.1-java/ -rw-r--r-- root/root 6759 2018-12-12 16:48 ./usr/share/doc/libservlet3.1-java/changelog.Debian.gz -rw-r--r-- root/root 23165 2018-11-28 15:59 ./usr/share/doc/libservlet3.1-java/copyright drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/java/ -rw-r--r-- root/root242933 2018-12-12 16:48 ./usr/share/java/servlet-api-3.1.jar drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/maven-repo/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/maven-repo/javax/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/maven-repo/javax/servlet/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/maven-repo/javax/servlet/javax.servlet-api/ drwxr-xr-x root/root 0 2018-12-12 16:48 ./usr/share/maven-repo/javax/servlet/javax.servlet-api/3.1/ -rw-r--r-- root/root 1404 2018-12-12 16:48 ./usr/share/maven-repo/javax/servlet/javax.servlet-api/3.1/javax.servlet-api-3.1.pom lrwxrwxrwx root/root 0 2018-12-12 16:48 ./usr/share/maven-repo/javax/servlet/javax.servlet-api/3.1/javax.servlet-api-3.1.jar -> ../../../../../java/servlet-api-3.1.jar > Markus Koschany reminded me on #debian-java that Emmanuel is in the > process of preparing a new javax-servlex package (#916354), which might > fix this issue. So I will wait for this. I'm indeed in the process of splitting the JavaEE APIs (Servlet, JSP, EL and WebSocket) away from the Tomcat package, but I fail to understand why it affects freeplane.
Bug#916401: ITP: jsp-api -- JavaServer Pages API
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jsp-api Version : 2.3.4 Upstream Author : Oracle * URL : https://github.com/javaee/javaee-jsp-api * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : JavaServer Pages API JavaServer Pages (JSP) is a technology that helps software developers create dynamically generated web pages based on HTML, XML, or other document types. The JSP API is already packaged in libservlet3.1-java, but this package is tied to src:tomcat8 which won't be part of Buster. The new tomcat9 package no longer builds the JavaEE APIs (Servlet, JSP, EL and WebSocket APIs) and separate API packages are introduced to replace them. This package will be maintained by the Java Team.
Bug#916354: ITP: servlet-api -- Java Servlet API
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: servlet-api Version : 4.0.1 Upstream Author : Oracle * URL : https://javaee.github.io/servlet-spec/ * License : Apache-2.0, CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : Java Servlet API The Servlet API is the Java platform technology of choice for interacting with the web. Servlets provide a component-based, platform-independent method, for building web-based applications generating dynamic content. Servlets are managed by a container and interact with web clients via a request/response paradigm. The Servlet API packages used to be built by the src:tomcat packages. This is changing with tomcat9 and a new separate package is being introduced. The package name no longer contains the specification number to facilitate future migrations to higher versions. This package will be maintained by the Java Team.
Bug#916343: ITP: el-api -- Expression Language API
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: el-api Version : 3.0.0 Upstream Author : Oracle * URL : https://github.com/javaee/el-spec/ * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : Expression Language API EL is a simple language designed to meet the needs of the presentation layer in Java web applications. It features: * A simple syntax restricted to the evaluation of expressions * Variables and nested properties * Relational, logical, arithmetic, conditional, and empty operators * Functions implemented as static methods on Java classes * Lenient semantics where appropriate default values and type conversions are provided to minimize exposing errors to end users The EL API is already packaged in libservlet3.1-java, but this package is tied to src:tomcat8 which won't be part of Buster. The new tomcat9 package no longer builds the JavaEE APIs (Servlet, JSP,EL and WebSocket APIs) and separate API packages are introduced to replace them. This package will be maintained by the Java Team.
Bug#916245: ITP: websocket-api -- Java API for WebSocket (JSR-356)
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: websocket-api Version : 1.1 Upstream Author : Oracle * URL : https://github.com/javaee/websocket-spec * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : Java API for WebSocket (JSR-356) Java API for WebSocket (JSR-356) defines a standard API for the development of websocket applications, both on the server side as well as on the Java client side. The Java WebSocket API is already partially packaged in libservlet3.1-java, but this package is tied to src:tomcat8 which won't be part of Buster. The new tomcat9 package no longer builds the JavaEE APIs (Servlet, JSP,EL and WebSocket APIs) and separate API packages are introduced to replace them. This package will be maintained by the Java Team.
Bug#916216: RM: jakarta-ecs -- ROM; No longer used, discontinued upstream
Package: ftp.debian.org Severity: normal Hi, Please remove the jakarta-ecs package. This is an old API for generating HTML that isn't used in Debian. The last update was released in 2003 and the upstream project was discontinued in 2010. Thank you, Emmanuel Bourg
Bug#916177: i2p: FTBFS with Jetty 9.4
Source: i2p
Severity: serious
Tags: patch sid buster
Justification: FTBFS
Hi,
The jetty9 package has been updated to the version 9.4 and it breaks i2p.
Could you pleased review and apply the patch attached? It fixes the build
failure but it's untested at run time.
Thank you,
Emmanuel Bourg
--- a/apps/jetty/java/src/net/i2p/jetty/JettyXmlConfigurationParser.java
+++ b/apps/jetty/java/src/net/i2p/jetty/JettyXmlConfigurationParser.java
@@ -43,9 +43,9 @@
private static XmlParser initParser()
{
XmlParser parser = new XmlParser();
-URL config60 = Loader.getResource(XmlConfiguration.class,
"org/eclipse/jetty/xml/configure_6_0.dtd");
-URL config76 =
Loader.getResource(XmlConfiguration.class,"org/eclipse/jetty/xml/configure_7_6.dtd");
-URL config90 =
Loader.getResource(XmlConfiguration.class,"org/eclipse/jetty/xml/configure_9_0.dtd");
+URL config60 =
Loader.getResource("org/eclipse/jetty/xml/configure_6_0.dtd");
+URL config76 =
Loader.getResource("org/eclipse/jetty/xml/configure_7_6.dtd");
+URL config90 =
Loader.getResource("org/eclipse/jetty/xml/configure_9_0.dtd");
parser.redirectEntity("configure.dtd",config90);
parser.redirectEntity("configure_1_0.dtd",config60);
parser.redirectEntity("configure_1_1.dtd",config60);
--- a/apps/jetty/java/src/net/i2p/servlet/I2PDefaultServlet.java
+++ b/apps/jetty/java/src/net/i2p/servlet/I2PDefaultServlet.java
@@ -132,7 +132,6 @@
*
* Get the resource list as a HTML directory listing.
*/
-@Override
protected void sendDirectory(HttpServletRequest request,
HttpServletResponse response,
Resource resource,
--- a/apps/jetty/java/src/net/i2p/jetty/I2PRequestLog.java
+++ b/apps/jetty/java/src/net/i2p/jetty/I2PRequestLog.java
@@ -317,7 +317,7 @@
buf.append(request.getMethod());
buf.append(' ');
-request.getUri().writeTo(u8buf);
+u8buf.append(request.getHttpURI().toString());
buf.append(' ');
buf.append(request.getProtocol());
--- a/apps/routerconsole/java/src/net/i2p/router/web/HostCheckHandler.java
+++ b/apps/routerconsole/java/src/net/i2p/router/web/HostCheckHandler.java
@@ -15,7 +15,7 @@
import net.i2p.util.PortMapper;
import org.eclipse.jetty.server.Request;
-import org.eclipse.jetty.servlets.gzip.GzipHandler;
+import org.eclipse.jetty.server.handler.gzip.GzipHandler;
/**
* Block certain Host headers to prevent DNS rebinding attacks.
--- a/apps/routerconsole/java/src/net/i2p/router/web/RouterConsoleRunner.java
+++ b/apps/routerconsole/java/src/net/i2p/router/web/RouterConsoleRunner.java
@@ -22,6 +22,7 @@
import java.util.SortedSet;
import java.util.StringTokenizer;
import java.util.concurrent.LinkedBlockingQueue;
+import javax.servlet.ServletRequest;
import net.i2p.I2PAppContext;
import net.i2p.app.ClientAppManager;
@@ -46,6 +47,7 @@
import org.eclipse.jetty.security.HashLoginService;
import org.eclipse.jetty.security.ConstraintMapping;
import org.eclipse.jetty.security.ConstraintSecurityHandler;
+import org.eclipse.jetty.security.UserStore;
import org.eclipse.jetty.security.authentication.DigestAuthenticator;
import org.eclipse.jetty.server.AbstractConnector;
import org.eclipse.jetty.server.ConnectionFactory;
@@ -932,6 +934,8 @@
} else {
HashLoginService realm = new
CustomHashLoginService(JETTY_REALM, context.getContextPath(),
ctx.logManager().getLog(RouterConsoleRunner.class));
+UserStore userStore = new UserStore();
+realm.setUserStore(userStore);
sec.setLoginService(realm);
sec.setAuthenticator(authenticator);
String[] role = new String[] {JETTY_ROLE};
@@ -939,7 +943,7 @@
String user = e.getKey();
String pw = e.getValue();
Credential cred =
Credential.getCredential(MD5_CREDENTIAL_TYPE + pw);
-realm.putUser(user, cred, role);
+userStore.addUser(user, cred, role);
Constraint constraint = new Constraint(user, JETTY_ROLE);
constraint.setAuthenticate(true);
ConstraintMapping cm = new ConstraintMapping();
@@ -959,7 +963,7 @@
try {
// each char truncated to 8 bytes
String user2 = new String(b2, "ISO-8859-1");
-realm.putUser(user2, cred, role);
+userStore.addUser(user2, cred, role);
constraint = new Constraint(user2, JETTY_ROLE);
constrain
Bug#906770: README.Debian could use some clarificatons
Le 20/08/2018 à 23:36, Moritz Muehlenhoff a écrit : > For my tests of the jetty9 security update for stretch (released as > DSA 4278) I had looked into creating a test setup and the README.Debian > confused me quite a bit (and external references usally refer to a > totally different way to deploy Jetty using the upstream packages): > > It mentions: > | Additional contexts can be configured and (hot) deployed via the > | /etc/jetty9/contexts directory (linked from /usr/share/jetty9/contexts). > > But it seems that is now replaced by /etc/jetty9/start.d?` Good catch, /contexts is probably a left over from a previous version. But start.d looks more like a directory for .ini config files than .xml context files. > Also from > | Webapps can be deployed by placing them in /var/lib/jetty9/webapps > | (linked from /usr/share/jetty9/webapps) > > it wasn't obvious for me whether the .war file or a config file should > be placed in /var/lib/jetty9/webapps. I think it supports both. Upstream has the following README file in this directory (I'll add it in the next update) : | This directory is scanned by the WebAppDeployer provider for web | applications to deploy using the following conventions: | | + A directory called example/ will be deployed as a standard web | application if it contains a WEB-INF/ subdirectory, otherwise it will be | deployed as context of static content. The context path will be /example | (eg http://localhost:8080/example/) unless the base name is "root" (not | case sensitive), in which case the context path is /. If the directory name | ends with ".d" it is ignored (but may still be used by explicit configuration). | | + A file called example.war will be deployed as a standard web application | with the context path /example (eg http://localhost:8080/example/). If the | base name is root, then the context path is /. If example.war and example/ | exist, then only the WAR is deployed (which may use the directory as an | unpack location). | | + An XML file like example.xml will be deployed as a context whose | configuration is defined by the XML. The context path must be set by | the configuration itself. If example.xml and example.war exist, then | only the XML is deployed (which may use the war in its configuration). | | This directory is scanned for additions, removals and updates | for hot deployment. | | To configure the deployment mechanism, edit the files: |start.d/500-deploy.ini |etc/jetty-deploy.ini | | To disable the auto deploy mechanism use the command: | |java -jar start.jar --disable=deploy
Bug#915898: picard-tools FTBFS: error: module not found: java.xml.bind
Le 08/12/2018 à 20:04, Andreas Tille a écrit : > Hmmm, > > grep -R java.xml.bind > > in the picard-tools source tree does not have any result. Probably due to this ? :) https://salsa.debian.org/med-team/picard-tools/commit/9359e09f
Bug#915871: RM: aether -- ROM; No longer used, replaced by maven-resolver
Package: ftp.debian.org Severity: normal Hi, Please remove the aether package, it's has been replaced by maven-resolver and is no longer used. Thank you, Emmanuel Bourg
Bug#915791: tomcat9: broken symlinks: /var/lib/tomcat9/{logs,work}
Le 06/12/2018 à 21:01, Andreas Beckmann a écrit : > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 0m40.0s ERROR: FAIL: Broken symlinks: > /var/lib/tomcat9/work -> ../../cache/tomcat9 (tomcat9) > /var/lib/tomcat9/logs -> ../../log/tomcat9 (tomcat9) > > > Shouldn't tomcat9 ship (or create) the targets as well? Hi Andreas, These directories are created automatically when the service is started. Is it ok or should this be changed to directories created at install time? Emmanuel Bourg
Bug#915604: RM: maven-indexer -- ROM; No longer used, depends on old libraries
Package: ftp.debian.org Severity: normal Hi, Please remove the maven-indexer package. This package is no longer used, it was only used by src:leiningen which was removed 4 years ago. The version 2.8 of Leiningen now packaged as src:leiningen-clojure no longer needs it. maven-indexer depends on old libraries that we'd like to remove now (aether, liblucene3-java). Thank you, Emmanuel Bourg
Bug#910764: openjfx: no glassgtk3 in java.library.path
retitle 910764 openjfx: segmentation fault in GtkNativeMainLoopThread with GTK 3 and Wayland
Bug#912527: [Openjdk] Bug#912527: openjdk-8-jdk: please update to support class file version 64
Control: tags -1 + wontfix On Tue, 20 Nov 2018 01:33:21 -0200 Tiago Daitx > The only way for Debian to support that would be for it to have > something like a separated openjfx-8 package that was compiled with > openjdk-8. Somebody would have to be willing to support that but I am > not sure if openjdk-8 will even be included in buster. The openjfx > maintainer can probably provide a more insights into that. I don't plan to support an openjfx-8 package, sorry that's too much work. openjdk-8 remains in Buster only as a convenience to build or bootstrap packages that cannot build with OpenJDK 11 only. The openjdk-8 package is not supported at runtime, so JavaFX applications have to migrate to OpenJDK 11. Emmanuel Bourg
Bug#915540: openjdk-8-jre-dcevm should likely not be in buster
Le 04/12/2018 à 16:06, Adrian Bunk a écrit : > With OpenJDK 8 not supported in Debian this version is > likely not suitable for buster. > > The OpenJDK 11 version seems to be at > https://github.com/HotswapProjects/openjdk-jdk11u There is no harm keeping openjdk-8-jre-dcevm in Buster though. I take this more as a RFP for the JDK 11 version.
Bug#873695: jetty9: RolloverFileOutputStream does not roll over
Le 10/07/2018 à 15:41, Adrian Wiedemann a écrit : > any chance this fix will be included in future stretch releases? Hi Adam, This should be fixed in stretch-backports, the version 9.2.24 was uploaded in May. Emmanuel Bourg
Bug#915463: i2p: Transition to Tomcat 9
Source: src:i2p Severity: important Hi, tomcat9 has been recently uploaded to sid, this will be the only version of Tomcat released in Buster. Could you please update the i2p dependencies to use libtomcat9-java instead of libtomcat8-java? Thank you, Emmanuel Bourg
Bug#910698: dogtag-pki needs jdk8
Le 17/10/2018 à 10:10, Timo Aaltonen a écrit : >> What errors do you get if you use the Java 11 compiled ldapjdk with >> jss/dogtag-pki? > > I can't remember offhand, some compatibility errors with versions. The tasks in the Ant build don't specify the source/target level, that's probably why you got these errors. I sent a pull request on Salsa addressing this issue [1]. Emmanuel Bourg [1] https://salsa.debian.org/freeipa-team/ldapjdk/merge_requests/1
Bug#912235: activation and corba removed from jdk
On Tue, 6 Nov 2018 09:40:17 +0100 Olivier Sallou wrote: > javax.activation should be "replaced" by JAF standalone version i > suppose but > > 1) it is not in Debian > > 2) seems to be named now java.activation (so needs patching to rename calls) JAF is packaged as libactivation-java. The API is the same, no need to change the package name in the source files.
Bug#915065: starjava-vo: Unused dependency on libaxis-java
Source: starjava-vo
Severity: normal
Dear Maintainer,
starjava-vo has a dependency on libaxis-java but it actually builds fine
without it. It uses a SOAP client from starjava-registry [1] that used to
be based on Axis but no longer use it as highlighted by this comment in
the SoapClient class:
/**
* Lightweight, freestanding SOAP client which can make simple requests
* and allows the responses to be processed as a SAX stream.
* Logging of sent and received XML can optionally be performed by
* using the {@link #setEchoStream} method.
* Probably, there is much of SOAP that this doesn't implement, but
* it works well enough to write a registry client on top of it.
*
* Why write yet another SOAP client? Last time I tried to get Axis
* to do this (stream processing of the response) it took me several
* days of misery, and still didn't work. The actual job I need to
* do here is quite straightforward, so it's not difficult to write it
* from scratch.
*
* @author Mark Taylor
* @since9 Dec 2009
*/
Since we plan to request the removal of libaxis-java due to compatibility
issues with Java 11 (#911187), could you please remove the libaxis-java
dependency from starjava-vo?
Thank you,
Emmanuel Bourg
[1]
https://salsa.debian.org/debian-astro-team/starjava-registry/blob/master/src/main/uk/ac/starlink/registry/SoapClient.java
Bug#911187: axis: FTBFS with Java 11 due to javax.rmi and CORBA removal
Le 30/10/2018 à 14:18, Markus Koschany a écrit :
> I was investigating the Java 11 FTBFS of axis and uddi4j. I wonder if we
> rather should focus on removing these packages instead of patching them.
I agree, I've requested the removal of uddi4j and wsil4j.
> eclipse-* packages can be ignored and jalview has been RC buggy for a
> long time. uddi4j can go as well and it only has eclipse-wtp and wsil4j
> as r-deps.
The two eclipse packages have now been removed.
jalview uses Axis for the javax.xml.rpc API. It can probably use
libjaxrpc-api-java instead.
> I don't see any code in starjava-vo that uses axis, looks more like a
> runtime feature but I'm not sure.
I got a quick look. starjava-vo builds fine without axis. I've found
only one class with SOAP related code (Ri1RegistryQuery) and it calls
the SoapClient class from starjava-registry [1]. Axis isn't used for
this client implementation as explained in the source file:
/**
* Lightweight, freestanding SOAP client which can make simple requests
* and allows the responses to be processed as a SAX stream.
* Logging of sent and received XML can optionally be performed by
* using the {@link #setEchoStream} method.
* Probably, there is much of SOAP that this doesn't implement, but
* it works well enough to write a registry client on top of it.
*
* Why write yet another SOAP client? Last time I tried to get Axis
* to do this (stream processing of the response) it took me several
* days of misery, and still didn't work. The actual job I need to
* do here is quite straightforward, so it's not difficult to write it
* from scratch.
*
* @author Mark Taylor
* @since9 Dec 2009
*/
So I think it's safe to remove the axis dependency in this case.
> In uimaj the uimaj-adapter-soap makes use of axis.
uima-as builds fine without libuima-adapter-soap-java, so we can scrap it.
[1]
https://salsa.debian.org/debian-astro-team/starjava-registry/blob/master/src/main/uk/ac/starlink/registry/SoapClient.java
Bug#915029: RM: uddi4j -- ROM; No longer used, deprecated
Package: ftp.debian.org Severity: normal Hi, Please remove the uddi4j package. It is no longer used in Debian and fails to build with Java 11 (#912267). It has been deprecated upstream (last release in 2006) and was replaced by the "UDDI Version 3 Client for Java" [1] Thank you, Emmanuel Bourg [1] https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/cwsu_uddi4j.html
Bug#915028: RM: wsil4j -- ROM; No longer used, abandoned upstream since 2002
Package: ftp.debian.org Severity: normal Hi, Please remove the wsil4j package. It is no longer used in Debian and the upstream project was discontinued in 2002. Thank you, Emmanuel Bourg
Bug#895837: jruby: Please package 9.1.16.0 or more recent releases
It seems upgrading to 9.1.16 isn't enough [1], we need at least JRuby 9.2.1 for a good compatibility with Java 9, 10 and 11. https://github.com/jruby/jruby/issues/5446#issuecomment-438732326
Bug#914849: ITP: junixsocket -- Unix Domain Sockets in Java
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: junixsocket Version : 2.0.4 Upstream Author : Christian Kohlschütter * URL : https://github.com/kohlschutter/junixsocket * License : Apache-2.0 Programming Lang: Java, C++ Description : Unix Domain Sockets in Java junixsocket is a Java/JNI library that allows the use of Unix Domain Sockets (AF_UNIX sockets) from Java. In contrast to other implementations, junixsocket extends the Java Sockets API (java.net.Socket, java.net.SocketAddress etc.) and even supports RMI over AF_UNIX. It is also possible to use it in conjunction with Connector/J to connect to a local MySQL server via Unix domain sockets. This package is required to build the byte-buddy-agent module in src:byte-buddy, and then upgrade Mockito to the version 2.x.
Bug#914173: surefire FTBFS
Control: fixed -1 Control: close -1 This issue has been fixed with plexus-utils2/3.1.0-4
Bug#914780: RM: netty-3.9 -- ROM; No longer used, replaced by netty
Package: ftp.debian.org Severity: normal Hi, Please remove the netty-3.9 package. This is an old version of Netty that is no longer maintained and affected by security issues. Netty 4.x from the libnetty-java package should be used instead. Thank you, Emmanuel Bourg
Bug#850945: ant: exec task fails with error 127 on kfreebsd-i386
Le 11/01/2017 à 21:37, Gilles Filippini a écrit : > I've just submitted #851053 against openjdk-8 on kfreebsd-*. #851053 has been fixed last year. I guess we can closed this bug now?
Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant
Control: severity -1 normal Le 26/11/2018 à 23:38, Gilles Filippini a écrit : > To me this is RC because it makes opencv FTBFS on some official buildd > machines. No opinion at all about usrmerge. My understanding is that usrmerge is optional at this point and the builders are going to be reverted to non usrmerged. For this reason I'm lowering the severity. > In any case the scriplet replaced by the patch is buggy. > How about pushing this patch upstream? The patch looks good to me, thanks a lot. Do you know if readlink is commonly available on other Unix platforms? Emmanuel Bourg
Bug#898821: maven-plugin-tools: FTBFS with Java 10 due to com.sun.tools.doclets removal
Le 22/11/2018 à 15:45, Emmanuel Bourg a écrit : > This issue has been "solved" upstream in the version 3.6 by dropping > support for javadoc annotations. This means we have to convert the > plugins still using these javadoc annotations to use the Java > annotations instead [2]. I misanalysed the issue, it's the Javadoc taglets which were removed in the version 3.6, not the support for defining plugins with javadoc tags (this is implemented using doxia and doesn't rely on internal JDK classes anyway). The taglets are only used when generating the javadoc of a plugin and this never happens in Debian. So no need to update all the plugins still using javadoc tags.
Bug#914566: RM: pleiades -- ROM; No longer used
Package: ftp.debian.org Severity: normal Hi, Please remove the pleiades package. It contains a Japanese translation plug-in for Eclipse but it's about to be removed (#914448). Thank you, Emmanuel Bourg
Bug#914503: RM: plexus-cdc -- ROM; No longer used, replaced by plexus-component-metadata
Package: ftp.debian.org Severity: normal Hi, Please remove the plexus-cdc package. It is no longer used and along plexus-maven-plugin it has been replaced by libplexus-component-metadata-java. Thank you, Emmanuel Bourg
Bug#914502: RM: plexus-maven-plugin -- ROM; No longer used, replaced by plexus-component-metadata
Package: ftp.debian.org Severity: normal Hi, Please remove the plexus-maven-plugin package. It's no longer used and has been replaced by libplexus-component-metadata-java from src:plexus-containers. Thank you, Emmanuel Bourg
Bug#914497: RM: tomcat7 -- ROM; No longer used
Package: ftp.debian.org Severity: normal Hi, Please remove the src:tomcat7 package. It only builds the libservlet3.0-java package but it is no longer used, it has been replaced by libservlet3.1-java. Thank you, Emmanuel Bourg
Bug#914467: RM: swt-gtk -- ROM; No longer used, superseded by swt4-gtk
Package: ftp.debian.org Severity: normal Hi, Please remove the swt-gtk package. It's an old version of SWT that was only used for the needs of src:eclipse, and it's about to be removed (#914448). swt4-gtk should now be used instead. Thank you, Emmanuel Bourg
Bug#914466: RM: icu4j-49 -- ROM; Obsolete, no longer used
Package: ftp.debian.org Severity: normal Hi, Please remove the icu4j-49 package. It's an old version of ICU4J that was only used for the needs of src:eclipse, and it's about to be removed (#914448). Thank you, Emmanuel Bourg
Bug#914463: RM: icu4j-4.2 -- ROM; Obsolete, no longer used
Package: ftp.debian.org Severity: normal Hi, Please remove the src:icu4j-4.2 package. It's an old version of ICU4J that was only used for the needs of lucene2, and it's about to be removed (#914450). Thank you, Emmanuel Bourg
