Bug#938351: marked as pending in renpy
Am 27.10.20 um 20:10 schrieb Gregor Riepl: >> https://salsa.debian.org/games-team/renpy/commit/fc29ebfe106238b590a7896450a5d1ad1f94f84e >> >> >> Switch to python3. >> >> Closes: #938351 >> > > I'm confused. > Does that mean upstream has completed the port to Python 3? No. > Last I checked, the bug was still wide open: > https://github.com/renpy/renpy/issues/1098 Just the dependencies were switched to Python 3 and the Git hook sent an automatic email to the BTS. signature.asc Description: OpenPGP digital signature
Bug#972993: eclipse-wtp: FTBFS cannot find symbol
Source: eclipse-wtp Version: 3.18-4 Severity: serious Tags: ftbfs X-Debbugs-Cc: eclipse-wtp: FTBFS cannot find symbol Hi, while I was rebuilding reverse-dependencies of jflex, I discovered that eclipse-wtp fails to build from source. The error is unrelated to the new version of jflex. org.eclipse.wst.sse.ui: [echo] Building bundle 'Structured Source Editor' (org.eclipse.wst.sse.ui:1.7.0) [mkdir] Created dir: /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/classes [touch] Creating /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/dependencies [mkdir] Created dir: /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources [copy] Copying 295 files to /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources [javac] Compiling 295 source files to /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/classes [javac] /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/selection/SelectionHistory.java:23: error: cannot find symbol [javac] import org.eclipse.jface.util.Assert; [javac] ^ [javac] symbol: class Assert [javac] location: package org.eclipse.jface.util [javac] /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/preferences/ui/StatusInfo.java:18: error: cannot find symbol [javac] import org.eclipse.jface.util.Assert; [javac] ^ [javac] symbol: class Assert [javac] location: package org.eclipse.jface.util [javac] /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/selection/StructureSelectAction.java:20: error: cannot find symbol [javac] import org.eclipse.jface.util.Assert; [javac] ^ [javac] symbol: class Assert [javac] location: package org.eclipse.jface.util [javac] /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/TransferBuilder.java:297: warning: non-varargs call of varargs method with inexact argument type for last parameter; [javac] >--->--->--->---obj = mtd.invoke(null, null); [javac] >--->--->--->--- ^ [javac] cast to Object for a varargs call [javac] cast to Object[] for a non-varargs call and to suppress this warning [javac] /build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/selection/SelectionHistory.java:36: error: cannot find symbol [javac] >--->---Assert.isNotNull(editor); [javac] >--->---^
Bug#912485: childsplay: Please migrate to python3-pygame
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. Markus signature.asc Description: OpenPGP digital signature
Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9
Am 19.10.20 um 23:33 schrieb Joachim Wuttke: > Markus: > > Further investigation shows that the problem is not with NumPy. > CMake not even finds Python.h. > > The problem is most likely a mixture of Python 3.8 and 3.9 files on your > system. > > Try to uninstall libpython3-dev, which still depends on 3.8. > > Good luck, Joachim I built siconos in a clean chroot environment. The recent rebuild of siconos also shows build failures https://buildd.debian.org/status/package.php?p=siconos I don't think it's specific to my environment. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#972394: got same error in other project
Hi Joachim, Am 19.10.20 um 23:15 schrieb Joachim Wuttke: > Hi Markus, > > I confirm that this is a serious issue. > > I got the same error message > > Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES > Development NumPy Development.Module Development.Embed) (found version > "3.9.0") at first I just thought the package is missing a build-dependency on python3. > in a completely different software project after I dist-upgraded my Debian/ > testing system. That upgrade did not affect my cmake, which I compile > myself (version 3.18.20200714-g2da7786-dirty). However, the upgrade did > change numerous Python3 packages, among them > > python3-numpy:amd64 (1:1.19.1-1, 1:1.19.2-2+b1) > > but not python3-dev. So my guess is the problem is a change in > python3-numpy > that breaks CMake's > > find_package(Python3 COMPONENTS Development NumPy) > > command. > > Accordingly, I will report the bug to python3-numpy. Ok, that sounds reasonable. I just stumbled upon this issue while rebuilding your package, feel free to reassign or address it as you see fit. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#972394: siconos: FTBFS could not find Python 3
Package: libsiconos-io-dev Version: 4.3.0+dfsg-1 Severity: serious Hi, while I was rebuilding all reverse-dependencies of bullet, I discovered that siconos fails to build from source. The issue is related to Python 3, maybe a missing build-dependency. Full build log is attached. The error message is: CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message): Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES Development NumPy Development.Module Development.Embed) (found version "3.9.0") Call Stack (most recent call first): /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.18/Modules/FindPython/Support.cmake:2966 (find_package_handle_standard_args) /usr/share/cmake-3.18/Modules/FindPython3.cmake:389 (include) cmake/SiconosSetup.cmake:58 (find_package) CMakeLists.txt:127 (include) Regards, Markus -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-11-amd64 (SMP w/4 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 /bin/dash Init: unable to detect Versions of packages libsiconos-io-dev depends on: pn libsiconos-io6 pn libsiconos-kernel-dev libsiconos-io-dev recommends no packages. libsiconos-io-dev suggests no packages. siconos_4.3.0+dfsg-1_amd64.build.gz Description: application/gzip
Bug#964195: guacamole-client: CVE-2020-9497 and CVE-2020-9498
I somehow missed the guacamole-server package in Debian. Currently I believe it is possible to backport the patch from 1.2.0 to 0.9.9. However there is still the problem with freerdp2 (#888321), most likely a new upstream version for unstable/testing is required anyway. Markkus signature.asc Description: OpenPGP digital signature
Bug#964195: guacamole-client: CVE-2020-9497 and CVE-2020-9498
Hi, I am currently investigating the security vulnerabilities in guacamole-client. I believe the reported CVE-2020-9497 and CVE-2020-9498 issues only affect the server part of guacamole but this one has not been packaged yet. The security researchers who reported the vulnerabilities have discussed them in detail at https://research.checkpoint.com/2020/apache-guacamole-rce/ The paragraph about the Disclosure Timeline mentions the following commit which appears to fix both issues. (or all four according to checkpoint.com) https://github.com/apache/guacamole-server/commit/a0e11dc81727528224d28466903454e1cb0266bb Please double-check if the findings are correct. At the moment I am inclined to mark the guacamole-client package as not affected by CVE-2020-9497 and CVE-2020-9498. Then I also looked into CVE-2016-1566. It appears to me the current version in stretch and unstable has already been fixed. If https://github.com/glyptodon/guacamole-client/commit/7da13129c432d1c0a577342a9bf23ca2bde9c367 is the fixing commit, then it is already included in version 0.9.9+dfsg-1 The other CVE, CVE-2018-1340 and CVE-2017-3158, are still relevant though. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#957271: gfpoken: ftbfs with GCC-10
On Sat, 5 Sep 2020 17:03:15 +0200 Reiner Herrmann wrote: > Hi, > > the GCC 10 build error is easily fixed with the attached patch. > > But the build also fails while generating artwork via a Gimp script > (art/mktiles): > > > Starting extension: 'extension-script-fu' > > No batch interpreter specified, using the default 'plug-in-script-fu-eval'. > > Welcome to TinyScheme, Version 1.40 > > Copyright (c) Dimitrios Souflis > > > > ts> > > It then just hangs in this tinyscheme "shell". > Unfortunately I don't know enough about Gimp scripting to fix that. I have pushed a new update with the GCC 10 patch to https://salsa.debian.org/games-team/gfpoken When I try to build gfpoken I see a coredump ./art/mkmarbles: line 25: 20560 Aborted (core dumped) blender -b "`dirname "$0"`"/marbles.blend -o "$BLENDERDIR" -P initdir -a an OSError: Python file "/build/gfpoken-1/initdir" could not be opened: No such file or directory Unable to open a display and another GIMP error but the build succeeds. Markus signature.asc Description: OpenPGP digital signature
Bug#966190: marked as pending in alien-arena
Control: tag -1 pending Hello, Bug #966190 in alien-arena reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/alien-arena/-/commit/4467e5cb82565f7f78bc4d22a0ee9c10f41f77e8 Work around FTBFS with GCC 10 by building with -fcommon. Closes: #966190 (this message was generated automatically) -- Greetings https://bugs.debian.org/966190
Bug#942814: libhibernate-validator-java: update to 5.3.6 breaks reverse-dependencies
Am 26.09.20 um 10:27 schrieb Emmanuel Bourg: > On 25/09/2020 13:50, Markus Koschany wrote: > >> Why did you upgrade hibernate-validator to version 5.x when >> no other package in Debian requires it? Wouldn't it have been >> simpler to revert the upgrade instead of creating a separate >> hibernate-validator4 package? > > The version 5.x is a prerequisite to upgrade Spring to the next major > release. Also the version 4.x is no longer supported and security issues > are frequently reported. The idea is to use libhibernate-validator4-java > as a transitional package until all reverse dependencies are updated to > use the version 5.x. That sounds like a sensible reason to upgrade a package. Though when I look closer into the details I find only four reported security vulnerabilities in the past six years. The last two in 2019 and 2020 did only affect the 5.x and later versions specifically which is rather an argument against upgrading hibernate-validator. So the real reason for 5.x is to upgrade Spring which is also fine. However the update has not materialized so far but in the meantime pdfsam was broken in two Ubuntu releases and unstable. I would recommend to upload such a package to experimental first or release it to unstable when the complete work is done. I believe this all could have been avoided if you had outlined your goals beforehand or if you had responded to this bug report in time. Then we both could actually seek for a solution to make this work. The current situation is a bit demotivating though because I don't want to guess why something is broken and I don't want to invest time to clean up the fallout when the key problem is communication. I will switch pdfsam to use libhibernator-validator4-java now but I can only address this problem when libsejda-commons-java has been approved by the ftp team. This may take a while. Markus signature.asc Description: OpenPGP digital signature
Bug#942814: libhibernate-validator-java: update to 5.3.6 breaks reverse-dependencies
Am 25.09.20 um 08:17 schrieb Emmanuel Bourg: [...] > Hi Paul, > > The version 4.x has been packaged separately as > libhibernate-validator4-java. libspring-java has been updated to use it > but not the other reverse dependencies. > > Emmanuel Bourg Hi, pdfsam is the only other reverse-dependency. I am currently working on updating it including the sejda libraries. Why did you upgrade hibernate-validator to version 5.x when no other package in Debian requires it? Wouldn't it have been simpler to revert the upgrade instead of creating a separate hibernate-validator4 package? Markus signature.asc Description: OpenPGP digital signature
Bug#967125: desmume: Unversioned Python removal in sid/bullseye
On Sun, 20 Sep 2020 23:51:22 +0200 Markus Koschany wrote: > > I believe this issue was fixed in libglade2-dev (#967157) and > monster-masher ^ should be desmume of course :-) signature.asc Description: OpenPGP digital signature
Bug#957671: marked as pending in pcsxr
Control: tag -1 pending Hello, Bug #957671 in pcsxr reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/pcsxr/-/commit/ad106eb96a557077bb0558ae19fe1fd02f44eeb6 Work around FTBFS with GCC 10 and build with -fcommon. Closes: #957671 (this message was generated automatically) -- Greetings https://bugs.debian.org/957671
Bug#969123: webext-ublock-origin: FF80 broke ublock again
On Sat, 29 Aug 2020 01:37:27 +0200 Christoph Anton Mitterer wrote: [...] > Interestingly it seems other (all) add-ons are broken too, at least for > me... but not when I create fresh profiles. I stand corrected. Apparently this is a similar problem like https://bugs.debian.org/931640 Disabling and re-enabling the addons should work or you can remove ~/.mozilla/firefox to create a new profile to get it working again. I don't know how we can fix that in Debian because the bug affects the home directory of the user. I intend to add this information to README.Debian but if someone knows a better solution, please let us know. Markus signature.asc Description: OpenPGP digital signature
Bug#967213: marked as pending in teeworlds
Control: tag -1 pending Hello, Bug #967213 in teeworlds reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/teeworlds/-/commit/9def6b59e0c7bd168a731dcbdf646551db052c75 Import Debian changes 0.7.5-1 teeworlds (0.7.5-1) unstable; urgency=medium . * Team upload. . [ Dylan Aïssi ] * Remove patches applied upstream: - CVE-2019-10877.patch - CVE-2019-10878.patch - CVE-2019-10879.patch - immintrin_FTBFS.patch - no-sse2-required.patch - recursiv_dir.patch . [ Markus Koschany ] * New upstream version 0.7.5. - Fix CVE-2020-12066: Remote denial-of-service. * Build-depend on python3 instead of python. Fix python3 incompatibilities. (Closes: #967213, #938632) * Refresh the patches. Use system library libjsonparser-dev. (Closes: #958249) * Switch to debhelper-compat = 13. * Declare compliance with Debian Policy 4.5.0. (this message was generated automatically) -- Greetings https://bugs.debian.org/967213
Bug#966892: marked as pending in megaglest
Control: tag -1 pending Hello, Bug #966892 in megaglest reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/megaglest/-/commit/f6118a758663fe664ccae49e6c9ea2ada0de82f8 Work around FTBFS with GCC 10 by compiling with -fcommon. Closes: #966892 (this message was generated automatically) -- Greetings https://bugs.debian.org/966892
Bug#969123: webext-ublock-origin: FF80 broke ublock again
Hello ftp team, ublock origin is in the NEW queue again. [1] The binary packages have not changed since the last review. I had uploaded a newer version to unstable and when you finally approved the version I had uploaded to experimental it got automatically removed from Debian because the version was lower than in unstable. Please fast-track the review of ublock-origin because nothing has changed in reality and the package is currently unusable due to a new Firefox version. Thank you Markus [1] https://ftp-master.debian.org/new/ublock-origin_1.29.0+dfsg-1.html signature.asc Description: OpenPGP digital signature
Bug#969123: webext-ublock-origin: FF80 broke ublock again
Control: tags -1 pending On Thu, 27 Aug 2020 23:13:45 +0200 Christoph Anton Mitterer wrote: [...] > It seems stupid *zilla broke ublock origina again with the new Firefox. Thanks for reporting. I believe this is fixed in 1.29.0+dfsg. Unfortunately the package has to go through NEW again which is unfortunate. I hope I can convince the ftp-team to fast-track reviewing uBo (again). Markus signature.asc Description: OpenPGP digital signature
Bug#966885: marked as pending in spring
Control: tag -1 pending Hello, Bug #966885 in spring reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/spring/-/commit/e53b8e4b413013fd4860dc0bdbbfa2defe5445d7 Fix build failure with gcc 10 due to missing include. Closes: #966885 Thanks: Steve Langasek for the patch. (this message was generated automatically) -- Greetings https://bugs.debian.org/966885
Bug#966406: pygame-sdl2: diff for NMU version 7.3.3-1.1
Hello Adrian, Am 28.07.20 um 07:42 schrieb Adrian Bunk: > Package: pygame-sdl2 > Version: 7.3.3-1 > Severity: normal > Tags: patch pending > > Dear maintainer, > > I've prepared an NMU for pygame-sdl2 (versioned as 7.3.3-1.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I should > cancel it. > > renpy has already been broken by several other removals. > > cu > Adrian I appreciate your general bug triaging work but I don't think a NMU was necessary in this case. The last time I checked renpy in unstable it was playable with the version of pygame-sdl2 in unstable. If more Python 2 modules have been removed and renpy is unplayable now, then we can upload pygame-sdl2 from experimental to unstable. However pygame-sdl2 is only relevant in the context of renpy, there was no other reason to package it for Debian. A simple message to a bug report would have sufficed. Markus signature.asc Description: OpenPGP digital signature
Bug#957604: marked as pending in neverball
Control: tag -1 pending Hello, Bug #957604 in neverball reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/neverball/-/commit/6df7cbfede041dd484caef992ce527c752f5af5d Work around FTBFS with GCC 10 by compiling with -fcommon. Closes: #957604 (this message was generated automatically) -- Greetings https://bugs.debian.org/957604
Bug#957497: marked as pending in lmemory
Control: tag -1 pending Hello, Bug #957497 in lmemory reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/lmemory/-/commit/dba797c4a835dd8f003e23bc0a228d8f2c01c32b Work around FTBFS with GCC 10 by compiling with -fcommon. Closes: #957497 (this message was generated automatically) -- Greetings https://bugs.debian.org/957497
Bug#957021: marked as pending in atomix
Control: tag -1 pending Hello, Bug #957021 in atomix reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/atomix/-/commit/7f15c975b4d743dca8fa93564d2b1383c0afee4f Work around FTBFS with GCC 10 by compiling with -fcommon. Closes: #957021 (this message was generated automatically) -- Greetings https://bugs.debian.org/957021
Bug#964242: bsdmainutils: depends on non-existing version of bsdextrautils
affects 964242 javahelper thanks This also affects javahelper which depends on bsdmainutils and breaks a lot of Java packages in Debian currently. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#963367: marked as pending in simutrans-pak128.britain
Control: tag -1 pending Hello, Bug #963367 in simutrans-pak128.britain reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/simutrans-pak128.britain/-/commit/715e32330b38c3f7017eaee1f962176f5628ed6e Fix FTBFS and path to makeobj binary. Closes: #963367 (this message was generated automatically) -- Greetings https://bugs.debian.org/963367
Bug#963460: marked as pending in simutrans-pak64
Control: tag -1 pending Hello, Bug #963460 in simutrans-pak64 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/simutrans-pak64/-/commit/1c0d627388da3faa14ddb6dd6140544800046022 Fix FTBFS and path to makeobj binary. Closes: #963460 (this message was generated automatically) -- Greetings https://bugs.debian.org/963460
Bug#962512: nethack: Security issues in Buster's nethack 3.6.1
Control: fixed -1 3.6.6-1 Control: severity -1 important Am 09.06.20 um 03:25 schrieb Jason L. Quinn: [...] > Seems like the vunerabilities are important enough to warrant an upgrade in > Buster. I'm not against an update of nethack in Buster. However currently such an update would break nethack-lisp. See also Debian bug 961932. If we could fix the lisp fork, then it would be ok to backport 3.6.6-1 to stable I guess. Please note that those security vulnerabilities are not very severe as long as you play nethack alone and nobody else has access to your configuration options or nethack itself. This is the most common game play mode hence the security risk is rather low. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#961932: nethack-lisp: broken and unmaintained
Package: nethack-lisp Version: 3.6.6-1 Severity: serious I have just updated nethack to the latest upstream version to fix several security vulnerabilities and a compilation error with GCC 10. Unfortunately the Debian specific lisp patches don't work anymore with the current release. I could fix a few minor errors but there are more issues and I'm not really interested in maintaining a fork of nethack. Though I guess someone else can fix it. I have pushed all lisp related patches to a new lisp branch in Git. I wonder if we should drop nethack-lisp completely or try to upstream the code. It is quite obvious that the additional work to make the lisp port work prevents more regular updates.
Bug#928813: libapache2-mod-jk: Jk can not find any configured worker
Am 27.05.20 um 21:54 schrieb Thorsten Glaser: [...] > Thank you. Please also take care of buster. I will take care of Buster eventually. Markus signature.asc Description: OpenPGP digital signature
Bug#928813: marked as pending in libapache-mod-jk
Control: tag -1 pending Hello, Bug #928813 in libapache-mod-jk reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/libapache-mod-jk/-/commit/f8d4df2710889793f7f1a0d862ad76bec1302d25 Rename httpd-jk.conf to jk.conf to restore compatibility with Debian's Apache helpers a2enmod and a2dismod. Closes: #928813 (this message was generated automatically) -- Greetings https://bugs.debian.org/928813
Bug#928813: libapache2-mod-jk: Jk can not find any configured worker
Am 27.05.20 um 17:28 schrieb Thorsten Glaser: [...] > In stretch, an “a2enmod jk” will enable mods-available/jk.conf > and make things work. > > From reading the changelog, you wanted to “Install new httpd-jk.conf > file which follows Apache 2.4 syntax”, but the directory is wrong; > these files belong into conf-available, not mods-available. > That being said, that would require both “a2enmod jk” *and* > “a2enconf httpd-jk”, which is a UI regression against earlier, > so I’d prefer for the file to be renamed back to what it was > in stretch over moving it to another directory. > > > ⚠ I intend to team-upload the fix if not done within the week. ⚠ > The mods-available directory is correct. Both conf and load file have to be installed into it but the file naming is wrong. httpd-jk.conf should be jk.conf. Just renaming the file should be sufficient. I will upload a new revision. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#936557: freeorion: Python2 removal in sid/bullseye
Am 17.05.20 um 15:36 schrieb Fedja Beader via Pkg-games-devel: > Why does this bug still exist? > > I was able to build headless Freeorion on Devuan with Python 3 just by > changing the control file (see > https://framagit.org/specing/debian-freeorion/-/commit/948beb224601838163bf7c9bea4d8bcf677dcb8d). > It seems that Freeorion migrated from Python 2 a long time ago? I suggest you check your package again and try to play the game with only Python 3 installed. Freeorion 0.4.9 is still Python 2 only, the next version will support Python 3 and then we can close this bug report. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#959937: tomcat9: update to tomcat9:amd64 9.0.31-1~deb10u1 breaks application
Control: severity -1 normal Am 07.05.20 um 17:58 schrieb Michael Meier: [...] > The application doesn't use ajp. > > The sense of using unattended-upgrades and debian stable (no breaking > changes on updates) is not to read each security announcement in before. > > I'm not working in an area, where anybody would (be able to) pay for that. It is not feasible to detect any possible incompatibility beforehand because it heavily depends on the apps in use. Debian stable updates work 99% of the time without major issues but there will never be a 100% success rate because some problems are unrelated or simply not under Debian control. Setting up a test server before deploying updates to a production environment is the way to go here. >> If that does not solve your problem, then we need more information about >> your setup and configuration to debug the problem but note that we ship >> the latest upstream version basically unmodified, so this would be most >> likely an upstream bug. > > I could trace it back to the zk library used: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64097 > > https://tracker.zkoss.org/browse/ZK-4510 > > That seems to be a really really weird bug. If I understand it > correctly, it's the fault of zk, but I'm not 100% sure. > > Anyway, as it seems if I manage to update the project to the new zk > major version, it's supposed to work again. Ok, as I previously thought, it is an upstream bug but not in Tomcat itself but in el-api. Updating the zk library for your app might resolve the issue. I wonder if we need to upgrade src:el-api in Debian too. I think it is best when Emmanuel Bourg chimes in here. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#959937: tomcat9: update to tomcat9:amd64 9.0.31-1~deb10u1 breaks application
Am 07.05.20 um 10:04 schrieb Michael Meier:
> Package: tomcat9
> Version: 9.0.16-4
> Severity: grave
> Justification: renders package unusable
>
> I've just been called out of bed.
> As it seems unattended-upgrades upgraded on a debian buster server
> from:9.0.16-4 to 9.0.31-1~deb10u1
> One of the installed webapps throws following error when trying to use it:
>
> [https-openssl-nio-8443-exec-13] ERROR org.zkoss.zk.ui.metainfo.Property -
> Failed to assign [value=${i18n:rt('Benutzername')}] to
> Unable to find ExpressionFactory of type: # Licensed to the Apache Software
> Foundation (ASF) under one or more
>
> Downgrading to 9.0.16-4 solves the issue.
Have you read the changelog or the Debian security announcement before
upgrading Tomcat 9 ? Does your application require the AJP protocol to
work? Then you probably need to slightly change your Tomcat
configuration. For more information please also refer to the official
documentation at
https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html
If that does not solve your problem, then we need more information about
your setup and configuration to debug the problem but note that we ship
the latest upstream version basically unmodified, so this would be most
likely an upstream bug.
Regards,
Markus Koschany
signature.asc
Description: OpenPGP digital signature
Bug#959747: tomcat8: Tomcat8 fix for CVE-2020-1938 breaks compatibility with Apache2 mod_proxy_ajp
Control: severity -1 normal Hello, Am 04.05.20 um 21:58 schrieb Gianluca Bonetti: > Package: tomcat8 > Version: 8.5.54-0+deb9u1 > Severity: grave > > Dear Maintainer, > > Last tomcat8 upgrade, fixing CVE-2020-1938, is breaking the > functionalities of Tomcat AJP connector > in standard setup. > The updated tomcat8 version implements 'secretRequired' parameter in > tag for config file > /etc/tomcat8/server.xml (attached by reportbut) and the implicit default > for 'secretRequired' is true. > The default value is not explicitly marked in the standard server.xml, > nor documented there. [...] The security update requires a manual update to your Tomcat 8 configuration, and only in specific cases. Debian cannot fix that automatically. The Tomcat 8 documentation is relevant here: https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html This is not a Debian bug and it works as intended. signature.asc Description: OpenPGP digital signature
Bug#953487: fixed in runescape 0.7-1
I suggest we wait a little for a response from non-f...@buildd.debian.org before we make another upload. However if there is no response in two weeks, we can just proceed by making a binary upload of runescape. Bug #956275 can be resolved by replacing the runescape.png icon. The license is most likely not BSD-2-clause. You should either document the correct license, the image must be distributable at least, or you can create or find your own icon. For instance you could create an image the same size with a black, red or blue background and then you add the R S initials in white. Simple icon, easily done. Bug #956276 is about an additional verification step, e.g. to verify the integrity of the launcher with a hashsum. You could store the value in a text file in our Git repository and then fetch the value and compare it with the hashsum of the binary before you run the java command. By storing the value in Git we can adjust the value whenever there is a new runescape update without having to make another Debian upload. This could be especially useful for stable releases. In any case I would try to avoid to hardcode the value. I don't consider bug #956276 release critical because there is no Debian Policy justification for it and there is no more risk involved than downloading the file with a web browser normally poses, so it should be treated as a normal or important bug. What you can and should do is to improve the package description. It should be clear that src:runescape is a mere script that downloads and runs the runescape launcher and that Debian cannot guarantee the integrity of this binary file because it is non-free and it is closed source. So simply warn about that in the package description and when your script is executed. The warning message could be displayed in a text terminal or you could use zenity to make it more user friendly and obvious. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#953487: fixed in runescape 0.7-1
Hello Carlos, I had uploaded the new version of runescape to fix bug 953487 because you stated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953487#25 that the package has been whitelisted. Apparently this is not the case hence I am writing to non-f...@buildd.debian.org again and I kindly ask that runescape is whitelisted for autobuilding. The package is basically a script and the license allows autobuilding. Thanks, Markus signature.asc Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
Am 09.04.20 um 15:18 schrieb Stephen Kitt: > Le 09/04/2020 14:47, Markus Koschany a écrit : >> Am 09.04.20 um 13:58 schrieb Stephen Kitt: >>> Le 09/04/2020 13:44, Markus Koschany a écrit : >>>> Am 09.04.20 um 13:24 schrieb Stephen Kitt: >>>>> On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany >>>>> wrote: >>>>>> Am 09.04.20 um 11:36 schrieb Ivo De Decker: > [...] >>> Installing a Debian package doesn’t involve downloading a tarball from >>> github.com or anywhere else. A packager downloads the tarball, vets it >>> in some way or other (hopefully), and then uploads it to Debian >>> infrastructure, where it is used to build the binary packages which >>> users eventually download. After the initial upload, the contents don’t >>> change, unless a new version is uploaded. >> >> In general we offer users the opportunity to rebuild a package from >> scratch. That sometimes includes precise instructions in README.source >> and a get-orig-source target in debian/rules but we often just assume >> that running uscan will download the same original tarball that is >> shipped in Debian's archive. In many cases this assumption is not true >> and users will get a different tarball. Nowhere do we enforce that the >> data is identical. > > We’re not talking about rebuilding the package (at least, I wasn’t). > > When a user installs a package in Debian, there’s a reasonable > expectation that the user will get when the maintainer intended. Even if > they choose to rebuild the package, the typical "apt source" invocation > will retrieve the source last used to build the Debian package, *not* > the upstream source. I was using the rebuilding the package from scatch example because your requirement that upstream files must be verified against a signature or hash is simply not true here. That we verify Debian packages in main and contrib with apt-secure is a given and is also true for runescape. However packages in main do not require software outside of the archive to function. They are self-contained. Thus your comparison between the runescape script in non-free and any package in main is flawed. > Incidentally, there is one place where we do enforce that the orig > tarball doesn’t change: when uploading to the archive... So there is > that expectation somewhere. All the effort that went into pristine-tar > also suggests that at least some people care about it in other > circumstances too. We do the same for runescape... > >>> Put another way, when you install a Debian package, you get the exact >>> same contents as any other user installing the same version of the >>> package, and thus a certain amount of collective trust can be built. >>> This isn’t necessarily the case with the runescape package. >> >> Right, because the runescape package does neither qualify for main nor >> contrib hence why it was put in non-free and for its purpose the level >> of trust is sufficient. > > The fact that a package is in non-free isn’t a blank cheque for it to do > anything it wants; Policy 2.2.3 still requires packages in non-free to > “meet all policy requirements presented in this manual that it is > possible for them to meet”. I disagree with the level of trust involved > but that’s a matter of opinion. > Now to answer your initial question, as far as I can tell there is no > Policy requirement that packages which download third-party files verify > the contents. Correct. So the severity of this bug report should not have been release critical. >>> Oh I know, we can’t do anything about trusting the publisher. The main >>> issue is that if for whatever reason a compromised JAR is put in place >>> on the upstream site, the runescape package will download it and run it >>> without any warning. Even the TLS protection doesn’t do much since the >>> download script doesn’t check the upstream certificate (so the site >>> could be hijacked and it would still work). >> >> As Simon has already pointed out, the binary hash/signature will >> probably change due to updates or other minor changes. That makes >> runescape prone to other RC bugs and any implementation to validate the >> launcher should take that into consideration. > > Not necessarily: note that I said “without any warning”. The package > could check the downloaded JAR against a signature, and if there’s a > mismatch, warn the user before running it. That wouldn’t make the > package prone to RC bugs. Sure, you can put as many warnings in runescape as you wish but it is still in non-free which is by definition _not part_ of Debian. This alone is a stark
Bug#956276: runescape: downloads unverified binary and runs it
Am 09.04.20 um 13:58 schrieb Stephen Kitt: > Le 09/04/2020 13:44, Markus Koschany a écrit : >> Am 09.04.20 um 13:24 schrieb Stephen Kitt: >>> On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany >>> wrote: >>>> Am 09.04.20 um 11:36 schrieb Ivo De Decker: >>>>> It seems runescape downloads a binary and runs it, without >>>>> verifying its >>>>> integrity. At least the download happens using https, but no other >>>>> verification is done. >>>> >>>> Could you quote the relevant part of Debian Policy, that requires >>>> verification (and what kind of verification) of downloaded files. Is >>>> downloading of verified orig tarballs now a requirement or is it still >>>> just sufficient to download the tarball and verify its integrity by >>>> hand? >>> >>> This is a bit different: runescape downloads a binary the first time >>> it’s >>> run by any given user, so each user can potentially get a different >>> binary. >>> Checking orig tarballs (whether using a signing key or manually) >>> produces a >>> result which remains the same for all users... >> >> How is this any different? It is possible that tarballs from github.com >> differ each time a user is downloading them, but we don't require >> verification. Where is this documented in Debian Policy as a "must" >> requirement? > > Installing a Debian package doesn’t involve downloading a tarball from > github.com or anywhere else. A packager downloads the tarball, vets it > in some way or other (hopefully), and then uploads it to Debian > infrastructure, where it is used to build the binary packages which > users eventually download. After the initial upload, the contents don’t > change, unless a new version is uploaded. In general we offer users the opportunity to rebuild a package from scratch. That sometimes includes precise instructions in README.source and a get-orig-source target in debian/rules but we often just assume that running uscan will download the same original tarball that is shipped in Debian's archive. In many cases this assumption is not true and users will get a different tarball. Nowhere do we enforce that the data is identical. > Put another way, when you install a Debian package, you get the exact > same contents as any other user installing the same version of the > package, and thus a certain amount of collective trust can be built. > This isn’t necessarily the case with the runescape package. Right, because the runescape package does neither qualify for main nor contrib hence why it was put in non-free and for its purpose the level of trust is sufficient. >> Note that we are talking about a non-free game here. The user has to >> trust the publisher and there is nothing Debian can do about it. We only >> provide a simple helper script to download the binary, which is done >> about a secure transport channel. This is just a little more convenient >> than to download it directly with your favorite web browser. > > Oh I know, we can’t do anything about trusting the publisher. The main > issue is that if for whatever reason a compromised JAR is put in place > on the upstream site, the runescape package will download it and run it > without any warning. Even the TLS protection doesn’t do much since the > download script doesn’t check the upstream certificate (so the site > could be hijacked and it would still work). As Simon has already pointed out, the binary hash/signature will probably change due to updates or other minor changes. That makes runescape prone to other RC bugs and any implementation to validate the launcher should take that into consideration. > Consider it this way: the packager will presumably check the package > before upload, and we can consider the JAR at that point to be > trustworthy (for some value of trustworthy). But there is absolutely no > guarantee that the JAR which users will receive bears any resemblance to > the JAR checked by the packager. If someone wants to implement some form of verification, hash or something else, please do. I still don't see why this issue is a Policy violation and why everyone seems to require the same standards as in main or contrib when the package is in non-free and does not have to comply with each and every part of the DFSG. In my opinion the package is very simple and sufficient for its purpose. A warning message may help here too. Construing a Policy violation seems wrong to me. signature.asc Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
Am 09.04.20 um 13:24 schrieb Stephen Kitt: > On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany wrote: >> Am 09.04.20 um 11:36 schrieb Ivo De Decker: >>> It seems runescape downloads a binary and runs it, without verifying its >>> integrity. At least the download happens using https, but no other >>> verification is done. >> >> Could you quote the relevant part of Debian Policy, that requires >> verification (and what kind of verification) of downloaded files. Is >> downloading of verified orig tarballs now a requirement or is it still >> just sufficient to download the tarball and verify its integrity by hand? > > This is a bit different: runescape downloads a binary the first time it’s > run by any given user, so each user can potentially get a different binary. > Checking orig tarballs (whether using a signing key or manually) produces a > result which remains the same for all users... How is this any different? It is possible that tarballs from github.com differ each time a user is downloading them, but we don't require verification. Where is this documented in Debian Policy as a "must" requirement? Note that we are talking about a non-free game here. The user has to trust the publisher and there is nothing Debian can do about it. We only provide a simple helper script to download the binary, which is done about a secure transport channel. This is just a little more convenient than to download it directly with your favorite web browser. signature.asc Description: OpenPGP digital signature
Bug#956268: Problems identified in debian/copyright
Control: severity -1 normal Am 09.04.20 um 12:51 schrieb Michael Lustfield: > Control: severity -1 serious > > src/lib/codemirror has > Copyright (C) 2017 by Marijn Haverbeke and others > This person is not mentioned in debian/copyright. > This files is NOT GPL-3+. > > > This is not a problem with my understanding of the format, this is a problem > with an incomplete debian/copyright file. The whole package is distributed under the GPL-3+ and MIT licensed code explicitly allows that. This is a minor documentation bug and will be fixed with one of the next uploads. Markus Koschany signature.asc Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
Control: tags -1 moreinfo Am 09.04.20 um 11:36 schrieb Ivo De Decker: > package: runescape > severity: serious > > Hi, > > It seems runescape downloads a binary and runs it, without verifying its > integrity. At least the download happens using https, but no other > verification is done. Could you quote the relevant part of Debian Policy, that requires verification (and what kind of verification) of downloaded files. Is downloading of verified orig tarballs now a requirement or is it still just sufficient to download the tarball and verify its integrity by hand? Markus Koschany signature.asc Description: OpenPGP digital signature
Bug#956268: Problems identified in debian/copyright
Control: severity -1 normal Control: tags -1 moreinfo Am 09.04.20 um 10:10 schrieb Michael Lustfield: > Package: ublock-origin > Version: 1.25.0+dfsg-1 > Severity: serious > > I noticed some issues with debian/copyright in this package. > > Missing from d/copyright: > - uAssets/thirdparties/hosts-file.net/* > - uAssets/fisters/annoyances.txt > - src/img/fontawesome > - src/js/codemirror > - src/lib/codemirror > - src/lib/publicsuffixlist > - src/lib/punycode.js > > > Note-1: I believe annoyances.txt is meant to be GPL-3+. > Please consider contacting upstream for clarification. Everything that is not explicitly mentioned in d/copyright is licensed under GPL-3+ because of the first license paragraph: Files: * Copyright: (C) 2014-2019 The uBlock Origin authors (C) 2014-2020 Raymond Hill License: GPL-3+ See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ to learn more about the copyright syntax. > Note-2: Rather than specifying each file, using globs on > "thirdparty/$location/*" would probably easier for you to maintain. Not all thirdparty files are non-free, using globs would be wrong. Currently it works as intended. > Note-3: Why are there changelog copies in debian/upstream? The amo-changelog tool in mozilla-devscripts does not work anymore. We cannot extract the latest changelog information with it and upstream does not ship a changelog file with the sources. The changelog copies in debian/upstream were the last time we could extract the information without any issues. Markus Koschany signature.asc Description: OpenPGP digital signature
Bug#955755: marked as pending in commons-configuration2
Control: tag -1 pending Hello, Bug #955755 in commons-configuration2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/commons-configuration2/-/commit/868a70a31bd1d9f61f5898f160715bd3cefcec44 Add commons-text.jar to the CLASSPATH. Closes: #955755 (this message was generated automatically) -- Greetings https://bugs.debian.org/955755
Bug#952062: marked as pending in openjfx
Control: tag -1 pending Hello, Bug #952062 in openjfx reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/openjfx/-/commit/73412f16343b07d15b2f27e25d5cbc1b3505e520 Fix FTBFS due to -Werror=deprecated-declarations. Closes: #952062 Thanks: Bas Couwenberg for the patch. (this message was generated automatically) -- Greetings https://bugs.debian.org/952062
Bug#948740: marked as pending in clanlib
Control: tag -1 pending Hello, Bug #948740 in clanlib reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/clanlib/-/commit/6359d134b61864eb1772c57be95230b19510a3ee Add remove-special-variable-perl-5.30.patch. Fix FTBFS and remove the occurrences of $* because the special variable $* is a fatal error in Perl 5.30. Not even upstream seemed to know what the code did back then. Closes: #948740 (this message was generated automatically) -- Greetings https://bugs.debian.org/948740
Bug#951959: marked as pending in megaglest
Control: tag -1 pending Hello, Bug #951959 in megaglest reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/megaglest/-/commit/0e4fd57cb77f2e4855f4aea58aefb5cdef7435f4 Add use-sdl2-config.cmake.patch. Mitigate SDL2 bug 951087. Closes: #951959 (this message was generated automatically) -- Greetings https://bugs.debian.org/951959
Bug#951974: marked as pending in spring
Control: tag -1 pending Hello, Bug #951974 in spring reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/spring/-/commit/afb8ced47358d0d887d1691a08c883ed0147c5ad Add use-sdl2-config.cmake.patch and workaround bug 951087 Closes: #951974 (this message was generated automatically) -- Greetings https://bugs.debian.org/951974
Bug#952049: pekka-kana-2: FTBFS: SDL_image.h:100:24: error: missing binary operator before token "("
Hi Carlos, I have uploaded pekka-kana-2 to unstable. The pristine-tar commit for version 1.2.6 was missing. Please don't forget to include it next time. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#951943: blockattack: FTBFS: SagoDataHolder.hpp:26:10: fatal error: SDL_mixer.h: No such file or directory
Hi Simon, thanks for the patch, very helpful. I have forwarded it upstream to https://github.com/blockattack/blockattack-game/issues/23 Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#951943: marked as pending in blockattack
Control: tag -1 pending Hello, Bug #951943 in blockattack reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/blockattack/-/commit/d3900ba42984518d25eb6c29b08448c957aa24c9 Fix FTBFS with recent SDL2 packages Closes: #951943 (this message was generated automatically) -- Greetings https://bugs.debian.org/951943
Bug#952295: marked as pending in freecol
Control: tag -1 pending Hello, Bug #952295 in freecol reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/freecol/commit/3e56efa7eee3694711a9b1a8e20fb4eb6a74b573 Build-depend on texlive-latex-extra to fix FTBFS. Closes: #952295 (this message was generated automatically) -- Greetings https://bugs.debian.org/952295
Bug#949301: marked as pending in ufoai
Control: tag -1 pending Hello, Bug #949301 in ufoai reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/ufoai/commit/017fe29c5151f7f0087a5c71a29ed9d30eaf32aa Add bug-949301-mxml.patch and fix invalid use of incomplete type mxml_node_t. Closes: #949301 (this message was generated automatically) -- Greetings https://bugs.debian.org/949301
Bug#951281: FTBFS: /usr/bin/ld: cannot find -lpthreads
On Wed, 19 Feb 2020 22:24:05 +0200 Juhani Numminen wrote: > Markus Koschany kirjoitti 19.2.2020 klo 20.32: > > Hello Juani, > > > > Am 15.02.20 um 09:49 schrieb Juhani Numminen: > > [...] > >> Markus, you have made team uploads of widelands before. I wonder if you > >> could make an upload that adds the patch? > > > > Could you adjust the patch to use the same mechanism to find SDL2 as in > > openjk? > > I actually started to work on that after receiving Simon's message, and > have now pushed the revised patch to a branch for your consideration. > > https://salsa.debian.org/games-team/widelands/commit/e470cba2029c459d3ab1bb6c385bfd4746a9dd05 > > -- > Juhani Thanks for the update! I have just uploaded a new revision to unstable. Best, Markus signature.asc Description: OpenPGP digital signature
Bug#951281: marked as pending in widelands
Control: tag -1 pending Hello, Bug #951281 in widelands reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/widelands/commit/e470cba2029c459d3ab1bb6c385bfd4746a9dd05 Use SDL2 CMake integration. Fixes FTBFS caused by FindSDL2.cmake being out of sync with SDL2. Closes: #951281 (this message was generated automatically) -- Greetings https://bugs.debian.org/951281
Bug#951281: FTBFS: /usr/bin/ld: cannot find -lpthreads
Hello Juani, Am 15.02.20 um 09:49 schrieb Juhani Numminen: [...] > Markus, you have made team uploads of widelands before. I wonder if you > could make an upload that adds the patch? Could you adjust the patch to use the same mechanism to find SDL2 as in openjk? https://salsa.debian.org/games-team/openjk/commit/22fd18c4f2fb01bce65bc8737536c123c5f4bceb Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#874870: Version 2.x is qt5-based
Hi, Am 14.02.20 um 23:12 schrieb Boyuan Yang: [...] > Since the complete removal of Qt4 is just around the corner, I am proposing to > do the following work to keep doomsday in Debian's development repository: > > * A Team-upload onto experimental of v2.2.2 with Qt5 support, > * NO support for /usr/games/ (why do we still force such path when it's > already 2020?), > * NO support for the alternatives system of /usr/games/doom, > * Dropping all Debian-specific patches (will review later), > * NO complete review of copyright information (know fixable issues, see > changelog) > > ...and I may solve those issues later and have the 2.x version back into > Sid/Testing. > > The git packaging repo is here: https://salsa.debian.org/games-team/doomsday . > If I did not upload on time, someone else can continue with the packaging > work. Thanks for working on doomsday. I just wanted to chime in and say that anything is better than just a removal but you should be aware of that installing the binary into /usr/games is a Debian Policy requirement and not something specific to doomsday. Everything else is up-to the person who actually works on the package. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#937393: pyblosxom: Python2 removal in sid/bullseye
According to upstream's notice on http://pyblosxom.github.io/, Pyblosxom is no longer in active development. There was the attempt to port it to Python 3 but this one was never completed. Nowadays we have several good alternatives in Debian that achieve the same thing, e.g. hugo or jekyll. I believe it is time now to file a removal request for pyblosxom. signature.asc Description: OpenPGP digital signature
Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response
Hi Salvatore, Am 17.01.20 um 06:31 schrieb Salvatore Bonaccorso: [...] > The patch proposed by Red Hat looks straightforward (with my limited > understanding though), but might have as well potential for regression > reports, as it is disabling deserialization by default, i.e. only uses > it if isEnabledForExceptions is set. > > So I'm wary yet on what to do for stable (and older releases and have > not done any marking yet in the security tracker. > > Opinions on that? I have just filed https://bugs.debian.org/949188 and asked the maintainer of starjava-topcat to remove the build-dependency on libxmlrpc3-client-java. As it turned out it is not even required to build the package. As I know the patch only disables the feature to convert an exception into a byte array but not deserialization as a whole. The problem is that the client cannot control if potential exceptions should be serialized and that opens a potential attack surface if someone is able to control those serialized exceptions. In my opinion the severity for Debian is low and besides starjava-topcat there is only eclipse-mylyn in Jessie that depends on the library. I don't see a potential regression in these packages but rather in the rare case when someone uses the library in a custom project. I believe a security announcement that explains the vulnerability and what property needs to be set in order to restore the old behavior should be sufficient. The version is identical in all distributions, so I think I can just prepare an update for Jessie/Stretch/Buster and we are done with it. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response
Hi, Am 16.01.20 um 21:27 schrieb Salvatore Bonaccorso: > Source: libxmlrpc3-java > Version: 3.1.3-9 > Severity: grave > Tags: security upstream > Justification: user security hole > > Hi, > > The following vulnerability was published for libxmlrpc3-java. > > CVE-2019-17570[0]: > | Deserialization of server-side exception from faultCause in XMLRPC > | error response > > That said, should libxmlrpc3-java rather be removed from unstable, and > not included in bullseye? [...] It looks like starjava-topcat is the only package that build-depends on libxmlrpc3-java at the moment (need to check that again). I think the issue itself can be fixed by the proposed Red Hat patch, making the use of some parts of the vulnerable method conditional on a set property. Since Apache xml-rpc is EOL it makes sense to remove it from Debian though. I will file a bug report for starjava-topcat and then let's see how it goes. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response
Control: owner -1 ! More information and proposed patch at https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-17570 signature.asc Description: OpenPGP digital signature
Bug#948224: pillow: CVE-2020-5310 CVE-2020-5311 CVE-2020-5312 CVE-2020-5313
Package: pillow X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for pillow. It appears they are fixed in version 6.2.2. CVE-2020-5310[0]: | libImaging/TiffDecode.c in Pillow before 6.2.2 has a TIFF decoding | integer overflow, related to realloc. CVE-2020-5311[1]: | libImaging/SgiRleDecode.c in Pillow before 6.2.2 has an SGI buffer | overflow. CVE-2020-5312[2]: | libImaging/PcxDecode.c in Pillow before 6.2.2 has a PCX P mode buffer | overflow. CVE-2020-5313[3]: | libImaging/FliDecode.c in Pillow before 6.2.2 has an FLI buffer | overflow. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-5310 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5310 [1] https://security-tracker.debian.org/tracker/CVE-2020-5311 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5311 [2] https://security-tracker.debian.org/tracker/CVE-2020-5312 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5312 [3] https://security-tracker.debian.org/tracker/CVE-2020-5313 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5313 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#948180: found 948180 in 4.1.2+dfsg-5, closing 948180
Am 05.01.20 um 13:39 schrieb Salvatore Bonaccorso: > Hi Markus, > > On Sun, Jan 05, 2020 at 01:26:37PM +0100, Markus Koschany wrote: >> Am 05.01.20 um 06:44 schrieb Salvatore Bonaccorso: >>> found 948180 4.1.2+dfsg-5 >>> close 948180 4.2.0+dfsg-1 >>> thanks >> >> You could have kept the bug report open until the issue is really fixed >> in unstable. I didn't see the new version in experimental until after I >> filed the bug report but sometimes such versions will stay there a long >> time for various reasons. There are tools like apt-listbugs that will >> warn unstable users about RC bugs but only if someone files bug reports. > > The BTS (ans various tools) can handle the version tracking (and even > close a bug with multiple versions, this is actually what for instance > happends if a fix goes in as well via stable and oldstable and > contains a respective bug closer as well) -- this is the reason why I > first marked 4.1.2+dfsg-5 as found (which contains the bug), and then > one can close the bug (BTS will still see that it's unfixed in > unstable accordingly). > > So either the fix then goes in by cherry-picking fixes for unstable on > top of 4.1.2+dfsg-5 or it goes in via a subsequent upload to unstable > of the 4.2.0 version. > > See as well the respective graph the BTS know: > https://bugs.debian.org/cgi-bin/version.cgi?absolute=0;fixed=4.2.0%2Bdfsg-1;found=4.1.2%2Bdfsg-5;info=1;package=opencv;collapse=1 By closing the bug report it disappeared from https://tracker.debian.org/pkg/opencv There is no "action required" bullet point and the RC bug count is zero now. The bug is also marked as resolved now. https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=opencv I know the BTS but it was completely sufficient to mark the bug as fixed in experimental, you didn't have to close it. People usually don't look up the BTS graph to understand if their version is affected and they will check the most obvious places first. If bugs are getting closed in stable and oldstable, then those have been fixed in nearly all cases in unstable as well already. Markus signature.asc Description: OpenPGP digital signature
Bug#948180: found 948180 in 4.1.2+dfsg-5, closing 948180
Am 05.01.20 um 06:44 schrieb Salvatore Bonaccorso: > found 948180 4.1.2+dfsg-5 > close 948180 4.2.0+dfsg-1 > thanks You could have kept the bug report open until the issue is really fixed in unstable. I didn't see the new version in experimental until after I filed the bug report but sometimes such versions will stay there a long time for various reasons. There are tools like apt-listbugs that will warn unstable users about RC bugs but only if someone files bug reports. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#948180: opencv: CVE-2019-5063 and CVE-2019-5064
Package: opencv X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for opencv. CVE-2019-5064[0]: | An exploitable heap buffer overflow vulnerability exists in the data | structure persistence functionality of OpenCV, version 4.1.0. A | specially crafted JSON file can cause a buffer overflow, resulting in | multiple heap corruptions and potentially code execution. An attacker | can provide a specially crafted file to trigger this vulnerability. CVE-2019-5063[1]: | An exploitable heap buffer overflow vulnerability exists in the data | structure persistence functionality of OpenCV 4.1.0. A specially | crafted XML file can cause a buffer overflow, resulting in multiple | heap corruptions and potential code execution. An attacker can provide | a specially crafted file to trigger this vulnerability. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-5064 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5064 [1] https://security-tracker.debian.org/tracker/CVE-2019-5063 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5063 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#947212: Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager
Hello Niels, Am 23.12.19 um 15:04 schrieb DebBug: > Anyone to chime in? Craig? Markus? There is a bit of confusion here, so I try to explain the situation and how we should proceed. Thank you for filing bug report #947212 to track the security issues in Wordpress. This will help to answer those questions raised by Adam. However there was already #946905 that you could have been used as well. You have only recently added me to CC, presumably because I have done some security uploads in the past for Wordpress. I don't know what you have discussed with Craig and if he wants to review your work and sponsor it later. Then you actually don't need to open a sponsorship request on debian-mentors. Sponsorship requests are either of severity normal or important. Here it would be ok to use important but the severity is merely an indicator and it doesn't automatically guarantee that a bug is prioritized. Security related bugs like #947212/#946905 are either of severity important or grave. Version 5.3.2 seems to fix a couple of security vulnerabilities. No CVE has been assigned yet. This version should be uploaded to unstable. If you want to fix Wordpress in Buster and Stretch as well, then you have to go a different route. The security team is responsible for that. As previously discussed I recommend to base security updates on upstream releases for specific Wordpress branches. https://wordpress.org/download/releases/ Buster should be updated to version 5.0.8 and Stretch to 4.7.16. In both cases you would base your work on the Wordpress packages in Buster and Stretch. The changes to the debian files should be minimal, you would merely rebase existing patches and repack the tarball to make it compliant with the DFSG. In short: Version 5.3.2 -> unstable Did Craig agree with the upload? If there is simply no response because of the holiday season we could do a NMU with a delay of 5 to 10 days. I assume you haven't made any major changes to the package. After that: Version 5.0.8 -> buster-security Version 4.7.16 -> stretch-security You can already prepare the packages, then we contact the security team and ask for approval. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#945115: armagetronad does not find itself (and fails to start)
Control: tags -1 pending Am 20.11.19 um 14:45 schrieb Bernhard Übelacker: > Control: tags -1 + upstream fixed-upstream patch > > > Dear Maintainer, > the issue seems to be with newer gcc versions string literals > get not put into memory mappings " r-xp ", > instead they are mapped " r--p ". > > Such a string literal is used to determine the location > of the executable. > > Upstream fixed it already [1] [2]. > The issue points also to a fallback if reading from > memory fails, which might be worth to consider [3]. > > Kind regards, > Bernhard > > > [1] https://gitlab.com/armagetronad/armagetronad/issues/6 > [2] > https://gitlab.com/armagetronad/armagetronad/commit/aad48287a98d32112c8600ee8d1b96de25500987 > [3] > https://gitlab.com/armagetronad/armagetronad/commit/90036a889d6ca9fbcf4ce950e0e803eb2204e06b Thanks for reporting. A upload is pending which will address this issue. Best, Markus signature.asc Description: OpenPGP digital signature
Bug#925337: fixed in ublock-origin 1.22.2+dfsg-1~deb9u1
Hello, You have to enable the -proposed-updates archive in Stretch to download the latest version of ublock-origin. It will be merged to stable eventually. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#944431: marked as pending in berusky2
Control: tag -1 pending Hello, Bug #944431 in berusky2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/berusky2/commit/d253ecdf60c7bbe6a431faced3198f503c1d8929 Build with no optimization to avoid a segfault with GCC 9. Closes: #944431 Thanks: Enrico Zini for the report. (this message was generated automatically) -- Greetings https://bugs.debian.org/944431
Bug#943870: marked as pending in auralquiz
Control: tag -1 pending Hello, Bug #943870 in auralquiz reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/auralquiz/commit/067418a58c74c1e036f190f6333e6822294fc462 Fix FTBFS by adding -lphonon4qt5 to LDFLAGS. Thanks: Steve Langasek for the report and JanKusanagi for the fix. Closes: #943870 (this message was generated automatically) -- Greetings https://bugs.debian.org/943870
Bug#942507: pdfsam: Not working due to multiple errors
Control: severity -1 important I'm downgrading this issue to important because pdfsam in testing is not affected. As long as hibernate-validator 5.x does not migrate to testing, before this bug is fixed in unstable, it should not be a problem signature.asc Description: OpenPGP digital signature
Bug#925337: webext-ublock-origin: deactivated with Firefox 66
Control: block 943470 by 942349 Hello, Am 25.10.19 um 01:49 schrieb Jens Rottmann: > Ping. > > As Jonas anticipated, regression in Stable: ublock no longer works after > Firefox ESR updated to 68. > > Thanks and best regards, > Jens The testing version of ublock-origin is pending approval by the release team. [1] Once they approve the backport, I will upload 1.22.2+dfsg to stable and oldstable. Regards, Markus [1] https://bugs.debian.org/942349 signature.asc Description: OpenPGP digital signature
Bug#943439: src:asc: Please update/remove libwxgtk3.0-dev build-dependency
Hi Olly, Am 24.10.19 um 21:31 schrieb Olly Betts: > Package: src:asc > Version: 2.6.1.0-5 > Severity: serious > Justification: blocks the almost-complete wxwidgets3.0-gtk3 transition [...] Thanks for reporting. I have uploaded a new revision of asc that uses libwxgtk3.0-gtk3-dev instead of libwxgtk3.0-dev and it seems to make no difference. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#943439: marked as pending in asc
Control: tag -1 pending Hello, Bug #943439 in asc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/asc/commit/3d482be76754148688721f79e23aa93c59198a20 Replace libwxgtk3.0-dev build-dependency with libwxgtk3.0-gtk3-dev. Closes: #943439 (this message was generated automatically) -- Greetings https://bugs.debian.org/943439
Bug#942814: libhibernate-validator-java: update to 5.3.6 breaks reverse-dependencies
Package: libhibernate-validator-java Version: 5.3.6-1 Severity: serious The update of libhibernate-validator-java to version 5.3.6. broke at least pdfsam (#942507) and libspring-java. The new version is incompatible with libgeronimo-validation-1.0-spec-java and requires libgeronimo-validation-1.1-spec-java. In addition libhibernate-validator-java should add classmate.jar to its CLASSPATH because it won't work without it. Still PDFsam fails to work because libhibernate-validator-java causes another exception because of a missing el-api.jar and/or el-impl.jar file on the CLASSPATH. Some internet research suggests this is a known problem with version 5.x but at the moment I don't know if this is a packaging error or whether it requires a patch for the affected reverse-dependencies. Markus
Bug#942507: pdfsam: Not working due to multiple errors
Control: tags -1 confirmed On Thu, 17 Oct 2019 12:41:57 +0200 Domenico Cufalo wrote: > Package: pdfsam > Version: 4.0.4-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I'm sorry for the generic subject of this bug report, but... I don't know how > to explain it better. > > Anyway, when I try to split/extract/add some PDFs, simply the app does nothing > and gives this output: Hello and thanks for reporting. tl;dr In short, if you want a working PDFsam package in unstable at the moment, downgrade libhibernate-validator-java to 4.3.4-1. You can find the Debian package at http://snapshot.debian.org/ I can confirm your findings. Apparently the update of libhibernate-validator-java to version 5.3.6 broke PDFsam. There are multiple problems at the moment. First of all the latest version of libhibernate-validator-java requires libgeronimo-validation-1.1-spec-java because version 1.0 is incompatible. This can be solved by simply updating libsejda-java and changing the build-dependeny and maven.rule file. Then we also have to update pdfsam and symlink geronimo-validation-1.1-spec.jar in debian/rules. Additionally we need a symlink to classmate.jar and el-api. The former should be definitely added to the CLASSPATH of libhibernate-validator-java and I will file a new bug report for this one. Now I am stuck at the following error message: java.lang.ExceptionInInitializerError: null Caused by: javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found I don't know if someone has already packaged com.sun.el.ExpressionFactoryImpl and why it is necessary at all. So far for now Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#935669: assaultcube-data (1.2.0.2.1-3) in enabled autobuilding
Hi, Am 17.10.19 um 01:53 schrieb Carlos Donizete Froes: > Hi, > > The assaultcube-data (1.2.0.2.1-3) package includes "XS-Autobuild: yes" in the > header portion of "debian/control"[1] and the disclaimer compliance with the > licenses contained in "debian/copyright"[2] where It's okay to create the > software automatically across multiple architectures and distribute it. > > [1] https://sources.debian.org/src/assaultcube-data/1.2.0.2.1-3/debian/control > > [2] > https://sources.debian.org/src/assaultcube-data/1.2.0.2.1-3/debian/copyright > > If so, could you approve this package or do I need to target something else? > > Thanks! I believe the only thing that's missing is an email to nonf...@release.debian.org and ask them to accept assaultcube-data to be built on Debians buildd network in the future. https://www.debian.org/doc/manuals/developers-reference/ch05.html#non-free-buildd I hope they read this email and act accordingly. If you don't receive a response, we can still upload assaultcube-data but then we just need to remember to upload the binary packages as well because source-only uploads won't work. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable
Hello, Am 16.10.19 um 20:30 schrieb Romain Francoise: > Hi Guillem, > > On Mon, Oct 14, 2019 at 3:45 PM Guillem Jover wrote: >> With the latest upload to oldoldstable-security, the versions in >> oldstable and stable are now lower. This means that upgrades will >> not take effect for this package, which will be left built against >> libraries and packaging from oldoldstable. > > Yes, the jessie-lts team kinda jumped the gun here. I think the best > way forward is to request approval for a buster-pu update of tcpdump > to 4.9.3 as well... > > Salvatore, any thoughts? > > Thanks. I was assuming that Romain prepared the updates for stable again, so the corresponding backports will be 4.9.3-1~deb9u1 and 4.9.3-1~deb10u1 respectively exactly as it was done last time with the backport of 4.9.2. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#941687: lablie: FTBFS with jackson-databind 2.10.0
Hello Miroslav, Am 07.10.19 um 09:36 schrieb Miroslav Kravec: > Hello Markus, > > thank you for informing about this issue. Is this blocking you? Are > you releasing a new version of jackson databind to Debian? > > Kind regards, > Miro Not at all. I had to package a new release of jackson-databind to fix some CVE. After a rebuild of all reverse-dependencies I noticed that lablie FTBFS. There were only three or four errors, so it shouldn't be too hard to adapt lablie to the new version. Maybe upstream already has a fix for that? Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#941530: jackson-databind: CVE-2019-16942 CVE-2019-16943
Control: clone 941530 -1 Control: retitle -1 jackson-databind: consider using a whitelist Control: severity -1 wishlist Hi, Am 02.10.19 um 09:43 schrieb Salvatore Bonaccorso: [...] > Whilst I'm not yet sure if we should really release a futher DSA for > jackson-databind (we will come back to you on that), a possible idea > for bullseye (might be better cloned/filled as new bug, but want to > mention it here already): > > https://bugzilla.redhat.com/show_bug.cgi?id=1731271 > > Red Hat recently had fixed a CVE for codehaus. The approach they took > there was to rather continuing on jackson-databind side (that is my > interpretation), they started a whitelist approach on the applications > side which use jackson-databind. > > This might be something to consider for bullseye as well for the > reverse dependencies. Not sure if this is feasible in our case, but > this might be worth investigating. Good idea. Let's investigate this solution. I will track that in another bug report. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#941530: jackson-databind: CVE-2019-16942 CVE-2019-16943
Hi Salvatore, Am 01.10.19 um 22:34 schrieb Salvatore Bonaccorso: > Source: jackson-databind > Version: 2.10.0-1 > Severity: grave > Tags: security upstream > Justification: user security hole > Forwarded: https://github.com/FasterXML/jackson-databind/issues/2478 > Control: found -1 2.9.8-3 > Control: found -1 2.8.6-1+deb9u5 > Control: found -1 2.8.6-1 > > Hi, > > Tony, Markus, As it was already expected ;-). Upstream, whilst it > affects as well 2.10.0, seemigly is not considering doing an update > for 2.10 specifically but have fixed this one as well for older > versions. Previous point, that this is just going to start to be silly > upholds. > > That said, let's follow with the usual information: > > The following vulnerabilities were published for jackson-databind. [...] First of all, thank you very much for taking care of reporting these issues. Please let me know if you think this is a DSA-worthy issue. Otherwise I will just ask the release team for an update. Personally I believe we can treat that as an important issue from now on. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#874870: Version 2.x is qt5-based
Hello, Am 29.09.19 um 22:38 schrieb Moritz Mühlenhoff: > On Sun, Mar 18, 2018 at 09:11:24PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: >> Hi! Version 2.x is qt5-based. Please check if you can update this game. Feel >> free to ask for help with Qt5 if needed. > > It's been 1.5 years and we're now moving forward with the Qt4 removal. The > package > hasn't been uploaded since 2017, does anyone plan to update in the next weeks, > otherwise it'll be removed along with Qt4. > > Cheers, > Moritz I consider Michael Gilbert as the one who is responsible to reply to this issue because he is the initial uploader of doomsday. I have only fixed release critical bugs before to keep the package in Debian. Doomsday is an active project but I don't intend to maintain it alone. I suggest to keep it in unstable to give others the chance to work on the existing bugs even if Qt4 should have been removed from Debian. If there is no activity before we intend to release Debian 11, then I have absolute no objections to remove this package from Debian. Best, Markus signature.asc Description: OpenPGP digital signature
Bug#940498: jackson-databind: CVE-2019-14540 CVE-2019-16335
Control: tags -1 pending On Mon, 16 Sep 2019 15:14:37 +0200 Salvatore Bonaccorso wrote: > Source: jackson-databind > Version: 2.9.9.3-1 > Severity: grave > Tags: security upstream > Justification: user security hole [...] > p.s.: wondering where that will going to end ;-) Hi, I also think it is starting to get silly now. I will upload 2.10.0 to unstable shortly but I suggest to address these kind of issues from now on only via stable-updates. This can be done two or three times per year. It is basically just adding new classes to the blacklist. I believe the whole approach of blacklisting classes is not very sophisticated. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#874809: [alsoft-conf] Future Qt4 removal from Buster
Hi, Am 02.09.19 um 20:56 schrieb Moritz Mühlenhoff: [...] > alsoft-conf is dead upstream, does anyone in the Debian Games Team intend to > port it themselves? Otherwise I'll file a removal bug. I'm fine with removing alsoft-conf from Debian. There was only one initial upload by the actual uploader of the package and I made the only other upload eight years later to fix some bugs and clean up the package. I guess it won't be missed. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#933854: marked as pending in lucene-solr
Control: tag -1 pending Hello, Bug #933854 in lucene-solr reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/lucene-solr/commit/f58985f500c3ef0c7e874c011ac02ea0c1776de4 Disable obsolete call to ContextHandler in solr-jetty9.xml Install solr-permissions.conf into /etc/systemd/system/jetty9.service.d/ and override read-only permissions of Jetty9. Closes: #933854 #933857 Thanks: Stephan Beirer for the report. (this message was generated automatically) -- Greetings https://bugs.debian.org/933854
Bug#933854: solr-jetty: Jetty lacks necessary write permissions to /var/lib/solr/data/index/
Control: tags 933857 pending Control: tags 933854 pending On Sun, 1 Sep 2019 19:47:48 -0700 "J.P. Larocque" wrote: > stephan, thanks for tracking this down. I almost figured it out, and > then I found that you already reported this bug. Your other bug > report was also super helpful for me to get Solr working after my > upgrade to Buster. [...] Thanks for the report. Stephan is correct. The permissions of jetty9 must be overridden by solr-jetty. I don't know what call should replace the current addAliasCheck, so I have just commented it out and leave it to the system administrator to configure it until we have found a better default value. I will backport this change to Buster too. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e
I pushed more changes to Git. We could fix the NullPointerException in insubstantial but now I get two different errors. Failed to register bus name / null and NoClassDefFoundError: org/slf4j/LoggerFactory I don't know why this class is suddenly missing from the classpath. signature.asc Description: OpenPGP digital signature
Bug#911078: triplea: Fails to start with NullPointerException
Hello, On Wed, 7 Aug 2019 08:36:38 -0700 Dan Van Atta wrote: > Apologies for the long delay, updates to Debian are a deeper issue than I > initially realized. TripleA has had a history of maintenance overhead > problems, seeing the Debian fork has me realize that it is a fork with its > own unique code and in effect would be a second codebase to maintain. I do > not think it's sustainable to maintain two code bases as has been done. Of > note, it's difficult sustaining development in the core codebase itself and > there's been a lot of effort to improve efficiency there in order to make > progress in substantially improving the game. I wouldn't call the Debian packaging of triplea a fork. When I was packaging the last version for Debian I discovered that you used the non-free org.json:json artifact with the infamous copyright clause. I reported it upstream at https://github.com/triplea-game/triplea/issues/2672 So two patches, JSONException.patch and no-evil-json.patch do merely exist because of that reason. Since the issue has been already fixed upstream both patches can be dropped now. Then we have no-Mac.patch with MacOS specific code which is problematic with OpenJDK 11 and which didn't work on Debian. disable-javazoom-audioplayer.patch exists because nobody has packaged the javazoom audio player. And last but not least we have the build.patch to work around various issues with the Gradle build system. That's not a fork in my opinion but a call for more help in packaging triple in a Debian compliant way. > With that said, I think the solution is to try and incorporate the Debian > patches into the main codebase to the largest extent possible. In that case > the Debian version could be a clean fork of the main codebase and would > remove the second maintenance effort. I've opened a tracking issue in the > Github issue queue to discuss this amongst the TripleA developers and > greater community: https://github.com/triplea-game/triplea/issues/4933. > Input and coordination on that effort from the Debian side would be very > welcome. While I'm not sure if we can make the Debian version a 'true' > fork, having the main repo and Debian fork mirror as closely as possible > should reduce redundant maintenance efforts and make this process more > sustainable. Including our patches would be greatly appreciated. But as I said some do merely exist because due to a lack of contributors, some patches can be dropped and the other ones could be incorporated but it requires some work. What we would like to do in Debian is just download your release tarball and create a Debian package without patching at all. :) Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#933715: jh_linkjars: dpkg -L "debhelper-compat" returned exit code 1
Package: javahelper Version: 0.72.9 Severity: serious jh_linkjars apparently chokes on the new debhelper-compat package. Since it is not a real package dpkg -L does not work. I presume the workaround is to either add debhelper-compat to a blacklist or to find a more general way to not use dpkg -L on virtual packages. This bug can be reproduced by switching to debhelper-compat = 12, e.g. in lombok-patcher. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages javahelper depends on: ii bsdmainutils 11.1.2+b1 ii dctrl-tools 2.24-3 ii debhelper12.2.3 ii devscripts 2.19.6 ii dpkg-dev 1.19.7 ii libarchive-zip-perl 1.64-1 ii perl 5.28.1-6 javahelper recommends no packages. javahelper suggests no packages. -- no debconf information
Bug#931097: unattended-upgrades: InvalidURL(f"URL can't contain control characters. {url!r} "
Hello, Am 26.06.19 um 09:59 schrieb duncanwebb: > Package: unattended-upgrades > Version: 0.83.3.2+deb8u1 > Severity: serious > Justification: normal > > Dear Maintainer, > > Jessie uses python 3.4 and python 3.4 does not support f"" strings > > So now unattended upgrades no longer performs security upgrades. [...] Thank you for reporting this issue. We have corrected this problem with the upload of python3.4 version 3.4.2-1+deb8u4 yesterday. Unfortunately a manual upgrade is required, afterwards unattended-upgrades will continue to work again as intended. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#930676: goplay: Should this package be removed?
Hello, On Tue, 18 Jun 2019 12:46:30 +0200 Julian Andres Klode wrote: > Package: goplay > Severity: serious > > Hi folks, > > goplay has not received any updates since 2015, it uses libept, > which we'd like to get rid of eventually I think, as it's also > unmaintained, so I think it would be best to remove it. I agree with you in general. However, IMHO, can we defer this decision to buster +1 or is this really imminent. AFAIK the package works for Buster? Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#929483: marked as pending in robocode
Control: tag -1 pending Hello, Bug #929483 in robocode reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/robocode/commit/f8279e0af99e864e957613f7ef278d744cfc6cd8 Use javahelper and missing library classes to the classpath to fix startup error with Java 11. Thanks: Bardot Jerome for the report. Closes: #929483 (this message was generated automatically) -- Greetings https://bugs.debian.org/929483
Bug#925509: netbeans: Netbeans not usable with java in Buster
Hi Jochen, Am 03.05.19 um 13:47 schrieb Jochen Sprickerhof: [...] > This is due to libnb-javaparser-java which is still on the jdk-9 > version. [...] > So one way would be to get this packaged (maybe rename nb-javac-9-*.jar > to nb-javac-11-*.jar) and convince the release team to include include > this into buster. Normally we should upgrade libnb-javaparser-java to the JDK 11 compatible version. If I had known such a version existed, I would have packaged this one in January. > An other option may be to drop the nb-javac.patch and reopen #920707. > According to: > > https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac > > https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac > > Netbeans should work without nb-javac (but I really tried it). This > would trade the #925509 rc bug against a normal bug and we would be able > to release with buster. > > What do you think? If we drop the nb-javac.patch we will surely see new bug reports because the warning confuses people. Your links also mention some caveats when not using nb-javac, possible code completion errors and whatnot. So the user is forced to live with those caveats or download nb-javac manually. The latter solution might be preferable at the moment because of the freeze, but the point of packaging Netbeans for Debian was, that you can install Netbeans with system libraries. Now you have to download prebuilt binary files even for core features. There is also bug #920706 that makes Git unusable. One cannot even work around it by downloading the plugin from the internet. So yes, we can do that but I wonder if we should keep Netbeans out of Buster because it does not live up to the quality of the current version in Stretch. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#925509: netbeans: Netbeans not usable with java in Buster
Hi, Am 02.05.19 um 20:56 schrieb Jochen Sprickerhof: [...] > I had a look into this was able to create new projects when I remove the > nb-javac.patch. @Markus do we really need it? The nb-javac patch is necessary, otherwise the nb-javac module is not properly detected at runtime. You should see an error message when you start Netbeans for the first time then. Did you remove ~/.netbeans and ~/.cache/netbeans before you installed the version without the patch? I believe you are on the right track though. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#928240: etw: Segmentation fault at start
Thank you very much. I have uploaded a new revision with your patch a few minutes ago. The game itself appears to work, the settings menu for the controls is a bit hidden. ETW was originally developed for the AMIGA, so that may explain some of the oddities. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#928240: Bug #928240 in etw marked as pending
Control: tag -1 pending Hello, Bug #928240 in etw reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/etw/commit/6b4e59c19a33ff38a98e0802d849ecf42277a9cd Add debian-bug-928240.patch Closes: #928240 Thanks: Bernat for the report and Steinar H. Gunderson for the patch. (this message was generated automatically) -- Greetings https://bugs.debian.org/928240
Bug#928240: etw: Segmentation fault at start
Hi, Am 01.05.19 um 00:31 schrieb Steinar H. Gunderson: > On Tue, Apr 30, 2019 at 11:23:52PM +0100, Simon McVittie wrote: >>> On a quick analysis: It appears that etw tries to find its own path by >>> opening /proc/self/maps (code is in etw/prefix.c), looking for an executable >>> mapping (r-xp) that contains the string "", and then looking at the path. >> This seems unnecessarily complicated? /proc/self/maps is Linux-specific, >> and if relying on Linux-specific things is acceptable, then >> evaluating the symlink /proc/self/exe seems a lot easier. (See >> e.g. Sys_FindExecutableName() in darkplaces.) > > Yes; it seems to be written by someone whose primary experience was with > Windows, given that it talks about LINUX and not Linux. :-) > > However, given that we are in deep freeze, you probably want the smallest > possible fix for buster. > > /* Steinar */ Thanks for providing a solution and a way forward. Could you provide a trivial fix/patch as well? I'm willing to test it and ask the release team for an unblock. I currently don't understand the underlying issue and why it was triggered in the first place but I gladly accept patches. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#927152: teeworlds: CVE-2019-10877 CVE-2019-10878 CVE-2019-10879
Package: teeworlds X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for teeworlds. CVE-2019-10877[0]: | In Teeworlds 0.7.2, there is an integer overflow in CMap::Load() in | engine/shared/map.cpp that can lead to a buffer overflow, because | multiplication of width and height is mishandled. CVE-2019-10878[1]: | In Teeworlds 0.7.2, there is a failed bounds check in | CDataFileReader::GetData() and CDataFileReader::ReplaceData() and | related functions in engine/shared/datafile.cpp that can lead to an | arbitrary free and out-of-bounds pointer write, possibly resulting in | remote code execution. CVE-2019-10879[2]: | In Teeworlds 0.7.2, there is an integer overflow in | CDataFileReader::Open() in engine/shared/datafile.cpp that can lead to | a buffer overflow and possibly remote code execution, because size- | related multiplications are mishandled. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-10877 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10877 [1] https://security-tracker.debian.org/tracker/CVE-2019-10878 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10878 [2] https://security-tracker.debian.org/tracker/CVE-2019-10879 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10879 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#888547: CVE-2017-1000190
Hi, Am 13.04.19 um 11:31 schrieb Ivo De Decker: [...] > It is possible to remove the test-dependency (probably by disabling the > tests)? That way simple-xml could be removed from buster. Even if we don't do > this for buster, it might be good to do this for bullseye anyway, if the > package isn't really maintained. Simple-xml is only required to build carrotsearch-randomizedtesting. It is not a test-dependency though. However I have just disabled the only module in carrotsearch-randomizedtesting that uses simple-xml, which is junit4-ant. If we do that then lucene4.10 will FTBFS but it requires only a simple patch to tell the build system not to look for the now missing junit4-ant dependency. Apparently the removal makes no difference for lucene4.10. I can implement those changes in the coming days. Regards, Markus signature.asc Description: OpenPGP digital signature
