Bug#1060381: tomcat10: catalina.out is not recreated after deletion

[Markus Koschany]

Control: tags -1 moreinfo

[already CCed the submitter but forgot to add the bug report]

Hello Daniel,

On Wed, 10 Jan 2024 12:42:34 +0100 Daniel von Obernitz
 wrote:
> Package: tomcat10
> Version: 10.1.6-1+deb12u1
> Severity: normal
> X-Debbugs-Cc: t...@security.debian.org
> 
> Dear Maintainer,
> 
> when you stop tomcat10.service and delete the /var/log/tomcat10/catalina.out,
the file will not be recreated after the next tomcat10.service start.

[...]

I don't understand the problem here. You deliberately deleted catalina.out.
What stops you from using

touch /var/log/tomcat10/catalina.out

to recreate it?

Regards,

Markus



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

Bug#1057047: tomcat10-common: Tomcat 10 helper script doesn't look for temurin based jdk installs

[Markus Koschany]

On Tue, 28 Nov 2023 17:59:18 +0100 Joan  wrote:
> Package: tomcat10-common
> Version: 10.1.15-1
> Severity: normal
> X-Debbugs-Cc: aseq...@gmail.com
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> I am trying to use debian's tomcat 10 with java 21, since it's not present on
debian I used the one from 
> https://adoptium.net/installation/linux/ that has a repository.

[...]

Hello,

we support only OpenJDK and there is even openjdk-21-jre in unstable. For
stable releases only one version of openjdk is supported in general, currently
OpenJDK 17.


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

Bug#1057315: tiles: CVE-2023-49735

[Markus Koschany]

Am Sonntag, dem 03.12.2023 um 15:10 +0100 schrieb Moritz Muehlenhoff:
> > But maybe we can set it as "no-dsa", is it only used as build
> > dependency for libspring-java and not sensible outside?
> 
> Spring is already marked as unsupported, so we can simply extend that.

+1 This is sensible in this case.


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

Bug#933264: gradle: Nearly 3-year-old version almost useless

[Markus Koschany]

Am Freitag, dem 01.12.2023 um 13:06 +0100 schrieb Matthias Geiger:
> 
> Kotlin is now in debian, is there anything else blocking the update ?

As a start I have built Gradle 4.6 from source with almost only system
libraries but I hit a wall because there seems to be a bug in our Kotlin
version or rather 4.6 requires a different version, so this version still
relies on upstream's binary distribution of Kotlin. I will push this in a few
days and then let's see how we can proceed from here on. Why still 4.6? Jumping
to a newer version like 6.x (which is already superseded by 8.x) requires
updates of many different system libraries which in turn requires updates of
reverse-dependencies of said libraries and so on. So whenever you change
something in Debian's Java eco system you have to be prepared to fix a bunch of
other seemingly (un)related stuff as well. More details follow soon.

Markus


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

Bug#1056754: marked as done (bouncycastle: CVE-2023-33202)

[Markus Koschany]

Hi tony,

Am Donnerstag, dem 30.11.2023 um 21:02 -0800 schrieb tony mancill:
> On Thu, Nov 30, 2023 at 09:51:09PM +, Debian Bug Tracking System wrote:
> > Subject: Bug#1056754: fixed in bouncycastle 1.77-1
> > 
> > Source: bouncycastle
> > Version: 1.77-1
> > Distribution: unstable
> > Changed-By: Markus Koschany 
> >    * New upstream version 1.77. (Closes: #1049356)
> 
> Hi Markus,
> 
> Thank you for your efforts to get BC updated.
> 
> >    * Remove backward-compatibility.patch. It is time to fix those issues
> >  properly in our reverse-dependencies.
> 
> I agree completely.  And thank you for filing bugs for the r-deps that
> need to be addressed.

thanks. Fortunately there is enough time to fix them. I'll try to help fixing
them step by step.



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

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

[Markus Koschany]

Source: libitext5-java
Version: 5.5.13.3-2
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

libitext5-java fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

BUILD FAILURE
[INFO] 
[INFO] Total time:  12.832 s
[INFO] Finished at: 2023-11-30T13:27:49+01:00
[INFO] 
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-
plugin:3.10.1:compile (default-compile) on project itextpdf: Compilation
failure: Compilation failure: 
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[223,95] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: class org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[246,109] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: class org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[346,70] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tg of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[350,70] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tg of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[1286,28] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tag of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[1287,48] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tag of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/Certificate
Util.java:[123,67] incompatible types: org.bouncycastle.asn1.ASN1IA5String
cannot be converted to org.bouncycastle.asn1.DERIA5String
[ERROR] -> [Help 1]
[ERROR] 


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

Bug#1057168: jdeb: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: jdeb
Version: 1.9-1
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

jdeb fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

ERROR] Failures: 
[ERROR]   PGPSignerTestCase.testClearSign:79->Assert.assertEquals:146-
>Assert.assertEquals:117 expected:<...[]
-END PGP SIGNAT...> but was:<...[Sek]
-END PGP SIGNAT...>
[INFO] 
[ERROR] Tests run: 90, Failures: 1, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  14.039 s
[INFO] Finished at: 2023-11-30T13:32:26+01:00
[INFO] 
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-
plugin:2.22.3:test (default-test) on project jdeb: There are test failures.
[ERROR] 
[ERROR] Please refer to /<>/target/surefire-reports for the
individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-
jvmRun[N].dump and [date].dumpstream.
[ERROR] -> [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/MojoFailureException
dh_auto_test: error: /usr/lib/jvm/default-java/bin/java -noverify -cp
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven
-Dmaven.multiModuleProjectDirectory=/<> -
Dclassworlds.conf=/etc/maven/m2-debian.conf -
Dproperties.file.manual=/<>/debian/maven.properties
org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-
debian.xml -Ddebian.dir=/<>/debian -
Dmaven.repo.local=/<>/debian/maven-repo --batch-mode test returned
exit code 1
make: *** [debian/rules:6: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


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

Bug#1057167: libapache-poi-java: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: libapache-poi-java
Version: 4.0.1-4
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

libapache-poi-java fails to build from source with bouncycastle 1.77. The
reason is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

ompile-ooxml:
[javac] Compiling 589 source files to /<>/build/ooxml-classes
[javac] Ignoring source, target and bootclasspath as release has been set
[javac]
/<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/XAdESXLS
ignatureFacet.java:235: error: cannot find symbol
[javac] ASN1OctetString keyHashOctetString =
(ASN1OctetString)derTaggedObject.getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: variable derTaggedObject of type DERTaggedObject
[javac]
/<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/XAdESXLS
ignatureFacet.java:239: error: cannot find symbol
[javac] X500Name name =
X500Name.getInstance(derTaggedObject.getObject());
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: variable derTaggedObject of type DERTaggedObject
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note:
/<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/SignaturePart.j
ava uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors

BUILD FAILED
/<>/build.xml:1133: Compile failed; see the compiler error output
for details.



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

Bug#1057166: pgpainless: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: pgpainless
Version: 1.3.16-2
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

pgpainless fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log. It seems, in this case, just a test is
failing now.

Failures (1):
  JUnit Jupiter:CertifyCertificateTest:testKeyDelegation()
MethodSource [className =
'org.pgpainless.key.certification.CertifyCertificateTest', methodName =
'testKeyDelegation', methodParameterTypes = '']
=> org.pgpainless.exception.SignatureValidationException: Cannot verify
direct-key signature correctness
  
org.pgpainless.signature.consumer.SignatureValidator$17.verify(SignatureValidat
or.java:547)
  
org.pgpainless.signature.consumer.SignatureVerifier.verifyDirectKeySignature(Si
gnatureVerifier.java:328)
  
org.pgpainless.key.certification.CertifyCertificateTest.testKeyDelegation(Certi
fyCertificateTest.java:98)
   java.base/java.lang.reflect.Method.invoke(Method.java:568)
   java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
   [...]
 Caused by: org.bouncycastle.openpgp.PGPException: signature is not a key
binding signature.
   org.bouncycastle.openpgp.PGPSignature.verifyCertification(Unknown
Source)
  
org.pgpainless.signature.consumer.SignatureValidator$17.verify(SignatureValidat
or.java:539)
   [...]

Test run finished after 44748 ms
[   240 containers found  ]
[ 0 containers skipped]
[   240 containers started]
[ 0 containers aborted]
[   240 containers successful ]
[ 0 containers failed ]
[   732 tests found   ]
[ 1 tests skipped ]
[   731 tests started ]
[ 0 tests aborted ]
[   730 tests successful  ]
[ 1 tests failed  ]





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

Bug#1057165: libitext-java: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: libitext-java
Version: 2.1.7-14
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

libitext-java fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.



compile:
[mkdir] Created dir: /<>/build/bin
[javac] /<>/ant/compile.xml:45: warning: 'includeantruntime'
was not set, defaulting to build.sysclasspath=last; set to false for repeatable
builds
[javac] Using javac -source 1.5 is no longer supported, switching to 7
[javac] Using javac -target 1.5 is no longer supported, switching to 7
[javac] Compiling 359 source files to /<>/build/bin
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 7
[javac] warning: [options] source value 7 is obsolete and will be removed
in a future release
[javac] warning: [options] target value 7 is obsolete and will be removed
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use
-Xlint:-options.
[javac]
/<>/core/com/lowagie/text/pdf/MappedRandomAccessFile.java:58:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
[javac] import java.security.AccessController;
[javac] ^
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:356:
error: cannot find symbol
[javac] if (tag.getObject() instanceof ASN1Sequence) {
[javac]^
[javac]   symbol:   method getObject()
[javac]   location: variable tag of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:357:
error: cannot find symbol
[javac] seq = (ASN1Sequence)tag.getObject();
[javac]^
[javac]   symbol:   method getObject()
[javac]   location: variable tag of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:403:
error: cannot find symbol
[javac] ASN1Sequence content =
(ASN1Sequence)((DERTaggedObject)signedData.getObjectAt(1)).getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: class DERTaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:435:
error: cannot find symbol
[javac] DEROctetString rsaDataContent =
(DEROctetString)((DERTaggedObject)rsaData.getObjectAt(1)).getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: class DERTaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:488:
error: cannot find symbol
[javac] ASN1Sequence seqin =
(ASN1Sequence)tg.getObject();
[javac]  ^
[javac]   symbol:   method getObject()
[javac]   location: variable tg of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/FontDetails.java:264:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] Integer codeKey = new Integer(code);
[javac]   ^
[javac]
/<>/core/com/lowagie/text/pdf/TrueTypeFontUnicode.java:144:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] inverseCmap.put(new
Integer(metrics[0]), code);
[javac] ^
[javac]
/<>/core/com/lowagie/text/pdf/TrueTypeFontUnicode.java:150:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] return inverseCmap == null ? null : (Integer)
inverseCmap.get(new Integer(code));
[javac] 
 
^
[javac]
/<>/core/com/lowagie/text/pdf/MappedRandomAccessFile.java:203:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
[javac] Boolean b = (Boolean) AccessController.doPrivileged(new
PrivilegedAction() {
[javac]   ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 5 errors
[javac] 9 warnings


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

Bug#1032164: bouncycastle: inconsistency in debian/rules?

[Markus Koschany]

Hi,

On Tue, 28 Feb 2023 22:08:12 +0100 Thomas Uhle
 wrote:
> Source: bouncycastle
> Version: 1.72-1
> Severity: normal
> 
> Dear maintainers,
> 
> I wonder why in debian/rules the pom files were synchronized with the 
> ones from Maven having the suffix "-jdk18on" while for building the binary 
> packages still "ant/jdk15+.xml" is used instead of "ant/jdk18+.xml".

Good question. Perhaps the jdk18+ jar files were breaking some reverse-
dependencies in the past. The soon to be released 1.77 version of bouncycastle
will require updates of several of those reverse-dependencies. As soon as those
issues are fixed, we can rebuild everything with jdk18+ again.




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

Bug#1019488: bouncycastle: incomplete information in the manifest files

[Markus Koschany]

This problem still exists in 1.77 (to be released soon). That sounds like a bnd
problem. I can find a reference to a bnd.sh script but it is not included in
the source distribution. There is also a add_module.sh script. If we can't find
a way to automate this build step, we could use jh_manifest which I would
prefer over the patch. 


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

Bug#1052589: Additional information

[Markus Koschany]

> > https://salsa.debian.org/java-team/apache-directory-server/-/merge_requests/1
> 
> The patch looks good to me.  Markus, do you have a preference for this
> patch over updating to M27?  I haven't looked closely at the efforts to
> update to M27 aside from the fact that our (other) patches will need to
> be ported, and there could be some build adjustments for the dependency
> on BouncyCastle.

Hi tony and thanks Vladimir for preparing the patch. 

I only had a brief look at this issue but I am all for applying the patch now
rather than wait before someone can upgrade apache-directory-server to a new
upstream release. If it works, go for it. :)

Cheers,

Markus


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

Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl

[Markus Koschany]

Control: reassign -1 trapperkeeper-webserver-jetty9-clojure
Control: found -1 1.7.0-2+deb10u1
Control: close -1 1.7.0-2+deb10u2

I have just released DLA 3647-1. I believe this problem is fixed in version
1.7.0-2+deb10u2 of trapperkeeper-webserver-jetty9-clojure now.

Regards,

Markus


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

Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl

[Markus Koschany]

Am Sonntag, dem 05.11.2023 um 20:35 + schrieb Adam D. Barratt:
> [...]
> After a bit of searching, I happened across a discussion of a similar
> change in a different product that mentioned the
> SslContextFactory$Server syntax, so gave that a try. The resulting
> package is now installed on handel.d.o and seems to work - at least,
> it's been running for 45 minutes now (whereas the broken versions
> lasted less than 5 minutes) and at least one client has successfully
> made a "puppet agent" run in the meantime.
> 
> I've attached a debdiff of the package we're now running, with the
> revised patch.

Great, thanks for the update. I feared the Java dot syntax couldn't be applied
one-to-one to Clojure. I suggest we wait another 24h to confirm it works and if
you don't see another regression then I'll release a new update tomorrow.

Regards,

Markus


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

Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl

[Markus Koschany]

Am Sonntag, dem 05.11.2023 um 16:33 + schrieb Adam D. Barratt:
> [...]
> Do you have an idea how simple rebuilding the bullseye package on
> buster would be? I'm happy to try that in general, but I've not really
> looked at the Java ecosystem in Debian much.

Sorry, I missed those new or updated dependencies. That complicates the matter
a little. We also have to deal with clojure here, a LISP dialect of the Java
language with a different build system (leiningen), but if all dependencies
were in place a rebuild would be pretty simple. As a last resort I could bundle
all those dependencies together with trapperkeeper-* the Java way TM but I hope
we can avoid that.

The most ideal solution is a patch for the current version in Buster. I have
uploaded a new revision to people.debian.org with minimal changes here:

https://people.debian.org/~apo/lts/buster/trapperkeeper-webserver-jetty9-clojure/

dget -
x 
https://people.debian.org/~apo/lts/buster/trapperkeeper-webserver-jetty9-clojure/
trapperkeeper-webserver-jetty9-clojure_1.7.0-2+deb10u1.1.dsc 

should work as expected. I'm attaching the debdiff as well.

My solution is to replace the old SslContextFactory class with the new inner
SslContextFactory.Server class but I don't know if this change has the desired
effect because I couldn't test it.

FTR, the already applied 0005-maint-Disable-EndpointIdentification.patch (new
in version +deb10u1) is related to the problem. Actually back then it did "fix"
the SSL problem and I'm a bit surprised it resurfaced now. 

There is also a third alternative. I could revert the split change in jetty9.

https://github.com/jetty/jetty.project/pull/3480/files#diff-58640db0f8f2cd84b7e653d1c1540913

If the new revision doesn't work for you, please send me your puppetdb config,
and I try to figure out a solution myself without the feedback loop delay.
Thanks in advance.

Regards,

Markus
diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog
--- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog	2019-09-13 11:00:50.0 +0200
+++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog	2023-11-05 18:06:31.0 +0100
@@ -1,3 +1,10 @@
+trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1.1) buster-security; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace deprecated class SslContextFactory with SslContextFactory.Server.
+
+ -- Markus Koschany   Sun, 05 Nov 2023 18:06:31 +0100
+
 trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1) buster; urgency=medium
 
   [ Manfred Stock ]
diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch
--- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch	2019-09-13 10:54:48.0 +0200
+++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch	2023-11-05 18:06:31.0 +0100
@@ -1,4 +1,3 @@
-From 9db4170381e07165078e544340e12b38676c2613 Mon Sep 17 00:00:00 2001
 From: Justin Stoller 
 Date: Fri, 24 May 2019 16:10:44 -0700
 Subject: [PATCH] (maint) Disable EndpointIdentification
@@ -30,10 +29,10 @@
  1 file changed, 1 insertion(+)
 
 diff --git a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj
-index 3a577bb..02e7c7d 100644
+index 99c9885..28cfef7 100644
 --- a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj
 +++ b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj
-@@ -197,6 +197,7 @@
+@@ -192,6 +192,7 @@
(.setKeyStore (:keystore keystore-config))
(.setKeyStorePassword (:key-password keystore-config))
(.setTrustStore (:truststore keystore-config))
@@ -41,6 +40,3 @@
;; Need to clear out the default cipher suite exclude list so
;; that Jetty doesn't potentially remove one or more ciphers
;; that we want to be included.
--- 
-2.20.1
-
diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series
--- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series	2019-09-13 10:54:48.0 +0200
+++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series	2023-11-05 18:06:31.0 +0100
@@ -3,3 +3,4 @@
 0003-TK-369-Add-LifeCycleImplementingRequestLogImpl.patch
 0004-Implement-LifeCycle-methods-missing-from-RequestLogI.patch
 0005-maint-Disable-EndpointIdentification.patch
+SslContextFactory.patch
diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/SslContextFactory.patch trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/S

Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl

[Markus Koschany]

Hello,

Am Samstag, dem 04.11.2023 um 17:03 + schrieb Adam D. Barratt:
> Source: jetty9
> Version: 9.4.50-4+deb10u1
> Severity: serious
> X-Debbugs-Cc: d...@debian.org
> 
> Hi,
> 
> Upgrading libjetty9-java and libjetty9-extra-java to the version from
> DLA 3641-1 reliably causes PuppetDB to fail to start, with the
> stacktrace shown below. Downgrading resolves the issue.
> 
> I'm not sure which keystore is being referred to, but none of the files
> listed in /etc/puppetdb/conf.d/jetty.ini appear to contain more than a
> single certificate.

thanks for the report. This looks like a bug in trapperkeeper-webserver-jetty9-
clojure to me. Upstream commit

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/commit/3ee6a410436c1a236ca33d511c5373c3328054ef

appears to address the problem. The version in Buster lacks the
InternalSslContextFactory class though. Instead the deprecated
SslContextFactory class is referenced in jetty9_config.clj and
jetty9_core.clj. 

My first idea is to change SslContextFactory occurrences to
SslContextFactory.Server.

Backporting the version of trapperkeeper-webserver-jetty9-clojure from Bullseye
to Buster is the second one. AFAICS puppetdb and puppetserver are the only
consumers.

Could you install the version of trapperkeeper-webserver-jetty9-clojure from
Bullseye and reinstall the jetty9 security update and report back if this
solves your problem?

Regards,

Markus


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

Bug#1053820: fixed in tomcat9 9.0.43-2~deb11u8

[Markus Koschany]

Am Dienstag, dem 17.10.2023 um 08:00 +1100 schrieb Sam Lander:
> Hi Emmanuel
> Last night, I re-enabled HTTP2 with the new (9.0.43-2~deb11u8) build.
> Unfortunately, it did not fix my problem.
> I am going to rummage with tcpdump and a purpose-installed debian VM to
> investigate further. 
> Hopefully I can either track the problem down myself (not very likely), or at
> least offer you a better quality bug report.
> 

Hello Sam,

there was another issue that we only found today. HTTP2 should work as expected
in version 9.0.43-2~deb11u9 again. It will be released shortly.

Regards,

Markus












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

Bug#1053820: libtomcat9-java: ERR_HTTP2_PROTOCOL_ERROR in browsers after upgrade 9.0.43-2~deb11u7 over u6

[Markus Koschany]

Hello and thanks for the report,

I am currently looking into some test failures caused by the recent changes to
Tomcat's HTTP2 stack. The following tests fail for Tomcat9 now. Your issue
might be related. If we can find out more about the problem, we will address it
in a future update as soon as possible.

[concat] TEST-org.apache.coyote.http2.TestAsync.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestAsync.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_1.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_1.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_2.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_2.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_4.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_4.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_5.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_5.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Timeouts.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Timeouts.NIO2.txt   



Markus



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

Bug#1040475: Broken symlinks cause Apache Directory Server to not work at all out-of-the-box

[Markus Koschany]

I believe the symlink problem is fixed in version 2.0.0~M26-2 but I'd like to
test the apacheds server component more before I'm going to close this bug
report.

Markus


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

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[Markus Koschany]

Hi,

Am Dienstag, dem 15.08.2023 um 14:52 +0200 schrieb J. Tóth Tamás:
> Hi,
> 
> > Please keep the bug report always in CC.
> 
> I thought my 8 August mail contains no new information, so it makes no 
> sense to spam the BTS with it. But okay, next time (and this time) I’ll 
> use Reply All regardless of the message content.

I'm not the only Debian developer who could help you. There may be other users
too who are interested in this topic and who could provide valuable insight or
suggestions. Hence why it's so important to have a public bug tracker with the
record of our conversation.

> 
> > > We’d like to gradually upgrade
> > > to Bookworm, but I don’t want to make sysops’ lives more complicated by
> > > giving them one WAR file to install on Bookworm and another one to
> > > install on Bullseye.
> > 
> > […] You can just manually run the tomcat-jakartaee-migration tool on
> > your existing war files. All it mainly does is to replace the old
> > occurrences of javax.* with jakarta.*.
> 
> That’s exactly what I meant by “making sysops’ lives more complicated by
> giving them one WAR file to install on Bookworm and another one to 
> install on Bullseye”, so it’s out of question for me in production.

Ok, I'm not familiar with your workflow. Though I would never trust a tool to
do the right thing on the fly. I would instruct my development team to port the
application to Tomcat 10 and test it thoroughly and then my production team
only would take care of the administration and deployment task as usual. 

> 
> > You could also send a patch with your proposed changes to Debian's tomcat10
> > > package and I take a look at it.
> 
> I created https://salsa.debian.org/java-team/tomcat10/-/merge_requests/1 
> – it’s quite likely wrong in its current form, but I hope it can be fixed.

Thank you! I have merged your request and also pushed a new upstream version to
our Git repository but I didn't upload the package yet. Patches should be added
to the debian/patches/series file as well, otherwise they won't be applied. The
rest looked good to me. However I still get a migration warning when I follow
your initial steps with the basic "test" app. There is a
DirectoryNotEmptyException. Initially tomcat migrates the test folder in
webapps-javaee to a newx.tmp folder and then tries to remove the latter,
which fails. What can we do to avoid this warning?

Regards,

Markus


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

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[Markus Koschany]

Hello,

Am Montag, dem 07.08.2023 um 20:22 +0200 schrieb J. Tóth Tamás:
> Hi,
> 
> Did you notice my reply sent on 4 July?

Yes, I did. Please keep the bug report always in CC.

> We’d like to gradually upgrade 
> to Bookworm, but I don’t want to make sysops’ lives more complicated by 
> giving them one WAR file to install on Bookworm and another one to 
> install on Bullseye.

I haven't had the time to investigate this problem yet. You don't have to wait
for a solution of this bug though. You can just manually run the tomcat-
jakartaee-migration tool on your existing war files. All it mainly does is to
replace the old occurrences of javax.* with jakarta.*. You could also send a
patch with your proposed changes to Debian's tomcat10 package and I take a look
at it.

Markus


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

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[Markus Koschany]

Am Montag, dem 03.07.2023 um 18:28 +0200 schrieb Tamás J.Tóth:
> 
> 
> The web app doesn't load. The Tomcat log contains the following:
> 
> WARNING [main] org.apache.catalina.startup.HostConfig.migrateLegacyApp
> Migration failure
> java.lang.NoClassDefFoundError: org/apache/tomcat/jakartaee/Migration

Thanks for the report.

You have to install the tomcat-jakartaee-migration package. [1] I guess we
could either suggest or recommend this package to make it more obvious.

https://tracker.debian.org/pkg/tomcat-jakartaee-migration

Regards,

Markus


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

Bug#1039974: tomcat10: tomcat user has wrong home "/var/lib/tomcat" directory in /etc/passwd

[Markus Koschany]

Control: tags -1 moreinfo

> deploy .war in tomcat10
> got errors from tomcat10 in "journalctl -f"
> 
>    * What exactly did you do that was effective ?
> 
> change tomcat user home in /etc/passwd to /var/lib/tomcat10
> 
>    * What was the outcome of this action?
> 
> Problem solved

You most likely don't have to change the user home of tomcat to solve your
problem (which you did not specify at all)

There is a difference between the operating system user and home directory and
the applications' home directory.

See Debian bug https://bugs.debian.org/926338 for reference.

You have to tell your tomcat applications explicitly if they can write or read
certain file system directories. See /usr/share/doc/tomcat10/README.Debian for
more information. By default Debian's tomcat package is meant to be secure. It
is the task of the system administrator to configure tomcat correctly. 




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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Am Freitag, dem 26.05.2023 um 21:44 +0200 schrieb Emmanuel Bourg:
> 
> The changes to jetty9 have to be reverted too, the package is broken 
> (#1036798).
> 
> Sadly we can't do without tomcat9. The path forward implies packaging
> Jetty 11 or 12 first and migrating all the reverse dependencies, but
> that's a task for Trixie.

Thanks for investigating Emmanuel. I'll take care of jetty9 too.

Markus


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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Hi,

> Markus, can you please revert you logback change by tomorrow at the latest?

Sure. I will take care if it.

Do I understand you correctly, that we only ship libtomcat9-java in Bookworm
now? Shall I upload a new revision of tomcat9 too?

Regards,

Markus


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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

First of all trapperkeeper-webserver-jetty9-clojure should add a build-
dependency on logback to detect such regressions in advance.

#1036250 is mainly a logback problem, not a tomcat problem. I still would like
to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we
don't find a solution though.

The tomcatjss / dogtag-pki situation is simple too. If there is no way to make
the application work with Tomcat 10, then there are three options:

1. Embed Tomcat 9 in your application by creating a standalone jar

2. Continue to use the current Tomcat 9 package as is but make sure that nobody
else than dogtag-pki uses it. (Package descriptions should be adjusted, and the
binary tomcat9 package should be probably removed too) Nobody should think that
we support two major Tomcat versions.

In any case the dogtag-pki maintainers must commit to at least three years of
security support, web application + Tomcat 9. Otherwise this is pointless.

3. Remove dogtag-pki and tomcatjss from testing and prepare backports as soon
as dogtag-pki and Co support Tomcat 10.

Markus


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

Bug#1036212: visualvm: Version 2.1.5 doesn't work with Java 17

[Markus Koschany]

Am Mittwoch, dem 17.05.2023 um 12:24 +0200 schrieb david:
> Package: visualvm
> Version: Version 2.1.5 doesn't work with Java 17
> Severity: normal
> 
> Dear Maintainer,
> 
> I have installed visualvm with Java 17 configured. The app doesn't work in
> its
> installed version. Trying 2.1.6, downloaded from visualvm web page, it works
> without problem. Can we have this last version, please?

visualvm 2.1.5 works with Java 17


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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Hi Salvatore,

adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC

Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso:
> Hi Markus,
> 
> On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote:
> > I have just pushed the necessary changes to our Git repository. 
> > 
> > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993
> 
> Do we need to have done more here? When Paul asked on #debian-release
> I noted that pki-server depends on tomcat9-user, so reducing
> libtomcat9-java only would now cause a broken dpeends for pki-server:
> 
> $ dak rm --suite=bookworm -n -R -b tomcat9-user
> Will remove the following packages from bookworm:
> 
> tomcat9-user |   9.0.70-1 | all

We could simply replace tomcat9-user with tomcat10-user because it only ships a
script to create a standalone tomcat instance. We have to do
s/tomcat9/tomcat10/ in some debian service files as well.

The question is: If we ship libtomcat9-java in Bookworm and change the
dependency from tomcat9-user to tomcat10-user, will a web application like
dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I
don't know yet and maybe Timo can chime in here. 

Regards,

Markus


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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

I have just pushed the necessary changes to our Git repository. 

https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993


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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Hello Paul,

Am Donnerstag, dem 11.05.2023 um 21:44 +0200 schrieb Paul Gevers:
> Hi Markus,
> 
> On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany  wrote:
> > We can only support one major Tomcat version per release. Tomcat9 has
> > been part of Buster and Bullseye already and is superseded by Tomcat
> > 10 in Bookworm. I wanted to wait with the removal request until the
> > issues in [resteasy3.0] and [tomcatjss] have been resolved but to make
> > it more obvious I am filing this bug report now.
> 
> Release Team member here. I'll note that I'm not impressed by the 
> communication and timing of this bug. We're in Full Freeze for bookworm. 
> This is no time for transitions, let alone for *uncoordinated* ones.

This bug report was merely intended as a reminder. I assumed that tomcatjss
(#1031816) and resteasy3.0 were the only two issues left to resolve. I agree
that we should have filed the bug report earlier. I was under the impression
that all affected packages are maintained by the Java team. IMHO it doesn't
make much sense to maintain a Tomcat plugin outside of it, which is by
definition tightly coupled with the web server.

Still, there was plenty of time and I have pointed to several possible ways to
resolve this problem but there was no response. [1] 

> 
> You should have raised the issue earlier and brought it to the release 
> team. tomcat9 and tomcat10 are both key packages so neither can easily 
> be removed.
> 
>  From a quick look at the key packages:
> 
> It seems you didn't follow up (86 days) on libcommons-dbcp-java which 
> can't migrate to bookworm because it would make libbiojava-java-doc 
> uninstallable (no fix there, no bug report filed).

I did not upload libcommons-dbcp-java and I was not aware of the problem. I
will take care of it. 

> src:tiles also build-depends on libtomcat9-java, with no bug filed for 
> the migration to tomcat10 *and* it having it's own FTBFS bug. (It's key 
> because of src:libspring-java)

Again I was not aware of src:tiles, probably because there was an RC bug
already. This problem seems solvable too.

> On IRC carnil and jmm_ suggested that src:tomcat9 could be left in 
> bookworm but have it's server component stripped. Would that help the 
> situation?

Yes, that was one of my suggestions. 

> Everything in this transition would still need an unblock by the release 
> team, as we're now very close to the hard freeze (24 May) and nearly 
> ready to release.

I suggest we just drop all tomcat9 binary packages except libtomcat9-java and I
fix tiles and libcommons-dbcp-java. That seems to be the easiest solution right
now.

Regards,

Markus



[1] https://bugs.debian.org/1031816#37


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

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Source: tomcat9
Version: 9.0.70-1
Severity: serious
X-Debbugs-Cc: a...@debian.org


We can only support one major Tomcat version per release. Tomcat9 has
been part of Buster and Bullseye already and is superseded by Tomcat
10 in Bookworm. I wanted to wait with the removal request until the
issues in [resteasy3.0] and [tomcatjss] have been resolved but to make
it more obvious I am filing this bug report now.



[resteasy3.0] https://bugs.debian.org/1033366
[tomcatjss] https://bugs.debian.org/1031816

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

Bug#1031055: apache-curator: FTBFS randomly (org.opentest4j.AssertionFailedError: expected: <1> but was: <0>)

[Markus Koschany]

I can reproduce the FTBFS here on my system. Apparently some of the tests are
not 100 % reliable and reproducible. For now I will just disable them.

Markus


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

Bug#1033366: resteasy3.0: should migrate to tomcat10

[Markus Koschany]

Am Freitag, dem 21.04.2023 um 14:50 +0200 schrieb Andreas Tille:
> 
> Ahhh, right, the repository went over to source package resteasy.  So
> well, the CI log is not helpful for this bug log.  What I rather want to
> know is how to proceed with this bug since some Debian Med package
> received a testing removal warning and I became interested why there is
> just a serious bug report open with no response from the maintainer. 

The removal of resteasy3.0 will lead to the removal fo apache-curator as well
which in turn will remove aeonbits-owner. I guess this is the package you are
referring to. Let me take a look at apache-curator. Maybe we can omit the
dependency on resteasy3.0. That should solve the problem.

Markus


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

Bug#1033366: resteasy3.0: should migrate to tomcat10

[Markus Koschany]

Am Freitag, dem 21.04.2023 um 12:23 +0200 schrieb Andreas Tille:
> Hi,
> 
> I tried to rebuild this package which does not work as you can
> see in Salsa CI:
> 
>     https://salsa.debian.org/java-team/resteasy/-/jobs/4105287
> 
> Unfortunately I have no idea how to fix this.


Hi Andreas,

it seems you are trying to build a different package than is currently
available in the archive. The latest version of 3.0.26-5 builds fine with
libtomcat9-java but fails with libtomcat10-java. The error message is
unrelated.



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

Bug#1034492: libtcnative-1: Tomcat warning suggesting a minimum version of 2.0.1 for tcnative

[Markus Koschany]

Hello,

Am Sonntag, dem 16.04.2023 um 16:15 -0400 schrieb Jorge Moraleda:
> Package: libtcnative-1
> Version: 1.2.35-1
> Severity: normal
> X-Debbugs-Cc: jorge.moral...@gmail.com
> 
> Dear Maintainer,
> 
> When running tomcat 10 (installed from default bookworm repo) it warns that
> "An
> older version [1.2.35] of the Apache Tomcat Native library is installed,
> while
> Tomcat recommends a minimum version of [2.0.1]"
> 
> I feel debian should package a version of tc-native equals or newer than the
> recommendation of the packaged tomcat version.

This is something we aim for in Debian 13. For now 1.2.35 should work just fine
despite the warning.

> 
> I wonder if we tomcat 9 still requires version 1.x of tcnative, which means
> debian should package both libtcnative-1 and a libtcnative-2, or if the
> latest
> tcnative 2 would suffice for both tomcat 9 and tomcat 10, and then we might
> want to drop the 1 in the tcnative package name and just package the latest
> 2.x
> version under that name.

We will remove Tomcat 9 in the near future because we can support only one
version. I guess we can rename libtcnative-1 to just libtcnative instead of
creating a new libtcnative-2 package. I'm sure we will make a decision after
the freeze.

Markus



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

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hello,

Am Donnerstag, dem 06.04.2023 um 12:54 +0200 schrieb Paul Gevers:
> Hi,
> 
> On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany  wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.
> 
> I'm wondering how you know, did you test (without rebuilding) all the 
> reverse dependencies? If so, how did you do that? (I'm worried we're 
> missing cases like src:dojo).

I always rebuild all reverse-dependencies with ratt before I upload a Java
library package. From my Java experience I know this uncovers almost all
problems. Rhino is not some obscure C/C++ library. It is a Javascript engine
written in Java. You can install reverse-dependencies and run them against the
new rhino version. If the package works, then there is no further action
required. Could I have missed a corner case? Maybe. But there is always a risk
whenever you change something. Remember why we did the upgrade in the first
place. We did fix two RC bugs and just hit a special case with a leaf package
(shrinksafe)

From dojo developer documentation:

"Note that the linkage requires the same version of Rhino used to build the
shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into
Rhino by way of patch, and shipped as custom_rhino.jar."

We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.

> 
> Also, given that shrinksafe is from a different source than rhino, this 
> qualifies as a transition (it *needs* changes in different (binary) 
> packages).

I cannot remember when we asked for a Java library transition in the past.
shrinksafe is, as I pointed out before, a special case. It was once part of the
rhino distribution and probably should have tightened the dependency on a
specific rhino version in the first place. 

> 
> > 2. shrinksafe has no reverse-dependencies
> 
> So it can be easily removed, but that's not a great service to its users.

No, we don't want to remove neither shrinksafe nor any other package. Please
don't exaggerate the problem at hand.


> > 3. We had the exact same problem before [1]. Back then the fix was to
> > rebuild
> > the package and to fix the shrinksafe tests by setting a specific
> > Javascript
> > version. [2] Since just rebuilding dojo also fixes the problem, I assume
> > that
> > we don't have to change this option.
> 
> Well, rebuilding without fixing the underlying issue is just papering 
> over. I'd like to get a proper (future proof) solution in place, see 
> below. (And yes, we can paper over for bookworm now).

The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly. 

> > 4. I have rebuilt all rhino reverse-dependencies successfully.
> 
> Yes, normal transitions are handled that way, we (the Release Team) 
> schedule binNMU's for those (albeit we can't do arch:all that way).

As I said this is standard procedure for Java libraries which I touch. It does
not imply a transition is needed.

> > 6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable.
> > Hence
> > why I tightened the dependency on rhino to 1.7.14. The current version of
> > rhino
> > in testing breaks the Javascript application.
> 
> Suggesting even more that this is a real transition.

You are misunderstanding the problem. OpenRefine does not work with Rhino in
testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is
the solution, not the cause of the problem.
[...]
> 



> 
> I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5 
> today, where I'll add an appropriate Breaks to src:rhino and an 
> appropriate versioned Depends to src:dojo. Please let me know if you 
> object or want to handle this yourself.

Fine with me and thanks!


Markus


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

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hi Graham,

Am Sonntag, dem 26.03.2023 um 19:28 +0200 schrieb Graham Inggs:
> Hi Markus
> 
> On Sun, 26 Mar 2023 at 16:34, Markus Koschany  wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.


> How did you determine this?

Rhino 1.7.14 was mostly API compatible meaning I only had to fix an issue in
closure-compiler. All other packages can be built from source without
modifications. I didn't find any other runtime / ABI issues so far.   

> 
> > 2. shrinksafe has no reverse-dependencies
> 
> That is true, but src:dojo has ledgersmb and tt-rss as reverse-dependencies.

I used codesearch.debian.net and found only documentation or other minor
references of shrinksafe in affected packages.

https://codesearch.debian.net/search?q=shrinksafe=1

Since all Java tests in dojo pass after the rebuild and almost all of the code
in dojo is Javascript anyway, I don't see how ledgersmb and tt-rss can be
affected by the new rhino version. Wouldn't those packages depend on rhino in
some way? To me it seems rhino is only required to build shrinksafe which can
be used for compressing Javascript files. But maybe the dojo maintainers can
chime in here.


Regards,

Markus


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

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hello,

On Sun, 26 Mar 2023 09:41:48 +0200 Graham Inggs  wrote:
[...]
> To both the rhino and dojo maintainers, please investigate so we can
> have this resolved for bookworm.

Here are my investigations:

1. There is no transition needed because only shrinksafe is affected by the new
rhino version.

2. shrinksafe has no reverse-dependencies

3. We had the exact same problem before [1]. Back then the fix was to rebuild
the package and to fix the shrinksafe tests by setting a specific Javascript
version. [2] Since just rebuilding dojo also fixes the problem, I assume that
we don't have to change this option.

4. I have rebuilt all rhino reverse-dependencies successfully.

5. I have tested yui-compressor, a similar tool, with rhino 1.7.14 and without
rebuilding the existing package and this one works as expected.

6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable. Hence
why I tightened the dependency on rhino to 1.7.14. The current version of rhino
in testing breaks the Javascript application.

7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to
reconsider the current autopkgtest behavior. At least there should be a warning
or a note for maintainers in the future that dojo requires a rebuild whenever
rhino changes.

Regards,

Markus

[1] https://bugs.debian.org/970501
[2]
https://salsa.debian.org/js-team/dojo/-/commit/68e6a048b4c4386d0495e7faf11bd46bf0516604


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

Bug#1033366: resteasy3.0: should migrate to tomcat10

[Markus Koschany]

Source: resteasy3.0
Version: 3.0.26-5
Severity: serious
Tags: help
X-Debbugs-Cc: a...@debian.org

Hello,

currently resteasy3.0 depends on libtomcat9-java but should rather
depend on libtomcat10-java. The reasoning for this is the fact that we
can only support one tomcat package per release for security reasons.
I have tried to replace the javax.servlet imports with jakarta.servlet
but the issue is more complicated than expected. It would be great if
someone else could take a look at it too.

Regards,

Markus

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

Bug#1026639: fixed in rhino 1.7.14-1

[Markus Koschany]

Hi,

Am Donnerstag, dem 23.03.2023 um 15:08 +0100 schrieb Paul Gevers:
> Hi,
> 
> On Mon, 13 Feb 2023 14:42:17 + Debian FTP Masters 
>  wrote:
> >    * New upstream version 1.7.14.
> >  - Fix FTBFS with OpenJDK 17. (Closes: #1026639)
> 
> Is it possible to get a targeted fix? This new upstream is not 
> reviewable and I seriously doubt it meets the freeze policy [1]

rhino would have been migrated to testing in time but the dojo autopkgtests
prevented that. I don't think they work correctly because the same tests pass
when I rebuild the package. [1]

I cannot isolate a targeted fix for this problem, mainly because that was not
the only problem with the package. The older rhino version caused a silent
runtime error in openrefine which broke the web application. We should really
ship 1.7.14 in Bookworm because the old version is already six years old. The
route forward should be simply to fix the autopkgtests in dojo and unblock
rhino.

Regards,

Markus

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








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

Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found

[Markus Koschany]

Control: reopen -1
Control: severity -1 serious

Hello Robert,

Am Donnerstag, dem 23.03.2023 um 10:41 +0100 schrieb Robert Jäschke:
> Dear Markus,
> 
> I found the problem: the package misses a dependency to libjoda-time-java.

thank you for debugging this problem. I will prepare an update for Bookworm
soon.

Best,

Markus


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

Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found

[Markus Koschany]

Hi Robert,

> 
> Sorry, I forgot to add this:
> 
>  > dpkg -l | grep rhino
> ii  librhino-java   1.7.14-2
> ii  rhino   1.7.14-2
> 
> I've upgraded (lib)rhino after reading the bug report but this did not help.
> 
> Is there a way to debug Openrefine? I tried both -v debug and -v trace 
> but did not get more output (Maybe I have to configure log4j properly as 
> the warning suggests?)

I can't reproduce a 404 error at the moment. OpenRefine works as expected for
me. Unfortunately it is not easy to debug openrefine because there is a
separate Javascript based web application and the server module based on Java.
The former can only be debugged via Chrome or Firefox console. I'm not sure how
useful the log messages would be. I agree that there is currently a problem
with configuring SLF4j and this is something which should work out-of-the-box.
A 404 error indicates a web server (Jetty in this case) problem or a missing
file but I don't know how this could help right now.

Regards,

Markus


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

Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found

[Markus Koschany]

Am Freitag, dem 17.03.2023 um 12:38 +0100 schrieb Robert Jäschke:
> Package: openrefine
> Version: 3.6.2-1
> Followup-For: Bug #1022760
> X-Debbugs-Cc: jaesc...@l3s.de
> 
> Dear Maintainer,
> 
> I experience the exact same problem with the latest version, that is,
> starting openrefine and opening http://localhost: results in a 404.

I presume you don't have librhino-java >= 1.7.14 installed on your system
because your apt policy prefers testing over unstable. 


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

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Control: reassign -1 shrinksafe
Control: severity -1 serious

Hi,

I uploaded a new version of rhino a while ago and it seems this bug is still
relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass.
However the same tests fail with autopkgtest and block the migration of rhino
to testing. Could you take a look at that please?

Regards,

Markus


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

Bug#1031840: geogebra: FTBFS with librhino-java

[Markus Koschany]

Package: geogebra
Version: 4.0.34.0+dfsg1-9
Severity: important
X-Debbugs-Cc: a...@debian.org

Hi,

the Debian Java team currently "fixes" a FTBFS in geogebra by applying
this patch in src:rhino.

https://salsa.debian.org/java-team/rhino/-/blob/master/debian/patches/public_getSourcePositionFromStack.patch

However this should be addressed in geogebra instead. We can't support
old API forever.

Regards,

Markus

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

Bug#991408: Netbeans: source code problem

[Markus Koschany]

Am Montag, dem 20.02.2023 um 12:41 -0300 schrieb Leandro Cunha:
> Hi Markus,
> 
> I have no interest in keeping Netbeans on Debian, but when I mention
> consistency (according to the dictionary: state or quality of what is
> coherent), it would be consistent with the reality that would be
> represented in the tracker and on package.debian.org that the package
> was removed from repository and if I give apt install netbeans it
> would not be found. The same as with other packages follows the Debian
> Developer Reference [1].


apt install netbeans will do nothing. The binary package has been removed from
Debian. The Netbeans source package has always produced libnb-absolutelayout-
java. There is no inconsistency. You either don't understand the difference
between a source and a binary package or you are deliberately annoying. In any
case I won't reply to this bug report anymore.


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

Bug#991408: Netbeans: source code problem

[Markus Koschany]

Am Sonntag, dem 19.02.2023 um 03:34 -0300 schrieb Leandro Cunha:
> Hi,
> 
> For some consistency please request the removal of this package
> including unstable. It makes no sense to have the name of an IDE and
> install a Java LayoutManager to allow placement in absolute positions.
> I even agree with the removal, but it must be done correctly and in
> such a way that I don't find this package in the repository via
> tracker.debian.org and packages.debian.org as if exist.
> I'll let whoever takes care of this package do that.
> Thanks!

If you want to re-introduce the Netbeans IDE, please do! Use the current source
package, prepare your work, find a sponsor and upload it to Debian. However the
Java team will not remove a source package from Debian just "for consistency".
We don't rename source packages just to re-introduce them later under a
different name, only to produce the same binary package as the current package
again. This would be completely nonsensical and a whole lot of make-work for
all involved parties, mostly the ftp-team and the Java team itself.


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

Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found

[Markus Koschany]

On Tue, 25 Oct 2022 10:44:19 + Francesco Frassinelli
 wrote:
> Package: openrefine
> Version: 3.6.1-1
> Severity: important
> X-Debbugs-Cc: francesco.frassine...@nina.no
> 
> Dear Maintainer,
> 
> I started openrefine and try to connect to it using the web brower
(http://localhost:), but I got the following error:

...

Hello,

thanks for the report! Sorry for not getting back to you sooner. I had a hard
time to debug this issue. It turned out that a) third party javascript files
were missing from the upstream sources and b) librhino-java in Debian was too
old and caused a silent runtime error. I believe this is all fixed now. Version
3.6.2-1 should be available in a few hours on the mirrors.

Regards,

Markus


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

Bug#1026639: rhino FTBFS

[Markus Koschany]

I believe I have corrected all regressions except of one in closure-compiler
which I will fix later today (renamed class). It turned out that I had to
update the Manifest file and include another META-INF file,
javax.script.ScriptEngineFactory, to solve some FTBFS in reverse-dependencies.
This is the downside of just using javahelper. You have to be extra careful to
include everything that ant or gradle will do "automagically" for you. I'm
going to upload rhino 1.7.14 now.


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

Bug#1026639: rhino FTBFS

[Markus Koschany]

Am Montag, dem 13.02.2023 um 11:04 +0100 schrieb Markus Koschany:
> preserve-backward-compatibility.patch

To answer my own question. Yes, this is still needed otherwise closure-compiler
starts to FTBFS



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

Bug#1026639: rhino FTBFS

[Markus Koschany]

Am Montag, dem 13.02.2023 um 12:14 +0200 schrieb Adrian Bunk:
> On Mon, Feb 13, 2023 at 11:04:38AM +0100, Markus Koschany wrote:
> > ...
> > I don't really like to use gradle for a key package.
> > ...
> 
> FTR, gradle is already a key package:
> libxi -> asciidoc -> fop -> mockito -> gradle

I know. That's what I want to change in the future.


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

Bug#1026639: rhino FTBFS

[Markus Koschany]

Am Montag, dem 13.02.2023 um 09:33 +0100 schrieb Emmanuel Bourg:
> I don't think this should be assigned to rhino. ckeditor should
> open the internal packages it touches.

I'm currently working on rhino. I have packaged 1.7.14 now. I haven't looked
into ckeditor yet but it seems we have to upgrade rhino anyway. At least
openrefine fails with a silent error when rendering javascript in its webapp
and there may be other errors with OpenJDK 17. Fortunately rhino has no build
dependencies on other packages. However I had to change the way how we build
the package because upstream removed support for ant and I don't really like to
use gradle for a key package. Hence I am using just javahelper now which seems
to work fine. I'm a bit confused about all the old rhino patches. script-
engine.patch is included in the sources now, but I'm not not sure if we still
need the others like preserve-backward-compatibility. Right now I am rebuilding
everything with ratt. There is a build failure with libapache-poi-java. I'm
going to upload my current work to Git.

Markus


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

Bug#1026639: rhino FTBFS

[Markus Koschany]

Control: owner -1 !




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

Bug#1030869: tomcat10: Catalina won't deploy applications missing class jakarta.websocket.DeploymentException

[Markus Koschany]

Control: tags -1 pending

On Wed, 08 Feb 2023 11:38:25 -0500 Jorge Moraleda 
wrote:
> Package: tomcat10
> Version: 10.1.5-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: jorge.moral...@gmail.com
> 
> Dear Maintainer,
> 
> Catalina is unable to deploy any applications (including samplp ROOT)
> complaining of java.lang.ClassNotFoundException:
> jakarta.websocket.DeploymentException

Thanks for the report! I believe I have found the root cause for this
Exception. Apparently upstream split the websocket API into two jar files in
version 10.1.x but only one was linked into the correct location. I will upload
a new revision shortly.

Regards,

Markus


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

Bug#1016131: libapache2-mod-jk: Apache does not start after upgrade (JkWorkersFile only allowed once)

[Markus Koschany]

Hello,

On Wed, 27 Jul 2022 20:36:06 +0200 Thorsten Glaser  wrote:
> Package: libapache2-mod-jk
> Version: 1:1.2.48-1
> Severity: critical
> Justification: breaks unrelated software
> X-Debbugs-Cc: t...@mirbsd.de
> 
> After upgrading from buster to bullseye, apache2 does not start any more
> if libapache2-mod-jk was installed and active prior to the upgrading:

I had only a quick look at this issue. I remember that one configuration file
was wrongly named back when Stretch was oldstable and Buster the new stable
distribution. For now I suggest to downgrade this bug to important because the
issue is not present when upgrading from Bullseye to Bookworm. I can take a
look at it later. We probably only need to use a maintscript file to remove the
obsolete configuration file on upgrade.

Regards,

Markus


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

Bug#1030046: Document snakeyaml security expectations

[Markus Koschany]

Hi,

Am Montag, dem 30.01.2023 um 18:44 +0100 schrieb Moritz Muehlenhoff:
> 
> Could we please add a README.Debian.security with something like the
> following
> to make this also visible to users?
> 
> 
> Note that snakeyaml isn't designed to operate on YAML data coming from
> untrusted
> sources, in such cases you need to apply sanitising/exception handling
> yourself.
> 
> Please see https://bitbucket.org/snakeyaml/snakeyaml/wiki/CVE%20&%20NIST.md
> for additional information.
> 

Sure, that's doable. But how do we treat the current and new CVE in stable and
oldstable releases? no-dsa, ignored or keep them open until upstream eventually
fixes them?

Cheers,

Markus


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

Bug#1026766: sweethome3d: Crashes with "Assertion `!xcb_xlib_threads_sequence_lost' failed"

[Markus Koschany]

Hello,

Am Freitag, dem 27.01.2023 um 08:29 +0100 schrieb Lluís Gras:
> Hi,
> 
> It seems somehow related to VGA in use.
> 
> Same setup (cloned boxes) works with 
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation GeminiLake [UHD
> Graphics 600] [8086:3185] (rev 06)
>  DeviceName: Onboard - Video
>  Subsystem: Hewlett-Packard Company GeminiLake [UHD Graphics 600] [103c:87f9]
>  Kernel driver in use: i915
>  Kernel modules: i915
> 
> and crashes with
> 
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev e2)
>  Subsystem: Hewlett-Packard Company Stoney [Radeon R2/R3/R4/R5 Graphics]
> [103c:8381]
>  Kernel driver in use: amdgpu
>  Kernel modules: amdgpu

This is most likely a driver related issue. I assume we can't fix this in
sweethome3d. 

Markus



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

Bug#1026695: undertow: FTBFS: make: *** [debian/rules:4: build] Error 25

[Markus Koschany]

This is some kind of incompatibility with jboss-classfilewriter 1.3.0. I will
look into it after the release of Debian 12. Undertow should not be part of a
stable release as long as there is no real demand for another Java web server
anyway.


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

Bug#1027687: netty: please package 4.1.86 or later

[Markus Koschany]

Source: netty
Version: 1:4.1.48-5
Severity: wishlist

I have uploaded my preliminary packaging work to experimental in Git
but could not finish it yet.

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

Bug#1025910: libcommons-net-java: CVE-2021-37533

[Markus Koschany]

Hello tony,


Am Dienstag, dem 27.12.2022 um 08:40 -0800 schrieb tony mancill:
> On Sun, Dec 11, 2022 at 09:02:16PM +0100, Salvatore Bonaccorso wrote:
> > Source: libcommons-net-java
> > Version: 3.6-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://issues.apache.org/jira/browse/NET-711
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team
> > 
> 
> I see that there has been an upload of 3.9.0 on 2022-12-26.
> 
> I'm just noting here that I prepared a 3.9.0 package locally but hadn't
> uploaded it yet because several of the build r-deps failed to compile.
> (Maybe I was just doing it wrong, but we may see some FTBFS.)

I noticed two FTBFS of wagon and nrepl-clojure. Both of them seemed unrelated
to me. I guess they will be fixed eventually. Everything else built fine. Sorry
for the double work.



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

Bug#1021935: syncany: FTBFS: Could not resolve javax.servlet:javax.servlet-api:4.0.1.

[Markus Koschany]

Hi tony,

Am Montag, dem 17.10.2022 um 20:09 -0700 schrieb tony mancill:
> 
> For any syncany users out there, is there any reason to continue to
> upload to experimental?  Is there anything preventing an upload to
> unstable?

Unfortunately the development of syncany has been discontinued a few years ago.
Although the basic storage functions appear to work I don't think I can promise
any security support or support at all for the life time of a stable release.
Maybe someone else will start a fork or continue to work on it. In the meantime
experimental seems to be the most appropriate place for syncany.

Cheers,

Markus


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

Bug#1015860: libxalan2-java: CVE-2022-34169

[Markus Koschany]

Control: reassign -1 src:bcel
Control: tags -1 pending


I have notified oss-security about the find. Reassigning to bcel.


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

Bug#1015860: libxalan2-java: CVE-2022-34169

[Markus Koschany]

Hi,

I just had a go at this issue and I discovered that libxalan2-java in Debian is
not affected but rather bcel.

https://tracker.debian.org/pkg/bcel

The fixing commit in OpenJDK addresses the same code which is nowhere to be
found in libxalan2-java but is present in bcel. The bcel upstream commit can be
found at

https://github.com/apache/commons-bcel/commit/f3267cbcc900f80851d561bdd16b239d936947f5


I suggest to reassign the bug to bcel. I agree that libxalan2-java should be
retired eventually. It is required by quite some reverse-dependencies though
and it may take some time to achieve that. In theory everything should work
without the library, because the code is in OpenJDK already?

I am not sure if we should request to clarify the CVE description or at least
post on oss-security to make other people aware of it. I assume the official
xalan2 release ships an internal copy of bcel and that might be the reason for
the confusion.

Regards,

Markus


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

Bug#1013959: Upgrade package to latest upstream version

[Markus Koschany]

> Dear maintainer,
> 
> Please upgrade mockito to the latest version, 4.6.1.

Hello,

The latest 4.x series introduces many breaking changes and not all reverse-
dependencies are ready for that. As long as projects continue to use 2.x it
would require some effort from our side to port them to newer mockito versions.
I don't think this is feasible at the moment. We could think about packaging
4.x for experimental in the future or even a new mockito4 source package but
that's not a priority for me.

Regards,

Markus


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

Bug#1012214: gradle: FTBFS with jansi 2

[Markus Koschany]

Control: retitle -1 gradle: FTBFS with jansi 2

Let me try to fix this 



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

Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Am Samstag, dem 20.08.2022 um 16:35 + schrieb Thorsten Glaser:
> Markus Koschany dixit:
> 
> > The newly added --add-opens option is only valid for OpenJDK 17. I
> > understand that we switch to it for Debian 12 but it currently breaks
> > all packages that are built with OpenJDK 11. I am currently in the
> 
> Is this true? AFAIK --add-opens is for 11+ (probably even 9+). It
> certainly seems to work on buster for me.


The --add-opens error message was misleading and it turned out the underlying
root cause for the FTBFS was a different one. Gradle currently fails to build
because of a different jansi bug. There is still some work to do with Gradle
6.x and progress is slow but I still think we should focus on that instead of
trying to ship Gradle 4 again.




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

Bug#1013565: libitext5-java: FTBFS: dh_auto_test: error:

[Markus Koschany]

Same here. Looks related to maven-resource-plugins / maven-filtering and
#1013582 and #1013586 


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

Bug#1013586: Bug#1013595: plexus-io: FTBFS: Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.1.0:testResources

[Markus Koschany]

I believe this is related to a bug in maven-filtering or maven-resources-
plugin. According to

https://issues.apache.org/jira/browse/MRESOURCES-237

the behavior how symlinks are handled has changed between version 2.7 and 3.0.x
of maven-resources-plugin. This is apparently fixed in maven-filtering 3.3.0. I
don't know why we see this problem only now because the bug has been reported
four years ago. I have pushed a new upstream version of maven-filtering to the
experimental branch but I have not uploaded it yet. The upgrade would break
Maven with "No implementation ... was bound" error and I presume some extra
steps have to be taken in order to match this package with our Maven version.


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

Bug#1013582: libapache-jena-java: Jena shell utilities are missing

[Markus Koschany]

> I would also call the binary package
> apache-jena-bin and omit the lib prefix because this one is reserved for
> libraries only. 

On second thought, maybe we can just ship the shell scripts with libapache-
jena-java. It is an arch:all package anyway and space is not an issue here.


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

Bug#1013582: libapache-jena-java: Jena shell utilities are missing

[Markus Koschany]

Control: severity -1 wishlist

Am Freitag, dem 24.06.2022 um 13:17 +0200 schrieb David Haller:
> Package: libapache-jena-java
> Version: 3.17.0-3
> Severity: normal
> X-Debbugs-Cc: david.hal...@fau.de
> 
> Hello there,
> 
> the package includes the Java libraries of Jena only, but not their command
> line utilities which I often use for testing and development.
> 
> Would it be possible to include them too? Maybe in a separate package, like
> "libapache-jena-bin".

Hello,

I believe you are referring to the apache-jena/bin subdirectory of the source
package tree. That should be doable. However I am not sure if all these scripts
will work correctly because we ship only a subset of all apache-jena artifacts
in Debian. In fact the package is currently just a dependency of openrefine.
Could you try to install those scripts into /usr/local/bin (for testing
purposes) and report back if they work as you would expect them to work when
you use libapache-jena-java from Debian? I would also call the binary package
apache-jena-bin and omit the lib prefix because this one is reserved for
libraries only. 

Regards,

Markus


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

Bug#1013355: groovy: FTBFS with jansi 2.4.0-1

[Markus Koschany]

Forgot to CC the bug report

Am Mittwoch, dem 22.06.2022 um 18:14 +0200 schrieb Emmanuel Bourg:
> Le 2022-06-22 17:54, Markus Koschany a écrit :
> 
> > groovy FTBFS with jansi 2.4.0. I intend to either prepare a patch or
> > upgrade to a newer upstream release in the future.
> 
> Please hold the upload, this is going to blow up Maven and Gradle. I've 
> introduced
> jansi1 to try to work around the issue but I haven't completed the 
> transition yet.

Could you share your plans with jansi1 and why we just can't upgrade to a newer
version of it? I am still working on a major gradle upgrade in the background
and I hope we don't need the current version any longer. jansi 2.4.0 was also
required to upgrade maven-shared-utils. Besides from gradle and groovy no other
r-dep failed to build from source, at least that was the outcome of a ratt
rebuild.






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

Bug#1013355: groovy: FTBFS with jansi 2.4.0-1

[Markus Koschany]

Package: groovy
Version: 2.4.21-1
Severity: serious
X-Debbugs-Cc: a...@debian.org

groovy FTBFS with jansi 2.4.0. I intend to either prepare a patch or
upgrade to a newer upstream release in the future.

Markus

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

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Am Mittwoch, dem 01.06.2022 um 17:36 +0200 schrieb Emmanuel Bourg:
> gradle-debian-helper/2.2 already checks if the JDK supports modules before
> adding the --add-opens options, but it checks the default JDK and not the one
> specified by JAVA_HOME, that's why it fails when OpenJDK 8 is used.

ok, cool. Thanks for fixing it!


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

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Am Mittwoch, dem 01.06.2022 um 15:03 +0200 schrieb Emmanuel Bourg:
> The --add-opens option was introduced in Java 9, so this shouldn't cause an
> issue with Java 11. What error did you get?


The compiler complains about "unknown option --add-opens" when I try to rebuild
kotlin in unstable. 

Starting process 'Gradle build daemon'. Working directory:
/<>/.gradle/daemon/4.4.1 Command: /usr/lib/jvm/java-11-openjdk-
amd64/bin/java -Xbootclasspath/a:/usr/share/java/gradle-helper-
hook.jar:/usr/share/java/maven-repo-helper.jar --add-opens
java.base/java.lang=ALL-UNNAMED -Dfile.encoding=UTF-8 -Duser.country -
Duser.language=en -Duser.variant -cp /usr/share/gradle/lib/gradle-launcher-
4.4.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 4.4.1

It might be related to the build-dependency on openjdk-8 but the command
mentions java-11 which is strange. In any case we should be more careful when
we force new options to all packages. A conditional is safer and prevents
regressions.



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

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Package: gradle-debian-helper
Version: 2.2
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

The newly added --add-opens option is only valid for OpenJDK 17. I
understand that we switch to it for Debian 12 but it currently breaks
all packages that are built with OpenJDK 11. I am currently in the
process to update gradle to a newer upstream release. We should try to
use a conditional clause depending on the JVM in use.

Markus

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

Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Package: gradle
Version: 4.4.1-14
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

The newly added --add-opens option is only valid for OpenJDK 17. I
understand that we switch to it for Debian 12 but it currently breaks
all packages that are built with OpenJDK 11. I am currently in the
process to update gradle to a newer upstream release. We should try to
use a conditional clause depending on the JVM in use.

Markus

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

Bug#1011492: tika: FTBFS cannot find symbols

[Markus Koschany]

Source: tika
Version: 1.22-2
Severity: serious
X-Debbugs-Cc: a...@debian.org


I just stumbled upon this FTBFS while rebuilding some packages for a new
jsoup release. There are some missing symbols but it is not related to
jsoup. I am just filing this bug report for further investigation
later.

Markus

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

Bug#1010657: google-oauth-client-java: CVE-2021-22573 - IdTokenVerifier does not verify the signature of ID Token

[Markus Koschany]

Hi tony,

Am Sonntag, dem 15.05.2022 um 11:17 -0700 schrieb tony mancill:

> [...]
> Any thoughts?  It's a tad messy either way, but using current versions
> simplifies the porting of patches.

I haven't investigated the CVE closely enough but the current reverse-
dependencies in Bullseye don't seem to be severely affected by it. bazel-
bootstrap and libgoogle-api-client-java are more like leaf packages unless we
take openrefine in bullseye-backports into consideration as well. 

We could also mark the CVE as ignored for Bullseye because of the minor impact,
or just upload the new google-http-client-java package to bullseye after
approval by the release team and then update google-oauth-java-client as well.
We just have to check if this breaks the two other packages in Bullseye (bazel-
bootstrap and google-api-client-java).

So yes, a newer upstream version is fine, if it does not break any existing
packages and there is no other way or the alternative would be way too time
consuming and inconvenient. 

Cheers,

Markus



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

Bug#1010558: jetty9: FTBFS An API incompatibility was encountered while executing org.apache.maven.plugins:maven-assembly-plugin

[Markus Koschany]

Package: jetty9
Version: 9.4.46-1
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

I have just discovered that jetty9 fails to build from source.

An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-assembly-plugin

Probably some recently upgraded reverse-dependency is to blame here.

Markus

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

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

[Markus Koschany]

Am Donnerstag, dem 14.04.2022 um 16:23 +0530 schrieb Utkarsh Gupta:
> Hi Emmanuel,
> 
> We have bug #1008668 that's causing problems on the Ubuntu side and is
> also reproducible via the Debian package (essentially, it's the same
> in both places).

Hi Utkarsh,

I have been trying to reproduce this problem but on an up-to-date Debian system
running tomcat9 version 9.0.58-1 I cannot reproduce it. catalina.out is
truncated when I run 

logrotate -f /etc/logrotate.d/tomcat9

The logrotate file changes the permissions to "su tomcat adm" which is
sufficient to operate on tomcat9 log files. I'm not familiar with the Ubuntu
differences when it comes to logrotate and rsyslogd but I suppose that is the
underlying issue here. It would be strange if we had to change the permissions
to syslog adm because other Debian packages also own log files with their
specific users and then does not cause any problems too.

Thus said I am not against fixing this for Ubuntu but the current approach
seems wrong to me.

Regards,

Markus




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

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

[Markus Koschany]

Am Montag, dem 28.03.2022 um 21:06 -0700 schrieb tony mancill:
> [...]
> I am interested to hear other opinions from the Debian Java Team.

I have no objections with implementing this change and I agree that a
versionless symlink is preferable for consistency reasons. The current behavior
doesn't do any harm though. The Lintian warning should be fixed with a regular
upload and not just for the sake of it.

Regards,

Markus


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

Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Markus Koschany]

Hi,

Am Mittwoch, dem 02.03.2022 um 16:43 +0200 schrieb Per Lundberg:

[...]

> (Speaking about tomcat10, I noted the package in experimental is really 
> old - doesn't seem to have been updated for a few years. Do you know if 
> anyone is working on updating the package to e.g. Tomcat 10.0.17 or will 
> it perhaps happen later in the Bookworm release cycle?)

I intend to update it in the near future. I believe the initial goal was to
make it co-installable with Tomcat 9. Currently there are still some file
conflicts which have to be resolved before we can upload Tomcat 10 to unstable.

> 
> Also, I wonder if it wouldn't even make sense to remove openjdk-8-jdk 
> altogether from unstable at this point. The fact that it's present there 
> is actually a bit confusing, since it gives the (completely false) 
> impression that JDK 8 will be supported in future versions of Debian. If 
> you agree, I can file a separate removal bug on that package. (I'm not 
> currently a Debian maintainer myself, so I cannot help out more than 
> that. ;)

We still need OpenJDK 8 to bootstrap Kotlin. Please don't ask for its removal.
It would be great if we could use OpenJDK 11 instead but we are not there yet.

> 
> As for the actual libeclipse-jdt-core-java package, is there any 
> particular reason for going with the 4.21 version in Debian unstable & 
> bookworm? I am just curious. It feels like a somewhat odd decision to go 
> with a more recent version than the 4.20 version which Apache bundles in 
> their distribution. But perhaps there are other Debian packages which 
> can find use of the newer package, or has it perhaps just been done to 
> be able to ship the "latest and greatest" version of this package with 
> Bookworm? (I mean: to not ship something which is "old" already at the 
> time of release.)

I guess there was no particular reason other than upgrading to the latest
available version back then. I have not investigated yet if another Debian
package requires 4.21 specifically but since we don't really support Java 8
anymore I think we can just move forward. Tomcat 9 will be gone next year and
since we rather have to invest time into fixing OpenJDK 17 bugs than making
packages Java 8 compatible, I would say let's keep it as is. 

Regards,

Markus


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

Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Markus Koschany]

Hello Per,

Am Mittwoch, dem 02.03.2022 um 12:54 +0200 schrieb Per Lundberg:
> reassign 1006647 tomcat9
> thanks
> 
> This might better belong to this package, since the problem is that 
> tomcat9-common depends on default-jre-headless | java8-runtime-headless 
> > java8-runtime, while in reality it requires Java 11. (because of 
> Eclipse JDT 4.21, see original bug report for details)
> 
> If we are unable to fully resolve this, I think that we should at least 
> fix these incorrect dependencies to make the package depend on 
> "default-jre-headless | java11-runtime-headless | java11-runtime" 
> instead. But as previously mentioned, I would much rather see us move to 
> Eclipse JDT 4.20 instead so we can retain Java 8 support until Debian at 
> some point upgrades to Tomcat 10.1 (at which point requiring Java 11 is 
> inevitable).

As a matter of fact OpenJDK 11 is the only supported Java version in oldstable,
stable and testing right now. We plan to release with Java 17 next year and one
of our goals is to ship only Tomcat 10 in Debian 12 "Bookworm". I think you are
right that we should tighten the dependency to java11-runtime-headless to avoid
any confusion but as I said, OpenJDK 11 is the only supported JDK/JRE at the
moment. If you cannot upgrade your application to Java 11, then you could
create a custom Tomcat 9 package or simply downgrade libeclipse-jdt-core-java
to 4.20 again. 

Regards,

Markus


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

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi Jochen,

Am Donnerstag, dem 24.02.2022 um 11:26 +0100 schrieb Jochen Sprickerhof:
> 
> 
> - Keep the current (old) version of h2 in Debian till jameica is 
>    updated, given that jameica is the only user.
> 
> - Upload the old version of h2 as jameica-h2database and move the jar to 
>    /usr/share/jameica. That would basically mark the package as jameica 
>    only and would free up the h2database package to move to a newer 
>    version.
> 
> What do you think?

I would rather tend to option two in order to move forward and to provide the
latest version of h2 which is supported by upstream and easier to maintain in
the future. You could also try to import the h2 1.4.x source code into jameica
or hibiscus for the time being and then use it to build both packages. That
would allow us to simply upgrade the existing h2 source package and you could
do whatever you want with the old h2 version. We just have to keep track of
potential security vulnerabilities but the attack surface should be much
smaller. I leave the decision to you because your packages are the only real
consumers of h2 in Debian.

Cheers,

Markus


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

Bug#1006140: New version can't load old databases

[Markus Koschany]

Am Samstag, dem 19.02.2022 um 23:13 +0100 schrieb Jochen Sprickerhof:
> * Markus Koschany  [2022-02-19 22:38]:
> > Ok. Did you file an upstream bug report already?
> 
> I did not yet. Upstream bundles the old binary version so I don't think 
> I can convince them to do a quick migration.
> But I will open a bug to get it fixed there.
> 
> > The old version of H2 is already present in Ubuntu or Debian stable. You
> > could
> > either ask users to execute all those commands manually (README.Debian,
> > Debian.NEWS) or there could be some kind of pre/post hook script that does
> > all
> > that automatically.
> 
> Asking users to install packages from other releases does not sound 
> convincing. We can't use the pre/post maintainer scripts as the database 
> files could be stored anywhere on disk (default is in $HOME but could 
> even be on a thumb drive). So we can only hook into the jameica 
> executable. I don't think doing this before the Ubuntu jammy freeze is 
> feasible.

I believe there is a misunderstanding somewhere. We don't need to ask users to
install anything. They simply upgrade from an older version to a newer one.
There must be some sort of logic for the database storage. It is possible to
move a file to a different location but your program will always look in the
same place. If your database isn't there, then a good script would ask where it
is, you enter the new location and the program proceeds. 

> > For a quick solution you could upload 1.4.197 again based on the version in
> > Bullseye
> 
> Thanks, I will do that, i.e. I will upload 2.1.210+really1.4.197-1 = 
> 1.4.197-4+deb11u1 as proposed in my initial bug report.
> 
> > but this doesn't really solve the problem.
> 
> Can you explain what you mean here?


You only fix your single use case. You keep an unsupported and buggy version of
the H2 database in Debian and this is not how we usually solve problems in
Debian. 


> > As I said we don't need multiple H2 versions in Debian.
> 
> Can you give reasons why you think so? As I stated multiple times I 
> don't see a way not to have multiple versions available in one release 
> to support the migration.

You don't need multiple version of H2 in Bookworm. We ship 1.4.197 in Bullseye
and 2.x in Bookworm, that's it. When users upgrade from Bullseye to Bookworm,
they either have to perform some manual migration steps, or the package takes
care of them automatically. That's how it works for every package in Debian. We
also don't ship multiple Tomcat or Jetty, MariaDB or PostgreSQL versions in
stable releases because we support only one of them for their life cycle. This
is because of security and maintenance reasons, otherwise we would have
multiple versions of every piece of Java software in Debian and we could stop
using system libraries and instead bundle everything together in fat jars. At
one point you have to upgrade to a newer H2 database, that's a fact and it
should happen before we freeze for Bookworm.

> > You should only do that if you are willing to
> > support an officially unsupported piece of software for the next Debian 12
> > LTS
> > cycle until the year 2028. And that means taking care of all other libh2-
> > java
> > dependencies too, dealing with people who request an upgrade to 2.x because
> > their use case depends on it, etc. And you and the rest of the users should
> > be
> > fine with the disabled H2 console and all the other bugs in that version.
> 
> That would be fine with me.

Ok, that's your choice but please add yourself to the list of Uploaders and
keep an eye on all H2 bug reports from now on because I won't. ;>




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

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi Jochen,

Am Samstag, dem 19.02.2022 um 21:21 +0100 schrieb Jochen Sprickerhof:
> Hi Markus,
> 
> thanks for your quick reply.
> 
> * Markus Koschany  [2022-02-19 21:01]:
> > That means only hibiscus/jameica require our attention. I would try to
> > remove
> > the obsolete connection setting mentioned in #1005838.
> 
> Tried that already, did not solve the problem.


Ok. Did you file an upstream bug report already?

> 
> > You could also try to
> > dump the SQL database with the current version in stable and then try to
> > re-
> > import the SQL tables with H2 in unstable. That should actually work
> > because
> > the SQL syntax will not have changed. (See also the Upgrading paragraph
> > here
> > https://h2database.com/html/migration-to-v2.html)
> 
> That would be the plan, yes. But for that we would need to provide both 
> versions to our users, thus I propose to upload the new version as a new 
> source and binary package.
> 
> Also the SQL syntax did change.
[...]
> Can you explain how you want to implement this re-import feature then?


I don't think the SQL syntax itself did change. SQL is a separate language and
different SQL databases must be compatible in this regard. MySQL, MariaDB,
hsqldb, H2, they all should be able to read and write SQL. If H2 changed some
H2 specific commands, then all we have to do is to execute a command for the
old H2 database to dump the old database and then use another command to re-
import the database into H2 2.x. 

The old version of H2 is already present in Ubuntu or Debian stable. You could
either ask users to execute all those commands manually (README.Debian,
Debian.NEWS) or there could be some kind of pre/post hook script that does all
that automatically. 

I would try to solve that problem on the package level though, and ask upstream
to come up with a migration plan because sticking with 1.4.x forever is not a
great plan.

> I would really appreciate a quick solution here so users of the next 
> Ubuntu version would not be locked out of their homebanking system.
> 
> I'm happy to help with uploading new versions and NEW is rather empty 
> currently so I don't see the point in not doing a proper transition 
> here.

For a quick solution you could upload 1.4.197 again based on the version in
Bullseye but this doesn't really solve the problem. As I said we don't need
multiple H2 versions in Debian. You should only do that if you are willing to
support an officially unsupported piece of software for the next Debian 12 LTS
cycle until the year 2028. And that means taking care of all other libh2-java
dependencies too, dealing with people who request an upgrade to 2.x because
their use case depends on it, etc. And you and the rest of the users should be
fine with the disabled H2 console and all the other bugs in that version. 



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

Bug#1003894: fixed in h2database 2.1.210-1

[Markus Koschany]

Control: fixed -1 1.4.197-4+deb10u1
Control: fixed -1 1.4.197-4+deb11u1


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

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi,

Am Samstag, dem 19.02.2022 um 18:52 +0100 schrieb Jochen Sprickerhof:
> Package: libh2-java
> Version: 2.1.210-1
> Severity: important
> X-Debbugs-Cc: jspri...@debian.org, Markus Koschany 
> Control: -1 affects mediathekview jameica hibiscus
> 
> Hi,
> 
> the new version of libh2-java uses a new SQL syntax and file format and
> is not able to read old data or work with the old syntax:
> 
> https://h2database.com/html/migration-to-v2.html
> 
> This renders all it's users, i.e. mediathekview and jameica/hibiscus,
> unusable.

I had rebuilt all reverse-dependencies of libh2-java and they still can be
built from source. Unfortunately there are runtime problems as you have rightly
pointed out. Actually only mediathekview and jamaica/hibiscus are really
affected. Mediathekview downloads a large json file from the internet (the
filmlist) and then it is converted into a h2 database. Normally it should be
fine to remove the old database and then mediathekview would create a new
database again. Persistent settings are saved in xml files anyway. However I
just noticed at least one SQLException when this happens and the conversion
appears to take forever. Probably solvable but...

the latest version of Mediathekview uses a SQLite database now, because
upstream likes changing dependencies, thus upgrading to the lastest upstream
release would solve the problem.

That means only hibiscus/jameica require our attention. I would try to remove
the obsolete connection setting mentioned in #1005838. You could also try to
dump the SQL database with the current version in stable and then try to re-
import the SQL tables with H2 in unstable. That should actually work because
the SQL syntax will not have changed. (See also the Upgrading paragraph here
https://h2database.com/html/migration-to-v2.html)


> 
> Given that there is no online conversion available, the H2MigrationTool
> actually contains jars of the different version, I would propose to
> upload the v2 version with a new source and binary package name and
> upload the v1 version to unstable again with a +really version number:
> 
> 2.1.210+really1.4.197-1
> 
> based on the git tag debian/1.4.197-4+deb11u1.
> 
> Given that this affects all linked programs and that v2 already
> transitioned to testing as well as the next Ubuntu version (which will
> stop importing from Debian soon) I would like to get this fixed fast.
> 
> I'm planning to upload the +really version tomorrow unless someone
> disagrees.

I would advise against that plan because

a) jameica/hibiscus is the only affected package

b) the grave security issues would be present again #1003894.

 I have fixed the most severe ones in stable releases by disabling the H2
console and JNDI lookups. There are probably more issues mentioned by upstream
here: 

https://github.com/h2database/h2database/issues/3360#issuecomment-1018351050

However users would want an up-to-date version of H2 in the future. At some
point an upgrade is inevitable. 

c) two source packages make only sense if we talk about an (important) library
that is incompatible and breaks many reverse-dependencies. H2 is a database and
affects only 2 packages.

d) versions 1.4.xxx are no longer supported. 1.4.197 is already four years old.
That makes security support or any support in general not feasible if we want
to release this version again for Bookworm.


I would contact jameica/hibiscus upstream and report this issue as a bug. A
database dump and re-import should be possible in any case and depending on a
supported version of H2 is surely desirable for all parties.

Regards,

Markus



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

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Markus Koschany]

Hi,

Am Donnerstag, dem 10.02.2022 um 17:22 +0100 schrieb Christoph Anton Mitterer:
> Hey.
> 
> Is that going to be fixed in stable, too?
> 
> Cheers,
> Chris.

Yes, these issues will be fixed with a stable point update.

Regards,

Markus


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

Bug#1004284: tomcat9: postinst creates wrong userhome via systemd-sysusers

[Markus Koschany]

Control: tags -1 moreinfo

Hello,

 
> Dear Maintainer,
> 
> Debian creates in the postinst script via systemd-sysusers
> a system user named tomcat whose home directory is /var/lib/tomcat. 
> This directory does not exist, but /var/lib/tomcat9

The idea was to create a general tomcat system user but without an existing
home directory for security reasons. Note that the shell is set to
/usr/sbin/nologin too.

Previously we created a new tomcat user for every new major version. You could
end up with several tomcat users on a normal server and that was not really
desirable. In theory it should be possible to install multiple major versions
on the same server by now (tomcat9 and tomcat10) but there are some bugs in
tomcat10 which require some attention before we can call this task as complete.

Is there anything we missed or can we close this bug report ?

Regards,

Markus



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

Re: apache-jena_3.17.0-1_amd64.changes REJECTED

[Markus Koschany]

Hi Thorsten,

Am Sonntag, dem 06.02.2022 um 19:28 +0100 schrieb Thorsten Alteholz:
> Hi Markus,
> 
> On 06.01.22 22:23, Markus Koschany wrote:
> > 
> > thanks for reviewing apache-jena, much appreciated. If you have more time
> > on
> > your hands I would also appreciate a review of libmarc4j-java, libodfdom-
> > java,
> > librdfa-java, libwikidata-toolkit-java and openrefine. They all belong
> > together
> > and currently I'm stuck with a project which I can't continue without them.
> 
> I hope I didn't miss a package for openrefine now ...
> 
>    Thorsten

Perfect. That's all for now. Thanks a lot!

Cheers,

Markus




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

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Markus Koschany]

Am Sonntag, dem 30.01.2022 um 16:49 -0800 schrieb tony mancill:
> On Mon, Jan 31, 2022 at 01:18:49AM +0100, Emmanuel Bourg wrote:
> > Le 31/01/2022 à 00:47, Markus Koschany a écrit :
> > 
> > > Thanks tony! I'm currently rebuilding all reverse-dependencies of
> > > log4j1.2. So
> > > far it looks like I was right and there is no package that actually
> > > requires
> > > one of the affected classes to build. None of the affected features are
> > > enabled
> > > by default hence why I would rather prefer the sledgehammer approach and
> > > just
> > > remove them. What doesn't exist can't be exploited. At least this makes
> > > sense
> > > for stable and oldstable distributions right now.
> > 
> > +1
> 
> Yes, I didn't mean to imply anything otherwise for stable and oldstable. 

Ok, I will remove the affected classes in Stretch and prepare a point update
for Buster and Bullseye which will achieve the same.


> 
> > > I suggest to file bugs against all those packages with severity normal
> > > and ask
> > > to migrate to log4j2. If we don't make a lot of progress within the next
> > > six
> > > months then we could consider packaging reload4j, although I would rather
> > > avoid
> > > to package (and maintain) a fork of an obsolete project.
> > 
> > We may also pick the reload4j changes and apply them on top of log4j1.2,
> > that should induce less work (no extra package, no dependency change, no
> > migration to a new API).
> 
> Right.  My point in writing was to point out that reload4j is a direct
> fork of log4j1.2.  Porting to log4j2 could be quite a bit of
> (unnecessary) work.

For unstable and testing I have applied the changes from the reload4j project
on top of our sources now. I agree that porting every dependency to log4j2 on
our own is too much work but I presume there are some projects that already did
the switch a while ago and their package was simply not updated in Debian. In
any case as long as reload4j continues to provide security fixes log4j1.2
should be maintainable. 






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

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Markus Koschany]

Am Sonntag, dem 30.01.2022 um 15:20 -0800 schrieb tony mancill:
> 
> Hi Markus,
> 
> You might take some inspiration and/or patches from the reload4j
> project.
> 
>   https://reload4j.qos.ch/  
> 
> I have been using it as drop-in replacement for the log4j 1.2.x jar for
> applications at ${dayjob} without any problem.  Once you decide how you
> would like to address the CVE, we can discuss the possibility of
> packaging reload4j for bookworm as a replacement for apache-log4j1.2.


Thanks tony! I'm currently rebuilding all reverse-dependencies of log4j1.2. So
far it looks like I was right and there is no package that actually requires
one of the affected classes to build. None of the affected features are enabled
by default hence why I would rather prefer the sledgehammer approach and just
remove them. What doesn't exist can't be exploited. At least this makes sense
for stable and oldstable distributions right now. 

I don't know much about the reload4j fork at the moment. From an application
manager perspective it could make sense to replace log4j1.2 with reload4j but
Debian should better move forward to log4j2 in my opinion. Ideally we could
just replace log4j1.2 with log4j2 in all reverse dependencies. Some upstream
projects should be really shaken up by now because of log4shell and eventually
move away from log4j1.2. We still have a lot of Debian packages which depend on
it though.

I suggest to file bugs against all those packages with severity normal and ask
to migrate to log4j2. If we don't make a lot of progress within the next six
months then we could consider packaging reload4j, although I would rather avoid
to package (and maintain) a fork of an obsolete project.

Cheers,

Markus


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

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Markus Koschany]

Control: owner -1 !

On Fri, 28 Jan 2022 17:04:08 +0100 Christoph Anton Mitterer
 wrote:
> Package: liblog4j1.2-java
> Version: 1.2.17-10
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: Debian Security Team 
> 
> Hey.
> 
> A number of holes was found in the 1.2 branch of log4j.
> 
> The following is apparently critical (code injection):
> https://www.cvedetails.com/cve/CVE-2022-23307/
> 
> https://www.cvedetails.com/cve/CVE-2022-23305/
> https://www.cvedetails.com/cve/CVE-2022-23302/


I intend to address these issues shortly. I believe we can just remove the
affected classes because they are not used by our dependencies but I need to
double-check that.

Markus




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

Re: libmarc4j-java_2.9.1-1_amd64.changes REJECTED

[Markus Koschany]

Am Samstag, dem 15.01.2022 um 19:00 + schrieb Thorsten Alteholz:
> 
> Please ping me again after the next upload.

Hello Thorsten,

thanks for your diligent work. I have added Bas Peters to debian/copyright and
uploaded libmarc4j-java to NEW again.

Regards,

Markus


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

Re: libodfdom-java_0.9.0~RC2-1_amd64.changes REJECTED

[Markus Koschany]

Am Freitag, dem 07.01.2022 um 01:00 + schrieb Thorsten Alteholz:
> 
> Hi Markus,
> 
> I am bit stuck. LICENSE contains some remarks that third party stuff is added
> to this package.
> 
> I can find text that was taken from the ODF spec (in [1]), so this copyright
> information is missing in any case.

Those messages are part of a specification but the copyright of the file is
Apache 2.0. This is like using  tags in a document, or printing a
novel on DIN A4 sized paper. The tags are part of the HTML language
specification but the document can be licensed under a different copyright.

> But where can I find the MathML-, the MSV- and this isorelax-stuff? A comment
> about this in your debian/copyright would be great.

Ah, I can see where the confusion stems from. I have cloned the complete
repository from

https://github.com/tdf/odftoolkit

but I did only package 

https://github.com/tdf/odftoolkit/tree/master/odfdom

as the Source link states correctly in debian/copyright.

The LICENSE in the root directory is the license file from the complete
odftoolkit repository. The relevant LICENSE file is in the odfdom directory. I
did not package ODF Validator and none of the dependencies which are mentioned
in the LICENSE file are included in this package. I have clarified this with a
comment in d/c. The whole libodfdom-java source package is under the Apache 2.0
license.


Regards,

Markus


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

Re: apache-jena_3.17.0-1_amd64.changes REJECTED

[Markus Koschany]

Hi Thorsten,

Am Donnerstag, dem 06.01.2022 um 19:00 + schrieb Thorsten Alteholz:
> 
> Hi Markus,
> 
> our hardworking trainees left a note at your package:

thanks for reviewing apache-jena, much appreciated. If you have more time on
your hands I would also appreciate a review of libmarc4j-java, libodfdom-java,
librdfa-java, libwikidata-toolkit-java and openrefine. They all belong together
and currently I'm stuck with a project which I can't continue without them.

> 
>   File apache-jena-osgi\jena-osgi\src\main\resources\META-INF\NOTICE mentions
>   portions of this software were originally based on copyrighted material.
> The
>   copyright holders are stated, but we do not find these in the d/copyright
> file.
>   Maybe that acknowledgement should be stated in the d/c file?

I believe the acknowledgement is the NOTICE file in the root directory which we
install into /usr/share/doc/libapache-jena-java already. We have never copied
the content verbatim into d/c but installed the NOTICE file instead. There is
also a Lintian tag for it. Everything stated in this NOTICE file is for
informational purposes as stated in the Apache Lincence paragraph 4 d)

The contents of the NOTICE file are for informational purposes only
and
do not modify the License.

Some of the source material was developed by other parties but they granted
their work to the Apache Software Foundation, so the copyright holder is the
Apache Software Foundation. 
>   
>   Likewise so for apache-jena\dist\NOTICE
>   
>   A number of files are licensed under the W3C software license. Some are
>   mentioned in d/c, but others not, like
>   
>   jena-arq\testing\DAWG-Final\ask\
>   jena-arq\testing\DAWG-Final\bound\
>   jena-arq\testing\DAWG-Final\cast\

Indeed the DAWG and DAWG-Final directories are licensed under the W3C Software
license. I have corrected this issue and re-uploaded the package to unstable.

Regards,

Markus




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

Bug#970721: xom: new releases available

[Markus Koschany]

Am Dienstag, dem 04.01.2022 um 16:45 +0200 schrieb Andrius Merkys:
> Hello,
> 
> I have packaged successfully packaged xom v1.3.7 locally and launched
> ratt to test-rebuild the reverse dependencies. 81 of 137 of them are
> done at the moment, all of the failures happened in already RC-buggy
> packages.
> 
> Is it OK for me to:
> 
> 1. Push my packaging to a branch in xom repo on salsa?
> 
> 2. Upload xom v1.3.7 to experimental?


Sure. Thanks for preparing the update!

Cheers,

Markus


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

Bug#1001891: apache-log4j2: CVE-2021-45105: Certain strings can cause infinite recursion

[Markus Koschany]

Control: owner -1 !

Am Samstag, dem 18.12.2021 um 14:37 +0100 schrieb Salvatore Bonaccorso:
> Source: apache-log4j2
> Version: 2.16.0-1
> Severity: grave
> Tags: security upstream
> Forwarded: https://issues.apache.org/jira/browse/LOG4J2-3230
> X-Debbugs-Cc: car...@debian.org, Debian Security Team
> 
> Control: found -1 2.16.0-1~deb11u1
> Control: found -1 2.16.0-1~deb10u1
> 
> Hi,
> 
> The following vulnerability was published for apache-log4j2, again
> less stronger impact.
> 
> CVE-2021-45105[0]:
> > Certain strings can cause infinite recursion
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

Thanks for the report. I hope we are not going to see a new log4j CVE every
week now...

I can prepare the security update for Buster and Bullseye again.

Regards,

Markus


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