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#1036039: unblock: debian-games/5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package debian-games [ Reason ] debian-games is a Debian Blend and a collection of metapackages. debian-games' purpose is to recommend or suggest games of a specific category. As usual I have updated and synced the list of packages with the actual situation in Bookworm and Sid because we are close to a release now. Packages which are not part of the next stable release but still in unstable have been downgraded to Suggests. Games which have been removed from Debian are no longer listed. Newly introduced games have been added to Recommends or Suggests. [ Impact ] The recommendations in Bookworm would be outdated. [ Tests ] I have verified that the changes work and the metapackages can be installed successfully. [ Risks ] There have been only changes in the Recommends or Suggests sections. No code changes. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock debian-games/5 diff -Nru debian-games-4/debian/changelog debian-games-5/debian/changelog --- debian-games-4/debian/changelog 2021-07-04 08:50:03.0 +0200 +++ debian-games-5/debian/changelog 2023-05-06 23:13:53.0 +0200 @@ -1,3 +1,31 @@ +debian-games (5) unstable; urgency=medium + + [ Andreas Tille ] + * Build-Depends: Drop versioned constraint on blends-dev. + + [ Markus Koschany ] + * Declare compliance with Debian Policy 4.6.2. + * New games: +- puzzle: chromono, explosive-c4, parolottero +- console: chroma-curses, nbsdgames, tty-solitaire +- platform: davegnukem +- fps: dsda-doom, ktx, mvdsv, woof-doom +- emulator: yuzu +- tetris: ghextris +- arcard: lbreakouthd +- toys: pipes-sh + * Removed games: (removed from Debian) +- education: childsplay, gcompris +- rpg: ember +- puzzle: gnubik +- emulator: higan +- arcade: monster-masher +- strategy: snowballz +- c++-dev: libogre-1.9-dev + * Update the blacklist + + -- Markus Koschany Sat, 06 May 2023 23:13:53 +0200 + debian-games (4) unstable; urgency=medium * Update the blacklist diff -Nru debian-games-4/debian/control debian-games-5/debian/control --- debian-games-4/debian/control 2021-07-04 08:50:03.0 +0200 +++ debian-games-5/debian/control 2023-05-06 23:13:53.0 +0200 @@ -4,8 +4,8 @@ Priority: optional Maintainer: Debian Games Team Uploaders: Markus Koschany -Build-Depends: debhelper-compat (= 13), blends-dev (>= 0.6.92.1) -Standards-Version: 4.5.1 +Build-Depends: debhelper-compat (= 13), blends-dev +Standards-Version: 4.6.2 Homepage: https://blends.debian.org/games/tasks/ Vcs-Git: https://salsa.debian.org/blends-team/games.git Vcs-Browser: https://salsa.debian.org/blends-team/games @@ -78,7 +78,7 @@ jzip, lure-of-the-temptress, onscripter, -qtads, +renpy-thequestion, rlvm, scottfree, scummvm, @@ -89,7 +89,7 @@ xzip, zoom-player Suggests: fizmo-ncursesw, - renpy-thequestion, + qtads, scummvm-tools Description: Debian's adventure games This metapackage will install adventure games, interpreter and engines. @@ -128,7 +128,6 @@ excellent-bifurcation, freedroid, freegish, -funguloids, funnyboat, garden-of-coloured-lights, gav, @@ -153,13 +152,13 @@ kraptor, late, lbreakout2, +lbreakouthd, lierolibre, luola, madbomber, maelstrom, marsshooter, mirrormagic, -monster-masher, moon-buggy, moon-lander, mousetrap, @@ -236,11 +235,9 @@ xsoldier, xtron, zatacka -Suggests: adanaxisgpl, - efp, - fretsonfire, +Suggests: efp, + funguloids, gnome-games, - jmdlx, kdegames, netrek-client-cow, spout @@ -346,7 +343,6 @@ libltdl-dev, libode-dev, libogg-dev, -libogre-1.9-dev, libopenal-dev, libopenscenegraph-dev, libphysfs-dev, @@ -387,7 +383,6 @@ openpref, pescetti, pokerth, -pysolfc, tenace, xmille, xpat2, @@ -395,6 +390,7 @@ xsol Suggests: gnome-games, kdegames, + pysolfc, yahtzeesharp Description: Debian's card games This metapackage will install card games. @@ -412,11 +408,12 @@ ethereal-chess, fairy-stockf
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: 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#1004844: games-finest: Consider adding endless-sky
Hi, thanks for the suggestion! On Wed, 02 Feb 2022 03:58:43 -0500 Dave Vasilevsky wrote: > Package: games-finest > Version: 4 > Severity: wishlist > X-Debbugs-Cc: d...@vasilevsky.ca > > Hi, > > Thanks for all your work maintaining debian-games. > > It's been a few years since we've added anything new to games-finest, and I > think endless-sky would be a great choice. [...] endless-sky looks really good and seems to be a fun game. However there haven't been any Debian uploads from the maintainer in almost six years and several new versions of endless-sky have been released since then. If we can fix this situation, then I would include it in games-finest. At the moment that would be premature. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1035618: dreamchess: please remove artificial limit (15) on number of save slots
Control: forwarded -1 https://github.com/dreamchess/dreamchess/issues/58 Hello, On Sat, 06 May 2023 17:14:08 +0200 Lucio Crusca wrote: > Package: dreamchess > Version: 0.3.0-2 > Severity: wishlist > X-Debbugs-Cc: lu...@sulweb.org > > Dear Maintainer, > > I often find myself copying savegames in a new folder only to have > ~/.dreamchess empty to be able to save new games. I can't see any > compelling reason to limit the number of savegams to 15, so assuming > there actually isn't any, please remove the limit or at least raise it > to 100 or something way larger than 15. I agree that 15 appears to be a bit low. I have forwarded your request upstream. Since this request is not strictly related to Debian, it is better to discuss game play changes with the upstream developer of dreamchess. signature.asc Description: This is a digitally signed message part
Bug#1035372: unblock: wbar/2.3.4-13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package wbar [ Reason ] There is currently a dpkg unpack error when wbar is upgraded from Bullseye to Bookworm while the old wbar-config package is still installed. (#1035001) wbar-config has been removed from Debian. The error is caused by an old glade file, once needed by wbar-config but now installed into wbar itself. That was not intentional. Since the file is not needed, I have simply removed it from the package. [ Impact ] There will be a dpkg unpack error when upgrading wbar from Bullseye to Bookworm. [ Tests ] I have confirmed that the glade file has been removed from wbar. [ Risks ] None. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock wbar/2.3.4-13 diff -Nru wbar-2.3.4/debian/changelog wbar-2.3.4/debian/changelog --- wbar-2.3.4/debian/changelog 2022-08-23 00:05:18.0 +0200 +++ wbar-2.3.4/debian/changelog 2023-04-27 15:44:41.0 +0200 @@ -1,3 +1,11 @@ +wbar (2.3.4-13) unstable; urgency=medium + + * Do not install wbar.glade because it is not required and breaks wbar on +upgrade from Bullseye to Bookworm (leftover from the wbar-config removal). +Thanks to Helmut Grohne for the report. (Closes: #1035001) + + -- Markus Koschany Thu, 27 Apr 2023 15:44:41 +0200 + wbar (2.3.4-12) unstable; urgency=medium * Declare compliance with Debian Policy 4.6.1. diff -Nru wbar-2.3.4/debian/rules wbar-2.3.4/debian/rules --- wbar-2.3.4/debian/rules 2022-08-23 00:05:18.0 +0200 +++ wbar-2.3.4/debian/rules 2023-04-27 15:44:41.0 +0200 @@ -17,6 +17,7 @@ override_dh_install: $(RM) -r debian/wbar/etc/bash_completion.d $(RM) debian/wbar/etc/wbar.d/wbar.desktop + $(RM) -r debian/wbar/usr/share/wbar/glade/ dh_install override_dh_missing:
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#1034693: unblock: apache-curator/5.4.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package apache-curator [ Reason ] resteasy3.0 is most likely going to be removed from testing in the near future. (#1033366) This would affect apache-curator as well, which build-depends on libresteasy3.0-java. However, in fact this dependency is neither required to build the package or run any tests because the module curator-x-discovery-server has been disabled in apache-curator. [ Impact ] apache-curator would be autoremoved from testing eventually. [ Tests ] The package builds fine. The change had no effect on the package. Please note that I had to ignore test failures because some tests were unreliable and they made the package FTBFS randomly. See also #1031055. [ Risks ] None. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing Have a nice weekend Markus unblock apache-curator/5.4.0-3 diff -Nru apache-curator-5.4.0/debian/changelog apache-curator-5.4.0/debian/changelog --- apache-curator-5.4.0/debian/changelog 2022-11-19 23:01:18.0 +0100 +++ apache-curator-5.4.0/debian/changelog 2023-04-21 15:41:45.0 +0200 @@ -1,3 +1,13 @@ +apache-curator (5.4.0-3) unstable; urgency=medium + + * Team upload. + * maven.ignoreRules: Ignore resteasy-jaxrs artifact. + * Remove build-dependency on resteasy3.0. + * Ignore test failures because some tests are not 100 % reliable. +(Closes: #1031055) + + -- Markus Koschany Fri, 21 Apr 2023 15:41:45 +0200 + apache-curator (5.4.0-2) unstable; urgency=medium * Team upload diff -Nru apache-curator-5.4.0/debian/control apache-curator-5.4.0/debian/control --- apache-curator-5.4.0/debian/control 2022-11-19 23:00:40.0 +0100 +++ apache-curator-5.4.0/debian/control 2023-04-21 15:41:45.0 +0200 @@ -32,7 +32,6 @@ libmaven-bundle-plugin-java, libmaven-dependency-plugin-java, libmockito-java, - libresteasy3.0-java, libscannotation-java, libsnappy-java, libslf4j-java, diff -Nru apache-curator-5.4.0/debian/maven.ignoreRules apache-curator-5.4.0/debian/maven.ignoreRules --- apache-curator-5.4.0/debian/maven.ignoreRules 2022-06-27 22:08:50.0 +0200 +++ apache-curator-5.4.0/debian/maven.ignoreRules 2023-04-21 15:41:45.0 +0200 @@ -21,3 +21,5 @@ org.codehaus.mojo clirr-maven-plugin * * * * org.commonjava.maven.plugins directory-maven-plugin * * * * org.mortbay.jetty jetty * * * * +org.jboss.resteasy resteasy-jaxrs * * * * + diff -Nru apache-curator-5.4.0/debian/maven.properties apache-curator-5.4.0/debian/maven.properties --- apache-curator-5.4.0/debian/maven.properties1970-01-01 01:00:00.0 +0100 +++ apache-curator-5.4.0/debian/maven.properties2023-04-21 15:41:45.0 +0200 @@ -0,0 +1 @@ +maven.test.failure.ignore=true
Bug#1031055: apache-curator: FTBFS randomly (org.opentest4j.AssertionFailedError: expected: <1> but was: <0>)
I can reproduce the FTBFS here on my system. Apparently some of the tests are not 100 % reliable and reproducible. For now I will just disable them. Markus signature.asc Description: This is a digitally signed message part
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#1034196: unblock: openrefine/3.6.2-2
Hi Paul, Am Donnerstag, dem 20.04.2023 um 18:07 +0200 schrieb Paul Gevers: > [...] > > Since I already followed the Debian Policy and included the missing sources > > in > > debian/missing-sources, I felt that shipping the 3rdparty directory in > > debian/missing-sources/3rdparty would be a good intermediate solution. > > But you added a more files than you have in testing (including jquery.js). Yes, because 3.6.1 was the first version after 3.5.2 that removed those 3rdparty Javascript files. I noticed it after I had uploaded the package. I corrected this problem in 3.6.2-1. > > If you > > insist I can repack the tarball, add the 3rdparty directory and remove it > > from > > debian/missing-sources but in the end it would not make any difference. > > Huh? I wasn't asking you to do that. I was asking you to use packaged > binaries as a dependency. > > > Openrefine is a desktop application which only runs on your own computer. > > You know, now I know. Does the security team also know? Should they really? I am a member of the security team. It is on my radar. > > > If > > you insist I can depend on libjs-jquery and replace the local copy with a > > symlink but I feel this would be an example of over-engineering without any > > real value to our users in this specific case. > > That argument holds for a lot of things we do. What I try to say is that > there's a price we pay in our community too by not doing it. In this > case: tracking embedded versions. Because of the popularity of things > like jquery they are embedded a lot and we're trying to track them *and* > remove them. Just to clear, I wasn't *only* talking about jquery.js, but > also about the others that are covered by binaries in our archive. Even > if upstream added stuff back, I would still recommend you to link (and > depend on) the files shipped in e.g. libjs-jquery. I know what I talking > about, my upstream cacti ships a lot of embedded libraries too; I do my > best to remove things that we already ship in Debian. My upstream > complained once in a while that my versions are wrong; I still believe > it's the right thing to do in a distribution like Debian. I think they > are starting to see the value of our side too. > > Lintian is telling you that too: > https://udd.debian.org/lintian/?packages=openrefine As I had explained in my previous reply, there is no security impact. Cacti is a network application and can be accessed remotely by different parties. Instead openrefine is a privacy focused standalone application. Keeping your data on your own computer is a feature here. The security team would triage any Javascript CVE for openrefine as either unimportant or minor because openrefine is intended to be used for local and single person usage. Code deduplication is also not a problem, JS files are often small. On the other hand there is a huge downside for all those Javascript system libraries. Even minor changes may break existing applications, APIs are not stable, upstream is unable to help you if you diverge from their version. And then there is another point which is often neglected in Debian discussions: developer time. We waste too much time for over-optimizations and often neglect user experience and maintainability aspects. It seems we treat every computer language and every package as it was C only and try to use always the same hammer because everything looks like a nail. I believe it is important to differentiate from time to time. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034196: unblock: openrefine/3.6.2-2
Hello, Am Donnerstag, dem 20.04.2023 um 11:57 +0200 schrieb Paul Gevers: > Control: tags -1 moreinfo > > Hi, > > On Mon, 10 Apr 2023 23:55:44 +0200 Markus Koschany wrote: > > This unblock is related to #1034127 and the unblock of rhino. > > rhino is now unblocked. Thank you. > > > The main reason for > > upgrading from 3.6.1 to 3.6.2 was to include missing Javascript files > > which are needed to run the web / desktop application of openrefine. > > I *think* you are abusing missing-sources. Quoting policy [1]: > """ > Sometimes upstream does not include the source code for some files in > the upstream tarball. In order to satisfy the DFSG for packages in main > or contrib, you should either: > > repack the upstream tarball to include those sources; or > > include a copy of the sources in the debian/missing-sources directory. > """ > But you are *installing* those missing sources. In version 3.5.x upstream included all Javascript files in the original source tarball but also shipped some minified files without the unminified sources. I kindly asked them to change that. They then decided to remove third party Javascript files completely and download them separately with npm while building their own version of openrefine. I didn't have the chance to discuss this change with them yet and how they want to distribute those third party Javascript files in the future. Since I already followed the Debian Policy and included the missing sources in debian/missing-sources, I felt that shipping the 3rdparty directory in debian/missing-sources/3rdparty would be a good intermediate solution. If you insist I can repack the tarball, add the 3rdparty directory and remove it from debian/missing-sources but in the end it would not make any difference. The debdiff and the functionality would be the same. I feel such a change could be postponed for the next release cycle when I know upstream's thoughts. > On top of that, you are > shipping yet another copy of e.g. jquery.js [2]. Please, if remotely > possible, use bin:libjs-jquery (and similar for the other dependencies) > instead. Openrefine is a desktop application which only runs on your own computer. Openrefine is not affected by any possible security vulnerabilities in jquery or any other Javascript library hence why it is more beneficial to use a local copy that is closely integrated and tested with Openrefine. The risk of breaking the application whenever the system library changes is much higher. If you insist I can depend on libjs-jquery and replace the local copy with a symlink but I feel this would be an example of over-engineering without any real value to our users in this specific case. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034492: libtcnative-1: Tomcat warning suggesting a minimum version of 2.0.1 for tcnative
Hello, Am Sonntag, dem 16.04.2023 um 16:15 -0400 schrieb Jorge Moraleda: > Package: libtcnative-1 > Version: 1.2.35-1 > Severity: normal > X-Debbugs-Cc: jorge.moral...@gmail.com > > Dear Maintainer, > > When running tomcat 10 (installed from default bookworm repo) it warns that > "An > older version [1.2.35] of the Apache Tomcat Native library is installed, > while > Tomcat recommends a minimum version of [2.0.1]" > > I feel debian should package a version of tc-native equals or newer than the > recommendation of the packaged tomcat version. This is something we aim for in Debian 13. For now 1.2.35 should work just fine despite the warning. > > I wonder if we tomcat 9 still requires version 1.x of tcnative, which means > debian should package both libtcnative-1 and a libtcnative-2, or if the > latest > tcnative 2 would suffice for both tomcat 9 and tomcat 10, and then we might > want to drop the 1 in the tcnative package name and just package the latest > 2.x > version under that name. We will remove Tomcat 9 in the near future because we can support only one version. I guess we can rename libtcnative-1 to just libtcnative instead of creating a new libtcnative-2 package. I'm sure we will make a decision after the freeze. Markus signature.asc Description: This is a digitally signed message part
Bug#1034194: unblock: closure-compiler/20130227+dfsg1-13
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org
Please unblock package closure-compiler
[ Reason ]
This is related to #1034127 and the unblock request of rhino 1.7.14.
If we ship rhino 1.7.14 in Bookworm, then closure-compiler should be
unblocked too to fix a FTBFS.
[ Impact ]
If rhino is unblocked but closure-compiler is not, then the package in
testing will FTBFS.
[ Tests ]
closure-compiler builds fine now and works as expected.
[ Risks ]
closure-compiler is used to minify/optimize Javascript files and this
still seems to work.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock closure-compiler/20130227+dfsg1-13
diff -Nru closure-compiler-20130227+dfsg1/debian/changelog
closure-compiler-20130227+dfsg1/debian/changelog
--- closure-compiler-20130227+dfsg1/debian/changelog2022-11-19
09:00:34.0 +0100
+++ closure-compiler-20130227+dfsg1/debian/changelog2023-02-14
00:18:02.0 +0100
@@ -1,3 +1,12 @@
+closure-compiler (20130227+dfsg1-13) unstable; urgency=medium
+
+ * QA upload.
+ * Tighten dependency on librhino-java to >= 1.7.14.
+ * Fix FTBFS with rhino 1.7.14.
+ * Use canonical VCS URI.
+
+ -- Markus Koschany Tue, 14 Feb 2023 00:18:02 +0100
+
closure-compiler (20130227+dfsg1-12) unstable; urgency=medium
* QA upload.
diff -Nru closure-compiler-20130227+dfsg1/debian/control
closure-compiler-20130227+dfsg1/debian/control
--- closure-compiler-20130227+dfsg1/debian/control 2022-11-19
09:00:34.0 +0100
+++ closure-compiler-20130227+dfsg1/debian/control 2023-02-14
00:18:02.0 +0100
@@ -12,7 +12,7 @@
libargs4j-java,
libguava-java (>= 15.0),
libjsr305-java,
-librhino-java (>= 1.7R4),
+librhino-java (>= 1.7.14),
ant,
libjarjar-java,
protobuf-compiler,
@@ -20,8 +20,8 @@
javahelper (>= 0.25)
Build-Depends-Indep: default-jdk-doc, libmaven-javadoc-plugin-java
Standards-Version: 4.1.0
-Vcs-Git: https://anonscm.debian.org/git/pkg-java/closure-compiler.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-java/closure-compiler.git
+Vcs-Git: https://salsa.debian.org/java-team/closure-compiler.git
+Vcs-Browser: https://salsa.debian.org/java-team/closure-compiler
Homepage: https://developers.google.com/closure/compiler/
Package: closure-compiler
diff -Nru
closure-compiler-20130227+dfsg1/debian/patches/fix-librhino-java-FTBFS.patch
closure-compiler-20130227+dfsg1/debian/patches/fix-librhino-java-FTBFS.patch
---
closure-compiler-20130227+dfsg1/debian/patches/fix-librhino-java-FTBFS.patch
1970-01-01 01:00:00.0 +0100
+++
closure-compiler-20130227+dfsg1/debian/patches/fix-librhino-java-FTBFS.patch
2023-02-14 00:18:02.0 +0100
@@ -0,0 +1,65 @@
+From: Markus Koschany
+Date: Tue, 14 Feb 2023 00:06:12 +0100
+Subject: fix librhino-java FTBFS
+
+Fix FTBFS with rhino 1.7.14.
+
+Forwarded: not-needed
+---
+ src/com/google/javascript/jscomp/parsing/IRFactory.java | 4 ++--
+ src/com/google/javascript/jscomp/parsing/TypeSafeDispatcher.java | 6 +++---
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/src/com/google/javascript/jscomp/parsing/IRFactory.java
b/src/com/google/javascript/jscomp/parsing/IRFactory.java
+index 361f31d..0e34a4d 100644
+--- a/src/com/google/javascript/jscomp/parsing/IRFactory.java
b/src/com/google/javascript/jscomp/parsing/IRFactory.java
+@@ -65,7 +65,7 @@ import com.google.javascript.rhino.head.ast.SwitchCase;
+ import com.google.javascript.rhino.head.ast.SwitchStatement;
+ import com.google.javascript.rhino.head.ast.ThrowStatement;
+ import com.google.javascript.rhino.head.ast.TryStatement;
+-import com.google.javascript.rhino.head.ast.UnaryExpression;
++import com.google.javascript.rhino.head.ast.UpdateExpression;
+ import com.google.javascript.rhino.head.ast.VariableDeclaration;
+ import com.google.javascript.rhino.head.ast.VariableInitializer;
+ import com.google.javascript.rhino.head.ast.WhileLoop;
+@@ -1145,7 +1145,7 @@ class IRFactory {
+ }
+
+ @Override
+-Node processUnaryExpression(UnaryExpression exprNode) {
++Node processUpdateExpression(UpdateExpression exprNode) {
+ int type = transformTokenType(exprNode.getType());
+ Node operand = transform(exprNode.getOperand());
+ if (type == Token.NEG && operand.isNumber()) {
+diff --git a/src/com/google/javascript/jscomp/parsing/TypeSafeDispatcher.java
b/src/com/google/javascript/jscomp/parsing/TypeSafeDispatcher.java
+index 95aaacd..fc6ace3 100644
+--- a/src/com/google/javascript/jscomp/parsing/TypeSafeDispatcher.java
b/src/com/google/javascript/jscomp/parsing/TypeSafeDispatcher.java
+@@ -55,7 +55,7 @@ import com.google.javascript.rhino.head.ast.SwitchCase;
+ import com.google.javascript.rhino.h
Bug#1034127: unblock: rhino/1.7.14-2.1
Am Sonntag, dem 09.04.2023 um 22:28 +0200 schrieb Paul Gevers: > > [ Risks ] > This is a new upstream release. This is not a small change. And while > typing this unblock request, I'm getting uncomfortable and wonder if > we want this. But as it's all prepared, let's discuss and pull Markus > in to elaborate a bit too. I am in favor of shipping rhino 1.7.14 in Bookworm for all the reasons Paul has mentioned. I believe at this point in the release cycle we don't want to make arbitrary changes but we also want to deliver the best possible software package to our users. I'm not confident to find a different fix to address #1026639 and the broken web application in openrefine. It clearly works with 1.7.14 but not with the current version in testing. Since I only had to patch one reverse-dependency, the orphaned package closure-compiler, and everything else appears to work as expected, I believe the risks are very manageable. Worst case would be to rebuild another package. We also get the latest upstream version and don't have to ship a six year old version again. Markus signature.asc Description: This is a digitally signed message part
Bug#1034099: unblock: zstd-jni-java/1.5.2-5+ds-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package zstd-jni-java [ Reason ] zstd-jni-java FTBFS on buildd when built as binary-arch only. #1034059 [ Impact ] FTBFS during binary-arch build [ Tests ] Manually tested. Works as expected now. [ Risks ] None. [ Checklist ] [*] all changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in testing unblock zstd-jni-java/1.5.2-5+ds-3 diff -Nru zstd-jni-java-1.5.2-5+ds/debian/changelog zstd-jni-java-1.5.2-5+ds/debian/changelog --- zstd-jni-java-1.5.2-5+ds/debian/changelog 2022-11-12 21:54:22.0 +0100 +++ zstd-jni-java-1.5.2-5+ds/debian/changelog 2023-04-08 22:46:57.0 +0200 @@ -1,3 +1,12 @@ +zstd-jni-java (1.5.2-5+ds-3) unstable; urgency=medium + + * Team upload. + * Depend on maven-resources-plugin 3.3.0 and maven-compiler-plugin 3.10.1. +Fixes FTBFS when building zstd-jni-java for binary-arch only. +Thanks to Andreas Beckmann for the report. (Closes: #1034059) + + -- Markus Koschany Sat, 08 Apr 2023 22:46:57 +0200 + zstd-jni-java (1.5.2-5+ds-2) unstable; urgency=high * Prevent duplicate Java files install into arch-dependent package diff -Nru zstd-jni-java-1.5.2-5+ds/debian/patches/modify_pom.patch zstd-jni-java-1.5.2-5+ds/debian/patches/modify_pom.patch --- zstd-jni-java-1.5.2-5+ds/debian/patches/modify_pom.patch2022-10-26 03:47:40.0 +0200 +++ zstd-jni-java-1.5.2-5+ds/debian/patches/modify_pom.patch2023-04-08 22:46:57.0 +0200 @@ -28,7 +28,7 @@ + + org.apache.maven.plugins + maven-compiler-plugin -+ 3.8.1 ++ 3.10.1 + +1.8 +1.8 @@ -46,7 +46,7 @@ + + org.apache.maven.plugins + maven-resources-plugin -+ 3.1.0 ++ 3.3.0 + + + org.apache.maven.plugins
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#1033993: bullseye-pu: package unbound/1.13.1-1
diff -Nru unbound-1.13.1/debian/changelog unbound-1.13.1/debian/changelog --- unbound-1.13.1/debian/changelog 2021-02-09 23:53:57.0 +0100 +++ unbound-1.13.1/debian/changelog 2023-04-05 23:06:47.0 +0200 @@ -1,3 +1,41 @@ +unbound (1.13.1-1+deb11u1) bullseye; urgency=high + + * Non-maintainer upload by the LTS team. + * Fix the following security vulnerabilities. +CVE-2022-3204: +A vulnerability named 'Non-Responsive Delegation Attack' (NRDelegation +Attack) has been discovered in various DNS resolving software. The +NRDelegation Attack works by having a malicious delegation with a +considerable number of non responsive nameservers. The attack starts by +querying a resolver for a record that relies on those unresponsive +nameservers. The attack can cause a resolver to spend a lot of +time/resources resolving records under a malicious delegation point where a +considerable number of unresponsive NS records reside. It can trigger high +CPU usage in some resolver implementations that continually look in the +cache for resolved NS records in that delegation. This can lead to degraded +performance and eventually denial of service in orchestrated attacks. +Unbound does not suffer from high CPU usage, but resources are still needed +for resolving the malicious delegation. Unbound will keep trying to resolve +the record until hard limits are reached. Based on the nature of the attack +and the replies, different limits could be reached. From now on Unbound +introduces fixes for better performance when under load, by cutting +opportunistic queries for nameserver discovery and DNSKEY prefetching and +limiting the number of times a delegation point can issue a cache lookup +for missing records. + * CVE-2022-30698 and CVE-2022-30699: (Closes: #1016493) +Unbound is vulnerable to a novel type of the "ghost domain names" attack. +The vulnerability works by targeting an Unbound instance. Unbound is +queried for a rogue domain name when the cached delegation information is +about to expire. The rogue nameserver delays the response so that the +cached delegation information is expired. Upon receiving the delayed answer +containing the delegation information, Unbound overwrites the now expired +entries. This action can be repeated when the delegation information is +about to expire making the rogue delegation information ever-updating. From +now on Unbound stores the start time for a query and uses that to decide if +the cached delegation information can be overwritten. + + -- Markus Koschany Wed, 05 Apr 2023 23:06:47 +0200 + unbound (1.13.1-1) unstable; urgency=medium * New upstream version 1.13.1 diff -Nru unbound-1.13.1/debian/patches/CVE-2022-30698-and-CVE-2022-30699.patch unbound-1.13.1/debian/patches/CVE-2022-30698-and-CVE-2022-30699.patch --- unbound-1.13.1/debian/patches/CVE-2022-30698-and-CVE-2022-30699.patch 1970-01-01 01:00:00.0 +0100 +++ unbound-1.13.1/debian/patches/CVE-2022-30698-and-CVE-2022-30699.patch 2023-04-05 23:06:47.0 +0200 @@ -0,0 +1,612 @@ +From: Markus Koschany +Date: Wed, 5 Apr 2023 13:03:57 +0200 +Subject: CVE-2022-30698 and CVE-2022-30699 + +Origin: https://github.com/NLnetLabs/unbound/commit/f6753a0f1018133df552347a199e0362fc1dac68 +--- + cachedb/cachedb.c | 2 +- + daemon/cachedump.c| 5 +- + daemon/worker.c | 2 +- + dns64/dns64.c | 4 +- + ipsecmod/ipsecmod.c | 2 +- + iterator/iter_utils.c | 4 +- + iterator/iter_utils.h | 2 +- + iterator/iterator.c | 19 --- + pythonmod/interface.i | 5 +- + pythonmod/pythonmod_utils.c | 3 +- + services/cache/dns.c | 111 -- + services/cache/dns.h | 18 +-- + services/mesh.c | 1 + + testdata/iter_prefetch_change.rpl | 16 +++--- + util/module.h | 6 +++ + validator/validator.c | 4 +- + 16 files changed, 156 insertions(+), 48 deletions(-) + +diff --git a/cachedb/cachedb.c b/cachedb/cachedb.c +index e948a6b..b6b2b92 100644 +--- a/cachedb/cachedb.c b/cachedb/cachedb.c +@@ -656,7 +656,7 @@ cachedb_intcache_store(struct module_qstate* qstate) + return; + (void)dns_cache_store(qstate->env, >qinfo, + qstate->return_msg->rep, 0, qstate->prefetch_leeway, 0, +- qstate->region, store_flags); ++ qstate->region, store_flags, qstate->qstarttime); + } + + /** +diff --git a/daemon/cachedump.c b/daemon/cachedump.c +index b1ce53b..908d2f9 100644 +--- a/daemon/cachedump.c b/daemon/cachedump.c +@@ -677,7 +677,8 @@ load_msg(RES* ssl, sldns_buffer* buf, struct worker* worker) + if(!go_on) + return 1; /* skip this one, not all references satisfied */ + +- if(!dns_cache_st
Bug#1033993: bullseye-pu: package unbound/1.13.1-1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: a...@debian.org Hello, I would like to update unbound in Bullseye and fix three no-dsa CVE, namely CVE-2022-3204, CVE-2022-30698 and CVE-2022-30699. The same patches have been successfully applied to older distributions and I want to make sure these CVE are fixed in Bullseye too. [ Impact ] Bullseye would still be vulnerable. [ Tests ] I have tested unbound myself on all current Debian releases and found no issues. [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in (old)stable [*] the issue is verified as fixed in unstable [ Changes ] Applied two patches to address the CVE.
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#1031816: [Pkg-freeipa-devel] Bug#1031816: tomcatjss: Migrate to Tomcat 10
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. Regards, Markus 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#1031817: i2p: Migrate to Tomcat 10
Control: severity -1 serious On Thu, 23 Feb 2023 12:33:35 +0100 Emmanuel Bourg wrote: > Source: i2p > Version: 0.9.48-1.1 > Severity: important > > i2p depends on libtomcat9-java but this package is going to be removed. > Please use libtomcat10-java instead. This is actually release-critical. I tried to replace the javax.servlet imports with jakarta.servlet but there are significant changes and it is not just find and replace. It seems there have been several new upstream releases in the past (#983410) and other bug reports have been ignored too (#1024461, #1027972) I would rather suggest to remove i2p from testing for now because of that. If someone wants to give it a try as well, then just replace libtomcat9-java with libtomcat10-java in debian/control and apply the tomcat10-migration.patch to get you started. From: Markus Koschany Date: Sun, 5 Mar 2023 17:40:15 +0100 Subject: tomcat10 migration --- apps/jetty/build.xml | 1 + build.xml| 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/apps/jetty/build.xml b/apps/jetty/build.xml index bb01643..d220dc4 100644 --- a/apps/jetty/build.xml +++ b/apps/jetty/build.xml @@ -268,6 +268,7 @@ + diff --git a/build.xml b/build.xml index 84651fe..9814ceb 100644 --- a/build.xml +++ b/build.xml @@ -12,7 +12,7 @@ - + signature.asc Description: This is a digitally signed message part
Bug#1033364: unblock: logback/1:1.2.11-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package logback [ Reason ] We can only support one Tomcat web server per release. Hence we have to replace libtomcat9-java with libtomcat10-java. [ Impact ] There would be two versions of Tomcat in Debian 12 which would need security support. [ Tests ] I have rebuilt all reverse-dependencies successfully. Tomcat support is only optional ( thus the dependency is only suggested) The change was merely replacing the import of javax.servlet.* with jakarta.servlet.* [ Risks ] logback is a key package and the benefits outweigh the risks by far. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock logback/1:1.2.11-2 diff -Nru logback-1.2.11/debian/changelog logback-1.2.11/debian/changelog --- logback-1.2.11/debian/changelog 2022-03-23 04:36:14.0 +0100 +++ logback-1.2.11/debian/changelog 2023-03-05 01:43:23.0 +0100 @@ -1,3 +1,11 @@ +logback (1:1.2.11-2) unstable; urgency=medium + + * Team upload. + * Migrate to Tomcat 10. Depend on libtomcat10-java instead of tomcat9-java. +Add tomcat10-migration.patch. + + -- Markus Koschany Sun, 05 Mar 2023 01:43:23 +0100 + logback (1:1.2.11-1) unstable; urgency=medium * New upstream version 1.2.11 diff -Nru logback-1.2.11/debian/control logback-1.2.11/debian/control --- logback-1.2.11/debian/control 2022-03-23 04:36:14.0 +0100 +++ logback-1.2.11/debian/control 2023-03-05 01:43:23.0 +0100 @@ -17,7 +17,7 @@ libmaven-javadoc-plugin-java, libservlet-api-java, libslf4j-java (>= 1.7.18), - libtomcat9-java, + libtomcat10-java, maven-debian-helper Standards-Version: 4.6.0 Vcs-Git: https://salsa.debian.org/java-team/logback.git diff -Nru logback-1.2.11/debian/maven.properties logback-1.2.11/debian/maven.properties --- logback-1.2.11/debian/maven.properties 2022-03-23 04:36:14.0 +0100 +++ logback-1.2.11/debian/maven.properties 2023-03-05 01:43:23.0 +0100 @@ -3,3 +3,5 @@ # maven.test.skip=true maven.test.skip=true +maven.compiler.source=1.8 +maven.compiler.target=1.8 diff -Nru logback-1.2.11/debian/maven.rules logback-1.2.11/debian/maven.rules --- logback-1.2.11/debian/maven.rules 2022-03-23 04:36:14.0 +0100 +++ logback-1.2.11/debian/maven.rules 2023-03-05 01:43:23.0 +0100 @@ -1,5 +1,5 @@ junit junit jar s/4\..*/4.x/ javax.mail s/mail/javax.mail-api * s/.*/debian/ * * -org.apache.tomcat tomcat-catalina * s/.*/9.x/ -org.apache.tomcat tomcat-coyote * s/.*/9.x/ +org.apache.tomcat tomcat-catalina * s/.*/10.x/ +org.apache.tomcat tomcat-coyote * s/.*/10.x/ org.eclipse.jetty jetty-server * s/.*/9.x/ diff -Nru logback-1.2.11/debian/patches/series logback-1.2.11/debian/patches/series --- logback-1.2.11/debian/patches/series2022-03-23 04:36:14.0 +0100 +++ logback-1.2.11/debian/patches/series2023-03-05 01:43:23.0 +0100 @@ -2,3 +2,4 @@ 04-privacy-breach.patch 05-java11-compatibility.patch 06-jetty-compatibility.patch +tomcat10-migration.patch diff -Nru logback-1.2.11/debian/patches/tomcat10-migration.patch logback-1.2.11/debian/patches/tomcat10-migration.patch --- logback-1.2.11/debian/patches/tomcat10-migration.patch 1970-01-01 01:00:00.0 +0100 +++ logback-1.2.11/debian/patches/tomcat10-migration.patch 2023-03-05 01:43:23.0 +0100 @@ -0,0 +1,593 @@ +From: Markus Koschany +Date: Sat, 4 Mar 2023 19:43:08 +0100 +Subject: tomcat10 migration + +Forwarded: not-needed +--- + logback-access/pom.xml | 3 +-- + .../ch/qos/logback/access/ViewStatusMessagesServlet.java | 6 +++--- + .../java/ch/qos/logback/access/jetty/RequestLogImpl.java | 3 ++- + .../java/ch/qos/logback/access/servlet/TeeFilter.java| 16 + .../logback/access/servlet/TeeHttpServletRequest.java| 6 +++--- + .../logback/access/servlet/TeeHttpServletResponse.java | 6 +++--- + .../logback/access/servlet/TeeServletInputStream.java| 6 +++--- + .../logback/access/servlet/TeeServletOutputStream.java | 6 +++--- + .../main/java/ch/qos/logback/access/servlet/Util.java| 4 ++-- + .../logback/access/sift/AccessEventDiscriminator.java| 4 ++-- + .../main/java/ch/qos/logback/access/spi/AccessEvent.java | 8 + .../java/ch/qos/logback/access/spi/IAccessEvent.java | 4 ++-- + .../java/ch/qos/logback/access/tomcat/LogbackValve.java | 4 ++-- + .../java/ch/qos/logback/access/dummy/DummyRequest.java | 4 ++-- + .../java/ch/qos/logback/access/dummy/DummyResponse.java | 6 +++--- + .../logback/access/dummy/DummyServletOutputStream.java | 4 ++-- + .../ch/qos/logback/access/jetty/JettyFixtureBase.java| 6 +++--- + .../ch/qos/logback/access/pattern/ConverterTest.java | 2 +- + logb
Bug#1033363: unblock: xarchiver/1:0.5.4.20-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org
Please unblock package xarchiver
[ Reason ]
Fix detection of zstd version 1.5.4 and later (#1032591)
[ Impact ]
Xarchiver won't be able to detect and decompress zstd archives.
[ Tests ]
Manual decompression of zstd archives with xarchiver works as expected
now.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock xarchiver/1:0.5.4.20-2
diff -Nru xarchiver-0.5.4.20/debian/changelog
xarchiver-0.5.4.20/debian/changelog
--- xarchiver-0.5.4.20/debian/changelog 2022-11-12 14:36:12.0 +0100
+++ xarchiver-0.5.4.20/debian/changelog 2023-03-12 12:48:14.0 +0100
@@ -1,3 +1,9 @@
+xarchiver (1:0.5.4.20-2) unstable; urgency=medium
+
+ * Fix detection of zstd version 1.5.4 and later. (Closes: #1032591)
+
+ -- Markus Koschany Sun, 12 Mar 2023 12:48:14 +0100
+
xarchiver (1:0.5.4.20-1) unstable; urgency=medium
* New upstream version 0.5.4.20.
diff -Nru xarchiver-0.5.4.20/debian/patches/fix-detection-of-zstd.patch
xarchiver-0.5.4.20/debian/patches/fix-detection-of-zstd.patch
--- xarchiver-0.5.4.20/debian/patches/fix-detection-of-zstd.patch
1970-01-01 01:00:00.0 +0100
+++ xarchiver-0.5.4.20/debian/patches/fix-detection-of-zstd.patch
2023-03-12 12:48:14.0 +0100
@@ -0,0 +1,79 @@
+From: Markus Koschany
+Date: Sun, 12 Mar 2023 12:40:42 +0100
+Subject: fix detection of zstd
+
+Bug-Debian: https://bugs.debian.org/1032591
+Origin:
https://github.com/ib/xarchiver/commit/a298cf82391e4b447e702d7e51078554253b1b8d
+---
+ src/gzip_et_al.c | 44 +++-
+ 1 file changed, 39 insertions(+), 5 deletions(-)
+
+diff --git a/src/gzip_et_al.c b/src/gzip_et_al.c
+index 650d24a..c862b60 100644
+--- a/src/gzip_et_al.c
b/src/gzip_et_al.c
+@@ -67,6 +67,40 @@ void xa_gzip_et_al_check_lrzip (const gchar *path)
+ g_free(output);
+ }
+
++static gboolean xa_gzip_et_al_zstd_option (const gchar *output, const gchar
*option)
++{
++ const gchar *nl, *delim;
++ size_t op;
++
++ if (!output)
++ return FALSE;
++
++ nl = output;
++ op = strlen(option);
++
++ while ((nl = strchr(nl, '\n')))
++ {
++ nl++;
++
++ /* skip multiple leading spaces added since v1.5.4 */
++ while (*nl && (*nl == ' '))
++ nl++;
++
++ if (!*nl)
++ break;
++
++ if (strncmp(nl, option, op) == 0)
++ {
++ delim = nl + op;
++
++ if (*delim && (*delim == ' ' || (*delim == ',' &&
*++delim == ' ')))
++ return TRUE;
++ }
++ }
++
++ return FALSE;
++}
++
+ gchar *xa_gzip_et_al_check_zstd (const gchar *compressor, const gchar
*decompressor, gboolean *is_compressor)
+ {
+ gchar *path, *command, *output = NULL;
+@@ -82,18 +116,18 @@ gchar *xa_gzip_et_al_check_zstd (const gchar *compressor,
const gchar *decompres
+ if (!path)
+ return NULL;
+
+- command = g_strconcat(path, " -h", NULL);
++ command = g_strconcat(path, " -H", NULL);
+ g_spawn_command_line_sync(command, , NULL, NULL, NULL);
+ g_free(command);
+
+ /* check whether decompression is available */
+- if (output && strstr(output, "\n -d "))
++ if (xa_gzip_et_al_zstd_option(output, "-d"))
+ {
+ if (found_compressor)
+- *is_compressor = (strstr(output, "\n -# ") != NULL);
++ *is_compressor = xa_gzip_et_al_zstd_option(output,
"-#");
+
+- zstd_can_list = (strstr(output, "\n -l ") || strstr(output,
"\n--list "));
+- zstd_can_test = (strstr(output, "\n -t ") || strstr(output,
"\n--test "));
++ zstd_can_list = xa_gzip_et_al_zstd_option(output, "-l");
++ zstd_can_test = (xa_gzip_et_al_zstd_option(output, "--test") ||
/* check short test option just in case */ xa_gzip_et_al_zstd_option(output,
"-t"));
+ }
+ else // useless
+ {
diff -Nru xarchiver-0.5.4.20/debian/patches/series
xarchiver-0.5.4.20/debian/patches/series
--- xarchiver-0.5.4.20/debian/patches/series1970-01-01 01:00:00.0
+0100
+++ xarchiver-0.5.4.20/debian/patches/series2023-03-12 12:48:14.0
+0100
@@ -0,0 +1 @@
+fix-detection-of-zstd.patch
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#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
Control: reopen -1 Control: severity -1 serious Hello Robert, Am Donnerstag, dem 23.03.2023 um 10:41 +0100 schrieb Robert Jäschke: > Dear Markus, > > I found the problem: the package misses a dependency to libjoda-time-java. thank you for debugging this problem. I will prepare an update for Bookworm soon. Best, Markus signature.asc Description: This is a digitally signed message part
Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
Hi Robert, > > Sorry, I forgot to add this: > > > dpkg -l | grep rhino > ii librhino-java 1.7.14-2 > ii rhino 1.7.14-2 > > I've upgraded (lib)rhino after reading the bug report but this did not help. > > Is there a way to debug Openrefine? I tried both -v debug and -v trace > but did not get more output (Maybe I have to configure log4j properly as > the warning suggests?) I can't reproduce a 404 error at the moment. OpenRefine works as expected for me. Unfortunately it is not easy to debug openrefine because there is a separate Javascript based web application and the server module based on Java. The former can only be debugged via Chrome or Firefox console. I'm not sure how useful the log messages would be. I agree that there is currently a problem with configuring SLF4j and this is something which should work out-of-the-box. A 404 error indicates a web server (Jetty in this case) problem or a missing file but I don't know how this could help right now. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
Am Freitag, dem 17.03.2023 um 12:38 +0100 schrieb Robert Jäschke: > Package: openrefine > Version: 3.6.2-1 > Followup-For: Bug #1022760 > X-Debbugs-Cc: jaesc...@l3s.de > > Dear Maintainer, > > I experience the exact same problem with the latest version, that is, > starting openrefine and opening http://localhost: results in a 404. I presume you don't have librhino-java >= 1.7.14 installed on your system because your apt policy prefers testing over unstable. signature.asc Description: This is a digitally signed message part
Bug#1032591: xarchive error when open or unpack .zst files
Thanks for the report. The bug will be fixed soon. 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#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Control: reassign -1 shrinksafe Control: severity -1 serious Hi, I uploaded a new version of rhino a while ago and it seems this bug is still relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass. However the same tests fail with autopkgtest and block the migration of rhino to testing. Could you take a look at that please? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1031635: bullseye-pu: package snakeyaml/1.28-1
Hi, Am Freitag, dem 24.02.2023 um 16:01 +0100 schrieb Moritz Mühlenhoff: [...] > Could we also ship the README.Debian.security that was recently added > in unstable to bullseye/buster? I've just uploaded a new revision of snakeyaml, 1.28.1+deb11u2. This one includes the README file. There have been no further changes to my previous upload. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#962695: iftop resolves all IPv6 addresse to the same hostname
Am Freitag, dem 24.02.2023 um 21:42 +0100 schrieb Romain Francoise: > On Fri, Jun 12, 2020 at 12:31:14PM +0300, Harald Hannelius wrote: > > When running iftop on a server with serveral IPv6-connections ongoing, > > iftop seems to resolve the ip-addresses to the same hostname. This is a > > bit confusing. By pressing 'n' to get numerical output everything looks > > correct. > > Yes, this is very annoying. It looks like this might have been fixed by > this upstream commit: > https://code.blinkace.com/pdw/iftop/-/commit/35af3cf65f17961d173b31fd3b00166ec095c226 > > If so, can we have it in a new upload targeted at bookworm? Sure, if it helps. signature.asc Description: This is a digitally signed message part
Bug#1031840: geogebra: FTBFS with librhino-java
Package: geogebra Version: 4.0.34.0+dfsg1-9 Severity: important X-Debbugs-Cc: a...@debian.org Hi, the Debian Java team currently "fixes" a FTBFS in geogebra by applying this patch in src:rhino. https://salsa.debian.org/java-team/rhino/-/blob/master/debian/patches/public_getSourcePositionFromStack.patch However this should be addressed in geogebra instead. We can't support old API forever. Regards, Markus
Bug#991408: Netbeans: source code problem
Am Montag, dem 20.02.2023 um 12:41 -0300 schrieb Leandro Cunha: > Hi Markus, > > I have no interest in keeping Netbeans on Debian, but when I mention > consistency (according to the dictionary: state or quality of what is > coherent), it would be consistent with the reality that would be > represented in the tracker and on package.debian.org that the package > was removed from repository and if I give apt install netbeans it > would not be found. The same as with other packages follows the Debian > Developer Reference [1]. apt install netbeans will do nothing. The binary package has been removed from Debian. The Netbeans source package has always produced libnb-absolutelayout- java. There is no inconsistency. You either don't understand the difference between a source and a binary package or you are deliberately annoying. In any case I won't reply to this bug report anymore. signature.asc Description: This is a digitally signed message part
Bug#1031635: bullseye-pu: package snakeyaml/1.28-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
Hi,
I would like to update snakeyaml in Bullseye. The package is currently
affected by various potential (no-dsa) security vulnerabilities. Those have
been fixed in Buster, Bookworm and Sid already. Please find attached
the debdiff.
Regards,
Markus
diff -Nru snakeyaml-1.28/debian/changelog snakeyaml-1.28/debian/changelog
--- snakeyaml-1.28/debian/changelog 2021-02-28 22:49:25.0 +0100
+++ snakeyaml-1.28/debian/changelog 2023-02-19 17:05:00.0 +0100
@@ -1,3 +1,13 @@
+snakeyaml (1.28-1+deb11u1) bullseye; urgency=medium
+
+ * Team upload.
+Fix CVE-2022-25857, CVE-2022-38749, CVE-2022-38750 and CVE-2022-38751.
+Several security vulnerabilities have been discovered in SnakeYaml, a YAML
+parser for Java, which could facilitate a denial of service attack whenever
+maliciously crafted input files are processed by SnakeYaml.
+
+ -- Markus Koschany Sun, 19 Feb 2023 17:05:00 +0100
+
snakeyaml (1.28-1) unstable; urgency=medium
* Team upload.
diff -Nru snakeyaml-1.28/debian/patches/CVE-2022-25857.patch
snakeyaml-1.28/debian/patches/CVE-2022-25857.patch
--- snakeyaml-1.28/debian/patches/CVE-2022-25857.patch 1970-01-01
01:00:00.0 +0100
+++ snakeyaml-1.28/debian/patches/CVE-2022-25857.patch 2023-02-19
17:05:00.0 +0100
@@ -0,0 +1,173 @@
+From: Markus Koschany
+Date: Sun, 19 Feb 2023 16:57:20 +0100
+Subject: CVE-2022-25857
+
+This is also the fix for CVE-2022-38749.
+
+Bug-Debian: https://bugs.debian.org/1019218
+Origin:
https://github.com/snakeyaml/snakeyaml/commit/fc300780da21f4bb92c148bc90257201220cf174
+---
+ .../java/org/yaml/snakeyaml/LoaderOptions.java | 15 +
+ .../java/org/yaml/snakeyaml/composer/Composer.java | 28
+ .../issues/issue525/FuzzyStackOverflowTest.java| 39 ++
+ .../resources/fuzzer/YamlFuzzer-4626423186325504 | 1 +
+ 4 files changed, 83 insertions(+)
+ create mode 100644
src/test/java/org/yaml/snakeyaml/issues/issue525/FuzzyStackOverflowTest.java
+ create mode 100644 src/test/resources/fuzzer/YamlFuzzer-4626423186325504
+
+diff --git a/src/main/java/org/yaml/snakeyaml/LoaderOptions.java
b/src/main/java/org/yaml/snakeyaml/LoaderOptions.java
+index b45780b..b62daed 100644
+--- a/src/main/java/org/yaml/snakeyaml/LoaderOptions.java
b/src/main/java/org/yaml/snakeyaml/LoaderOptions.java
+@@ -23,6 +23,7 @@ public class LoaderOptions {
+ private boolean allowRecursiveKeys = false;
+ private boolean processComments = false;
+ private boolean enumCaseSensitive = true;
++private int nestingDepthLimit = 50;
+
+ public boolean isAllowDuplicateKeys() {
+ return allowDuplicateKeys;
+@@ -114,4 +115,18 @@ public class LoaderOptions {
+ public void setEnumCaseSensitive(boolean enumCaseSensitive) {
+ this.enumCaseSensitive = enumCaseSensitive;
+ }
++
++public int getNestingDepthLimit() {
++return nestingDepthLimit;
++}
++
++/**
++ * Set max depth of nested collections. When the limit is exceeded an
exception is thrown.
++ * Aliases/Anchors are not counted.
++ * This is to prevent a DoS attack
++ * @param nestingDepthLimit - depth to be accepted (50 by default)
++ */
++public void setNestingDepthLimit(int nestingDepthLimit) {
++this.nestingDepthLimit = nestingDepthLimit;
++}
+ }
+diff --git a/src/main/java/org/yaml/snakeyaml/composer/Composer.java
b/src/main/java/org/yaml/snakeyaml/composer/Composer.java
+index 2135d84..35f20c3 100644
+--- a/src/main/java/org/yaml/snakeyaml/composer/Composer.java
b/src/main/java/org/yaml/snakeyaml/composer/Composer.java
+@@ -45,6 +45,7 @@ import org.yaml.snakeyaml.nodes.SequenceNode;
+ import org.yaml.snakeyaml.nodes.Tag;
+ import org.yaml.snakeyaml.parser.Parser;
+ import org.yaml.snakeyaml.resolver.Resolver;
++import org.yaml.snakeyaml.error.YAMLException;
+
+ /**
+ * Creates a node graph from parser events.
+@@ -62,6 +63,9 @@ public class Composer {
+ private final LoaderOptions loadingConfig;
+ private final CommentEventsCollector blockCommentsCollector;
+ private final CommentEventsCollector inlineCommentsCollector;
++// keep the nesting of collections inside other collections
++private int nestingDepth = 0;
++private final int nestingDepthLimit;
+
+ public Composer(Parser parser, Resolver resolver) {
+ this(parser, resolver, new LoaderOptions());
+@@ -77,6 +81,7 @@ public class Composer {
+ CommentType.BLANK_LINE, CommentType.BLOCK);
+ this.inlineCommentsCollector = new CommentEventsCollector(parser,
+ CommentType.IN_LINE);
++nestingDepthLimit = loadingConfig.getNestingDepthLimit();
+ }
+
+ /**
+@@ -186,6 +191,7 @@ public class Composer {
+ } else {
+ NodeEvent event = (NodeEvent
Bug#991408: Netbeans: source code problem
Am Sonntag, dem 19.02.2023 um 03:34 -0300 schrieb Leandro Cunha: > Hi, > > For some consistency please request the removal of this package > including unstable. It makes no sense to have the name of an IDE and > install a Java LayoutManager to allow placement in absolute positions. > I even agree with the removal, but it must be done correctly and in > such a way that I don't find this package in the repository via > tracker.debian.org and packages.debian.org as if exist. > I'll let whoever takes care of this package do that. > Thanks! If you want to re-introduce the Netbeans IDE, please do! Use the current source package, prepare your work, find a sponsor and upload it to Debian. However the Java team will not remove a source package from Debian just "for consistency". We don't rename source packages just to re-introduce them later under a different name, only to produce the same binary package as the current package again. This would be completely nonsensical and a whole lot of make-work for all involved parties, mostly the ftp-team and the Java team itself. signature.asc Description: This is a digitally signed message part
Bug#1031525: c-ares: CVE-2022-4904
Hi Gregor, I'm a member of the LTS team. I intend to prepare a DLA release for this issue so you don't have to. If you could prepare a point update for Bullseye though, that would be appreciated. Cheers, Markus 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#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
On Tue, 25 Oct 2022 10:44:19 + Francesco Frassinelli wrote: > Package: openrefine > Version: 3.6.1-1 > Severity: important > X-Debbugs-Cc: francesco.frassine...@nina.no > > Dear Maintainer, > > I started openrefine and try to connect to it using the web brower (http://localhost:), but I got the following error: ... Hello, thanks for the report! Sorry for not getting back to you sooner. I had a hard time to debug this issue. It turned out that a) third party javascript files were missing from the upstream sources and b) librhino-java in Debian was too old and caused a silent runtime error. I believe this is all fixed now. Version 3.6.2-1 should be available in a few hours on the mirrors. Regards, Markus signature.asc Description: This is a digitally signed message part
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: 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#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#1030046: Document snakeyaml security expectations
Hi, Am Montag, dem 30.01.2023 um 18:44 +0100 schrieb Moritz Muehlenhoff: > > Could we please add a README.Debian.security with something like the > following > to make this also visible to users? > > > Note that snakeyaml isn't designed to operate on YAML data coming from > untrusted > sources, in such cases you need to apply sanitising/exception handling > yourself. > > Please see https://bitbucket.org/snakeyaml/snakeyaml/wiki/CVE%20&%20NIST.md > for additional information. > Sure, that's doable. But how do we treat the current and new CVE in stable and oldstable releases? no-dsa, ignored or keep them open until upstream eventually fixes them? Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1026766: sweethome3d: Crashes with "Assertion `!xcb_xlib_threads_sequence_lost' failed"
Hello, Am Freitag, dem 27.01.2023 um 08:29 +0100 schrieb Lluís Gras: > Hi, > > It seems somehow related to VGA in use. > > Same setup (cloned boxes) works with > > 00:02.0 VGA compatible controller [0300]: Intel Corporation GeminiLake [UHD > Graphics 600] [8086:3185] (rev 06) > DeviceName: Onboard - Video > Subsystem: Hewlett-Packard Company GeminiLake [UHD Graphics 600] [103c:87f9] > Kernel driver in use: i915 > Kernel modules: i915 > > and crashes with > > 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev e2) > Subsystem: Hewlett-Packard Company Stoney [Radeon R2/R3/R4/R5 Graphics] > [103c:8381] > Kernel driver in use: amdgpu > Kernel modules: amdgpu This is most likely a driver related issue. I assume we can't fix this in sweethome3d. Markus signature.asc Description: This is a digitally signed message part
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#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#946434: /usr/games/ace-freecell: feature request: add undo funktion
Control: severity -1 wishlist This is a feature request. Unfortunately upstream is no longer active. Patches are welcome. Markus signature.asc Description: This is a digitally signed message part
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#1028486: bullseye-pu: package jersey1/1.19.3-6
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
Hello,
I would like to update jersey1 in Bullseye. The package currently
FTBFS because of the latest security update of libjettison-java. The
fix is trivial. Please find attached the debdiff.
Regards,
Markus
diff -Nru jersey1-1.19.3/debian/changelog jersey1-1.19.3/debian/changelog
--- jersey1-1.19.3/debian/changelog 2019-03-02 02:04:24.0 +0100
+++ jersey1-1.19.3/debian/changelog 2022-12-31 16:49:13.0 +0100
@@ -1,3 +1,10 @@
+jersey1 (1.19.3-6+deb11u1) bullseye; urgency=medium
+
+ * Team upload.
+ * Fix FTBFS with libjettison-java 1.5.3.
+
+ -- Markus Koschany Sat, 31 Dec 2022 16:49:13 +0100
+
jersey1 (1.19.3-6) unstable; urgency=medium
* Fixed the build failure with librome-java >= 1.6
diff -Nru jersey1-1.19.3/debian/control jersey1-1.19.3/debian/control
--- jersey1-1.19.3/debian/control 2019-03-02 02:04:14.0 +0100
+++ jersey1-1.19.3/debian/control 2022-12-31 16:49:13.0 +0100
@@ -19,7 +19,7 @@
libjackson-json-java,
libjaxb-java,
libjdom1-java,
- libjettison-java,
+ libjettison-java (>= 1.5.3),
libjsr311-api-java,
libmail-java,
libmaven-bundle-plugin-java,
diff -Nru jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch
jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch
--- jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch 1970-01-01
01:00:00.0 +0100
+++ jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch 2022-12-31
16:49:13.0 +0100
@@ -0,0 +1,27 @@
+From: Markus Koschany
+Date: Sat, 31 Dec 2022 11:56:31 +0100
+Subject: libjettison-java 1.5.3
+
+Fix FTBFS with libjettison-java 1.5.3.
+---
+ .../src/main/java/com/sun/jersey/json/impl/JSONTransformer.java | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git
a/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
b/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
+index e7c001f..46c7361 100644
+--- a/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
b/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
+@@ -85,11 +85,11 @@ final class JSONTransformer {
+ return result;
+ }
+
+-static String asJsonArray(Collection collection) {
++static String asJsonArray(Collection collection) throws
JSONException {
+ return (null == collection) ? "[]" : (new
JSONArray(collection)).toString();
+ }
+
+-static String asJsonObject(Map map) {
++static String asJsonObject(Map map) throws JSONException {
+ return (null == map) ? "{}" : (new JSONObject(map)).toString();
+ }
+ }
diff -Nru jersey1-1.19.3/debian/patches/series
jersey1-1.19.3/debian/patches/series
--- jersey1-1.19.3/debian/patches/series2019-03-02 01:54:20.0
+0100
+++ jersey1-1.19.3/debian/patches/series2022-12-31 16:49:13.0
+0100
@@ -2,3 +2,4 @@
02-disable-moxy-support.patch
03-add-enterprise-dependencies.patch
04-rome-compatibility.patch
+libjettison-java-1.5.3.patch
Bug#1028248: transition: bullet
Am Dienstag, dem 10.01.2023 um 22:34 +0100 schrieb Sebastian Ramacher: > Please go ahead Thank you! Uploaded. Markus signature.asc Description: This is a digitally signed message part
Bug#1028248: transition: bullet
Short follow-up: The bug in dart (#1028247) has already been fixed. That means only 7 binNMU would be required to complete this transition now. signature.asc Description: This is a digitally signed message part
Bug#1028248: transition: bullet
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: a...@debian.org Hello, I would like to request a transition slot for Bullet 3.24 which is already available in experimental. I have successfully rebuilt all reverse-dependencies except of siconos (#1024864) and gazebo (#1004795,1011657) which fail for different reasons. dart is the only source package which fails to build from source because of one failing test. Since the package builds otherwise fine, I believe it should be as simple as updating the unittest. According to dart's changelog test_SkelParser has been flaky in the past. I have filed Debian bug #1028247 to discuss this problem with dart's maintainer. The complete list of reverse-dependencies: dart gazebo hkl ignition-physics jskeus openmw ros-geometry ros-geometry2 siconos Ben file: title = "bullet"; is_affected = .depends ~ "bullet3.06" | .depends ~ "bullet3.24"; is_good = .depends ~ "bullet3.24"; is_bad = .depends ~ "bullet3.06"; Regards, Markus
Bug#1028247: dart: FTBFS with Bullet 3.24 error in test_skelParser
Source: dart Version: 6.12.1+dfsg4-11 Severity: important X-Debbugs-Cc: a...@debian.org Dear maintainer, I would like to release Bullet 3.24 with Bookworm. Your package fails to build from source because one test fails, test_SkelParser. Error [FCLCollisionDetector.cpp:1074]^[[0m [FCLCollisionDetector::createFCLCollisionGeometry] Attempting to create an unsupported shape type [CapsuleShape]. Creating a sphere with 0.1 radius instead. test_SkelParser: ./dart/constraint/ContactConstraint.cpp:230: dart::constraint::ContactConstraint::ContactConstraint(dart::collision::Contact&, double): Assertion `std::abs(D.col(0).dot(D.col(1))) < DART_EPSILON' failed. Is this a real problem or can we just disable/update the failing test? Everything else seems to build fine. Thanks in advance for checking. I would appreciate it if you could take a look at it this week because the transition freeze is very close. Regards, Markus
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#1027687: netty: please package 4.1.86 or later
Source: netty Version: 1:4.1.48-5 Severity: wishlist I have uploaded my preliminary packaging work to experimental in Git but could not finish it yet.
Bug#1018018: imlib2 FTBFS
Control: severity -1 serious Hello, I have just uploaded imlib2 1.10.0 to unstable. This issue is release critical now. signature.asc Description: This is a digitally signed message part
Bug#1027113: RM: childsplay -- RoQA; Python2, unmaintained
Am Dienstag, dem 27.12.2022 um 23:39 + schrieb Scott Kitterman: > Because it looked untouched for years. It seemed unlikely anyone cares. If > you want to upload it back (I'd suggest experimental), ping me and I'll look > at it in New. > > Absent porting to Python 3, I don't particularly see the point, but I'll add > it back if you want. I don't recall that someone can remove packages from Debian without the consent of the maintainer or an explicit decision by the CTTE. We need a procedure not arbitrariness. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912485#40 Who requested the removal of childsplay from Debian? Why is this necessary at all? How can I upload I package to experimental which has not been ported to python3 yet? signature.asc Description: This is a digitally signed message part
Bug#1027113: RM: childsplay -- RoQA; Python2, unmaintained
On Tue, 27 Dec 2022 18:15:53 -0500 Scott Kitterman wrote: > Package: ftp.debian.org > Severity: normal > > This is the last external rdepend for python-all and needs to go. It > appears unmaintained both upstream and in Debian. > > Scott K Hello Scott, why did you remove childsplay from Debian without asking the maintainer for his consent? You don't have to remove childsplay as a reverse-dependency of python-all to complete the removal request. I am aware that childsplay has not been ported to python3 yet. Why can't we just keep it in Debian (even if uninstallable) for the time being. We all know that a reintroduction to Debian can take several months. This all seems to be a lot of make work to me. signature.asc Description: This is a digitally signed message part
Bug#1025910: libcommons-net-java: CVE-2021-37533
Hello tony, Am Dienstag, dem 27.12.2022 um 08:40 -0800 schrieb tony mancill: > On Sun, Dec 11, 2022 at 09:02:16PM +0100, Salvatore Bonaccorso wrote: > > Source: libcommons-net-java > > Version: 3.6-1 > > Severity: important > > Tags: security upstream > > Forwarded: https://issues.apache.org/jira/browse/NET-711 > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > > I see that there has been an upload of 3.9.0 on 2022-12-26. > > I'm just noting here that I prepared a 3.9.0 package locally but hadn't > uploaded it yet because several of the build r-deps failed to compile. > (Maybe I was just doing it wrong, but we may see some FTBFS.) I noticed two FTBFS of wagon and nrepl-clojure. Both of them seemed unrelated to me. I guess they will be fixed eventually. Everything else built fine. Sorry for the double work. signature.asc Description: This is a digitally signed message part
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#1024353: asterisk: segfault with the latest security update
Am Samstag, dem 19.11.2022 um 16:14 +0400 schrieb sergio: > On 18/11/2022 17:32, Markus Koschany wrote: > > > thanks for reporting. I wonder if the segfault is related to the extra > > package > > asterisk-opus. What happens if you remove this package and start asterisk > > without it? > > Commeting out codec_opus_open_source, format_ogg_opus_open_source and > format_vp8 > in modules.conf (autoload=no) changes nothing. I believe the problem here is that the opus codec is embedded in Asterisk itself now and asterisk-opus conflicts with the new setup. Did you remove asterisk-opus as well? > > all debug files > > How to get them? I have a dumped core file, is it enough? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information I need more details how you trigger the segfault, a step by step explanation, because I cannot reproduce the problem with a new installation of Asterisk. You have to turn on verbose or debug logging and send me your log files. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1024353: asterisk: segfault with the latest security update
Hello, thanks for reporting. I wonder if the segfault is related to the extra package asterisk-opus. What happens if you remove this package and start asterisk without it? Please send all your debug files tar compressed to a...@debian.org please. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1021266: curl CVE patches applied at curl 7.74.0-1.3+deb11u2 breaks janus package working with RTSP sources
Hello Samuel, Am Dienstag, dem 15.11.2022 um 20:47 + schrieb Samuel Henrique: > Hello Markus, > > Would you have some time to investigate this issue, please? > > Thank you, (and thank you Raimon for reporting this) We need to CC Raimon because bug reporters are not automatically subscribed to bug reports. janus is not supported in Debian stable. There is only a version in stable- backports. Without a clear reproducer of an affected package in stable, I can't debug this issue. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1020606:
Hi Fukui, Am Montag, dem 14.11.2022 um 19:02 +0900 schrieb Daichi Fukui: > > Thanks for taking time. > > Ouch. The visibility was set to be private. > We are now able to look at the contents of that repo. > I'd appreciate it if you review my draft package and give me some feedback. Thanks for your excellent work. I've just uploaded enet to experimental. While rebuilding all reverse-dependencies of enet, I discovered that three packages currently fail to build from source. 2022/11/15 14:05:37 PASSED: redeclipse 2022/11/15 14:05:37 PASSED: 0ad 2022/11/15 14:05:37 PASSED: 7kaa 2022/11/15 14:05:37 PASSED: allegro5 2022/11/15 14:05:37 PASSED: godot 2022/11/15 14:05:37 PASSED: cube2 2022/11/15 14:05:37 FAILED: dolphin-emu (see buildlogs/dolphin-emu_5.0+dfsg-6) 2022/11/15 14:05:37 FAILED: lix (see buildlogs/lix_0.9.29-1.1) 2022/11/15 14:05:37 FAILED: python-enet (see buildlogs/python- enet_0.0~vcs.2017.05.26.git-2.2) dolphin-emu and lix fail for different reasons but I believe python-enet is incompatible with the latest enet release. Perhaps you could take a look at that and find out why it FTBFS? If we can solve this problem, then nothing speaks against an upload to unstable. Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1020606:
Hi, Am Dienstag, dem 08.11.2022 um 23:14 +0900 schrieb Daichi Fukui: > Hi all, > > I've created a new version of the enet source package [0], which is going > to be 1.3.17+ds-1 with this update. > > > [0] https://salsa.debian.org/dfukui/enet The repository seems to be gone. Can you reupload your sources again? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1020606:
Hi, Am Dienstag, dem 08.11.2022 um 23:14 +0900 schrieb Daichi Fukui: > Hi all, > > I've created a new version of the enet source package [0], which is going > to be 1.3.17+ds-1 with this update. > The draft source package has already been shared with the maintainers of > and a key contributor to enet as well as Debian Games Team. > However, I haven't received any response from them so far, so that I am > considering an NMU with the help of a Debian Developer. Sorry for the long delay. I'll review enet on Friday and get back to you. Cheers, 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#1020985: marked as done (webext-https-everywhere: https everywhere opens firefox tab even while uninstalled)
Hi Vagrant, you could try to backup your Firefox profile and then move it to a safe location, then restart Firefox and experiment with it a little. That's the best way to track down plugin issues. Usually the notification should pop-up only once. Such problems are often caused by new Firefox upgrades and are not directly related to addons. I haven't noticed anything strange since the last https-everywhere update but don't hesitate to reopen the bug report if you can reproduce the problem with a clean Firefox installation. Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#949422: osmo: diff for NMU version 0.4.4-1.1
Hi Hugh, Am Donnerstag, dem 29.09.2022 um 15:23 +1000 schrieb Hugh McMaster: > Control: tags 949422 + patch > > > Dear maintainer, > > I've prepared an NMU for osmo (versioned as 0.4.4-1.1). The diff > is attached to this message. > > As this package is marked LowNMU, I will seek sponsorship to > upload shortly. Please let me know if you would prefer to upload > this version yourself. Thanks for preparing a patch for this issue. I can take care of the upload myself. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1020496: games-finest: Please add a selection of minetest mods
Control: reassign -1 minetest Control: retitle -1 minetest: please install a selection of minetest mods Hi, Am Donnerstag, dem 22.09.2022 um 10:48 +0200 schrieb Elena ``of Valhalla'': > Package: games-finest > Severity: wishlist > > Dear Maintainer, > > the metapackage installs just the bare the package minetest with the > bare game; for the best enjoyment however a selection of mods is > required: could you please add them to the metapackage? Indeed this is intentional. All meta packages depend only on the main game. If there are multiple options (different GUIs or flavors) then only one is chosen. Mods and addons are optional, some people find them useful and others prefer different ones. It would be impossible to satisfy every user request. > alternatively, the minetest source package could build a metapackage > like “minetest-mods-finest”, and that could be installed by > games-finest. That could be an option for minetest. If those mods are really required to enjoy the game then minetest should simply add them to Recommends. If they are nice to have then adding them to Suggests would also make sense. In any case games-finest is the wrong place to discuss this topic. This issue should be solved by minetest and games-finest would automatically pick up the changes. > As for the selection of which mods to include, I defer to the choice of > the maintainer (I see as a start that minetest Suggests > minetest-mod-moreblocks, minetest-mod-moreores, minetest-mod-pipeworks, > minetest-server, minetestmapper; personally I tend to add a few more) I leave the decision to someone else because I don't regularly play the game anymore. Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#981944: libmatthew-java: FTBFS with OpenJDK 17 due to javadoc errors
Control: tags -1 patch
I'm attaching a simple patch that addresses the problem. I believe we can just
remove the javadoc param line.
From: Markus Koschany
Date: Sat, 27 Aug 2022 22:47:41 +0200
Subject: java17
---
cx/ath/matthew/unix/UnixSocket.java | 1 -
1 file changed, 1 deletion(-)
diff --git a/cx/ath/matthew/unix/UnixSocket.java b/cx/ath/matthew/unix/UnixSocket.java
index f652614..3c6df06 100644
--- a/cx/ath/matthew/unix/UnixSocket.java
+++ b/cx/ath/matthew/unix/UnixSocket.java
@@ -171,7 +171,6 @@ public class UnixSocket
* @see getPeerUID
* @see getPeerPID
* @see getPeerGID
-* @param data The byte of data to send.
*/
public byte recvCredentialByte() throws IOException
{
signature.asc
Description: This is a digitally signed message part
Bug#1018100: ITP: liblanguage-detector-java -- Language Detection Library for Java
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, a...@debian.org,debian-j...@lists.debian.org * Package name: liblanguage-detector-java Version : 0.6 Upstream Author : Nakatani Shuyo, Francois ROLAND, Fabian Kessler, Nicole Torres, Robert Theis * URL : https://github.com/optimaize/language-detector * License : Apache-2.0 Programming Lang: Java Description : Language Detection Library for Java This software uses language profiles which were created based on common text for each language. N-grams, a contiguous sequence of n items from a given sample of text, were then extracted from that text and stored in the profiles. When trying to figure out in what language a certain text is written, the program goes through the same process: It creates the same kind of n-grams of the input text. Then it compares the relative frequency of them, and finds the language that matches best. Currently 71 languages are supported.
Bug#949404: debdiff for kanatest 0.4.8-5
Hi, Am Mittwoch, dem 24.08.2022 um 13:02 +1000 schrieb Hugh McMaster: > Dear Maintainer, > > I've prepared a new version of kanatest (versioned as 0.4.8-5) for > Team Upload. A debdiff of all changes is attached. > > I have not been able to submit a MR on Salsa or update the Vcs-* > fields in d/control, as kanatest is not in your team repository. > > I have also avoided removing Sam Hocevar from the Uploaders list [1], > as that is a matter for the team. > > Please consider importing the debdiff and making a new upload. Thanks for your contribution! I have just uploaded the new revision. I also removed Sam from Uploaders because he is no longer active, so that makes sense. I also created a new Git repository for kanatest located at https://salsa.debian.org/games-team/kanatest Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1018029: idesk: FTBFS with imlib2 1.9.1
Package: idesk Version: 0.7.5-6 Severity: important Tags: ftbfs sid bookwork User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package fails to build from source with imlib2 1.9.1 in experimental. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly. I intend to upload imlib2 1.9.1 to unstable in one or two months. Feel free to reply to this bug report if you have any questions. Regards, Markus
Bug#1018028: xjadeo: please check compatibility with imlib2 1.9.1 in experimental
Package: xjadeo Version: 0.8.11-1 Severity: important Tags: ftbfs sid bookwork User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package currently fails to build from source in unstable and depends on imlib2. I intend to upload a new version of imlib2 to unstable in one or two months. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly if necessary. If you fix the current FTBFS please check if imlib2 1.9.1 in experimental works for you. If yes, please close this bug report. Regards, Markus
Bug#1018023: eterm: FTBFS with imlib2 1.9.1
Package: eterm Version: 0.9.6-6.1 Severity: important Tags: ftbfs sid bookwork User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package fails to build from source with imlib2 1.9.1 in experimental. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly. Looking closer there may be a different error that causes the FTBFS because of newly introduced symbols. In file included from menus.h:29, from actions.h:31, from actions.c:33: pixmap.h:224:20: error: conflicting types for ‘imlib_strerror’; have ‘const char *(Imlib_Load_Error)’ 224 | extern const char *imlib_strerror(Imlib_Load_Error); |^~ In file included from /usr/include/libast.h:79, from feature.h:100, from actions.c:27: /usr/include/Imlib2.h:2846:21: note: previous declaration of ‘imlib_strerror’ with type ‘const char *(int)’ 2846 | EAPI const char*imlib_strerror(int err); | ^~ I intend to upload imlib2 1.9.1 to unstable in one or two months. Feel free to reply to this bug report if you have any questions. Regards, Markus
Bug#1018022: wmhdplop: FTBFS with imlib2 1.9.1
Package: wmhdplop Version: 0.9.11-3 Severity: important Tags: ftbfs sid bookwork User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package fails to build from source with imlib2 1.9.1 in experimental. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly. I intend to upload imlib2 1.9.1 to unstable in one or two months. Feel free to reply to this bug report if you have any questions. Regards, Markus
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#1018021: giblib: FTBFS with imlib2 1.9.1
Source: giblib Version: 1.2.4-13 Severity: important Tags: ftbfs sid bookwork User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package fails to build from source with imlib2 1.9.1 in experimental. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly. I intend to upload imlib2 1.9.1 to unstable in one or two months. Feel free to reply to this bug report if you have any questions. Regards, Markus
Bug#1018020: wmcoincoin: FTBFS with imlib2 1.9.1
Package: wmcoincoin Version: 2.6.5.git+23.411d4a3-1 Severity: important Tags: ftbfs sid bookworm User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package fails to build from source with imlib2 1.9.1 in experimental. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly. I intend to upload imlib2 1.9.1 to unstable in one or two months. Feel free to reply to this bug report if you have any questions. 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 wmcoincoin depends on: ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u3 ii libcurl4 7.74.0-1.3+deb11u2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 pn libimlib2 ii libpango-1.0-0 1.46.2-3 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxft2 2.3.2-2 ii libxinerama1 2:1.1.4-2 ii libxmu6 2:1.1.2-2+b3 wmcoincoin recommends no packages. wmcoincoin suggests no packages.
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
