Bug#1066983: marked as pending in monopd
Control: tag -1 pending Hello, Bug #1066983 in monopd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/monopd/-/commit/68244a27a4122d4b4ba68e8c1e1708e924ae534b Remove systemd socket file and service template file. A simple systemd service file is sufficient to control the monopd server. Closes: #1066983 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066983
Bug#1066983: monopd: Fails to start monopd.service
Hello Shriram, Am Mittwoch, dem 27.03.2024 um 15:10 +0530 schrieb Shriram Ravindranathan: > Dear Markus, > > On 27/03/24 13:01, Markus Koschany wrote: > > As this bug report proves, normal people tend to have problems with system > > services. A system administrator would have simply disabled or masked the > > service. There is nothing here what could not have been resolved with some > > systemctl commands. > I am sorry but I don't understand the point you are trying to make here. > I don't think it is in the right spirit that we should expect anybody > (even sysadmins) to bodge the package somehow and get it to work. > The package is not broken and the bug severity is incorrect. Sylvain already explained what you could have done with systemctl to solve this issue. signature.asc Description: This is a digitally signed message part
Bug#1066983: monopd: Fails to start monopd.service
Hi Sylvain, Am Montag, dem 25.03.2024 um 18:48 +0100 schrieb Sylvain Rochet: > Hi Markus, > > On Mon, Mar 25, 2024 at 02:36:59AM +0100, Markus Koschany wrote: > > Sylvain Rochet wrote: > > > Actually, the main problem is /lib/systemd/system/monopd.socket which > > > set Accept=yes while monopd needs Accept=no (which is the default value). > > > > I wonder if monopd needs a systemd socket file at all and if we should > > disable the service after the installation. We have been using this > > setting since the introduction of systemd. If monopd runs with > > Accept=no then we also don't need a service template file. At some > > point I also noticed the same warning as Shriram > > > > "monopd.socket is a disabled or a static unit not running, not > > starting it." and then followed [1] and added the required template > > file. > > Yeah, socket activation is not really useful for public servers > services, it is mostly used for local services that can be spawned on > the fly later. Furthermore, socket activation breaks monopd metaserver > registration because the daemon must be running to register, so better > only ship the service file. I let you decide whether the service should > be disabled or enabled by default (but unless something recently > changed, daemon usually runs by default on Debian. I admit having lost > track :D). Our Policy is still to enable autostarting a service but I also don't see a must directive in 9.3.3.1 [1], so if there is a good reason it should be OK to disable the service and let the local administrator re-enable it, if desired. > > I have been running monopd for the past decade and I also suspect the > > daemon is affected by some bugs which might be remotely exploitable. > > What makes you think that? > > My daemon is running attached to gdb so I can easily catch and trace any > issue that would kill the process. So far it's been over 10 years > without a single issue, some process lived for several years between > systems reboot. > > I am not saying it is bug free because nothing is bug free, but if it is > remotely exploitable and actively exploited, I would be aware of it on > my running instance. I have seen multiple lines like that in my log files before: monopd.service: main process exited, code=killed, status=11/SEGV It happens from time to time but at some time it was more frequent which made me believe that some players found a way to reproducibly crash the server. I can send you my log file but you probably can't easily debug the problem because there was no gdb attached to the process. > > Since users usually don't need the monopd server anyway, if they want > > to play a game, they should make a conscious decision to start it if > > they want to use it locally. For a simple internet game, the daemon is > > not required. > > Installing the server package isn't already a conscious decision? As this bug report proves, normal people tend to have problems with system services. A system administrator would have simply disabled or masked the service. There is nothing here what could not have been resolved with some systemctl commands. However I believe I just remove the systemd socket file now and be done with it. There are pros and cons for autostarting the service or disabling it but we don't need to overthink this. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1066983: monopd: Fails to start monopd.service
Sylvain Rochet wrote: > Actually, the main problem is /lib/systemd/system/monopd.socket which > set Accept=yes while monopd needs Accept=no (which is the default value). I wonder if monopd needs a systemd socket file at all and if we should disable the service after the installation. We have been using this setting since the introduction of systemd. If monopd runs with Accept=no then we also don't need a service template file. At some point I also noticed the same warning as Shriram "monopd.socket is a disabled or a static unit not running, not starting it." and then followed [1] and added the required template file. I have been running monopd for the past decade and I also suspect the daemon is affected by some bugs which might be remotely exploitable. Since users usually don't need the monopd server anyway, if they want to play a game, they should make a conscious decision to start it if they want to use it locally. For a simple internet game, the daemon is not required. [1] https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html signature.asc Description: This is a digitally signed message part
Bug#1055147: seahorse-adventures: No keypress recognised
Hi Francesco, Am Sonntag, dem 03.12.2023 um 17:42 +0100 schrieb Francesco Ariis: > Il 03 dicembre 2023 alle 17:14 Markus Koschany ha scritto: > > I spoke too soon. Tested the wrong Debian release. So it appears the > > underlying > > problem is in python3-pygame which changed significantly between Bullseye > > and > > Bookworm but I'm not sure how I can fix this in seahorse-adventures right > > now. > > I managed to get keydown working like this: > - in /usr/share/games/seahorse-adventures/lib/menu.py > - go to line 119 > - substitute > if e.type is USEREVENT and e.action == 'down': > with > if e.type == USEREVENT and e.action == 'down': > - keydown will work again Thanks a lot for the report and your proposed patch. As soon as I'm back home tomorrow, I'll give it a try. Thanks for mentioning the other seahorse- adventures fork. Maybe there are even more improvements. I'll check that too. Best, Markus signature.asc Description: This is a digitally signed message part
Bug#1055147: seahorse-adventures: No keypress recognised
Control: severity -1 normal On Wed, 01 Nov 2023 09:25:19 +0100 Francesco Ariis wrote: > Package: seahorse-adventures > Version: 1.1+dfsg-6 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: fa...@ariis.it > > Dear Maintainer, > > to replicate: > > 1. Launch `seahorse-adventures` > 2. Now you are in the menu. > 3. Press any direction key > 3. The grey indicator in the menu does not move. It seems that keypresses > are not recognised. The game is thus unplayable. I could not reproduce your problem. The keys work as expected and I can navigate the menu and the game without any problems. signature.asc Description: This is a digitally signed message part
Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77
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
Bug#1057170: ssl-utils-clojure: FTBFS with bouncycastle 1.77
Source: ssl-utils-clojure Version: 3.5.0-2 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, ssl-utils-clojure 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. lein jar Compiling 2 source files to /<>/target/classes /<>/src/java/com/puppetlabs/ssl_utils/ExtensionsUtils.java:632: error: cannot find symbol return asn1ObjToObj(taggedObj.getObject()); ^ symbol: method getObject() location: variable taggedObj of type ASN1TaggedObject 1 error Compilation of Java sources(lein javac) failed. make[1]: *** [debian/rules:19: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:11: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 --- - signature.asc Description: This is a digitally signed message part
Bug#1057169: pdftk-java: FTBFS with bouncycastle 1.77
Source: pdftk-java Version: 3.3.3-1 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, pdftk-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. [javac] /<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java: 228: error: cannot find symbol [javac] ASN1Sequence content = (ASN1Sequence)((DERTaggedObject)signedData.getObjectAt(1)).getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: class DERTaggedObject [javac] /<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java: 261: error: cannot find symbol [javac] DEROctetString rsaDataContent = (DEROctetString)((DERTaggedObject)rsaData.getObjectAt(1)).getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: class DERTaggedObject [javac] /<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java: 297: error: cannot find symbol [javac] ASN1Sequence sseq = (ASN1Sequence)tagsig.getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: variable tagsig of type ASN1TaggedObject [javac] /<>/java/com/gitlab/pdftk_ signature.asc Description: This is a digitally signed message part
Bug#1057168: jdeb: FTBFS with bouncycastle 1.77
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 [0m[0mdh_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
Bug#1057167: libapache-poi-java: FTBFS with bouncycastle 1.77
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
Bug#1057166: pgpainless: FTBFS with bouncycastle 1.77
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
Bug#1057165: libitext-java: FTBFS with bouncycastle 1.77
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
Bug#1057162: jglobus: FTBFS with bouncycastle 1.77
Source: jglobus Version: 2.1.0-8.1 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, jglobus 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] COMPILATION ERROR : [INFO] - [ERROR] /<>/ssl-proxies/src/main/java/org/globus/gsi/proxy/ext/ProxyPolicy.java:[63,46] cannot find symbol symbol: method getObject() location: class org.bouncycastle.asn1.DERTaggedObject [INFO] 1 error
Bug#1019488: bouncycastle: incomplete information in the manifest files
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
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
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
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
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
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
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
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
Bug#1052572: hoteldruid: CVE-2023-43371 CVE-2023-43373 CVE-2023-43374 CVE-2023-43375 CVE-2023-43376 CVE-2023-43377
Package: hoteldruid X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for hoteldruid. CVE-2023-43371[0]: | Hoteldruid v3.0.5 was discovered to contain a SQL injection | vulnerability via the numcaselle parameter at | /hoteldruid/creaprezzi.php. CVE-2023-43373[1]: | Hoteldruid v3.0.5 was discovered to contain a SQL injection | vulnerability via the n_utente_agg parameter at | /hoteldruid/interconnessioni.php. CVE-2023-43374[2]: | Hoteldruid v3.0.5 was discovered to contain a SQL injection | vulnerability via the id_utente_log parameter at | /hoteldruid/personalizza.php. CVE-2023-43375[3]: | Hoteldruid v3.0.5 was discovered to contain multiple SQL injection | vulnerabilities at /hoteldruid/clienti.php via the annonascita, | annoscaddoc, giornonascita, giornoscaddoc, lingua_cli, mesenascita, | and mesescaddoc parameters. CVE-2023-43376[4]: | A cross-site scripting (XSS) vulnerability in | /hoteldruid/clienti.php of Hoteldruid v3.0.5 allows attackers to | execute arbitrary web scripts or HTML via a crafted payload injected | into the nometipotariffa1 parameter. CVE-2023-43377[5]: | A cross-site scripting (XSS) vulnerability in | /hoteldruid/visualizza_contratto.php of Hoteldruid v3.0.5 allows | attackers to execute arbitrary web scripts or HTML via a crafted | payload injected into the destinatario_email1 parameter. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-43371 https://www.cve.org/CVERecord?id=CVE-2023-43371 [1] https://security-tracker.debian.org/tracker/CVE-2023-43373 https://www.cve.org/CVERecord?id=CVE-2023-43373 [2] https://security-tracker.debian.org/tracker/CVE-2023-43374 https://www.cve.org/CVERecord?id=CVE-2023-43374 [3] https://security-tracker.debian.org/tracker/CVE-2023-43375 https://www.cve.org/CVERecord?id=CVE-2023-43375 [4] https://security-tracker.debian.org/tracker/CVE-2023-43376 https://www.cve.org/CVERecord?id=CVE-2023-43376 [5] https://security-tracker.debian.org/tracker/CVE-2023-43377 https://www.cve.org/CVERecord?id=CVE-2023-43377 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
I have just rebuilt and uploaded xorgxrdp 0.2.12-1+deb11u1 to bullseye- security. That should resolve the problem at hand. However I recommend to keep this bug report open and try to address the dependency problem between xrdp and xorgxrdp. If you claim that without a rebuild of xorgxrdp a new upstream version of xrdp would be broken, then this is a strong indication that xorgxrdp should be more than a recommendation in Debian terms: From the Debian Policy "Declaring relationships between packages" "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." If xrdp only works with a specific version of xorgxrdp then this is true in my opinion and the recommendation should be changed to a Depends. We had a similar issue with librhino-java and shrinksafe in the recent past. librhino-java had to declare a versioned Breaks on shrinksafe and shrinksafe had to add a versioned (Build-)Depends on rhino/librhino-java. In my opinion we have the exact same situation here. In any case I leave that to the maintainers of xrdp/xorgxrdp to resolve. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
Hello, the new Bullseye version of xrdp is identical to the version in Bookworm. Thus the underlying problem is probably more complex and I don't suspect that something is wrong with xrdp itself but more likely with a configuration option or related software packages which do something different than in Bookworm. I have tried to reproduce the problem on Bullseye with Gnome 3 installed. The problem here is that gnome-remote-desktop appears to interfere with xrdp, so I'm not totally sure what is caused by Gnome and what might be a bug in xrdp. Then I restarted the session with Gnome in Xorg mode and a remote connection to the xrdp server succeeded. However I got a black background instead of the normal wallpaper I have. Applications were shown correctly though. I definitely need more information about your setup or xrdp in general to debug this issue. Possible reasons for the behavior may be: 1. TLS / connection problem ? Did you do "adduser xrdp ssl-cert" ? Maybe a new TLS configuration option in 0.9.21.1? 2. graphic drivers ? I read that hardware accelerated drivers may cause such problems. Maybe try to disable them and use software rendering only? LIBGL_ALWAYS_SOFTWARE = true Please also upload the following log files: /var/log/xrdp-sesman.log /var/log/xrdp.log ~/.xsession-errors and journalctl -S -2m or something similar may provide more information about error messages, etc. ~/.xorgxrdp.10.log seems to belong to xorgxrdp. The package is only recommended but I wonder if the problem is potentially caused by it. xrdp is a build- dependency which suggests it might need a rebuild? But on the other hand then recommending the package would be wrong and it should be added to Depends. Someone else would have stumbled upon this sooner I guess. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1042140: trophy: FTBFS: undefined reference to `pthread_mutexattr_setkind_np'
Control: reassign -1 src:clanlib Control: tags -1 pending This is actually a bug in clanlib which surfaced because of the recent uploads / rebuilds against glibc > 2.34. The pthread_mutexattr_setkind_np symbol is obsolete and has been replaced by pthread_mutexattr_settype. signature.asc Description: This is a digitally signed message part
Bug#1037865: marked as pending in spring
Control: tag -1 pending Hello, Bug #1037865 in spring reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/spring/-/commit/1767889af0ac90325f5a4014fe985d4431ce91fb Fix FTBFS with GCC 13. Closes: #1037865 (this message was generated automatically) -- Greetings https://bugs.debian.org/1037865
Bug#1040475: marked as pending in apache-directory-server
Control: tag -1 pending Hello, Bug #1040475 in apache-directory-server reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/apache-directory-server/-/commit/02bd89466cb54bcf1e41e5dbc48a421a7fd1be0c Fix broken symlinks by explicitly depending on libapache-directory-api-java, libbcprov-java, libcaffeine-java, libmavibot-java and libapache-directory-jdbm-java. Closes: #1040475 Thanks: Andreas Beckmann for the report. (this message was generated automatically) -- Greetings https://bugs.debian.org/1040475
Bug#1040475: Broken symlinks cause Apache Directory Server to not work at all out-of-the-box
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
Bug#1042757: ublock-origin: embded javascript lib
Am Samstag, dem 19.08.2023 um 06:13 + schrieb Bastien Roucariès:
> [...]
> No unfortunatly this is transpiled aka compiled by webpack
> see the first line
> export default (function() {
>
> This is make by webpack or rollup that are automated tools. This means that
> this code is transpiled and I do not know the extend of transpiling.
>
> it may be only the es6 upstream code:
> https://sources.debian.org/src/node-punycode/2.2.3-2/scripts/prepublish.js/
> or something worst that replace the constant by something else.
>
> if you see the original code here:
> https://sources.debian.org/src/node-punycode/2.2.3-2/punycode.js/
>
> you do not see the export default (function() {
> line
>
> Javascript is strange you could edit generated file and min.js is not the
> only problem
Ok, I see. I don't think this a problem though. This is still reasonably
modifiable and human readable.
Markus
signature.asc
Description: This is a digitally signed message part
Bug#1042757: ublock-origin: embded javascript lib
Am Montag, dem 31.07.2023 um 11:56 + schrieb Bastien Roucariès: > Source: ublock-origin > Severity: serious > Justification: not prefered form of modification > > Dear Maintainer, > > src/lib include a few library that are already packaged for debian. > > per se it is not a serious bug, but we should try if possible after testing > to > use packaged version > > The serious bug is due that for instance punycode was not in prefered form of > modification due to being wepackaged (transpiled) in order to be an ES > module. > > They may be other transpiled package in this subdirectory Hello Bastien, thanks for the report. I have reviewed the src/lib directory and replaced the embedded Javascript libraries of csstree and js-beautify with Debian's system libraries. I also added the source file of hsluv to debian/missing-sources and documented the licenses of these three Javascript libraries in debian/copyright. I decided against replacing punycode because punycode.js in ublock-origin looks like the preferred form for me. The file is not minified and can be edited without problems. I believe you were referring to hsluv instead. I believe this issue is fixed in version 1.51.0+dfsg-2 soon. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1036967: fig2dev: insufficient Breaks+Replaces against transfig/jessie-elts
Am Mittwoch, dem 31.05.2023 um 14:41 +0200 schrieb Andreas Beckmann: > On 31/05/2023 14.26, Markus Koschany wrote: > > Hello Andreas, > > > > Neither fig2dev or transfig are supported in jessie-elts anymore. I > > appreciate > > the report though. Since Stretch is no longer supported by Debian I believe > > this issue is no longer actionable by the maintainer. > > Is fig2dev supported in stretch-elts? stretch-elts would be the natural > dist-upgrade target for jessie-elts. fig2dev is supported in stretch-elts but I don't think this issue warrants a separate ELA. Most customers install a certain release and keep it until it goes EOL and then they upgrade to the latest stable version anyway. signature.asc Description: This is a digitally signed message part
Bug#1036967: fig2dev: insufficient Breaks+Replaces against transfig/jessie-elts
Hello Andreas, Neither fig2dev or transfig are supported in jessie-elts anymore. I appreciate the report though. Since Stretch is no longer supported by Debian I believe this issue is no longer actionable by the maintainer. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1036778: ckbuilder: must be rebuilt against rhino 1.7.14
Hi, I have just rebuilt all reverse-dependencies of closure-compiler again, ckbuilder and ckeditor also build fine now. Thus the upload of ckbuilder 2.4.3+dfsg-2 was successful. > Should we clone this bug to ensure we have a proper (tracking) solution > after the bookworm release. If binaries need rebuilds for new versions > of build dependencies, we need to figure out how we can automatically > detect that. One way (very unpretty) is to hardcode the version which > it's going to be build against, than dose [1] will at least tell us. That's a good idea. In general the Javascript maintainers should be more considerate when it comes to packages like rhino or closure-compiler. The latter has been neglected for ten years but still many Javascript packages depend on it. It is only a matter of time when other issues in closure-compiler will surface. > > > The rebuild should be done after #1036249 in closure-compiler has been > > resolved. > > Which is not the case yet, is the 2.4.3+dfsg-2 upload futile and should > this bug be reopened? (To be safe, I'm reopening now). @yadd If you haven't done so already, could you please file an unblock request for ckbuilder? Thanks Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1036249: closure-compiler: #1036249
Sorry, that should have been #1036249. signature.asc Description: This is a digitally signed message part
Bug#1036249: closure-compiler: #1036159
Control: tags -1 patch Hello, I have been working on #1036159 and before I go ahead with my solution I would like to hear your opinion whether this is acceptable. Apparently closure-compiler embeds rhino classes and thus every time rhino is updated, closure-compiler must be rebuilt too. I did just that in revision -14 but still half of the reverse-dependencies FTBFS because of a parsing error. I tried to narrow this issue down and even reverted a commit in rhino which made closure-compiler FTBFS. We addressed the initial FTBFS in revision -13. Still that made no difference. Although rhino 1.7.14 and our ten year old closure- compiler package are seemingly compatible at the source level, there must be some subtle differences which cause the Javascript parsing errors. Since I could not find a targeted fix I decided to remove the dependency on rhino 1.7.14 and embedded rhino 1.7.7.2 instead, the last version that worked well for closure-compiler. You can find the results here: https://salsa.debian.org/java-team/closure-compiler/-/tree/bookworm I have rebuilt all reverse-dependencies and this would resolve the problem. The only exception is ckbuilder / ckeditor. The solution here is simple though. ckbuilder must be rebuilt against rhino 1.7.14. This is the original solution for #1026639 but the rebuilding part was forgotten. I have filed #1036778 as a reminder. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1036249: marked as pending in closure-compiler
Control: tag -1 pending Hello, Bug #1036249 in closure-compiler reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/closure-compiler/-/commit/cf3752994a05f1e5dd249c83aaec73784d18273c Import Debian changes 20130227+rhino-1 closure-compiler (20130227+rhino-1) unstable; urgency=medium . * QA upload. * Revert to last compatible rhino version because the latest one in Debian is not compatible with this 10! year old version of closure-compiler. - Embed rhino 1.7.7.2 source package into src:closure-compiler. - Build librhino-java from source. Update build_xml.patch and use the local binary package instead of the system library. - Drop build-dependency on librhino-java. - Drop fix-librhino-java-FTBFS.patch. - Update debian/copyright and document the rhino licenses. (Closes: #1036249) (this message was generated automatically) -- Greetings https://bugs.debian.org/1036249
Bug#1036778: ckbuilder: must be rebuilt against rhino 1.7.14
Source: ckbuilder Version: 2.4.3+dfsg-1 Severity: serious X-Debbugs-Cc: a...@debian.org ckbuilder must be rebuilt against rhino 1.7.14. This is a no-change rebuild. Otherwise ckeditor will continue to FTBFS. This was already reported in #1026639. This issue has also been reported upstream as https://github.com/ckeditor/ckbuilder/issues/34 Back then we decided to upgrade rhino but in fact ckbuilder could have also added the --add-exports java.desktop/sun.java2d=ALL-UNNAMED flag. The rebuild should be done after #1036249 in closure-compiler has been resolved.
Bug#1036249: reopen #1036249
I have identified the rhino upstream commit which caused the FTBFS in closure- compiler. If I revert said commit in rhino, then closure-compiler builds from source without any additional patches needed. https://github.com/mozilla/rhino/commit/fb77164ac4889ffa4be26d5d24cb538a8dbd632b However I still see the same runtime errors when I compile closure-compiler against this new rhino version. At the moment I am running out of ideas. Given that we approach full freeze in a few days, I am inclined to ship the last rhino version that worked for closure-compiler and bundle it together with src:closure-compiler. That should ensure all reverse-dependencies can be built from source again. We also don't have to touch src:rhino again. After the Bookworm release I recommend to file an RC bug against closure- compiler to ensure that someone either maintains it properly or it gets removed from Debian. Currently src:rhino already ships patches to maintain compatibility with a 10 year old version of closure-compiler and the burden should not be placed on other maintainers to keep it in Debian. signature.asc Description: This is a digitally signed message part
Bug#1036249: reopen #1036249
reopen 1036249 thanks The missing source files have been included with revision -14. Apparently closure-compiler embeds rhino classes but renames them to avoid conflicts. There is still a parsing error when closure-compiler tries to optimize Javascript files at runtime. E.g. ERROR - Parse error. Unsupported syntax: COMMENT This is likely related to src/com/google/javascript/jscomp/parsing/IRFactory.java method Node processUnaryExpression This was the only part of the code that failed to build with rhino 1.7.14. My patch to fix the FTBFS was incomplete and I am currently looking into a better solution. signature.asc Description: This is a digitally signed message part
Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest
Control: tags -1 patch Hi, I am attaching a patch for this issue. Somehow your package fell through the cracks because it has no dependency on logback. Logback is pulled in by Jetty though. While Logback and Jetty use the Jakarta servlet API now, your package still depends on libservlet-api-java. The fix for that was trivial. However the test failure is caused by my tomcat10-migration.patch https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91 Back then I thought it was acceptable to work around a build failure by setting the accessEvent variable to null since it seemed no package existed in Debian which would be affected by it. The Logback developers fixed that problem in newer versions, but a new upstream release of logback would have been too intrusive. Long story short: please double-check my patch and if we can ignore the logging problem Regards, Markus diff -Nru trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog --- trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog 2023-02-10 23:15:30.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog 2023-05-19 15:19:10.0 +0200 @@ -1,3 +1,14 @@ +trapperkeeper-webserver-jetty9-clojure (4.4.1-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Replace libservlet-api-java with libjakarta-servlet-api-java. + * Add jakarta.servlet.patch to fix FTBFS with latest Jetty and Logback +versions in Debian. (Closes: #1036250) + * Work around a test failure by disabling request-logging-test. +(Closes: #1034855) + + -- Markus Koschany Fri, 19 May 2023 15:19:10 +0200 + trapperkeeper-webserver-jetty9-clojure (4.4.1-5) unstable; urgency=medium * d/control: bump Breaks: on puppetserver diff -Nru trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control --- trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control 2023-02-10 23:15:30.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control 2023-05-19 15:19:10.0 +0200 @@ -15,7 +15,7 @@ libtools-logging-clojure, libjanino-java, libordered-clojure, - libservlet-api-java, + libjakarta-servlet-api-java, libjetty9-java, libjetty9-extra-java, libprismatic-schema-clojure (>= 1.1.12), diff -Nru trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath --- trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath 2023-02-10 23:15:30.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath 2023-05-19 15:19:10.0 +0200 @@ -1 +1 @@ -usr/share/java/trapperkeeper-webserver-jetty9.jar /usr/share/java/clojure.jar /usr/share/java/java.jmx.jar /usr/share/java/tools.logging.jar /usr/share/java/janino.jar /usr/share/java/servlet-api.jar /usr/share/java/jetty9-server.jar /usr/share/java/jetty9-io.jar /usr/share/java/jetty9-security.jar /usr/share/java/jetty9-client.jar /usr/share/java/jetty9-servlet.jar /usr/share/java/jetty9-http.jar /usr/share/java/jetty9-util.jar /usr/share/java/jetty9-servlets.jar /usr/share/java/jetty9-webapp.jar /usr/share/java/jetty9-proxy.jar /usr/share/java/jetty9-jmx.jar /usr/share/java/jetty9-websocket-server.jar /usr/share/java/jetty9-websocket-api.jar /usr/share/java/jetty9-websocket-servlet.jar /usr/share/java/schema.jar /usr/share/java/ring-servlet.jar /usr/share/java/ring-codec.jar /usr/share/java/ssl-utils.jar /usr/share/java/kitchensink.jar /usr/share/java/trapperkeeper.jar /usr/share/java/puppetlabs-i18n.jar /usr/share/java/trapperkeeper-filesystem-watcher.jar /usr/share/java/jul-to-slf4j.jar +usr/share/java/trapperkeeper-webserver-jetty9.jar /usr/share/java/clojure.jar /usr/share/java/java.jmx.jar /usr/share/java/tools.logging.jar /usr/share/java/janino.jar /usr/share/java/jakarta-servlet-api.jar /usr/share/java/jetty9-server.jar /usr/share/java/jetty9-io.jar /usr/share/java/jetty9-security.jar /usr/share/java/jetty9-client.jar /usr/share/java/jetty9-servlet.jar /usr/share/java/jetty9-http.jar /usr/share/java/jetty9-util.jar /usr/share/java/jetty9-servlets.jar /usr/share/java/jetty9-webapp.jar /usr/share/java/jetty9-proxy.jar /usr/share/java/jetty9-jmx.jar /usr/share/java/jetty9-websocket-server.jar /usr/share/java/jetty9-websocket-api.jar /usr/share/java/jetty9-websocket-servlet.jar /usr/share/java/schema.jar /usr/share/java/ring-servlet.jar /usr/share/java/ring-codec.jar /usr/share/java/ssl-utils.jar /usr/share/java/kitchensink.jar /usr/share/java/trapperkeeper.jar /usr/share/java/puppetlabs-i18n.jar /usr/share/java/trapperkeeper-filesystem-watcher.jar /usr/share/java/jul-to-slf4j.jar diff -Nru trapperkeeper-webserver-jetty9-clojure-4.
Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java
Control: tags -1 patch Hi, bazel-bootstrap already build-depends on libgeronimo-annotation-1.3-spec-java. The fix is trivial. Patch is attached. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java
diff -Nru bazel-bootstrap-4.2.3+ds/debian/changelog bazel-bootstrap-4.2.3+ds/debian/changelog --- bazel-bootstrap-4.2.3+ds/debian/changelog 2023-03-14 18:46:36.0 +0100 +++ bazel-bootstrap-4.2.3+ds/debian/changelog 2023-05-14 15:40:19.0 +0200 @@ -1,3 +1,12 @@ +bazel-bootstrap (4.2.3+ds-8.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Remove build-dependency on libtomcat9-java and replace +tomcat9-annotations-api.jar with geronimo-annotation-1.3-spec.jar. +(Closes: #1035995) + + -- Markus Koschany Sun, 14 May 2023 15:40:19 +0200 + bazel-bootstrap (4.2.3+ds-8) unstable; urgency=high * Correctly update 32-bit autopkgtests diff -Nru bazel-bootstrap-4.2.3+ds/debian/control bazel-bootstrap-4.2.3+ds/debian/control --- bazel-bootstrap-4.2.3+ds/debian/control 2023-03-13 21:26:15.0 +0100 +++ bazel-bootstrap-4.2.3+ds/debian/control 2023-05-14 15:40:19.0 +0200 @@ -59,7 +59,6 @@ libprotoc-dev, libreactive-streams-java, librx-java, - libtomcat9-java, libtruth-java, libxz-java, default-jdk-headless, diff -Nru bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch --- bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch 1970-01-01 01:00:00.0 +0100 +++ bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch 2023-05-14 15:40:19.0 +0200 @@ -0,0 +1,32 @@ +From: Markus Koschany +Date: Sun, 14 May 2023 15:34:17 +0200 +Subject: javax.annotations + +Switch to geronimo-annotation-1.3-spec. Do not require libtomcat9-java. + +Bug-Debian: https://bugs.debian.org/1035995 +Forwarded: no +--- + tools/distributions/debian/debian_java.BUILD | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/tools/distributions/debian/debian_java.BUILD b/tools/distributions/debian/debian_java.BUILD +index 497df78..5cfbd91 100755 +--- a/tools/distributions/debian/debian_java.BUILD b/tools/distributions/debian/debian_java.BUILD +@@ -55,13 +55,13 @@ java_import( + # libtomcat9-java + java_import( + name = "tomcat_annotations_api", +-jars = ["tomcat9-annotations-api.jar"], ++jars = ["geronimo-annotation-1.3-spec.jar"], + ) + + # For bootstrapping java toolcahin + filegroup( + name = "tomcat_annotations_api-jars", +-srcs = ["tomcat9-annotations-api.jar"], ++srcs = ["geronimo-annotation-1.3-spec.jar"], + ) + + # libjava-allocation-instrumenter-java diff -Nru bazel-bootstrap-4.2.3+ds/debian/patches/series bazel-bootstrap-4.2.3+ds/debian/patches/series --- bazel-bootstrap-4.2.3+ds/debian/patches/series 2023-03-14 18:46:36.0 +0100 +++ bazel-bootstrap-4.2.3+ds/debian/patches/series 2023-05-14 15:40:19.0 +0200 @@ -30,3 +30,4 @@ grpc-absl_synchronization.patch exclude_build_data.patch fix-install_base_key-generation.patch +javax.annotations.patch signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1034824: marked as pending in tomcat9
Control: tag -1 pending Hello, Bug #1034824 in tomcat9 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 Drop tomcat9 server packages because only one Tomcat version is supported per release. Closes: #1034824 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034824
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1034824: tomcat9 should not be released with Bookworm
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
Bug#1033366: resteasy3.0: should migrate to tomcat10
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
Bug#1033366: resteasy3.0: should migrate to tomcat10
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
Bug#1034059: marked as pending in zstd-jni-java
Hi tony, Am Sonntag, dem 09.04.2023 um 11:19 -0700 schrieb tony mancill: > > I wanted to ask you your thoughts on whether the fix should also include > updating debian/control to strictly depend on the version(s) specified > in the patched pom. Without some explicit declaration of dependencies, > it seems like this is going to break again, right? Yes, you're right. This will certainly break again if the maven dependencies are updated. I didn't investigate the root cause of the problem but I guess it has something to do with the execute_before_* lines in debian/rules. We call two build systems, maven and cmake, and somehow maven is unable to find the maven-compiler-plugin. Usually this just works without changes to the version number. I don't think a strict plugin dependency is the true solution but it might help future contributors to remember the RC bug. Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1034059: marked as pending in zstd-jni-java
Control: tag -1 pending Hello, Bug #1034059 in zstd-jni-java reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/zstd-jni-java/-/commit/67b4cbfab56dc775db01963cae87ca223b969b4a Depend on maven-resources-plugin 3.3.0 instead of version 3.1.0. Fixes FTBFS when building zstd-jni-java for binary-arch only. Thanks: Andreas Beckmann for the report. Closes: #1034059 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034059
Bug#1034059: marked as pending in zstd-jni-java
Control: tag -1 pending Hello, Bug #1034059 in zstd-jni-java reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/zstd-jni-java/-/commit/67b4cbfab56dc775db01963cae87ca223b969b4a Depend on maven-resources-plugin 3.3.0 instead of version 3.1.0. Fixes FTBFS when building zstd-jni-java for binary-arch only. Thanks: Andreas Beckmann for the report. Closes: #1034059 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034059
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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
Bug#1022760: marked as pending in openrefine
Control: tag -1 pending Hello, Bug #1022760 in openrefine reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/openrefine/-/commit/bb324f3b1989a0ec434d95d3ea6020a214c64b06 Depend on libjoda-time-java. Closes: #1022760 Thanks: Robert Jäschke for the report! (this message was generated automatically) -- Greetings https://bugs.debian.org/1022760
Bug#1032032: FTBFS: error: AM_INIT_AUTOMAKE expanded multiple times
Control: tags -1 pending Hi Thomas, Am Donnerstag, dem 30.03.2023 um 17:05 +0200 schrieb Thomas Uhle: > Dear maintainers, > > could someone of you please prepare a new version of fenix-plugins with my > patch added to save it from being auto-removed. thanks for your patch! Looks good to me. I'm going to upload a new revision in a minute. Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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
Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10
Am Sonntag, dem 26.03.2023 um 12:15 +0300 schrieb Timo Aaltonen: > Markus Koschany kirjoitti 24.3.2023 klo 15.35: > > Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen: > > > Markus Koschany kirjoitti 23.3.2023 klo 19.00: > > > > Control: severity -1 serious > > > > > > > > On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen > > > > wrote: > > > > > > > > > Upstream doesn't support tomcat10 yet, and tomcatjss fails to build > > > > > with > > > > > it. > > > > > > > > Unfortunately we can only support one Tomcat version per release. We > > > > should > > > > either migrate to tomcat10 or maybe it is possible to embed some of the > > > > required tomcat9 classes in your source package as a workaround > > > > provided > > > > the > > > > changes are rather small and the security impact is negligible. > > > > > > Right, but that's for bookworm+1? By that time I'm sure > > > jss/tomcatjss/dogtag have gained upstream support for tomcat10. > > > > We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in > > Buster > > and Bullseye already. Tomcat 10 also targets Java 11 and later while Tomcat > > 9 > > was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm. > > resteasy3.0 > > and tomcatjss are the only packages apart from i2p that still depend on > > libtomcat9-java. > > Nice, so you expect them to migrate after bookworm is already frozen? Targeted fixes are still allowed. Including required tomcat9 classes in your package may be a solution too. If you can find an agreement with the security and release team, then even shipping libtomcat9-java might be possible. But then your packages will not receive any security support. signature.asc Description: This is a digitally signed message part
Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10
Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen: > Markus Koschany kirjoitti 23.3.2023 klo 19.00: > > Control: severity -1 serious > > > > On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen > > wrote: > > > > > Upstream doesn't support tomcat10 yet, and tomcatjss fails to build with > > > it. > > > > Unfortunately we can only support one Tomcat version per release. We should > > either migrate to tomcat10 or maybe it is possible to embed some of the > > required tomcat9 classes in your source package as a workaround provided > > the > > changes are rather small and the security impact is negligible. > > Right, but that's for bookworm+1? By that time I'm sure > jss/tomcatjss/dogtag have gained upstream support for tomcat10. We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in Buster and Bullseye already. Tomcat 10 also targets Java 11 and later while Tomcat 9 was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm. resteasy3.0 and tomcatjss are the only packages apart from i2p that still depend on libtomcat9-java. signature.asc Description: This is a digitally signed message part
Bug#1033366: resteasy3.0: should migrate to tomcat10
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
Bug#1026639: fixed in rhino 1.7.14-1
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
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi tony, [...] > I'm not able to reproduce the autopkgtest failure locally running in > clean sid chroots. First, I build the dojo source package and ran the > autopkgtest against those binaries. When that didn't fail, I pulled the > binary packages from the archive and ran the autopkgtest against those. > Again, no failures. > > I see the autopkgtest failure when I run against a bookworm chroot. > > So it seems like the migration of rhino will resolve the test failure. > (Or I'm missing something fundamental.) Strange. I downloaded the source package and ran the autopkgtests manually. I symlinked js.jar and shrinksafe.jar into util/shrinksafe and then I executed the runner.sh script. I got the same error message "Cannot set property "dojo" of null to "[object Object]". Anyway, are the autopkgtests really useful if they prevent rhino from migration to testing every time we update the package, even if everything works as expected? The same tests already run at build time. signature.asc Description: This is a digitally signed message part
Bug#1031432: FTBFS: java.util.MissingResourceException: Can't find bundle for base name com.google.javascript.rhino.head.resources.Messages, locale en
Control: reassign -1 rhino I have recently updated src:rhino and it seems this is caused by the rhino script or one of the other scripts in the rhino binary package. Initially I assumed that the error java.util.MissingResourceException: Can't find bundle for base name com.google.javascript.rhino.head.resources.Messages, locale de was specific to my locale and that it should work with English and French as stated by upstream here https://github.com/mozilla/rhino/issues/382 Not sure what is currently missing but I don't think closure-compiler is to blame here hence I'm going to reassign these bugs to rhino. Markus signature.asc Description: This is a digitally signed message part
Bug#1026639: rhino FTBFS
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
Bug#1026639: rhino FTBFS
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
Bug#1026639: rhino FTBFS
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
Bug#1026639: rhino FTBFS
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
Bug#1026639: rhino FTBFS
Control: owner -1 ! signature.asc Description: This is a digitally signed message part
Bug#1030869: marked as pending in tomcat10
Control: tag -1 pending Hello, Bug #1030869 in tomcat10 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/tomcat10/-/commit/74d267fa68d39fdcf7f67d5f1003cae707b4e9b2 Link to websocket-client-api.jar. Fixes ClassNotFoundException. Thanks: Jorge Moraleda for the report. Closes: #1030869 (this message was generated automatically) -- Greetings https://bugs.debian.org/1030869
Bug#1030869: tomcat10: Catalina won't deploy applications missing class jakarta.websocket.DeploymentException
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
Bug#1016131: libapache2-mod-jk: Apache does not start after upgrade (JkWorkersFile only allowed once)
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
Bug#1030459: marked as pending in renpy
Control: tag -1 pending Hello, Bug #1030459 in renpy reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/renpy/-/commit/61f21802f5816c5548647b387650d4d3696bb8c8 Fix FTBFS with latest setuptools version in Debian. Closes: #1030459 (this message was generated automatically) -- Greetings https://bugs.debian.org/1030459
Bug#1030177: marked as pending in pygame-sdl2
Control: tag -1 pending Hello, Bug #1030177 in pygame-sdl2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/pygame-sdl2/-/commit/7d6dd7459876113fa14559a9fc3aa4c3e3f03ef2 Fix FTBFS with latest setuptools version. Closes: #1030177 Thanks: Sebastian Ramacher for the report and James Addison for the assistance. (this message was generated automatically) -- Greetings https://bugs.debian.org/1030177
Bug#1030177: pygame-sdl2: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '2.1.0-for-renpy-8.0.2'
Thanks for your help! Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1019230: Bug#1021276: Pending snort 2.9.20 update
Hi Javier, Am Freitag, dem 20.01.2023 um 22:23 +0100 schrieb Javier Fernandez-Sanguino: > Dear Markus, > > Thank you for preparing. Could you please share the patch you are working on? > Snort is available in Salsa. Maybe you could upload / provide there your > propose changes in a separate branch? I'm adding the security team to CC to give them a heads-up because the snort update is also relevant for stable and oldstable. I'm not allowed to push to your Git repository on salsa. I will just attach my debian directory to the RC bug reports next. First of all I decided to package 2.9.20 because this version seems less intrusive than the new 3.x series. For better long-term support it would be better to go for 3.x but I leave this decision to you. I have refreshed all patches and dropped the autoconf, fix_compile_errors and fix_ftbfs_in_manual.tex patches because the package builds fine without them. In debhelper-compat 13 auto-reconfiguration is the default now. There are still a couple of Lintian errors and warnings about snort which are also present in the current unstable version. I only removed the Windows binaries from the source tarball so far. https://udd.debian.org/lintian/?packages=snort I didn't touch anything else in your package. You just need to run uscan and remove the dll files again if you want to upload yourself. If you don't have time for that, let me know, and I'll take care of the rest. Best, Markus P.S.: Your VCS repository is not up-to-date, the last update is missing. signature.asc Description: This is a digitally signed message part
Bug#1004616: marked as pending in performous
Control: tag -1 pending Hello, Bug #1004616 in performous reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/performous/-/commit/ea2d7c1b45bca758a3bb717c1ab8b6119e52def2 Fix FTBFS with ffmpeg 5. Thanks: Dan Bungert for the patch. Closes: #1004616 (this message was generated automatically) -- Greetings https://bugs.debian.org/1004616
Bug#1010095: marked as pending in performous
Control: tag -1 pending Hello, Bug #1010095 in performous reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/performous/-/commit/9e9a43b1cbd50afdb22bb5a2a99fc356292c402b Remove -mno-altivec on ppc64el as not needed anymore (Closes: #1010095) (this message was generated automatically) -- Greetings https://bugs.debian.org/1010095
Bug#1019230: Pending snort 2.9.20 update
Control: tags -1 pending Control: owner -1! Dear maintainer, I have prepared a new upstream release of snort, version 2.9.20, which will address the current release critical bugs in your package. I am currently testing it and intend to upload it to delayed 5 tomorrow. That should ensure snort will re-enter testing in time for Bookworm's soft freeze. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1028804: marked as pending in libpdfbox2-java
Control: tag -1 pending Hello, Bug #1028804 in libpdfbox2-java reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/libpdfbox2-java/-/commit/95c2d69090ccf3ae812443150b26926d9bcab234 Drop documentation binary packages. Closes: #1028804 (this message was generated automatically) -- Greetings https://bugs.debian.org/1028804
Bug#1028669: marked as pending in easymock
Control: tag -1 pending Hello, Bug #1028669 in easymock reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/easymock/-/commit/328c5a157a155bce9dddbbc7198fe3d1e279109a Drop binary package libeasymock-java-doc and do not build the javadoc. Closes: #1028669 (this message was generated automatically) -- Greetings https://bugs.debian.org/1028669
Bug#1028709: marked as pending in objenesis
Control: tag -1 pending Hello, Bug #1028709 in objenesis reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/objenesis/-/commit/d1c40265e476b72869ff341297f62157fd85a73b Drop binary package libobjenesis-java-doc. Do not build the javadoc. Closes: #1028709 (this message was generated automatically) -- Greetings https://bugs.debian.org/1028709
Bug#965006:
Am Freitag, dem 13.01.2023 um 12:47 -0600 schrieb Jorge Moraleda: > I think getting tomcat 10 into unstable so it is in a path to eventually > making into testing and then stable has become a higher priority now that > tomcat 10 is required when using webapps developed using the latest Spring > framework version > (https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x > ) [...] Tomcat 10 coming to unstable this weekend. Stay tuned! Markus signature.asc Description: This is a digitally signed message part
Bug#1026695: undertow: FTBFS: make: *** [debian/rules:4: build] Error 25
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
Bug#912485: childsplay: Please migrate to python3-pygame
Am Donnerstag, dem 01.12.2022 um 14:31 +0100 schrieb Bastian Germann: > On Tue, 20 Oct 2020 21:19:16 +0200 Markus Koschany wrote: > > I have started to port childsplay to python3. There are no estimates > > when it's done but I hope I can finish the work before we freeze. > > Will you make it to the bookworm freeze? If not, please consider removing the > package. Probably not because there are other issue I have to attend to first. I don't intend to remove the game, just to introduce it later again. signature.asc Description: This is a digitally signed message part
Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hello,
I have prepared a security update for Bullseye which fixes CVE-2022-37026.
Sergei could you review the update please? I am attaching the debdiff.
Regards,
Markus
diff -Nru erlang-23.2.6+dfsg/debian/changelog erlang-23.2.6+dfsg/debian/changelog
--- erlang-23.2.6+dfsg/debian/changelog 2021-02-25 10:34:59.0 +0100
+++ erlang-23.2.6+dfsg/debian/changelog 2022-11-30 12:53:30.0 +0100
@@ -1,3 +1,16 @@
+erlang (1:23.2.6+dfsg-1+deb11u1) bullseye-security; urgency=high
+
+ * Non-maintainer upload.
+ * Fix CVE-2022-37026:
+A Client Authentication Bypass vulnerability has been discovered in the
+concurrent, real-time, distributed functional language Erlang. Impacted
+are those who are running an ssl/tls/dtls server using the ssl application
+either directly or indirectly via other applications. Note that the
+vulnerability only affects servers that request client certification, that
+is sets the option {verify, verify_peer}. (Closes: #1024632)
+
+ -- Markus Koschany Wed, 30 Nov 2022 12:53:30 +0100
+
erlang (1:23.2.6+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru erlang-23.2.6+dfsg/debian/patches/CVE-2022-37026.patch erlang-23.2.6+dfsg/debian/patches/CVE-2022-37026.patch
--- erlang-23.2.6+dfsg/debian/patches/CVE-2022-37026.patch 1970-01-01 01:00:00.0 +0100
+++ erlang-23.2.6+dfsg/debian/patches/CVE-2022-37026.patch 2022-11-30 12:53:30.0 +0100
@@ -0,0 +1,589 @@
+From: Markus Koschany
+Date: Wed, 30 Nov 2022 11:46:49 +0100
+Subject: CVE-2022-37026
+
+Bug-Debian: https://bugs.debian.org/1024632
+Origin: https://github.com/erlang/otp/commit/cd5024867e7b7d3a6e94194af9e01e1fb77e36c9
+Origin: https://github.com/erlang/otp/commit/6a1baa36e4e6c1b682e8b48e0c141602e0b8e6e5
+---
+ lib/ssl/src/dtls_connection.erl | 25 +-
+ lib/ssl/src/ssl_connection.hrl | 6 +-
+ lib/ssl/src/ssl_gen_statem.erl | 3 -
+ lib/ssl/src/tls_connection.erl | 21 -
+ lib/ssl/src/tls_dtls_connection.erl | 155 ++--
+ lib/ssl/src/tls_gen_connection.erl | 23 +-
+ lib/ssl/src/tls_handshake_1_3.erl | 8 +-
+ lib/ssl/test/ssl_npn_SUITE.erl | 8 +-
+ 8 files changed, 171 insertions(+), 78 deletions(-)
+
+diff --git a/lib/ssl/src/dtls_connection.erl b/lib/ssl/src/dtls_connection.erl
+index fb389dc..9f6a8a0 100644
+--- a/lib/ssl/src/dtls_connection.erl
b/lib/ssl/src/dtls_connection.erl
+@@ -46,7 +46,8 @@
+ %%ClientKeyExchange \
+ %%CertificateVerify* Flight 5
+ %%[ChangeCipherSpec] /
+-%%Finished> /
++%%NextProtocol* /
++%%Finished>/
+ %%
+ %%[ChangeCipherSpec]\ Flight 6
+ %%< Finished/
+@@ -64,7 +65,8 @@
+ %% < Finished/ part 2
+ %%
+ %%[ChangeCipherSpec] \ Abbrev Flight 3
+-%%Finished > /
++%%NextProtocol* /
++%%Finished >/
+ %%
+ %%
+ %% Message Flights for Abbbriviated Handshake
+@@ -140,6 +142,7 @@
+ user_hello/3,
+ wait_ocsp_stapling/3,
+ certify/3,
++ wait_cert_verify/3,
+ cipher/3,
+ abbreviated/3,
+ connection/3]).
+@@ -462,6 +465,24 @@ certify(state_timeout, Event, State) ->
+ certify(Type, Event, State) ->
+ gen_handshake(?FUNCTION_NAME, Type, Event, State).
+
++
++%%
++-spec wait_cert_verify(gen_statem:event_type(), term(), #state{}) ->
++ gen_statem:state_function_result().
++%%
++wait_cert_verify(enter, _Event, State0) ->
++{State, Actions} = handle_flight_timer(State0),
++{keep_state, State, Actions};
++wait_cert_verify(info, Event, State) ->
++gen_info(Event, ?FUNCTION_NAME, State);
++wait_cert_verify(state_timeout, Event, State) ->
++handle_state_timeout(Event, ?FUNCTION_NAME, State);
++wait_cert_verify(Type, Event, #state{connection_env = #connection_env{negotiated_version = Version}} = State) ->
++try tls_dtls_connection:gen_handshake(?FUNCTION_NAME, Type, Event, State)
++catch throw:#alert{} = Alert ->
++ssl_gen_statem:handle_own_alert(Alert, Version, ?FUNCTION_NAME, State)
++end.
++
+ %%
+ -spec cipher(gen_statem:event_type(), term(), #state{}) ->
+ gen_statem:state
Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Package: erlang X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for erlang. Initially the security team triaged this issue as minor but further investigation showed the impact might be much more severe. Red Hat and other vendors consider this issue to be urgent and critical. https://nvd.nist.gov/vuln/detail/CVE-2022-37026 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2022-37026 Sergei what are your thoughts and do you think older versions like Buster or Stretch are affected as well? CVE-2022-37026[0]: | In Erlang/OTP before 23.3.4.15, 24.x before 24.3.4.2, and 25.x before | 25.0.2, there is a Client Authentication Bypass in certain client- | certification situations for SSL, TLS, and DTLS. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-37026 https://www.cve.org/CVERecord?id=CVE-2022-37026 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1021935: syncany: FTBFS: Could not resolve javax.servlet:javax.servlet-api:4.0.1.
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
Bug#1015860: libxalan2-java: CVE-2022-34169
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
Bug#1020019: spring: FTBFS
I have been working on packaging a new upstream release which should address this problem. I still need to resolve some issues with the build system and the patches. The current results can be found in Git. signature.asc Description: This is a digitally signed message part
Bug#1015860: libxalan2-java: CVE-2022-34169
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
Bug#1020952: marked as pending in gradle
Control: tag -1 pending Hello, Bug #1020952 in gradle reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/gradle/-/commit/e0ae4bd7ac5a65535db5e67823c045cea328f587 Update normalize-classpath.patch and add jansi1.jar to the CLASSPATH. Closes: #1020952 Thanks: Fab Stz for the report. (this message was generated automatically) -- Greetings https://bugs.debian.org/1020952
Bug#1018019: gambas3: FTBFS in unstable
> The pcre component should use pcre2. > I saw this issue on s390x but can't explain why the pcre2 headers are not > found. > Do you have a clue? Unfortunately no. I just stumbled upon this error while rebuilding your package for the imlib2 transition and this happened on amd64. signature.asc Description: This is a digitally signed message part
Bug#1018019: gambas3: FTBFS in unstable
Package: gambas3 Version: 3.17.3-1 Severity: serious Tags: ftbfs sid bookworm X-Debbugs-Cc: a...@debian.org Dear maintainer, gambas3 fails to build from source in unstable. In file included from main.c:32: regexp.h:30:10: fatal error: pcre.h: No such file or directory 30 | #include "pcre.h" | ^~~~ compilation terminated. If you fix this problem, please also check if the new version of imlib2 in experimental, version 1.9.1, works for you. I intend to upload this version to unstable in one or two months. Regards, Markus -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (900, 'stable-security'), (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gambas3 depends on: pn gambas3-examples pn gambas3-gb-args pn gambas3-gb-cairo pn gambas3-gb-chart pn gambas3-gb-clipper pn gambas3-gb-complex pn gambas3-gb-compress-bzlib2 pn gambas3-gb-compress-zlib pn gambas3-gb-compress-zstd pn gambas3-gb-crypt pn gambas3-gb-data pn gambas3-gb-db-form pn gambas3-gb-db-mysql pn gambas3-gb-db-odbc pn gambas3-gb-db-postgresql pn gambas3-gb-db-sqlite3 | gambas3-gb-db-sqlite2 pn gambas3-gb-dbus pn gambas3-gb-dbus-trayicon pn gambas3-gb-desktop pn gambas3-gb-desktop-gnome pn gambas3-gb-desktop-x11 pn gambas3-gb-form-dialog pn gambas3-gb-form-mdi pn gambas3-gb-form-stock pn gambas3-gb-form-terminal pn gambas3-gb-gmp pn gambas3-gb-gsl pn gambas3-gb-gui-opengl pn gambas3-gb-gui-qt pn gambas3-gb-gui-qt-webkit pn gambas3-gb-httpd pn gambas3-gb-image-effect pn gambas3-gb-image-imlib pn gambas3-gb-image-io pn gambas3-gb-inotify pn gambas3-gb-jit pn gambas3-gb-libxml pn gambas3-gb-logging pn gambas3-gb-map pn gambas3-gb-markdown pn gambas3-gb-media pn gambas3-gb-media-form pn gambas3-gb-memcached pn gambas3-gb-mime pn gambas3-gb-mysql pn gambas3-gb-ncurses pn gambas3-gb-net-curl pn gambas3-gb-net-pop3 pn gambas3-gb-net-smtp pn gambas3-gb-openal pn gambas3-gb-opengl-glsl pn gambas3-gb-opengl-glu pn gambas3-gb-opengl-sge pn gambas3-gb-openssl pn gambas3-gb-option pn gambas3-gb-pcre pn gambas3-gb-pdf pn gambas3-gb-poppler pn gambas3-gb-qt5 pn gambas3-gb-qt5-ext pn gambas3-gb-qt5-opengl pn gambas3-gb-qt5-webkit pn gambas3-gb-report pn gambas3-gb-report2 pn gambas3-gb-scanner pn gambas3-gb-sdl-sound pn gambas3-gb-sdl2 pn gambas3-gb-sdl2-audio pn gambas3-gb-settings pn gambas3-gb-term-form pn gambas3-gb-util pn gambas3-gb-util-web pn gambas3-gb-v4l pn gambas3-gb-vb pn gambas3-gb-web pn gambas3-gb-web-feed pn gambas3-gb-web-form pn
Bug#1018017: ukui-greeter: FTBFS in unstable
Package: ukui-greeter Version: 3.0.3-1 Severity: serious X-Debbugs-Cc: a...@debian.org Dear maintainer, ukui-greeter currently fails to build from source in unstable. BiometricAuth/giodbus.cpp:22:10: fatal error: gio-unix-2.0/gio/gunixfdlist.h: No such file or directory 22 | #include | ^~~~ compilation terminated. If you fix this problem, please also check if the new version of imlib2 in experimental works for you. I intend to upload it in one or two months. Regards, Markus -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (900, 'stable-security'), (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ukui-greeter depends on: ii libc6 2.31-13+deb11u3 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libgl1 1.3.2-1 ii libglib2.0-02.66.8-1 pn libimlib2 pn liblightdm-qt5-3-0 pn libopencv-core406 pn libopencv-imgcodecs406 pn libopencv-imgproc406 ii libqt5core5a5.15.2+dfsg-9 ii libqt5dbus5 5.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5svg5 5.15.2-3 ii libqt5widgets5 5.15.2+dfsg-9 ii libqt5x11extras55.15.2-2 ii libstdc++6 10.2.1-6 ii libx11-62:1.7.2-1 ii libxi6 2:1.7.10-1 ii libxrandr2 2:1.5.1-1 ii libxtst62:1.2.3-1 ukui-greeter recommends no packages. Versions of packages ukui-greeter suggests: pn biometric-auth
Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found
Control: severity -1 wishlist Control: retitle -1 mediathekview update discussion I have fixed the underlying problem by using an internal version of the h2 database now. I will try to package tilesfx and glazedlists next. signature.asc Description: This is a digitally signed message part
Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found
Hi Helge, Am Sonntag, dem 21.08.2022 um 08:46 +0200 schrieb Helge Kreutzmann: > Hello Markus, > On Tue, Aug 09, 2022 at 03:09:08PM +0200, Markus Koschany wrote: > > I have pushed a new branch which includes version 13.9.1. > > … > > > Those are the major issues we have to fix in order to package a new > > upstream > > release of mediathekview. And we also need to fix kotlin in unstable. If > > someone wants to help, that's our todo list. > > This sounds like a plan. Unfortunately, I basically don't have a clue > on these issues, so I cannot help. Since I'm only a DM, I can't even > push an upload. But if I should test something, please let me know. [...] I intend to embed the H2 engine into Mediathekview and revert back to the previous working state. That should resolve the current issues at least for the short term. I hope all the new dependencies of mediathekview can be packaged at some point but realistically it will take more time and the new dependency on kotlin complicates future maintenance even more. If someone wants to help then my previous todo list is a good starting point. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1012214: gradle: FTBFS with jansi 2
Control: retitle -1 gradle: FTBFS with jansi 2 Let me try to fix this signature.asc Description: This is a digitally signed message part
Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages
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
Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found
Hello, I have pushed a new branch which includes version 13.9.1. https://salsa.debian.org/debian/mediathekview/-/tree/experimental As you can see I have started from scratch because this is basically a new package now. In order to complete this upgrade we need at least an upgrade of okhttp to version 4.x https://tracker.debian.org/pkg/libokhttp-java an upgrade of okio to 3.x https://tracker.debian.org/pkg/okio tilesfx a new package eu.hansolo tilesfx https://github.com/HanSolo/tilesfx a new package glazedlists https://github.com/glazedlists/glazedlists We could omit flatlaf because that seems to be only relevant for Windows Those are the major issues we have to fix in order to package a new upstream release of mediathekview. And we also need to fix kotlin in unstable. If someone wants to help, that's our todo list. Regards, Markus signature.asc Description: This is a digitally signed message part
