Bug#1069538: zeroc-ice: FTBFS on armel: Gradle / Java heap space
An NMU diff for the upload to fix this bug is attached. Thanks to Vladimir Petko and Tony Mancill on the [debian-java] mailing list for the fix https://lists.debian.org/debian-java/2024/05/msg1.html -- Chris Knadle chris.kna...@coredump.us diff -Nru zeroc-ice-3.7.10/debian/changelog zeroc-ice-3.7.10/debian/changelog --- zeroc-ice-3.7.10/debian/changelog 2024-04-10 10:48:17.0 -0400 +++ zeroc-ice-3.7.10/debian/changelog 2024-05-04 13:55:38.0 -0400 @@ -1,3 +1,15 @@ +zeroc-ice (3.7.10-2.3) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: +- Add GRADLE_OPTS=-Xmx512M to fix FTBFS on armel due to Java heap space + memory error + Thanks to Vladimir Petko and + Tony Mancill for the fix +(Closes: #1069538) + + -- Christopher Knadle Sat, 04 May 2024 13:55:38 -0400 + zeroc-ice (3.7.10-2.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru zeroc-ice-3.7.10/debian/rules zeroc-ice-3.7.10/debian/rules --- zeroc-ice-3.7.10/debian/rules 2024-04-10 10:25:18.0 -0400 +++ zeroc-ice-3.7.10/debian/rules 2024-05-04 13:55:38.0 -0400 @@ -19,7 +19,6 @@ java_compat_level ?= 8 export JAVA_HOME=/usr/lib/jvm/default-java/ - # # Use the system gradle unless it has been overridden by GRADLE # environment variable. @@ -35,6 +34,10 @@ -PiceBuilderClassPath=com.zeroc.gradle.ice-builder endif +# GRADLE_OPTS memory setting to work around FTBFS on armel +# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069538 +export GRADLE_OPTS=-Xmx512M + export GRADLEARGS = --gradle-user-home $(CURDIR)/.gradle \ --info \ --console plain \
Bug#1069538: zeroc-ice: FTBFS on armel: Gradle / Java heap space out-of-memory error
retitle 1069538 zeroc-ice: FTBFS on armel: Gradle / Java heap space out-of-memory-error tags 1069538 - moreinfo thanks I've done additional test builds of zeroc-ice-3.7.10-2.2 on armel on porter boxes amdahl and abel and the build fails with the same error which seems to be during a Java memory check. It is still unclear as to why this error is happening now but not previously. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1069538: zeroc-ice: FTBFS on armel: make[3]: out of memory error
Hello Lucas. The zeroc-ice 3.7.10-2.2 package built correctly on an armel buildd within two weeks ago: https://buildd.debian.org/status/logs.php?pkg=zeroc-ice=3.7.10-2.2=armel The underlying error in the build logs you sent looks like an out-of-memory condition: > Failed to execute org.gradle.process.internal.health.memory.DefaultMemoryManager$MemoryCheck@12c1b75. > java.lang.OutOfMemoryError: Java heap space > An exception has occurred in the compiler (17.0.11). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.OutOfMemoryError: Java heap space > :test:compileJava FAILED > :test:compileJava (Thread[Task worker for ':' Thread 3,5,main]) completed. Took 5 mins 20.937 secs. I suspect this isn't a bug in the zeroc-ice package. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1069538: zeroc-ice: FTBFS on armel: appears to be out-of-memory condition
tags 1069538 + moreinfo thanks
Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble
Hello Remus-Gabriel. Okay I've queued up the Romanian translation file to be included with the next upload of Mumble. There are several library transitions going on in Debian, so I'm going to wait a bit for those. I also did an NMU on zeroc-ice which was blocked from transition to Testing due to a FTBFS bug related to the time_t transition because of a newly enabled build flag that caused the build to break with an error. Let me know if you've contacted Mumble upstream about the Romanian translation; if not I'll contact them to see if we can get it included in the source directly. On 4/9/24 18:11, Remus-Gabriel Chelu wrote: Hello Chris, În 08.04.2024 22:22, Chris Knadle a scris: Is it as simple as renaming the mumble_debconf_ro.po file to ro.po and moving it to debian/po/ro.po ? Yes, this is the way to introduce translation within the project, or, even simpler: mv mumble_debconf_ro.po debian/po/ro.po renaming and moving into a single command. Respects, Remus-Gabriel PS: Sorry for the inconvenience caused, I grouped into my machine several translation files (of several programs) in the same folder, for their own convenience; so I had to differentiate them somehow from each other, and I chose to prefix their names with the name of the program for which they are made. The only inconvenience was not knowing how to incorporate the file into the Debian package -- the workflow described above makes sense. As long as I know what to do and can make the time I'm willing to do the work needed to incorporate desired changes. Thanks very much for your work -- Chris Knadle chris.kna...@coredump.us
Bug#1067911: Diff for fix of FTBFS bug
Attached is the NMUdiff for fixing FTBFS Bug #1067911 which would keep zeroc-ice from migrating to Testing. -- Chris -- Chris Knadle chris.kna...@coredump.us diff -Nru zeroc-ice-3.7.10/debian/changelog zeroc-ice-3.7.10/debian/changelog --- zeroc-ice-3.7.10/debian/changelog 2024-02-29 19:14:45.0 -0500 +++ zeroc-ice-3.7.10/debian/changelog 2024-04-10 10:48:17.0 -0400 @@ -1,3 +1,13 @@ +zeroc-ice (3.7.10-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * debian/patches: +- Add remove-Werror-build-option.patch to fix FTBFS bug due to injection + of "inplicit-function-declaration" flag during time_t 64bit transition + (Closes: #1067911) + + -- Christopher Knadle Wed, 10 Apr 2024 10:48:17 -0400 + zeroc-ice (3.7.10-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch --- zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch 1969-12-31 19:00:00.0 -0500 +++ zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch 2024-04-10 10:32:22.0 -0400 @@ -0,0 +1,18 @@ +Description: remove -Werror build option to fix FSBFS issue + During the time_t 64bit transition the "implicit-function-declaration" build + flag is injected and this breaks the build when -Werror is set +Author: Christopher Knadle +Bug: https://bugs.debian.org/1067911 +Last-Update: 2024-04-10 + +--- a/config/Make.rules.Linux b/config/Make.rules.Linux +@@ -137,7 +137,7 @@ + -pie $(if $(filter yes,$(new_dtags)),-Wl$(comma)--enable-new-dtags,-Wl$(comma)--disable-new-dtags) \ + $$(call unique,$$(foreach d,$($4_dependencies),$$(call make-rpath-link-ldflags,$$d,$($4_dependencies) + +-cppflags= -Wall -Wextra -Wredundant-decls -Wshadow -Wdeprecated -Werror -pthread $(if $(filter yes,$(OPTIMIZE)),-DNDEBUG,-g) ++cppflags= -Wall -Wextra -Wredundant-decls -Wshadow -Wdeprecated -pthread $(if $(filter yes,$(OPTIMIZE)),-DNDEBUG,-g) + ldflags = -pthread + + # -Wshadow is too strict with gcc 4 diff -Nru zeroc-ice-3.7.10/debian/patches/series zeroc-ice-3.7.10/debian/patches/series --- zeroc-ice-3.7.10/debian/patches/series 2023-11-07 04:45:43.0 -0500 +++ zeroc-ice-3.7.10/debian/patches/series 2024-04-10 10:27:07.0 -0400 @@ -1 +1,2 @@ java-build.patch +remove-Werror-build-option.patch
Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]
On 4/10/24 10:02, Andrey Rakhmatullin wrote: On Wed, Apr 10, 2024 at 09:52:44AM -0400, Chris Knadle wrote: Removing -Werror looks like it would be a simple patch, it seems to be set here: config/Make.rules.Linux:cppflags = -Wall -Wextra -Wredundant-decls -Wshadow -Wdeprecated -Werror -pthread $(if $(filter yes,$(OPTIMIZE)),-DNDEBUG,-g) ... but this also doesn't sound like the right answer. Yes, it just turns the error into a warning, it's still better to remove the problem that causes this warning, but it's *also* better to not use -Werror when building Debian packages. That's probably true. I've made a patch to do this, I'll do a test build and then upload an NMU. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]
On 4/10/24 04:32, Andrey Rakhmatullin wrote: On Tue, Apr 09, 2024 at 09:50:37PM -0400, Chris Knadle wrote: Apparently this new bug got introduced with the time_t 64bit transition: Yes, but it's a valid bug in the package, not a bad thing accidentally introduced by the transition. That doesn't sound right. The zeroc-ice source code does not set the '-Werror=implicit-function-declaration' build option. I think these two lines in debian/rules in the package are where CFLAGS get set: DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk In other words, whatever bug this is seems to be due to a change in reasonable default configs from Debian, not in the source. (?) Can the CFLAGS be cleared with: DEB_CFLAGS_SET="" What I don't know is what has to be done now to get zeroc-ice fixed. Does this require an upload to disable the implict-function-declaration flag Please don't disable it. I see two options here: either fix the package to not use $CFLAGS to build C++ code or fix the package to not use -Werror. From examining the source, zeroc-ice doesn't set CFLAGS when building with Linux.The source of CFLAGS being set seems to be set by dpkg-buildflags Removing -Werror looks like it would be a simple patch, it seems to be set here: config/Make.rules.Linux:cppflags = -Wall -Wextra -Wredundant-decls -Wshadow -Wdeprecated -Werror -pthread $(if $(filter yes,$(OPTIMIZE)),-DNDEBUG,-g) ... but this also doesn't sound like the right answer. But clearing CFLAGS seems like it would be reasonable. I need to fix this to allow zeroc-ice to transition to Testing, in order to allow mumble to transition to Testing. Note that it won't transition to testing before the time64 transition to to testing is allowed. -- Chris Knadle chris.kna...@coredump.us
Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]
Hello Audrey. Apparently this new bug got introduced with the time_t 64bit transition: "abi=time64 turns on -Werror=implicit-function-declaration in dpkg-buildflags, which causes unrelated build failures." See: https://wiki.debian.org/BrainDumpT64 https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=4993fe783 What I don't know is what has to be done now to get zeroc-ice fixed. Does this require an upload to disable the implict-function-declaration flag, or does this simply require a binNMU? I need to fix this to allow zeroc-ice to transition to Testing, in order to allow mumble to transition to Testing. -- Chris -- Chris Knadle chris.kna...@coredump.us Source: zeroc-ice Version: 3.7.10-2.1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=zeroc- ice=armhf=3.7.10-2.1=1711639887=0 arm-linux-gnueabihf-g++ -g -O2 -ffile-prefix-map=/<>=. -fstack- protector-strong -fstack-clash-protection -Wformat -Werror=format-security -MT modules/IcePy/build/arm-linux-gnueabihf/shared/pic/Grammar.o -MMD -MP -MF modules/IcePy/build/arm-linux-gnueabihf/shared/pic/Grammar.Td -Wall -Wextra -Wshadow -Wdeprecated -Werror -pthread -DNDEBUG -Imodules/IcePy -I../cpp/include -I../cpp/include/generated -I../cpp/src -I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash- protection -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O2 -Wall -Wno- missing-field-initializers -Wno-psabi -fPIC -fvisibility=hidden -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -c ../cpp/src/Slice/Grammar.cpp -o modules/IcePy/build/arm- linux-gnueabihf/shared/pic/Grammar.o cc1plus: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror] cc1plus: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror] cc1plus: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror] cc1plus: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]
Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble
Hello Remus-Gabriel. I would like to know how to incorporate the Romanian translation file into the Mumble 1.5.517 package. Is it as simple as renaming the mumble_debconf_ro.po file to ro.po and moving it to debian/po/ro.po ? It has been some time since I've dealt with translation files and I'm trying to figure out if there's something special necessary to do with the translation file for the packaging. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us On 4/5/23 19:18, Remus-Gabriel Chelu wrote: 3 aprilie 2023 la 07:44, "Chris Knadle" a scris: [...] Hello, Chris! I just finished checking the status of the debconf-mumble translation file (in Romanian) with the following commands: $: git clone https://salsa.debian.org/pkg-voip-team/mumble $: cp -v ../Documente/mumble_debconf_ro.po mumble/debian/po/ro.po $: LANG=en msgfmt -c -v -o /dev/null mumble/debian/po/ro.po 8 translated messages. and: #: cd mumble/ #: podebconf-display-po -fdialog debian/po/ro.po with good results; exactly as expected. So, from my side, considering the results of the test performed, the "ro.po" file can be added to mumble 1.5.517 without any problems.
Bug#1068504: mumble-server: wrong path for systemd-sysusers file
Greetings. As far as I know /etc/sysconfig.d/ is a directory used by Fedora/Red Hat based distros, not Debian. Looking through the Git log I see I added this on Feb 1 2023 with the following commit message: add etc/sysconfid./mumble-server.conf as the build breaks without it at compat 13 (it's commit f0cdad5245c6d1de6bff9223c6ce5767c13f9e45) /usr/lib/sysusers.d/*.conf does seem like where this file should go. I've made local Git commits to fix this for the next bugfix upload (1.5.517-3). Before doing any more uploads I need to look at what's going on with a number of library transitions going on that could get negatively affected by uploads of mumble. -- Chris -- Chris Knadle chris.kna...@coredump.us On 4/6/24 09:12, Stefan Schweizer via Pkg-voip-maintainers wrote: Package: mumble-server Severity: normal Hi, mumble-server installs a systemd-sysusers file to /etc/sysconfig.d According to the sysusers.d(5) man page sysusers files can be placed in /etc/sysusers.d/*.conf /run/sysusers.d/*.conf /usr/lib/sysusers.d/*.conf So installing the sysusers file to /etc/sysconfig.d has no effect and it should be moved to /usr/lib/sysusers.d. Since the mumble-server user is created by the debian package I think the sysusers file is unnecessary and can be omitted until a switch to sysusers is made.
Bug#1063711: mumble: autopkgtest fixes
Hello Diederik. Thanks for working on the autopkg test failure and including patches -- I'm about to try to incorporate them. I also pushed the Mumble 1.5.517 release from my local Git to Salsa; sorry I missed that. I wasn't in the Debian VoIP Packaging Team mailing list, so that's how I missed these bugs for a couple of months. I'm under heavy life burden right now but I hope I'm turning the corner and will be able to free up some time in a few weeks. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1060254: mumble: please make the build reproducible
Hello Chris and Diederik I missed that a couple of bugs came in for Mumble because it turns out up to now I had not signed up for the Debian VoIP Packaging Team mailing list. *sigh* It's going to take me some time to figure out the correct 'sieve' rules to get the Mumble bug messages to show up in my 'Debian-Bugs' mail folder so that I'll be able to quickly catch new bugs coming in. It's going to take a few weeks before I will be able to start work on packaging Mumble v.1.5.613, but I hope I can do an upload with the patches for reproducibility and fixing the autopkgtest 'smoke' test. Thanks for working on reproducibility in the Mumble package. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#999989: planning to NMU poco to orphan it
Hello Jochen. What I want to do is orphan the Poco package as an NMU and then do an NMU of a new version -- in that order. It seems to be the right thing to do for this situation. I had a brief discussion with [debian-qa] and was given feedback that the plan seems reasonable: https://lists.debian.org/debian-qa/2024/01/msg6.html The NMU uploads will go to a -delayed queue to allow stopping it or increasing delay if there is an objection. On 1/5/24 07:30, Jochen Sprickerhof wrote: * Chris Knadle [2024-01-02 16:53]: The way to orphan a package is to do an upload and setting the maintainer to be . Until that's done the package ends up in maintainership limbo. See the bottom of Policy 3.3, and Developer's Reference section 5.9.4. Agreed but I think that is something for the Maintainer: to do, who seems to be active in Debian, otherwise. Unfortunately that's not what I see. Feel free to add additional information. The last activity I've been able to find from Krzysztof was an upload of clamfs 2020-01-10. For Poco the last activity from him is 2009. The Git repository for Poco shows one commit 2009-08-30 and one package upload 2009-09-01. I find no email in [debian-devel] from him as far back as 2014. The Debian bug tracker last activity was January 2011 with one email in Bug #500134. Looking at his website, the first thing on the main page mentions ClamFS. The clamfs package in Debian has him as the only listed maintainer and the package has dropped out of Testing because of the Poco library dropped and there as has been no response. Bug #679125 for clamfs from 2012 has had no response. I sent email to the Debian MIA team but have not yet heard back from them. Assuming I can get contact with the MIA team and they start their process, that will take about six months. -- Chris -- Chris Knadle chris.kna...@coredump.us Debian Developer
Bug#999989: poco 1.1 uses PCRE3, Mumble 1.5 depends on poco
On 1/5/24 07:30, Jochen Sprickerhof wrote: * Chris Knadle [2024-01-02 16:53]: The way to orphan a package is to do an upload and setting the maintainer to be . Until that's done the package ends up in maintainership limbo. See the bottom of Policy 3.3, and Developer's Reference section 5.9.4. Agreed but I think that is something for the Maintainer: to do, who seems to be active in Debian, otherwise. Normally, yes. But it also doesn't do to have a maintainer that doesn't communicate concerning a package; that's the #1 responsibility a package maintainer has. The situation with Poco clearly fits the criteria for when "salvaging" a package is needed: https://wiki.debian.org/PackageSalvaging The RC bug for Poco is holding back the following list of source packages from migrating: clickhouse, clamfs, gm-assistant, gpsshogi, mumble. Feel free to ask if you have questions regarding maintaining a library. The main thing I'd like to understand is how to do coordinate the transition (i.e. the release) with the Release Team. I found some hints about that here: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#lib-trans -- Chris Knadle chris.kna...@coredump.us
Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco
Hello Jochen. On 1/4/24 02:44, Jochen Sprickerhof wrote: Hi Chris, * Chris Knadle [2024-01-02 03:06]: Can the poco library be updated? Can I help in some way? poco is basically orphaned, as I dropped myself from Uploaders in git and did not hear from the other maintainers for some time. The best way to help is to step up as a maintainer and update it ;). The way to orphan a package is to do an upload and setting the maintainer to be . Until that's done the package ends up in maintainership limbo. See the bottom of Policy 3.3, and Developer's Reference section 5.9.4. https://www.debian.org/doc/debian-policy/ch-binary.html#the-maintainer-of-a-package https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package https://wiki.debian.org/Orphaning I may be able to prepare an updated version to upload as an NMU (i.e. it would be Debian version 1.13.0-0.1), but I can't take over maintaining this package long-term because I don't use it and am not familiar with it -- I only maintain a package that has it as a required build dependency. I also haven't maintained a library yet, but I've been in this situation of needing to upload a newer version of a library before so I might be able to figure out what's required to prepare an upload. It would be interesting to upload a new version as an NMU with the maintainer marked as but strangely that seems to be what's called for here. Unless the Poco library can be updated the only way to save Mumble will be to introduce an epoch in the package version to upload the now well outdated mumble 1.3.4 again which upstream cannot support anymore. Nit: please don't use epochs for that, also see Policy 5.6.12.1. Hah ... okay so if absolutely required I could upload mumble "1.5.517+really1.3.4-2". As crazy a version scheme as that is it beats having to introduce an epoch that I'd have to live with forever, so I'm glad to know that trick. Thanks. -- Chris Knadle chris.kna...@coredump.us
Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco
All recent versions of Mumble now require Poco to build and will not build without it. Unless the Poco library can be updated the only way to save Mumble will be to introduce an epoch in the package version to upload the now well outdated mumble 1.3.4 again which upstream cannot support anymore. Can the poco library be updated? Can I help in some way? -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: 1.5.517 in salsa repository; systemd unit works now
Hello Sven. I've verified that your fix of the system unit and other changes allows mumble-server to start. :) I've tested the resulting packages, things look good as far as I can tell. I think I can finally release this. Doing some final touches to get it out the door. -- Chris -- Chris Knadle chris.kna...@coredump.us On 12/8/23 11:36, Sven Hartge wrote: On Fri, 3 Mar 2023 06:16:00 + Chris Knadle wrote: If someone knows how to fix the mumble-server.service file so that mumble-server can start, that would be helpful; once that's fixed I can make an upload to Debian Experimental. The file in the tree is at: Hello Chris, I looked at the problem and I fixed all the problems (and some more) preventing the daemon to start under systemd.
Bug#1043037: Reasonable fork of MLMMJ available now
retitle 1043037 Switch upstream source to fork after release of MLMMJ 1.4 summary 1043037 MLMMJ upstream is dead since 2017, but users of MLMMJ have created a usable fork with new features; it's time to switch to it thanks New location for ongoing fork MLMMJ releases (current release is 1.4.3): https://codeberg.org/mlmmj/mlmmj/releases -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: 1.5.517 in salsa repository [was: Version bump: 1.4.230]
Hello Sven, thank you for your quick response. On 12/18/23 03:57, Sven Hartge wrote: On 18.12.23 07:37, Chris Knadle wrote: Thank you very much for your efforts on this bug. Most the changes the patches make and offhand look reasonable, and for the moment I've pulled them from the 'improvement' branch your mumble Git repo. However I'm wondering about the permissions change to /etc/mumble as to why that's desired: chown root:mumble-server /etc/mumble/ What is the benefit of updating the /etc/mumble/ directory to have group ownership by mumble-server? Is the intent for allowing a number of users that are added to the mumble-server group to be allowed to update the mumble-server.ini file? Let me know so I can explain it. ;-) The problem is access to the configuration. If /etc/mumble is root:root and 750, then the daemon, running as mumble-server:mumble-server can't read its configuration file and fails to start. Okay, right, because there are no "other" read or execute permissions to allow traversing the directory. So /etc/mumble needs to be readable by the group, either 755 (which is worse security-wise) or owned by the group, which is the change I implemented. The configuration file itself is 640 and root:mumble-server, so the group can't change it. Accepted. Grüße, Sven. Grüße. Thanks -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: 1.5.517 in salsa repository [was: Version bump: 1.4.230]
Hello Sven. Thank you very much for your efforts on this bug. Most the changes the patches make and offhand look reasonable, and for the moment I've pulled them from the 'improvement' branch your mumble Git repo. However I'm wondering about the permissions change to /etc/mumble as to why that's desired: chown root:mumble-server /etc/mumble/ What is the benefit of updating the /etc/mumble/ directory to have group ownership by mumble-server? Is the intent for allowing a number of users that are added to the mumble-server group to be allowed to update the mumble-server.ini file? Let me know so I can explain it. ;-) Thanks On 12/8/23 11:36, Sven Hartge wrote: On Fri, 3 Mar 2023 06:16:00 + Chris Knadle wrote: If someone knows how to fix the mumble-server.service file so that mumble-server can start, that would be helpful; once that's fixed I can make an upload to Debian Experimental. The file in the tree is at: Hello Chris, I looked at the problem and I fixed all the problems (and some more) preventing the daemon to start under systemd. You can either pull from https://salsa.debian.org/hartge/mumble.git or apply the attached diff. I tested my changes for fresh installations and upgrades, both work correctly. These changes fix #1039271 as well. Grüße, Sven. -- Chris Knadle chris.kna...@coredump.us
Bug#1039271: mumble: ships sysv-init script without systemd unit
Greetings. I'll to try to incorporate the upstream .service file if possible.b The issue I keep running into with .service files with mumble-server is that I'm not able to get the daemon to start with systemd with most of the .service files I've seen and tried for it so far. Had worked out a working .service file for mumble-server many moons ago as part of another bug report, but I haven't been able to find that work I did again in order to incorporate that. Lack of being able to work out a working .service file is also what has led to delay in releasing Mumble 1.5.517 which I've had a package mostly ready for release since February. :-( Thanks for finding the upstream mumble 1.3.4 service file, I hope that will work in the test VM I have for it. -- Chris On 11/12/23 07:59, Chris Hofstaedtler wrote: Control: reassign -1 mumble-server Hi, * bl...@debian.org : Package: mumble Severity: important Usertags: missing-systemd-service [..] mumble has been flagged by Lintian as shipping a sysv-init script without a corresponding systemd unit file. The default init system in Debian is systemd, and so far this worked because a transitional sysv-init-to-unit generator was shipped by systemd. This is in the process of being deprecated and will be removed by the time Trixie ships, so the remaining packages that ship init scripts without systemd units will stop working. Upstream actually includes a .service file in the source tree, as can be seen here: https://sources.debian.org/src/mumble/1.3.4-4/scripts/murmur.service/ It seems like installing it with a small patch for the Debian path derivation should hopefully do the job. Best, Chris
Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble
Hello Remus-Gabriel. Please let me know if this Romanian translation file will work with mumble 1.5.517 which exists in the Debian Salsa mumble repository. https://salsa.debian.org/pkg-voip-team/mumble If it does I can add it to the work-in-progress mumble 1.5.517. I can't add this to the current mumble package in Debian main because there's a freeze going on in preparation for the release of Debian 12 (Bookworm). -- Chris -- Chris Knadle chris.kna...@coredump.us Remus-Gabriel Chelu: Package: mumble Severity: wishlist Tags: l10n, patch Dear Maintainer, Please find attached the Romanian translation of the «mumble» file. Thanks, Remus-Gabriel
Bug#1017780: 1.5.517 in salsa repository [was: Version bump: 1.4.230]
Greetings all. The current 1.5.517 packaging work has been uploaded to Debian Salsa. I intend to upload 1.5.517-1 to Debian Experimental after figuring out how to fix upstream's mumble-server.service file, which is currently broken. Right now mumble-server will not start, and the sysv init script was also removed upstream for 1.5.x. I'd also like to re-introduce the init script as an "extra" so that users/admins can use mumble-server with init systems other than systemd. The package builds, the binary packages are installable, and both mumble-server (started manually) and mumble both work. Right now The "DBUILD_NUMBER" to indicate the minor version [517] is hardcoded in debian/rules, and that will need to be scripted to fill in as a variable from the Debian package version number instead. I had been asked to abandon work on packaging 1.4.x in favor of 1.5.x because 1.5.x was designed to work on OpenSSL 3.0. Mumble 1.4.230 also contained unreleasable files requiring DFSG modifications to the tarball, so I reverted to a backup of my local repository, and thus 1.4.x was not introduced to the mumble repository on Salsa. If someone knows how to fix the mumble-server.service file so that mumble-server can start, that would be helpful; once that's fixed I can make an upload to Debian Experimental. The file in the tree is at: auxiliary_files/config_files/mumble-server.service.in -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1031160: reason for removal of zeroc-ice on armhf and arm64.
Greetings. I'd like to know the status of mumble-server on armhf and arm64 and whether it can be restored for those architectures, because mumble server is commonly run on that hardware and is one one of the base expected programs for the FreedomBox project which has a number of hardware targets for armhf and arm64. https://freedombox.org/ If there's a way I can help let me know, and please keep me in the loop if feasible. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us (maintainer of mumble in Debian) Adrian Bunk: On Tue, Feb 14, 2023 at 11:56:40AM +, Peter Green wrote: I recently became aware that mumble's build-dependencies were no longer satisfiable on armhf due to a missing zeroc-ice. I looked at the build logs for zeroc-ice and all were green. So I looked at the removal log and found the following. [Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott Kitterman] Removed the following packages from unstable: libzeroc-ice-dev | 3.7.8-2.1 | arm64, armhf libzeroc-ice3.7 | 3.7.8-2.1 | arm64, armhf libzeroc-icestorm3.7 | 3.7.8-2.1 | arm64, armhf mumble-server |1.3.4-4 | arm64, armhf php-zeroc-ice | 3.7.8-2.1 | arm64, armhf python3-zeroc-ice | 3.7.8-2.1 | arm64, armhf zeroc-glacier2 | 3.7.8-2.1 | arm64, armhf zeroc-ice-compilers | 3.7.8-2.1 | arm64, armhf zeroc-ice-utils | 3.7.8-2.1 | arm64, armhf zeroc-icebox | 3.7.8-2.1 | arm64, armhf zeroc-icebridge | 3.7.8-2.1 | arm64, armhf zeroc-icegrid | 3.7.8-2.1 | arm64, armhf zeroc-icepatch2 | 3.7.8-2.1 | arm64, armhf Closed bugs: 1031160 --- Reason --- RoQA; openjfx no longer builds on arm64 and armhf, build-depends not available This strikes me as strange in a couple of ways. 1. The only relationships of zeroc-ice to openjfx are in build-depends-indep and in the binary dependencies of an arch all package. Afaict it is perfectly normal for build-depends-indep and the binary dependencies of arch all packages to only be satisfiable on a subset of the architectures where 2. Only one of the two binaries from the mumble source package was removed. Was this removal just a mistake? or was there a reason behind it that I am not seeing? As requestor of #1031160 I would say this was a mistake, perhaps due to https://tracker.debian.org/pkg/openjfx Issues preventing migration: ∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes beast2-mcmc/2.7.3+dfsg-1/arm64 uninstallable ∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes josm/0.0.svn18646+dfsg-1/arm64 uninstallable ∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes pdfsam/4.3.4-1/arm64 uninstallable This will require a hint from the release team I have not yet requested, since installability of binary-all packages is tested on amd64 and arm64 but there is no requirement that a binary-all package is installable on arm64 and several are not.[1] cu Adrian [1] https://release.debian.org/britney/testing_uninst.txt
Bug#1017780: Version bump: 1.4.230
Hello Jarl. Jarl Gullberg: I've got a patchset that reworks the control files for proper CMake support and a couple of fixes to the existing patches in order to make 1.4.287 play nice with OpenSSL 3.0. I'm not sure if I've updated the upstream source in line with policy for this package, though, and could use some help making sure I'm doing it right. Debian Unsable is currently in "soft freeze" because of the upcoming release of Debian 12 "Bookworm", such that only small targeted fixes can be uploaded at this point. https://release.debian.org/testing/freeze_policy.html It's not realistic to try to upload 1.4.287 to Debian to get it into the next release at this point. However; it would still be useful to have a newer version packaged in order to release it for the Mumble Ubuntu PPA which is also out of date. I've been working on the Mumble 1.5.517 snapshot release, but unfortunately its not ready for release because the systemd service file it ships is broken and the sysv init file was removed. I'll send another email to this bug + all involved with the bug as to the status of the 1.5.517 work and what got uploaded to Debian (1.3.4-4) and the MR requests that were incorporated. At the moment, this is what I've done: 1. downloaded the upstream release tarball 3. renamed it to mumble_1.4.287.orig.tar.gz 2. cd mumble && pristine-tar commit ../mumble_1.4.287.orig.tar.gz 3. unpack tarball in upstream branch, commit and tag as 'upstream/1.4.287' 4. merge 'upstream' into 'debian' I haven't tested doing the above manually, but on first glance it looks right. I believe these are the same general steps that git-buildpackage does when running 'gbp import-orig '. If you don't use git-buildpackage yet and are interested there are some hints about using it here: https://wiki.debian.org/PackagingWithGit And the DebConf conferences have recorded videos on using git-buildpackage also, I think starting around 2013. I only found the 'extras/make-mumble-git-tarball.sh' script after the fact, and I do see that that script does some cleanup. I'm also seeing a lot of dpkg-source warnings about removed files when I build, so I'm pretty sure I've done something wrong. If you're importing a tarball, make-mumble-git-tarball.sh isn't meant to be used. The make-mumble-git-tarball.sh was specifically written for mumble 1.3 from Git and isn't meant for Mumble 1.4 and above; 1.4 changes file structure significantly. It was a script I had to build because at the time upstream wanted me to release Mumble 1.3 and there wasn't a tarball available to do it from, and Mumble's git repo uses submodules such that a standard 'git archive' command to build a tarball won't work alone. Upstream built another tool to extract a tarball from git which is a Python 3 script which is part of the upstream Git repo, so the make-mumble-git-tarball.sh script I created is outdated. https://github.com/mumble-voip/mumble/pull/6016 This is how to create a 1.5.x tarball within the 1.5.x Git checkout: scripts/create_source_archive.py --revision 1.5.x --format=tar But again this is only for the situation of creating a tarball from Git to work from; it's not needed if there's already a tarball to import. That aside, everything seems to run fine (with some hiccups related to config files for mumble-server that I assume has something to do with the above). I can open up a couple of MRs on Salsa if you want, provided I can get some handholding in regards to how you want it done :) Please do not open an MR right now, as I have 1.5.517 to push to the repo, so I won't be able to pull an MR for 1.4.287 unless its to a Git branch, which I don't know how to do off the top of my head. Also, MRs for the Mumble repo in Salsa are disabled for all but those within the VoIP team for now, because they've been happening without my knowledge. I need to figure out how to configure email notifications -- there were MRs put there for a long time that I was never notified by, with no BTS bug report associated with. I never knew MRs in Salsa were a thing until discussion about them in this particular bug. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1030813: mumble: autopkgtest regression
The autopkgtest smoke test still fails when calling /usr/bin/mumble because of not being able to connect to a display. I'm uploading another package that avoids calling mumble in the smoke test but still calls /usr/sbin/murmurd which should still pass, so I'll be closing this bug with it. [Feel free to re-open the bug if it returns.] - autopkgtest [03:17:07]: test smoke: [--- qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. Aborted autopkgtest [03:17:07]: test smoke: ---] autopkgtest [03:17:07]: test smoke: - - - - - - - - - - results - - - - - - - - - - smokeFAIL non-zero exit status 1 --------- -- Chris Knadle chris.kna...@coredump.us
Bug#1030813: mumble: autopkgtest regression
This should be fixed in Mumble 1.3.4-3. debian/tests/control had this: Test-Command: smoke when it should have been: Tests: smoke If the autopkgtest passes tomorrow as shown in the Debian tracker I'll close this bug. -- Chris -- Chris Knadle chris.kna...@coredump.us Adrian Bunk: Source: mumble Version: 1.3.4-2 Severity: serious https://ci.debian.net/data/autopkgtest/testing/amd64/m/mumble/31139421/log.gz ... autopkgtest [09:23:28]: test command1: smoke autopkgtest [09:23:28]: test command1: [--- bash: line 1: smoke: command not found autopkgtest [09:23:29]: test command1: ---] autopkgtest [09:23:29]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL non-zero exit status 127
Bug#1017780: Version bump: 1.4.230
Diederik de Haas: On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: What I really need is a Debian source package that uses CMake to see an example of how to build a package. I'm looking at list of packages that reverse depend on cmake, maybe I can find a Debian source package that build-depends on CMake that way. Maybe https://salsa.debian.org/cryptocoin-team/monero ? It uses CMake and upstream uses .gitsubmodules Yes the Debian monero package uses cmake and the debian/rules file does too which is indicated by this: DH_OPTIONS = -O--buildsystem=cmake %: dh $@ $(DH_OPTIONS:-O%=%) When I was looking at Debian packaging with cmake I saw that it's possible to differentiate files into binary packages in a new way. Instead the monero.install and monero-tests.install files in debian/ for the monero and monero-tests binary packages look traditional, which may simplify the transition, so that's something useful. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: Version bump: 1.4.230
Diederik de Haas: Hi Chris, On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: So I'd suggest skipping 1.4 altogether and go straight for 1.5. You _could_ now release a development snapshot (to Experimental?), especially if the package needs to go through NEW and then the update to the 1.5 released version should be (relatively) small (I'd guess). I want to release Mumble 1.5 when possible ... but this isn't about releasing to Unstable vs Experimental -- The reason I mentioned Experimental is that you can use that to get things through NEW if needed, while not blocking potential updates for Unstable/ Testing/Bookworm. Mostly because one doesn't know how long that'll take. I'm aware of Experimental, I believe I've uploaded to Experimental before. It's a worthwhile thought for aa release that may not be fitting (yet) for Unstable, which the current Mumble 1.5 would theoretically fit that because it's not released yet. Keep in mind -- any release to Experimental cannot be uploaded to Unstable with the same version #. i.e. anything in Experimental is strictly a work-in-progress. I believe once a package is released to Unstable with a higher version # than that of Experimental, the Experimental version is removed. it's about the fact that there isn't a 1.5 source tarball to work from to do any release at all. With snapshot I did mean using 'some' upstream git commit, like current HEAD. I'll try to find an example of that as I *know* they exist. Yes, I know. Many upstream packages that are in Git can be exported directly to a tarball and then built as a Debian package. Mumble is NOT one of those. Mumble's Git repo has submodules that are considered separate such that "git archive" won't export the submodules, and the code won't build without them. Also the submodules contain files that have restrictive copyright, making them unreleasable. So the process of /building/ a releasable tarball from several "git archive" operations, extraction, file deletion, re-tarring is messy with Mumble when trying to export it from Git. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: Version bump: 1.4.230
Hello Diederik. Diederik de Haas: On Tuesday, 6 December 2022 13:39:23 CET Diederik de Haas wrote: On 3 Nov 2022 08:00:00 + Chris Knadle wrote: tags 1017780 + help I've mentioned this bug in #debian-mentors (on OFTC), but it could help if you'd join that channel and ask yourself so you can get direct feedback on direct questions/issues you're encountering. I referenced this bug in the upstream repo and got a response which I think is REALLY helpful with dealing with this bug and the OpenSSL issue... On 3 Nov 2022 08:00:00 + Chris Knadle wrote: Mumble 1.5.x works with OpenSSL 3.0 but is still in development and not ready for release. Krzmbrzl in https://github.com/mumble-voip/mumble/pull/5354#issuecomment-1339277805: However, I will work on releasing 1.5 as soon as I find the time for it (maybe around Christmas?), which should solve the issue anyway So I'd suggest skipping 1.4 altogether and go straight for 1.5. You _could_ now release a development snapshot (to Experimental?), especially if the package needs to go through NEW and then the update to the 1.5 released version should be (relatively) small (I'd guess). I want to release Mumble 1.5 when possible ... but this isn't about releasing to Unstable vs Experimental -- it's about the fact that there isn't a 1.5 source tarball to work from to do any release at all. Here's the Stable releases: https://dl.mumble.info/stable/ Here's the snapshots: https://dl.mumble.info/snapshot/ The Stable release area has a source tarball available for 1.4 only, and the snapshots don't have any source tarballs for any version at all. So there's no 1.5 source snapshots available that I can find to make a package from. In order to get the source for 1.5 right now, as far as I know one would have to use Git to /build/ it using multiple 'git archive' operations, extract, and re-combine in order to build a custom tarball due to use of git submodules, while removing unreleasable files from the tarball that exist in the submodules. This is error prone enough that I built a script 'debian/extras/make-mumble-git-tarball.sh' in the Debian Mumble 1.3.0~git20190125.440b173+dfsg-2 release to do this, because at the time a Mumble 1.3 release was needed and there wasn't a better option than to do this. I'm attaching that script to this email so you can see for yourself what's involved. Mumble 1.5 reorganized a lot of files with the CMake redesign, so I'm quite sure this old script could not be used as-is to do the same thing today without a lot of tweaking. I've discussed the possibility of doing this with upstream and we mutually agreed against it, and that for now it's better to wait for an upstream tarball release of Mumble 1.5. Assuming a Mumble 1.5 source tarball did exist or was generated from Git, I still don't know how to properly create a Debian package's debian/rules for a source that uses CMake. I've got a package that sort of builds sometimes, depending on build dependencies, but I still haven't figured out how to move the built binaries in to the proper binary Debian packages yet. What I really need is a Debian source package that uses CMake to see an example of how to build a package. I'm looking at list of packages that reverse depend on cmake, maybe I can find a Debian source package that build-depends on CMake that way. I hope this clarifies the issue a bit more. If any of this isn't clear, let me know if there's something I could clarify further. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us make-mumble-git-tarball.sh Description: application/shellscript
Bug#1017780: Version bump: 1.4.230
tags 1017780 + help thanks Greetings. Adding "help" tag to this bug because I'm currently overwhelmed. It's going to be one hell of a life story assuming I get through it all. Valentin: Package: mumble-server Version: 1.3.4-1 Source: mumble Severity: wishlist Mumble released a new version in January, and I would very much like to use this on my server. I want it too, but unfortunately it's not simple or straightforward. I've had a number of discussions with upstream and others about Mumble 1.4.x and right now it's problematic -- Mumble 1.4 does not currently work with OpenSSL 3.0, and OpenSSL 3.0 is the version that's in Debian Unstable/Sid. Building Mumble against a static OpenSSL 1.0 would violate Debian Policy section 4.13 which states that libraries in the Debian archive should be used over convenience copies, so that's not an option: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies Mumble 1.5.x works with OpenSSL 3.0 but is still in development and not ready for release. It might be possible to find a patch to allow Mumble 1.4 to work with OpenSSL 3.0, similar to how Mumble 1.3.4 was patched by Steve Langasek and Judit Foglszinger. [Thanks to them both!] If someone would like to work on a patch for OpenSSL 3.0 for Mumble 1.4 (please), here are the necessary links and hints that I got from an email discussion with Robert Adam from Mumble upstream: I'd like to think that a similar patch could be made to get Mumble 1.4.x working with OpenSSL 3.0 and that that would be better than Mumble 1.3.4 patched for OpenSSL 3.0. I'd like to know what you think of that idea. Yes, such a patch could very certainly also be made against 1.4. See e.g. https://github.com/mumble-voip/mumble/pull/5354. But be sure to also include the changes from https://github.com/mumble-voip/mumble/pull/5364. I _think_ that was the only major issue we encountered with the OpenSSL switch. In any case you should test whether Mumble is stable after the patch. As to what I think of it: It would absolutely be better to have a patched 1.4 version in the Debian repos than a patched 1.3 version. The latter has the same risk of encountering regressions because of this patch (maybe even higher as the original patch was made to a much newer version of the source code), but of course has the disadvantage of still missing all features and fixed introduced with 1.4. Mumble 1.4 also switched to using CMake which requires changing the debian/rules file to account for that in ways that I don't yet understand. I've tried to follow some documentation that I had found, but there are few references in the Debian Developer documentation for building packages with CMake when I search, and I haven't found a suitable package in Debian that uses CMake to use as an example either. I was last working with dh-cmake (which I'm not sure if using the package is necessary or not) and calling: dh $@ -0buildsystem=cmake and there's a bunch of debhelper overrides that are necessary; for instance I was last trying using this based on reading the Mumble CMake hints: override_dh_auto_configure: dh_auto_configure -- \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_OVERLAY_XCOMPILE=ON \ -Dbundle-qt-translations=OFF \ -Dbundled_celt=ON \ -Dbundled_opus=OFF \ -Dbundled_speex=OFF \ -Donline-tests=OFF \ -Dsymbols=ON \ -Dtests=OFF \ -Dupdate=OFF \ -Dwarnings-as-errors=OFF The build-depends in the debian/control file seems to be more sensitive than expected and adding certain build-depends mentioned as optional for building the Mumble source for Debian can cause the build to fail. There are changes needed for CMake for how to separate which built files go into which Debian binary package after the build, I haven't yet worked that out. Some more hints on Debian packaging with CMake here: [These hints are for me as well as anyone else] https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html#cmake-multi https://gitlab.kitware.com/debian/dh-cmake https://unix.stackexchange.com/questions/519986/packaging-cmake-components-for-debian So if someone can give me some useful hints for Debian packaging with CMake, such as an example Debian package that uses it with multiple Debian binary package outputs, and/or a patch for Mumble 1.4.287 for building with OpenSSL 3.0 that would be greatly appreciated. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1005719: bug #1005719: mumble: FTBFS with OpenSSL 3.0
Mumble 1.3 is not buildable with OpenSSL 3.0 and there is no patch available to allow doing so. There was an upstream attempt to backport patches for Mumble 1.4 for Mumble 1.3 but there were enough issues that the effort had to be abandoned. https://github.com/mumble-voip/mumble/pull/5354 I'm currently trying to package Mumble 1.4 which could resolve the problem, but running into issues with the build refactoring including a switch to using CMake. I'm working with upstream to try to resolve the build failures. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1002723: Connection problems to murmur server with older client V 1.3.0
Karsten: Package: mumble X-Debbugs-Cc: deb...@decotrain.de Version: 1.3.4-1 Severity: normal Hello, please refer to this bug report at mumble: https://github.com/mumble-voip/mumble/issues/5382 The connection of the client to the server is always rejected the first time. Afterwards it connects with a "next server": |2021-12-27 10:28:31.399 ServerHandler: connection attempt to [2001:4dd0:af1b:3a0f:ca0e:14ff:fee6:a090]:64738 failed: Verbindung verweigert (0); trying next server | The above connection attempt is to an IPv6 address. Can you please verify that the Murmur / mumble-server in question actually has IPv6 connectivity to it? [IPv6 is more common in Europe, not so much in the United States where I am, so when I see this it's "usually an error".] In the config file in the upstream but report, I see this: ; Specific IP or hostname to bind to. ; If this is left blank (default), Murmur will bind to all available addresses. host=192.168.1.3 That's an IPv4 listening address, not IPv6 I think this is some kid of DNS lookup issue, where the client (for some reason) is getting an IPv6 address to connect to, but the server is only listening on IPv4. i.e. best I can tell this is an IP networking issue, unrelated to Mumur / mumble-server. With the older server V 1.2.18 this message does not appear. A connection with the older client V 1.3.0 (within Debian 10) to the current server is generally not possible and always rejected! But in the upstream bug report, there's a comment stating the opposite; "The other client that works is on Debian 10 with client V 1.3.0" https://github.com/mumble-voip/mumble/issues/5382#issuecomment-1000475491 ? Maybe the maintainer can help with this problem? One of the things I looking for and don't see in the bug report is what the IP address was the logs for a /working/ connection. If I was able to see that a connection attempt went to the same IPv6 address and worked, that would eliminate IPv4 vs IPv6 being the problem. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#982904: mumble: CVE-2021-27229
Salvatore Bonaccorso: Hi Chris, On Sat, May 01, 2021 at 05:52:04PM +, Chris Knadle wrote: Salvatore Bonaccorso: [...] Yes I submitted release.debian.org bug #987859 last night and did the upload (and was "accepted"), which I think fits almost all of the criteria in the link above except that I did a "source only" upload rather than upload a built package; hopefully a source-only upload is acceptable here -- if it's not let me know. Yes defintively, in meanwhile source-only are possible (and would encourage so) to do as well for stable (buster, and buster-security) uploads. Last question on this: for non-dsa security uploads, is it better to target "buster" or "buster-security"? In my upload I targeted "buster" but I still have some confusion as to whether buster-security would be "better". Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#982904: mumble: CVE-2021-27229
Salvatore Bonaccorso: Hi Chris, On Sat, May 01, 2021 at 05:52:04PM +, Chris Knadle wrote: Salvatore Bonaccorso: [...] Yes I submitted release.debian.org bug #987859 last night and did the upload (and was "accepted"), which I think fits almost all of the criteria in the link above except that I did a "source only" upload rather than upload a built package; hopefully a source-only upload is acceptable here -- if it's not let me know. Yes defintively, in meanwhile source-only are possible (and would encourage so) to do as well for stable (buster, and buster-security) uploads. I hoped as much, I've gotten into the habit of doing source-only uploads for everything ... the one exception I think might still exist is the very *first* upload of a new package (last I knew) requiring to be a built package rather than source-only. I forget at the moment if Debian update that (like Ubuntu). -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#982904: mumble: CVE-2021-27229
Salvatore Bonaccorso: Hi Chris, On Fri, Apr 30, 2021 at 08:12:54PM +, Chris Knadle wrote: Salvatore Bonaccorso: [...] So now re-reading it, it seems the upload should target "buster" and the upload I ship should likely be to the "proposed-updates-new" queue. Probably? Somehow I find the wording a little difficult to be certain in its parsing. If this is correct please let me know. That is correct, and then one it hits there the NEW queue, a stable release mnager will decide if the upload should be accepted into the proposed-updates section. It should be accompanied with a respective release.debian.org bugreport accordingly as mentioned in the above rerference. Note there is as well this "improved" workflow: https://lists.debian.org/debian-devel-announce/2019/08/msg0.html . Yes I submitted release.debian.org bug #987859 last night and did the upload (and was "accepted"), which I think fits almost all of the criteria in the link above except that I did a "source only" upload rather than upload a built package; hopefully a source-only upload is acceptable here -- if it's not let me know. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#987859: buster-pu: package mumble/1.3.0~git20190125.440b173+dfsg-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Greetings.
Attached is a debdiff for mumble to fix CVE-2021-27229 in Buster marked no-dsa
by the security team, bug #982904.
As the upload to buster-proposed-updates only contains one patch and a
changelog entry (the same patch used for mumble in Sid), I'm going to go
ahead and do the upload as suggested in Debian Developers Reference §5.5.1
paragraph 3.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diff -Nru mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog
mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog
--- mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog 2019-02-28
16:36:21.0 +
+++ mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog 2021-04-30
22:24:25.0 +
@@ -1,3 +1,16 @@
+mumble (1.3.0~git20190125.440b173+dfsg-2+deb10u1) buster; urgency=medium
+
+ * debian/patches:
+- Add 67-only-http-https-URLs-in-Connect.diff to fix CVE-2021-27229
+ "Mumble before 1.3.4 allows remote code execution if a victim navigates
+ to a crafted URL on a server list and clicks on the Open Webpage text."
+ This patch only allows "http"/"https" URLs in ConnectDialog
+ (Closes: #982904)
+ Thanks to Salvatore Bonaccorso for reporting the bug
+ and giving links to the fix.
+
+ -- Christopher Knadle Fri, 30 Apr 2021 22:24:25
+
+
mumble (1.3.0~git20190125.440b173+dfsg-2) unstable; urgency=medium
* debian/patches:
diff -Nru
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
---
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
1970-01-01 00:00:00.0 +
+++
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
2021-03-04 08:44:10.0 +
@@ -0,0 +1,61 @@
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982904
+Last-Updated: 2021-03-04
+From e59ee87abe249f345908c7d568f6879d16bfd648 Mon Sep 17 00:00:00 2001
+From: Davide Beatrici
+Date: Fri, 5 Feb 2021 20:01:04 +0100
+Subject: [PATCH] FIX(client): Only allow "http"/"https" for URLs in
+ ConnectDialog
+
+Our public server list registration script doesn't have an URL scheme
+whitelist for the website field.
+
+Turns out a malicious server can register itself with a dangerous URL in
+an attempt to attack a user's machine.
+
+User interaction is required, as the URL has to be opened by
+right-clicking on the server entry and clicking on "Open Webpage".
+
+This commit introduces a client-side whitelist, which only allows "http"
+and "https" schemes. We will also implement it in our public list.
+
+In future we should probably add a warning QMessageBox informing the
+user that there's no guarantee the URL is safe (regardless of the
+scheme).
+
+Thanks a lot to https://positive.security for reporting the RCE
+vulnerability to us privately.
+---
+ src/mumble/ConnectDialog.cpp | 20 +---
+ 1 file changed, 17 insertions(+), 3 deletions(-)
+
+--- a/src/mumble/ConnectDialog.cpp
b/src/mumble/ConnectDialog.cpp
+@@ -1259,11 +1259,25 @@
+ }
+
+ void ConnectDialog::on_qaUrl_triggered() {
+- ServerItem *si = static_cast(qtwServers->currentItem());
+- if (! si || si->qsUrl.isEmpty())
++ auto *si = static_cast< const ServerItem * >(qtwServers->currentItem());
++ if (!si || si->qsUrl.isEmpty()) {
+ return;
++ }
+
+- QDesktopServices::openUrl(QUrl(si->qsUrl));
++ const QStringList allowedSchemes = { QLatin1String("http"),
QLatin1String("https") };
++
++ const auto url = QUrl(si->qsUrl);
++ if (allowedSchemes.contains(url.scheme())) {
++ QDesktopServices::openUrl(url);
++ } else {
++ // Inform user that the requested URL has been blocked
++ QMessageBox msgBox;
++ msgBox.setText(QObject::tr("Blocked URL scheme
\"%1\"").arg(url.scheme()));
++ msgBox.setInformativeText(QObject::tr("The URL uses a scheme
that has been blocked for security reasons."));
++ msgBox.setDetailedText(QObject::tr("Blocked URL:
\"%1\"").arg(url.toString()));
++ msgBox.setIcon(QMessageBox::Warning);
++ msgBox.exec();
++ }
+ }
+
+ void ConnectDialog::onFiltersTriggered(QAction *act) {
diff -Nru mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series
--- mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series 2019-02-28
16:36:21.0 +
+++ mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series 2021-03-04
08:21:39.0 +
@@ -8,3 +8,4 @@
52-use-update-rc.d-for-disable.diff
60-crossbuild.diff
65-fix-sample-path.diff
+67-only-http-https-URLs-in-Connect.diff
Bug#982904: mumble: CVE-2021-27229
Note: for the three messages recently sent (Benedikt, Salvatorie, Chris/me) that have recently been sent, none went to #982904 because the bug had been archived. I've unarchived the bug since fixing it for Buster is still pending. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#985362: mumble: Unhide after Minimize to tray flashes rapidly
tags 985362 + unreproducible thanks Chris Knadle: I'm still working to get KDE installed in a Sid VM because the Sid VM I have has a disk that's too small to add KDE to, so I'm figuring out the procedure needed to extend the virtual disk to fit it. It involves extending the virtual disk file size withe VM off (qemu-img), then partition size, logical volume size, then filesystem size. Okay I got KDE 5 / KDE Plasma installed in the VM and tested. In my VM Mumble is able to come in and out of being minimized in the tray as expected, no flashing. It doesn't matter if Mumble is connected to a server or not -- works either way. I'm not sure what's producing the bug, but it looks like this works on Sid. I'm thinking of making a snapshot of the VM and then adding the 'experimental' repository and see if that's what might be going on. Right now I got nothin'. ;) -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#985362: mumble: Unhide after Minimize to tray flashes rapidly
retitle 985362 mumble: Unhide after Minimize to tray flashes rapidly under KDE tags 985362 - moreinfo thx Hello Johnathan. Thanks for your continued testing, it's appreciated. I'm still working to get KDE installed in a Sid VM because the Sid VM I have has a disk that's too small to add KDE to, so I'm figuring out the procedure needed to extend the virtual disk to fit it. It involves extending the virtual disk file size withe VM off (qemu-img), then partition size, logical volume size, then filesystem size. Jonathan Rubenstein: Thank you for your reply, Chris. This sounds like Mumble being brought out of being minimized and then minimizing again, as if there were either no or two mouse clicks; i.e. this sounds like a mouse button switch that's starting to go bad. I've had this happen to me, it leads to thinking of all kinds of things being broken that aren't. I have right clicked on the mumble icon and hit "Show"—which should only ever allow one mouse click because it disappears—and still experience this issue even with that. This can also happen when running 'mumble' in a terminal with mumble already open and minimized to tray, or opening a desktop file. I've also run xev and clicked the window 100 times, saving the log to a file[1]. This log contains no more and no less than exactly 100 mouse button down entries and 100 mouse button up entries. Hmm. Yeah that sounds conclusive that it's not a mouse button issue. Interesting. Thanks, this was a great idea. So my first suggestion is to try changing mice to see if it's a mouse button problem, I have briefly switched mice to my old one, and I have the same issue at the same reproduction rate. This also fits a conclusion that it's not the mouse button. and the second is to try adjust the mouse button timing in KDE settings (especially if you have done so recently). > I cannot find these settings in KDE 5, but as I can reproduce without using the mouse at all via a terminal or desktop file, I do not believe this will help. Yeah the other thing is that the test done with counting mouse clicks and them matching up in number would also invalidate the idea of this being an issue of mouse settings in KDE 5. To answer the question of where the settings for this should be, it should be in KDE "System Settings" under "Input Devices" https://userbase.kde.org/System_Settings/Input_Devices#Mouse At first glance I suspect this isn't a Mumble bug, or at least that if it does relate to Mumble directly that it doesn't happen on all desktop environments. I regularly use the "Hide in tray when minimized" feature but not on KDE. I agree, it does not seem to happen on all desktop environments. Okay cool, so that part seems consistent. I have a Sid VM where I think I'll try adding KDE Plasma to for testing. I can try in a VM as well. I'll also give it a go in some other DEs and WMs. I hope my testing is satisfactory, let me know if I can do anything else. Yes this testing has been very helpful, thank you. It means more than might be expected; this is the kind of collaboration that I enjoy. [1]: https://paste.debian.net/1190823/ Since this was supplied I got curious so I had a look: yup, 100 mouse clicks and releases as expected. user@host:~/Downloads$ fgrep ButtonPress paste_1190823 | wc -l 100 user@host:~/Downloads$ fgrep ButtonRelease paste_1190823 | wc -l 100 -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#985362: mumble: Unhide after Minimize to tray flashes rapidly
tags 985362 + moreinfo thanks Hello Johnathan. Jonathan Rubenstein: Package: mumble Version: 1.3.4-1 Severity: normal X-Debbugs-Cc: jrub...@gmail.com Dear Maintainer, On KDE Plasma 5.20.5, when I use mumble's Hide in tray when minimized feature, after clicking on the tray icon to show mumble again, the client will rapidly display and hide until I click the icon again. Sometimes this does not occur, and the client will display properly, but it is more often than not it will flash. This sounds like Mumble being brought out of being minimized and then minimizing again, as if there were either no or two mouse clicks; i.e. this sounds like a mouse button switch that's starting to go bad. I've had this happen to me, it leads to thinking of all kinds of things being broken that aren't. Another possibility is mouse settings in KDE for mouse click timing where the timing is either too short or too long such that "extra clicks" are detected that weren't intended, i.e. the mouse button doesn't get digitally "debounced" correctly, or too long so that no mouse clicks occur when expected. So my first suggestion is to try changing mice to see if it's a mouse button problem, and the second is to try adjust the mouse button timing in KDE settings (especially if you have done so recently). Earlier last year, this flashing was a soft-lock to my input on the machine, and I was not able to terminate mumble normally without switching to a tty console, or even using SSH from my mobile phone. This behavior has since improved, and is not as severe, so I am able to stop mumble when this happens. Is this possibly again about mouse clicks? i.e. did this have to do with trying to terminate Mumble using the mouse? I'd like a little more information about what specific input was used to try to terminate Mumble that didn't work, and what did. Is this really a KDE bug? I'm not sure. Let me know if I can provide any more information. At first glance I suspect this isn't a Mumble bug, or at least that if it does relate to Mumble directly that it doesn't happen on all desktop environments. I regularly use the "Hide in tray when minimized" feature but not on KDE. I have a Sid VM where I think I'll try adding KDE Plasma to for testing. Please let me know what you find; I'll do the same. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#984976: mumble: Keyboard shortcuts can't be assigned
tags 984976 + moreinfo thanks Pelle: Package: mumble Version: 1.3.4-1 Severity: normal Dear Maintainer, In the "Shortcuts" settings, when I add a new shortcut and click in the "Shortcut" column, a "Press Shortcut" label is shown. However, it is not possible to assign a shortcut, regardless of which key is pressed, and the "Press Shortcut" label remains, until I click somewhere else. I expected a key name to be listed in the "Shortcut" column after I pressed th key while the "Press Shortcut" label was visible. This issue may be because I'm running a Wayland compositor (Sway). I've tested adding shortcuts for mumble 1.3.4-1 and it seems to work as expected in the Debian Sid VM I use for testing and using mumble, which uses the Xfce window manager (and does not use Wayland). Just to double-check the procedure for setting a shortcut: 1. Press "Add" to add a shortcut 2. On the added shortcut, under the "shortcut" label, click on the blank area for the shortcut under the "Shotcut" tab 3. After clicking in the blank area, "Press Shortcut" appears 4. Press the desired key and/or mouse button for the desisred shortcut 5. Click the area under the "Function" tab for the shortcut (which starts off with "Unassigned") to assign the shortcut function The order of these steps is optional, i.e. item (5.) above can be done before item (2.) From the description of the bug I think these steps were done correctly, and that the underlying issue might be something to do with how keyboard and mouse input is done with Wayland, but I'd like a little more information. More specifically I'd like to know which window manager and/or desktop environment is in use, because I've repeatedly seen bugs with tiling window managers with Mumble where non-tiling window managers don't seem to show the symptoms. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#982904: mumble: CVE-2021-27229
Salvatore Bonaccorso: Hi [Adding CC to security-team alias] On Mon, Mar 01, 2021 at 08:31:54AM +, Chris Knadle wrote: Salvatore Bonaccorso: Source: mumble Version: 1.3.3-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://github.com/mumble-voip/mumble/pull/4733 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for mumble. CVE-2021-27229[0]: | Mumble before 1.3.4 allows remote code execution if a victim navigates | to a crafted URL on a server list and clicks on the Open Webpage text. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-27229 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27229 [1] https://github.com/mumble-voip/mumble/pull/4733 [2] https://github.com/mumble-voip/mumble/commit/e59ee87abe249f345908c7d568f6879d16bfd648 Please adjust the affected versions in the BTS as needed. I've reviewed the upstream git repo; there are 2 patches that are security related -- the other is for an OCB2 XEXStarAttack on encryption, both of which comprise the majority of the bugfix release of mumble 1.3.4. It seems to me that the best way to proceed is to upload mumble 1.3.4 as the other changes are incidental, and I hope that this will be acceptable during the soft freeze. Yes new upstream version might still be possible in the soft-freeze, so if that's the most sensible solution then I would go for that. https://release.debian.org/bullseye/freeze_policy.html For buster btw we marked in no-dsa, so if you can shedule a fix via a point release this would be great. Yep, I'm working on this for fixing CVE-2021-27229 for Buster. It looks like the commit ([2], above) can apply as a patch for 1.3.0~git20190125.440b173+dfsg-2 so this looks straightforward as far as I can tell. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#982904: mumble: CVE-2021-27229
Salvatore Bonaccorso: Source: mumble Version: 1.3.3-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://github.com/mumble-voip/mumble/pull/4733 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for mumble. CVE-2021-27229[0]: | Mumble before 1.3.4 allows remote code execution if a victim navigates | to a crafted URL on a server list and clicks on the Open Webpage text. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-27229 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27229 [1] https://github.com/mumble-voip/mumble/pull/4733 [2] https://github.com/mumble-voip/mumble/commit/e59ee87abe249f345908c7d568f6879d16bfd648 Please adjust the affected versions in the BTS as needed. I've reviewed the upstream git repo; there are 2 patches that are security related -- the other is for an OCB2 XEXStarAttack on encryption, both of which comprise the majority of the bugfix release of mumble 1.3.4. It seems to me that the best way to proceed is to upload mumble 1.3.4 as the other changes are incidental, and I hope that this will be acceptable during the soft freeze. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#980079: mumble-server: service restart and stop borked
tags 980079 unreproducible moreinfo thanks Nils König: I must correct myself. As I ofc only remembered after sending the bug report, I did already change the initscript once before to start as root (so it can read the root-owned ssl certs once on startup, before dropping privileges) So in the default config, the --user switches shouldn't be a problem (but with CAPABILITIES enabled they probably still are) and the pidfile-dir permission should be the only problem. ~~ Nils I'd like to have some more information in order to figure out how I can help with this issue. Is the system with this issue running systemd? Which method of creating an SSL cert is being used? I've tested mumble-server on Debian 10.7 for this, with the default configuration, both with and without CAPABILITIES enabled, and I'm able to shut down mumble-server correctly on a system running systemd. The PID file is /run/mumble-server/mumble-server.pid and it as well as the murmurd process disappear when shutting it with with 'systemctl stop mumble-server'. I understand the problem of needing to start as root in order to read ssl certs, and I'm assuming this is in relation to creating an SSL cert with LetsEncrypt. If so I think there's an alternative; I think the SSL cert can be copied with different ownership + permissions to a location that mumble-server can access using a "post-hook" or "deploy-hook" call to certbot or dehydrated (or copying the file manually if making a self-signed SSL cert) to run a script that will copy the cert(s) and alter file permissions in an automated way. I haven't actually done this yet but that's the method I last intended to look into. Mumble upstream also suggests a method of dealing with this by setting the execute bit on directories in the folder path to get to the SSL certficate to allow mumble-server to traverse the path and allow read the files. I think this method is less restrictive and less secure though. https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate I'm fairly interested in trying to find a good solution to this, because this permission problem is a common gripe that I hear from users on the Mumble IRC channel, so if a better solution can be found maybe I could have upstream add it to the wiki or the website so others could take advantage of it. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#976227: O: breathe -- Sphinx autodox support for languages with doxygen support
Melvin Vermeeren: Hi Chris, On Saturday, 5 December 2020 01:20:07 CET Chris Knadle wrote: [...] And assuming you'd like to take over for maintenance of the breathe Debian package yourself and have sponsored uploads, the next step for that would be to file an "ITA" (Intent To Adopt) bug, I believe. It seems you've got some Debian package development experience already, so this seems quite fitting. There's some additional explanation of the "ITA:" bug subject here: https://wiki.debian.org/how-can-i-help Yeah I'd say going for ITA makes most sense here so that's what I would like to do. Reading around a bit I find WNPP wiki page[1], the "ITA" entry of the "Removing entries" seems appropriate. However not being an Debian maintainer currently it seems inappropriate for me to actually do this. [1] https://www.debian.org/devel/wnpp/ In the WNPP page [1] above the suggestion is to rename the "O:" bug with "ITA:" and set ownership of the bug to yourself in order to start the process. In terms of not being a Debian Maintainer ... no, that isn't required. I know because I did this myself in 2014 for Mumble when its maintainer neglected it and then did not respond to communication about the package being broken: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739997 I filed to become a Debian Maintainer in 2015 after taking care of a couple of packages in Debian for a while. That's the typical path to becoming a Debian Maintainer (and eventually Developer) today -- so it's expected to start off with taking care of one or more packages without being a DM first. The mentor system also seems to have some overlap with GitLab's merge requests. I know Salsa is relatively new in Debian and am guessing it's mostly a maintainer preference which tooling and flow to use. So far I am most comfortable with the gbp tooling, as it nicely integrates with a git-based workflow which I'm used to. As far as I'm aware Git-Buildpackage is what is still most often recommended. There are some further details like whether or not to use dgit. I wanted to try dgit but didn't like the way it worked with patches, because I like my patches to contain comment headers for what the patch is for, and last I spoke to DDs about it this was something that dgit conflicted with. The basic idea with dgit is that everything is a direct commit, so there wouldn't be any use of quilt for patch creation. There's also some new 'git' package format that I haven't investigated much. (I'm still most comfortable with the '3.0 quilt' format.) I am used to working with GitLab and prefer direct merge requests as the ability to iterate with inline diffs with explicit thread resolution is a very nice review process in my opinion. Typically in a situation where a non-privileged user is contributing (that would be me) I would either fork the project and submit merge requests to upstream. Somewhat more comfortable is being granted developer permissions[2] on the project and then protecting[3] the primary branches so that only a maintainer can push/merge to those. [2] https://docs.gitlab.com/ee/user/permissions.html [3] https://docs.gitlab.com/ee/user/project/protected_branches.html Currently the Breathe repository is under Sebastian's namespace[4]. For the above workflow to work the repository would ideally be owned by the actual uploader/sponsor or possibly the python team[5]? That way it is ensured that the main branches contain finalised and reviewed work. [4] https://salsa.debian.org/sramacher/breathe [5] https://salsa.debian.org/python-team/packages Mostly just writing some ideas down above, hopefully it is somewhat relevant. Perhaps a starting point would be to fork the project inside my personal namespace on Salsa and create a merge request internally there for reviewing? A project on Salsa is usually made available on request; so if you wanted the project to exist under the python-team/ area then it makes sense to join that team and then request creation of the project in order to have a Git repo location for the package. That way the package can be team maintained rather than it being under a personal area. Although it's nice to have an online Git repo available for a package, it's also not a requirement. For instance I typically do an upload to Debian and /then/ push to the repo, so that if I have to back out changes in my local repo that it won't mess up the online repo. To start with when taking over a package I'll usually do the first upload with no listed Git: location in the debian/control file. Then usually I find a Git repo location to store the package repo, push, then update the Git: location in the debian/control file on the next upload. All of the work is done in Git-Buildpackage and made available later, it's just not available for the first upload. That's at least the path I've used so far ... having an online Git repo
Bug#976227: O: breathe -- Sphinx autodox support for languages with doxygen support
Melvin Vermeeren: Hi, I am the current maintainer of Breathe upstream[1] and also a Debian user since a few years after having switched distribution. If I possible I would like to also (help?) maintain Breathe in Debian in some way. Currently I'm not an official Debian maintainer, though I do have a around a year experience by now in maintaining an unofficial Debian repository[2], mainly for additional backports. Said repo is currently undergoing some rework to improve correctness and automation. On Salsa[3] I open up MRs for buster bugfixes if I find anything cumbersome as I'm used to the GitLab workflow. [1] https://github.com/michaeljones/breathe [2] https://mel.vin/debian/ [3] https://salsa.debian.org/vermeeren In some form of sponsorship or helping out possible? I could for example do some maintaining in a fork on Salsa and submit MRs to the real Salsa repo for a final check by someone with proper maintainer permissions. It has been a while since I read the specifics of sponsorship etc so I am not entirely sure what the options are. Had a very nice exchange of emails with Chris Knadle, the maintainer of Mumble, quite a while ago. Adding in the CC both for general interest and perhaps for some ideas. Looking forward to hearing what can be done! Thanks, Hello Melvin. I looked up the bug CCed in the email and see that the Breathe package was marked as Orphaned via the BTS; however the package still has a listed maintainer instead of Debian QA Group , meaning the full orphaning of the package hasn't been completed yet. More explanation here: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package At the moment all this means is that the Breathe package in Debian will have no official maintainer -- it doesn't necessarily mean that the package will be removed from the archive soon. Package removals happen sometimes for packages that go out of maintenance for an extended period, but this package was only _just_ been (partially) orphaned, so as far as I know, the situation is not "alarming". Breathe has now joined 1175 other packages that have been orphaned -- you can see a list of them here, many of which have been orphaned for several years: https://www.debian.org/devel/wnpp/orphaned In terms of the Breathe package itself, I'm unfamiliar with it... and to date I've never used Doxygen or Sphinx, I'm not (yet) familiar with reStructuredText, and at the moment I'm only doing sporadic Python3 programming. Debian Developers are encouraged to be familiar with the packages that they upload or in sponsoring for uploads in case there are bugs in the package that require familiarity to fix. I'm probably not the right maintainer to sponsor uploads directly, but I /am/ interested in helping guide you through the process of getting you what you need to take care of the package. I'd likely be comfortable helping do NMUs (non-maintainer uploads) for targeted bug fixes, and I would also be comfortable helping with preparing and/or reviewing package uploads to mentors.debian.net to help get a sponsor for uploads. https://mentors.debian.net/sponsors/ And assuming you'd like to take over for maintenance of the breathe Debian package yourself and have sponsored uploads, the next step for that would be to file an "ITA" (Intent To Adopt) bug, I believe. It seems you've got some Debian package development experience already, so this seems quite fitting. There's some additional explanation of the "ITA:" bug subject here: https://wiki.debian.org/how-can-i-help Strangely I don't see the "ITA:" bug explained in the Debian Developer's Reference guide under "Adopting a package", which I would like to see updated for that. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package mel.vin Debian repo =-=-=-=-=-=-=-=-=-= I had a quick look at your Debian repository at the [2] link from your email and wonder how the package list is being updated -- if the package list being automatically generated I would be interested in knowing how to do that. ;-) The other thing I noticed in the list of packages is that there's a mumble backport package. The maintainer for the Mumble backport in Debian hasn't done an upload for 2 years, so if you'd be interested in seeing your backport uploaded to Debian backports directly, that would be something I'd be interested in talking about. Thanks and talk to you soon. -- Chris -- Chris Knadle chris.kna...@coredump.us OpenPGP_signature Description: OpenPGP digital signature
Bug#967185: Migration blocked
Migration of openjfx 11.0.7+0-5 is blocked due to failure to build on 4 release architectures (armel, armhf, i386, mipsel) due to a missing dependency on libswt-gtk-4-java for those architectures. This occurred due to swt4-gtk failing to build on those architectures leading to packages being removed for those architectures: RM: swt4-gtk [armel armhf i386 mipsel] -- ROM; Upstream no longer supports 32 bits architectures https://bugs.debian.org/962915 Mumble is pending removal from Testing due to this issue. Noting this in this bug so that others can find it. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#969260: openfjx: FTBFS (gstreamer)
tony mancill: > Hi Chris! Hello again Tony :) > On Sat, Sep 05, 2020 at 05:43:17AM +, Chris Knadle wrote: >> Chris Knadle: >>> For what it's worth, I used a clean cowbuilder sid chroot that was fully >>> upgraded to build openjfx 11.0.7+0-4 and the package built fine. The build >>> log >>> is about 808kB -- I'll send it to the bug report if desired. Offhand I'm not >>> sure what's going on either. It's probably wishful thinking that the >>> cowbuilder >>> build log will be comparable to the buildd build logs, but I'll have a look. >> >> Okay, I've compared the cowbuilder logs and the buildd logs and there are a >> number of differences, and to me it looks like buildd might be using gcc-10 >> where my cowbuilder build may not be. The buildd logs show many warning/error >> lines of variables "first defined here" and that's indicative of a gcc-10 >> problem, along with many other errors and warnings that the cowbuilder build >> didn't show. >> >> I was given some hints about this in bug #957546: >> >>Common build failures are new warnings resulting in build failures with >>-Werror turned on, or new/dropped symbols in Debian symbols files. >>For other C/C++ related build failures see the porting guide at >>http://gcc.gnu.org/gcc-10/porting_to.html > > Thank you for taking a look at this. I suspect that you're on to > something with gcc-10, but if that's the case, I'm worried about my > entire build toolchain with respect to gcc-10 bugs. Just to be sure, I > created a fresh chroot with: > >sudo sbuild-createchroot sid /path/to/chroot > > And the package still builds correctly for me, and "gcc -v" in that > chroot shows gcc 10.2: > > $ schroot -c sid-amd64-sbuild -u root > (sid-amd64-sbuild)root@lark:~# gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper > OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa > OFFLOAD_TARGET_DEFAULT=1 > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.0-6' > --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs > --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr > --with-gcc-major-version-only --program-suffix=-10 > --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug > --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new > --enable-gnu-unique-object --disable-vtable-verify --enable-plugin > --enable-default-pie --with-system-zlib --enable-libphobos-checking=release > --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch > --disable-werror --with-arch-32=i686 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > --enable-offload-targets=nvptx-none=/build/gcc-10-OZNiN5/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-OZNiN5/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa > --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 10.2.0 (Debian 10.2.0-6) I got the *exact* same output from cowbuilder when checking 'gcc -v' -- I literally copied the above from your email, copied the output from 'gcc -v' in my cowbuilder chroot, ran 'diff -u' on the files, and came back identical. So ... yeah ... I also don't quite know what's going on either. I /suspect/ it's a GCC-10 issue because of the particular warning/error messages, so it seems to make _sense_ that it would be some GCC-10 issue, however both your and my local build chroots should be using GCC-10 and build fine. So ... ? > So I'm confused about what's different on the buildd system. I will > keep poking at it. Something to try if you've got time: Try doing a "colordiff -u" on the log output from your successful sbuild vs the failed sbuild output from the buildd's; that should give a colorized output of where there are differences in lines, and maybe there will be a hint as to something that's different on the buildd's, like different GCC options, and also where the build "starts to go wrong". Maybe you've done that already, but if not that might give us some hints. I'm building an sbuild chroot and will see if I can poke at this some also. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#969260: openfjx: FTBFS (gstreamer)
Chris Knadle: > For what it's worth, I used a clean cowbuilder sid chroot that was fully > upgraded to build openjfx 11.0.7+0-4 and the package built fine. The build log > is about 808kB -- I'll send it to the bug report if desired. Offhand I'm not > sure what's going on either. It's probably wishful thinking that the > cowbuilder > build log will be comparable to the buildd build logs, but I'll have a look. Okay, I've compared the cowbuilder logs and the buildd logs and there are a number of differences, and to me it looks like buildd might be using gcc-10 where my cowbuilder build may not be. The buildd logs show many warning/error lines of variables "first defined here" and that's indicative of a gcc-10 problem, along with many other errors and warnings that the cowbuilder build didn't show. I was given some hints about this in bug #957546: Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#969260: openfjx: FTBFS (gstreamer)
For what it's worth, I used a clean cowbuilder sid chroot that was fully upgraded to build openjfx 11.0.7+0-4 and the package built fine. The build log is about 808kB -- I'll send it to the bug report if desired. Offhand I'm not sure what's going on either. It's probably wishful thinking that the cowbuilder build log will be comparable to the buildd build logs, but I'll have a look. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#967185: Migration blocked
Migration of openjfx 11.0.7+0-3 is blocked because it introduces a new FTBFS bug https://bugs.debian.org/969260 Noting this in this bug so that others can find it -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#965002: fixed in mumble 1.3.2-1
Jonathan Rubenstein: > On Thu, 27 Aug 2020 04:03:38 + Debian FTP Masters > wrote: >> Changes: >> mumble (1.3.2-1) unstable; urgency=medium >> . >> * New upstream release from 2020-07-09 >> - Fixes 7-second startup delay due to jackd (Closes: #941455) >> Thanks to Matthias Heinz for reporting the bug >> - Fixes sound lockups caused when jackd started by Mumble client >> (Closes: #952742) >> Thanks to lemmel for reporting the bug >> Thanks to Sébastien Leblanc for finding a fix >> - Fixes getCurrentUrl return value (Closes: #956379) >> - Fixes New upstream version available (Closes: #965002) >> * debian/control: >> - Update Standards-Version to 4.5.0 (no changes needed) >> * debian/mumble.gconf-defaults: >> - Remove file due to GConf being deprecated (Closes: #959108) >> Note https://bugs.debian.org/908845 for reference concerning planned >> dh_gconf removal >> Thanks to Michael Biebl for reporting the bug and >> explaining the fix >> * debian/patches: >> - Add 54-fix-mysql-start.diff to change $mysql -> mysql (Closes: #698715) >> Thanks to Tim Besard for reporting the bug and >> finding the fix > > > Thanks for your hard work! If it's still in your workflow, don't forget to > push > these changes to https://salsa.debian.org/pkg-voip-team/mumble > > - Jonathan Rubenstein Yes, I just completed that just now. :) I had to wait until DAK accepted the package before I could push the changes in Git to Salsa. I'm glad to have these issues fixed finally. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#959108: mumble: Installs deprecated gconf-defaults file
Simon: I've already attempted to upload a Mumble-1.3.2 Debian package that would remove the debian/mumble.gconf-defaults file, but 5 days before the upload my GPG key hit its expiration date. I've updated my key's expiration date and sent it to Debian's keyring, but it takes time to propagate. Multiple attempts I've made to upload packages to Debian have failed; I'll get email notification that the package is "Processing", but then no disposition of "accepted" or "denied". DAK in Debian needs to see a valid GPG key signature before it will process an upload. The keyring package is set to be updated in a about a week or so, and that's when I'll make another attempt to send the package. https://salsa.debian.org/debian-keyring/keyring -- Chris -- Chris Knadle chris.kna...@coredump.us Simon McVittie: > Control: tags -1 + patch > > On Wed, 29 Apr 2020 at 14:42:39 +0200, Michael Biebl wrote: >> your package mumble ships a gconf defaults file >> >> # cat debian/mumble.gconf-defaults >> /desktop/gnome/url-handlers/mumble/command "mumble %s" >> /desktop/gnome/url-handlers/mumble/needs_terminalfalse >> /desktop/gnome/url-handlers/mumble/enabled true >> >> GConf has long been deprecated and is no longer used by modern desktops, >> like GNOME, Cinnamon, XFCE etc. > > Please see attached patch. I have verified with diffoscope that its only > practical effect is to remove > > ./usr/share/gconf/ > ./usr/share/gconf/defaults/ > ./usr/share/gconf/defaults/10_mumble > > from the mumble binary package. > > Also available at > <https://salsa.debian.org/pkg-voip-team/mumble/-/merge_requests/4>. > > Thanks, > smcv >
Bug#965002: mumble: New upstream version available (1.3.2)
Chris Knadle: > Jonathan Rubenstein: >> On Wed, 15 Jul 2020 04:27:16 +0000 Chris Knadle >> wrote: >> Are there any blockers in updating to the new version? > > I did an upload of 1.3.2 this evening, so it's just pending acceptance. The Debian GPG keyring needs to be updated for the expiration of my GPG key before DAK will accept the upload. The keyring is updated about once/month and it's been about 3 weeks since the last keyring update, so if I understand correctly the upload might start processing in about a week or so. If it doesn't after the keyring is updated I'll send the upload again. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#965002: mumble: New upstream version available (1.3.2)
Jonathan Rubenstein: > On Wed, 15 Jul 2020 04:27:16 +0000 Chris Knadle > wrote: > Are there any blockers in updating to the new version? I did an upload of 1.3.2 this evening, so it's just pending acceptance. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#965002: mumble: New upstream version available (1.3.2)
Matthias Heinz: > Package: mumble > Version: 1.3.0+dfsg-1+b3 > Severity: wishlist > > Hi! > > There is a new version of mumble available upstream. It would be great if this > could be packaged, because it would solve the slow startup of mumble (waiting > for jack). > > Thanks you! > > - Matthias Yes I'm aware of the 1.3.2 bugfix release. I've also been wanting to fix the startup delay. Prior to 1.3.1 which had a long delay before release, I had attempted to include patches to the current Debian package to fix the slow startup among other issues, but unfortunately when I tested I found that the patches caused Mumble to fail to find internal audio notification sound files. This means backtracking the local Git changes out and then trying again with a 1.3.2 tarball now that that's available. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#964063: Mention Linux in "Running Mumble" section
積丹尼 Dan Jacobson: > Package: mumble > Version: 1.3.0+dfsg-1+b2 > Severity: wishlist > File: /usr/share/doc/mumble/README > > We read > >Running Mumble >== > >On Windows, after installation, you should have a new Mumble folder in your >Start Menu, from which you can start Mumble. > >On Mac OS X, to install Mumble, drag the application from the downloaded >disk image into your /Applications folder. > > Wait, what about Linux?! > >Once Mumble is launched, you need a server to connect to. Either create > your >own or join a friend's. > >Running Murmur on Unix-like systems >=== > > Oh, there's the Linux section. But wait, now it is talking about Murmur! > > Yes, there is a separate /usr/share/doc/mumble/README.Linux but that is > besides the point, and a different story. The README and README.Linux files in the 'mumble' package in Debian come directly from the upstream Mumble release tarball. A good way of suggesting specific changes would be to open an issue upstream: https://github.com/mumble-voip/mumble/issues As best I can tell there is no open issue concerning the README about mentioning Linux right now. If you decide to open an issue upstream, please mention Debian bug #964063 so that the bugs get linked. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#958059: mumble: push-to-talk not working with some media keys
forwarded 958059 https://github.com/mumble-voip/mumble/issues/4140 thanks nfb: > Package: mumble > Version: 1.3.0~git20190125.440b173+dfsg-2 > Severity: normal > Tags: upstream > > Dear Maintainer, > > some multimedia keys are not working when bound to the push-to-talk > shortcut, but some of them do work fine. > > For example the ThinkVantage button on a Thinkpad x230 keyboard > generates XF86Launch1 keysym. Output from xev: > > KeyPress event, serial 34, synthetic NO, window 0x161, > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374), > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False > > KeyRelease event, serial 34, synthetic NO, window 0x161, > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374), > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES, > XLookupString gives 0 bytes: > XFilterEvent returns: False > > The key is correctly detected and saved (as XF86Launch1) by the > shortcut setting dialog in mumble, but when pushing it, the voice is > not activated. > Also, there should be no interference by the rest of the system, since > this button, but also all other media keys i chose for testing, are > not used by the window manager, nor by any running application. > > The same for e.g. XF86Display. Other media keys such as XF86AudioPlay > instead, work as expected, as all other "standard" keys do, afaict. > > I already reported on the #mumble irc channel and was told to file a > bug because it probably is, but i decided to open it here so we can > track it in Debian and also because i dont't know if the package in > the stable repo is a bit outdated and the issue has been recently > fixed somehow... > > Let me know if you need more details. > > Thanks for the support. Thank you for opening a bug upstream about this; if upstream is able to fix the bug then I'll be able to upload a new package with the fix for unstable and testing. It is doubtful that this can be fixed for Debian stable though; the only bugs that are possible to fix for stable are bugs that are serious, and any fixes for serious bugs would have to be targeted for only the serious issues specifically. I don't think this bug passes that threshold. Out of curiosity, have you tested to see if Mumble 1.3.0+dfsg-1 in Debian unstable and testing exhibits the same bug? -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#952742: mumble: start locks sound for all application (even the client itself)
tags 952742 - unreproducible moreinfo tags 952742 + fixed-upstream patch thanks This has been fixed upstream in a one-line patch here: https://github.com/mumble- voip/mumble/pull/3990/commits/0780d93aab3eec9796e1cb8606c5f3c089d64eca Ubuntu users are also running into the problem https://bugs.launchpad.net/bugs/1874231 I'm going to do an upload with a patch to fix this. Upstream has a release snapshot up for 1.3.1 so a bugfix release should be available soon. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#956379: mumble: DBus call to getCurrentUrl responds with empty string
Florian Snow: > Hi Chris, > > Let me say first that this is my first time filing a bug with Debian and > I am not completely familiar with the process yet. So if I made a > mistake, please accept my apologies. Being that this is your first bug report please let me extend my thanks for taking the time and effort to do that. It's an important and worthwhile thing and it gives both users and Debian developers an opportunity to interact and find opportunities to work together. > Chris Knadle writes: >> I'd like to know what risks and/or problems this bug poses, in order to >> understand how important this bug is and to figure out how it needs to be >> handled. > > The bug is not security related; it is just an inconvenience. Usually, > you can get the current URL via DBus and use that to script certain > things. For example, getting the current URL makes it possible to not > only switch rooms on screen lock, but also to switch back to the > previous room on unlock. So nothing major, but something I noticed > using the program and I wanted to help getting it fixed. That's why I > fixed it upstream and I figured the best way to proceed was to now file > a bug with Debian. Okay I think I understand. Thank you for fixing this upstream -- that's especially good because it means the fix will [most likely] be in the upcoming 1.3.1 tarball and will get to Debian unstable when I can upload that. >> Mumble-server / Murmur defaults to not using DBUS, and does not depend on it >> either for the package in Debian in order to allow not having DBUS >> installed. > > True, but this is about the client. The default configuration on Debian > uses DBus here to interact with the client from the CLI. Ahh. Okay I didn't understand that this was about the client. In Debian bugs are organized by "source package", and both mumble-server (the server) and mumble (the client) are bundled together in the source package named "mumble", so it wasn't clear which is being referred to. ;-) >> Mumble currently only has an "oldstable" backport right now, and no "stable" >> backport. For a bugfix to a backport to be allowed, the bug is required to >> be >> fixed in "testing" first, and the only way to get a package to "testing" is >> to >> upload it to "unstable". > > Ok, sure, thanks for letting me know. That was just an idea because I > realized that the bug severity was probably not high enough to warrant a > fix in stable. That's why I was thinking of stable-updates or > backports, but again, I am not completely familiar with the internals of > Debian. I am willing to learn, though. The reason I included > information about the bug also being in testing and sid was because > reportbug told me to verify if the bug existed there. Okay. When there are serious bugs in "stable", fixes targeting those specific bugs are made and fixed packages are uploaded to the "stable-proposed-updates" repository pending the next "point" release for "stable". "stable-updates" is a repository of packages with fixes pending to be included with the next point release and made available to users if they choose to include that repository. In other words, "stable-updates" are packages that are "staged" for the "stable" repository. References: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions https://wiki.debian.org/StableUpdates This bug isn't serious enough to try to fix it in "stable". (Even if I prepared a package with the fix, the bug isn't serious enough for the release team to accept the upload.) This is still a bug for Sid/unstable, and it'll be fixed when I'm able to upload the 1.3.1 bugfix release that upstream is actively working on. I'm trying to consider what to do about the backport package -- another Debian developer has been doing that but it's been a while since it's been updated. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#956379: mumble: DBus call to getCurrentUrl responds with empty string
Florian Snow: > Package: mumble > Version: 1.3.0~git20190125.440b173+dfsg-2 > Severity: normal > Tags: patch upstream > > When calling the DBus method getCurrentUrl, it responds with an empty > string instead of a Mumble URL, like the call to getTalkingUsers > responds with a list of talking users. Here is the call I used: > > dbus-send --print-reply --session --type=method_call \ > --dest=net.sourceforge.mumble.mumble / \ > net.sourceforge.mumble.Mumble.getCurrentUrl > > The bug is also present in testing and sid. I fixed it upstream and I > am hoping for a point release so this can hopefully go into stable > updates or backports. I'd like to know what risks and/or problems this bug poses, in order to understand how important this bug is and to figure out how it needs to be handled. If this is a security related bug, an upload for that would need to be coordinated with the Debian Security Team. Mumble-server / Murmur defaults to not using DBUS, and does not depend on it either for the package in Debian in order to allow not having DBUS installed. There shouldn't be an issue for default configurations, as far as I know. Mumble currently only has an "oldstable" backport right now, and no "stable" backport. For a bugfix to a backport to be allowed, the bug is required to be fixed in "testing" first, and the only way to get a package to "testing" is to upload it to "unstable". Any fix to "stable" requires the bug to be fixed in "unstable" first, and the bug has to be of more than "normal" severity and be a targeted-only fix with the individual patch provided in the request to the release team, with a detailed description of the issue and what problems it causes, as well as what testing the fix has had. Mumble upstream just released a 1.3.1-rc1 tarball today, so it's clear they're actively preparing a bugfix release. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#952742: mumble: start locks sound for all application (even the client itself)
lemmel: > Well done ! > > I was stupid: jackd was in the ouput, but as Pulse was selected I totally > ignored it ; and jackd doesn't even figure in the Mumble UI ! > > I'm really sorry: I filled a bug, and waste your time. I consider this bug to be worthwhile and important and I'm glad you opened it. I'm very thankful to Sébastien for figuring out that this relates to Jack and I didn't realize that could have been the cause. The Jack support in Mumble is rather new and there have been some other issues with it (7-second startup delay for Mumble on Sid without Jack installed, for instance): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941455 > Le mardi 31 mars 2020, 19:58:06 CEST Sébastien Leblanc a écrit : >>> ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2+b1 >> >> I see you have Jack installed, have you checked if Mumble started it? >> Unfortunately, while Mumble supports Jack, it does not play nicely with >> it in this release, as there are no options in the GUI pertaining to >> disabling automatic connections or automatic startup of the Jack server. >> By default, it will attempt to start Jack if it is installed on the >> system, even if you set the output module to ALSA or PulseAudio. >> >> >> In `~/.config/Mumble/Mumble.conf`, you can add the following : >> >> >> % >> >> [jack] >> startserver=false >> >> % >> >> >> Please see if this does anything. Thank you for figuring out the above setting; I didn't know that was possible. And as you mentioned there's no options in the GUI pertaining to Jack. :-/ I'll see if I can discuss this issue with upstream. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#952742: mumble: start locks sound for all application (even the client itself)
lemmel: > I too tested in a VM (with KDE) but to no avail: I wasn't able to reproduce > the problem with it. > > I will test this week-end an update, then a full reset of my Mumble prefs, > and will tell you the results. > > PS: thx for your invest Thanks for taking the time to try reproducing the problem; I'm glad to have verification that the issue is not as serious as it first appeared. I'd like to think that there would be a comparable difference between the KDE test VM and the Debian Sid/Testing instance that is having Mumble audio issues. A logical possibility would be something related to the PulseAudio settings / installation or perhaps AppArmor security settings related to audio, if those have been customized. I find these types of investigations can be worthwhile, as they can be good learning experiences. I'll try to think of whether there's another way I can help. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#952742: mumble: start locks sound for all application (even the client itself)
[sent this on 3/4 to the bug reporter and forgot to send it to the bug report] Chris Knadle: [...] > Concerning Debian Sid/Unstable, my understanding is that it is not a complete > distribution, and so Unstable is meant to be run as Unstable + Stable, i.e. > Sid > + Buster. Looking at the distributions you're currently using I see it's > Unstable + Testing, i.e. Sid + Bullseye. I'm not sure if that may explain > this > bug or not; I may try to take a VM snapshot and upgrade to Sid + Bullseye and > see if I can get the audio in Mumble to crap out. Okay I made a VM snapshot and upgraded the VM to Sid + Testing and Mumble audio (using PulseAudio) still worked, and audio for the rest of the system worked as well with and without Mumble running. I used MATE as the GUI for the testing. I've also enabled AppArmor in the same VM and audio works within and outside of Mumble, regardless of whether it's running or not. I am not able to reproduce this bug, and I think I've run out of options to try to do so. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#952742: mumble: start locks sound for all application (even the client itself)
severity 952742 important tags 952742 + moreinfo unreproducible thanks lemmel: > Package: mumble > Version: 1.3.0+dfsg-1+b1 > Severity: grave > Tags: upstream > Justification: renders package unusable > > Dear Maintainer, > > fresh dist-upgrade (this day 02/28/20) brought up a mumble that lock all sound > on the host, the mumble client itself producing no sound. > > I did all kind of setup with the mumble client (OSS, ALSA, etc), but it did > nothing. I upgraded a VM running native Sid + Buster and did a full upgrade, and found audio with Mumble 1.3.0+dfsg-1+b1 via pulseaudio worked fine. I tried using ALSA with Mumble, and was not able to get that to work with the "[default] Playback/recording through the PulseAudio sound server" setting, and haven't tried further settings (yet). I tried OSS with Mumble and was not able to get that to work, but that didn't surprise me. Concerning Debian Sid/Unstable, my understanding is that it is not a complete distribution, and so Unstable is meant to be run as Unstable + Stable, i.e. Sid + Buster. Looking at the distributions you're currently using I see it's Unstable + Testing, i.e. Sid + Bullseye. I'm not sure if that may explain this bug or not; I may try to take a VM snapshot and upgrade to Sid + Bullseye and see if I can get the audio in Mumble to crap out. But for now I'm marking the severity of this bug as "important" rather than "grave" because as best I can tell it's broken on your system but not others. [If other users hit this bug when running Sid + Buster, please report that to this bug.] It's also possible this might be AppArmor related, because Mumble doesn't ship an AppArmor profile at the moment, and I see you've got AppArmor enabled. [...] > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled The best place I know to get more helpful advice in tracking down the audio difficulty is the #mumble IRC channel on irc.freenode.net. There are users in the IRC channel that regularly help with PulseAudio issues. Similar to your experience, for me PulseAudio is mostly a "magic" thing which I tweak a bunch to get what I need if I find I need something specific. I'll try to be more help if I can. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#952742: mumble: start locks sound for all application (even the client itself)
Greetings, lemmel. lemmel: > Package: mumble > Version: 1.3.0+dfsg-1+b1 > Severity: grave1.3.0+dfsg-1 > Tags: upstream > Justification: renders package unusable > > Dear Maintainer, > > fresh dist-upgrade (this day 02/28/20) brought up a mumble that lock all sound > on the host, the mumble client itself producing no sound. > > I did all kind of setup with the mumble client (OSS, ALSA, etc), but it did > nothing. > > Don't really know the reason as pulseaudo is kind of a magic thing to me, but > I > did retrieve several versions of the mumble client and saw that the current > git > code work correctly. > > Here is the summary of my builds (all extracted from the Git repository) and > tests : > - git clone https://github.com/mumble-voip/mumble.git mumble > cd mumble > git checkout tags/1.3.0 > git submodule init > git submodule update > ===> FAILED > > - git clone --single-branch --branch 1.3.x https://github.com/mumble- > voip/mumble.git > cd mumble > git submodule init > git submodule update > ===> FAILED > > - git clone https://github.com/mumble-voip/mumble.git > cd mumble > git submodule init > git submodule update > ===> SUCCESS > > So it may suggest that the current devel version fixes something about its > sound management. I normally upload mumble when there's a release snapshot available; I don't upload development versions from Git unless upstream specifically directs doing that. (Which only happened once because there was no 1.3.0 snapshot available for release at the time.) I don't know why upstream is taking so long to make another release snapshot. :-/ > PS : system informations > - 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux > - libc6 : amd64 2.29-10 > - mumble : 1.3.0+dfsg-1+b1 > - gcc -v : gcc version 9.2.1 20200224 (Debian 9.2.1-30) > - Qt : 5.12.5 > - pulseaudio : 13.0-5 I'm glad this specific section was added because I had tested Mumble in a Sid VM and the audio worked fine, but the version of pulseaudio in that VM ended up being held back to 12.2-4+deb10u1 and can't be upgraded due to package conflicts. I would like to test this with a more "pure" Sid VM to see what I find. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards
Alexander Ponyatikh: > Thank you. I was expecting that there should be a separate procedure for > this case, but I could not find it. I've modified this bug report in > accordance with the Developers' Reference. Cool. Yeah the "salvaging" procedure is relatively new and it's gone through a few revisions over time. When I had to salvage a package (mumble) in 2014 there was no process for salvaging a package, so it was a lot more effort to adopt it, and it took months. I found out (as I think you have) that sometimes we end up needing to support software ourselves if we want it to function. > I've already put the original maintainer's address into the X-Debbugs-Cc > filed of this report, so he's got a copy of the initial message. > > I'll ask Andrej about sponsorship later, when 21 days have passed. The maintainer replied and he's not against it being adopted (the word "again" was used, but the context makes it clear it was meant to be "against"), so you can proceed at any time. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards
Giacomo Catenazzi: > Hello Chris, > > Alexander already asked me about packages, and I have nothing again getting it > adopted. Just I had no time (and hardware) to handle the packages, and the > lack > of upstream worries my a lot (e.g. security, but also upgrading support > libraries). > > ciao > cate Hello cate. I understand. These situations happen. Thanks for your reply. For situations where the maintainer does not have time to deal with packages, there's a procedure to follow for that described here in section 5.9.4 of the Developer's Reference: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning As the procedure describes, this could be filing RFA: bugs or orphaning the packages. Orphaning the packages would help others adopt the packages without needing to contact you first. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards
Greetings. Thanks for your interest in maintaining the libg15render package and for adopting the g15daemon package. Although I don't use g15, I maintain mumble which can optionally use it to support users that have the g15 keyboard. Right now I've had to disable g15 support in mumble because of the package removal that had occurred, but I can re-enable that if it's considered safe to do so. I'm CC:ing the current maintainer directly in order document them being notified of the ITA. This package IMHO is definitely available for salvage. Just for reference, the Debian Developer's Reference section 5.12.2 suggests normally giving the maintainer 21 days to respond before a salvage upload: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package Packaging of libraries is a special category in Debian, and I've never been involved in packaging a library so far, but am interested in how that works, and given what this package is for this library package seems to be of relatively low risk. I'm having another read through the Debian Developer's Reference section 6.7.2 concerning libraries: http://sejnfjrq6szgca7v.onion/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries I see that Andrej Shadura is sponsoring uploads for your work with the g15daemon package; have you checked with him to see if he's comfortable sponsoring uploads for this package? Mainly I'm asking because the packages are related. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye
There has been some discussion about #936299 on the upstream mailing list, and there have been a few upstream commits starting to port the code to Python3. http://intrepid.danplanet.com/pipermail/chirp_devel/2019-August/005580.html -- Chris, KB2IQN -- Chris Knadle chris.kna...@coredump.us
Bug#941455: mumble: Slow upstart since 1.3.0+dfsg-1 because of jackd
tags 941455 + patch
thanks
Chris Knadle:
> I think the best I can do is open a bug upstream (I opened issue #3822) about
> the problem so that they can either add a Mumble setting to disable trying to
> contact jackd in the client, or lower/shorten the attempts to contact jackd
> to decrease the startup delay.
Mumble upstream has pulled in a rewritten jackd implementation to fix this
issue, which I've tested and works. Attached is a patch which combines several
upstream commits that seems to fix the issue; I'm mainly including it in case
someone desires to rebuild the package locally with the fix. Upstream is fixing
several other things too, so I'm looking forward to uploading the next bugfix
release.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
From 01b097d6ee05aaafd20174d013b438e51fb584c8 Mon Sep 17 00:00:00 2001
From: Davide Beatrici
Date: Tue, 8 Oct 2019 03:09:22 +0200
Subject: [PATCH] Revamp JackAudio implementation
Some users were encountering issues such as the client taking ~8 seconds to
start when "jackd" could not be run, due to the library attempting many times
to connect to the JACK server (https://bugs.debian.org/941455).
While working on a fix I corrected the many warnings emitted by Clang-Tidy and
I realized that there were many things that could be improved.
This commit almost entirely rewrites the implementation, but here are some of
the changes:
- Mutexes are used everywhere, race conditions should not be possible anymore.
- The JACK client is not opened until it's required (i.e. "JackAudioInput"
and/or "JackAudioOutput" start running). The initialization code has been moved
to a dedicated function, the constructor doesn't execute it anymore. This is
what fixes the issue mentioned above.
- The JACK client is deactivated and closed automatically when both
"JackAudioInput" and "JackAudioOutput" are not running.
- Code specific to audio input or audio output has been moved from
"JackAudioSystem" to the corresponding section ("JackAudioInput" or
"JackAudioOutput").
- Some variables in "JackAudioSystem" have been replaced with functions which
retrieve the corresponding value from the JACK server.
- Removed all instances of "delete", raw pointers have been replaced with
"std::unique_ptr<>()".
- Replaced "NULL" with "nullptr".
--- a/src/mumble/JackAudio.cpp
+++ b/src/mumble/JackAudio.cpp
@@ -5,53 +5,53 @@
#include "JackAudio.h"
+// We define a global macro called 'g'. This can lead to issues when included
code uses 'g' as a type or parameter name (like protobuf 3.7 does). As such,
for now, we have to make this our last include.
#include "Global.h"
-
-static JackAudioSystem *jasys = NULL;
+static std::unique_ptr jas;
// jackStatusToStringList converts a jack_status_t (a flag type
// that can contain multiple Jack statuses) to a QStringList.
-QStringList jackStatusToStringList(jack_status_t status) {
+static QStringList jackStatusToStringList(const jack_status_t ) {
QStringList statusList;
- if ((status & JackFailure) != 0) {
+ if (status & JackFailure) {
statusList << QLatin1String("JackFailure - overall operation
failed");
}
- if ((status & JackInvalidOption) != 0) {
+ if (status & JackInvalidOption) {
statusList << QLatin1String("JackInvalidOption - the operation
contained an invalid or unsupported option");
}
- if ((status & JackNameNotUnique) != 0) {
+ if (status & JackNameNotUnique) {
statusList << QLatin1String("JackNameNotUnique - the desired
client name is not unique");
}
- if ((status & JackServerStarted) != 0) {
+ if (status & JackServerStarted) {
statusList << QLatin1String("JackServerStarted - the server was
started as a result of this operation");
}
- if ((status & JackServerFailed) != 0) {
+ if (status & JackServerFailed) {
statusList << QLatin1String("JackServerFailed - unable to
connect to the JACK server");
}
- if ((status & JackServerError) != 0) {
+ if (status & JackServerError) {
statusList << QLatin1String("JackServerError - communication
error with the JACK server");
}
- if ((status & JackNoSuchClient) != 0) {
+ if (status & JackNoSuchClient) {
statusList << QLatin1String("JackNoSuchClient - requested
client does not exist");
}
- if ((status & JackLoadFailure) != 0) {
+ if (status & JackLoadFailure) {
statusList << QLatin1String("JackLoadFailure - unable to load
initial client"
Bug#941455: mumble: Slow upstart since 1.3.0+dfsg-1 because of jackd
severity 941455 minor tags 941455 + confirmed forwarded 941455 https://github.com/mumble-voip/mumble/issues/3822 thanks Matthias Heinz: > Package: mumble > Version: 1.3.0+dfsg-1 > Severity: normal > > Hi, > > since the last update mumble starts very slow. > > On the console it shows: > > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > exec of JACK server (command = "/usr/bin/jackd") failed: No such file or > directory > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > jack server is not running or cannot be started > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > 2019-09-30 22:29:28.762 JackAudioSystem: unable to open client due to 2 > errors: > 2019-09-30 22:29:28.763 JackAudioSystem: JackFailure - overall operation > failed > 2019-09-30 22:29:28.763 JackAudioSystem: JackServerFailed - unable to > connect to the JACK server > > I'm using pulseaudio. jackd is not installed. > > Best regards > Matthias I also don't use jackd and I see the same behavior; on my system it takes about 7 seconds for Mumble to start as attempts to contact jackd fail, same as the above. As this bug causes a delay but doesn't break anything I'm setting the severity to 'minor'. I've had several requests to enable jackd support over time, which is why this uploaded enabled it. Upstream had asked me to enable the feature just before the freeze for Buster, but I considered adding the feature too risky at the time because I had only one upload left before the freeze to close some other bugs, so didn't enable it then. As best I can tell there's no setting to disable Jack in the client, so there's no way right now to avoid the startup delay. I would rather not remove the feature because others use it and want it, so I think the best I can do is open a bug upstream (I opened issue #3822) about the problem so that they can either add a Mumble setting to disable trying to contact jackd in the client, or lower/shorten the attempts to contact jackd to decrease the startup delay. I did test to make sure the client worked before doing the upload BTW (as I always do), but I had started the client from the GUI menu and didn't realize there was a startup delay. I would have done the upload had I known about it, due to the requests for the feature and the minor impact this otherwise. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#939901: Upstream has released 1.3.0
Michael Evans: > Package: mumble > Version: 1.3.0~git20190125.440b173+dfsg-2 > > Upstream has released 1.3.0 > https://www.mumble.info/blog/mumble-1.3.0-release-announcement/ Ignore my last message to you, it was due to user error -- I was verifying an old 2017 tarball in place of the new 1.3.0 tarball accidentally. I'm working to upgrade the package when possible. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#940270: mumble-server: Server fails to start with valid SSL Certs enabled.
Andrew Lawrence DeMarsh: > Package: mumble-server > Version: 1.3.0~git20190125.440b173+dfsg-2 > Severity: important > > Dear Maintainer, > > When adding SSL Certs from LetsEncrypt to the mumble server that was > operating with self signed certs it was found that the Server would > fail to start up with the following error: > > root@mumble:/# murmurd -ini /etc/mumble-server.ini -v > 2019-09-14 23:40:58.428 SSL: OpenSSL version is 'OpenSSL 1.1.1c 28 May > 2019' > 2019-09-14 23:40:58.428 Initializing settings from > /etc/mumble-ff-server.ini (basepath /etc) > > 2019-09-14 23:40:58.430 MetaParams: Failed to find certificate matching > private key. > 2019-09-14 23:40:58.430 MetaParams: Failed to load SSL settings. See > previous errors. > > This is not a permissions issue as the certificates are in roots home folder > and it is running as root. > These are standard SSL Cert from letsencrypt recieved using acme.sh. It's unusual to run mumble-server/murmur as root, and also unusual to have SSL certificates in the root user home folder. Mumble is typically started as root but then the user switched to the user listed in the configuration file in /etc/mumble-server.ini. The default setting is: "uname=mumble-server". Have you set the 'uname' setting to "root"? The Mumble wiki has some LetsEncrypt instructions here: https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate note that the instructions above discuss the folders in the path needing "directory execute permissions" for the server to be able to read the certificates. Other users have had issues getting mumble-server with LetsEncrypt certificates but eventually got it working after discussing it in the #mumble IRC channel on irc.freenode.net. If you get the chance to ask there I think they can help debug the issue further. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#929099: mlmmj-send fails when peer greeting is long and slow
Ian_Zimmerman: > Package: mlmmj > Version: 1.2.19.0-1 > Severity: normal > Tags: upstream > > When mlmmj-send injects mail into the MTA, it uses SMTP to 127.0.0.1 on port > 25. Those are the defaults, but the "relayhost" and "smtpport" settings are tunable, and there's also a "smtphelo" setting. > Unfortunately, it doesn't correctly implement the SMTP standard: it sends an > EHLO > command immediately after it gets the first line of the greeting, which in my > case > starts with "220-" and is followed by additional lines. The result is that it > interprets these additional lines of the greeting as a response to the EHLO, > which > of course fails. > > I don't know if this wrong behavior is simply because it only waits for one > line > (and, I'd guess, checks that the line starts with "2"), or because it is > confused > by the several seconds the MTA waits before sending its greeting. Both kinds > of > behavior have been observed in many spamming tools which is precisely why I > have > configured a multiline greeting and a delay. > > In my opinion when mlmmj runs on the same host as the MTA, it should be at > least an > option to inject mail directly via a pipe to /usr/sbin/sendmail; but I have > not found > such an option. There is a way of injecting mail directly with a pipe via entries in /etc/alisases such as: example-list: "|/usr/bin/mlmmj-recieve -L /var/spool/mlmmj/example-list/" (where "example-list" is the name of the mailing list) Whether and how a this type of entry will work depends on the specific MTA being used and how the MTA is configured. For instance the provided upstream instructions for Exim4 don't use entries like this in /etc/aliases, but the instructions for Postfix do. The MTA in the bug report shows 'equivs-mta' which I assume means that there's a fake 'equivs-mta' package in use and the real MTA in use for this case is something else. Depending on the MTA you might be able to work around your normal multiline greeting + delay if the originating sender it actually local (as opposed to a remote sender spoofing that the sender is local). I wasn't aware MLMMJ doesn't conform to proper SMTP EHLO, but it also won't surprise me if I test to verify this and find that it's so. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#925464: new upstream release (1.3rc1)
Update on the bug: Chris Knadle: [..] > I doubt this package is going to get accepted by the Release Team, because > upload after the freeze is meant for only small targeted fixes. I'll make the > request to see if it's possible, but I expect that the chances of this being > accepted to be very low. The release team has rejected the change in #927266 (which is not unexpected, and I agree with their decision). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927266 So Debian Buster will release with mumble 1.3.0~git20190125.440b173+dfsg-2 -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#925464: new upstream release (1.3rc1)
Antoine Beaupré: > On 2019-04-17 01:31:49, Chris Knadle wrote: > > [...] > > Wow, that must have all been a lot of work, thanks! :) You're welcome. >> I doubt this package is going to get accepted by the Release Team, because >> upload after the freeze is meant for only small targeted fixes. I'll make >> the >> request to see if it's possible, but I expect that the chances of this being >> accepted to be very low. > > I agree. In fact, I think it might even be better to *remove* mumble > from buster at this point, and maintain it through backports. We > *definitely* do not want a RC in buster that we'll have to maintain for > years... Much easier to do through backports! Mmm... no, I don't agree there. Backports are a separate repository that users have to find and specifically configure to use, and -- more importantly -- the only backports that can exist are for packages that have been uploaded to Debian and transitioned to Testing. i.e. the package *must* exist in Debian Testing already for an upload to be allowed to Backports. The Debian backport for mumble is done by another maintainer, not me, and backports are also messy because bugs to backports should go to the backports mailing list, *not* the BTS. It's possible to set the package up to cause that to happen by setting a Bugs: line with a 'mailto:', but not all of the bug reporting software comply with that. (reportbug does, reportbug-ng does not, at least last I checked.) There's always a running 'diff' between the package in Testing and the backport, and the 'diff' slowly gets bigger as there are changes in libraries, newer versions of debhelper, and so on. And in the case of Mumble the backport is in a separate offline Git repository away from the one used for the main package. Backports may be easier for (some) users, but they're harder for maintainers -- or at least that's my experience with them so far. > I can change the severity of this bug, if you agree, which should > eventually kick the package out of testing... Heh... :-p Please don't. I understand the sentiment but it makes a bigger mess rather than easing one. > I'm sorry, but I think it's just "partie remise" as we say in french: > we'll get it in bullseye! And this time it will be awesome. ;) Dude I did my best to try to get upstream to release a viable snapshot of some kind before the soft freeze -- I mean really, I pleaded with them -- but it didn't happen. It didn't make sense to release the old Mumble 1.2 to Buster, the upstream snapshots for Mumble 1.3 that were available were broken, upstream asked me to release directly from Git instead, and the upstream repo uses submodules such that making a tarball required creating a script to do it which breaks the debian/watch stuff. I did the best that could be done, and there's no opportunity to re-do it. *shrug* C'est la vie!! ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#925464: new upstream release (1.3rc1)
Here's an update on this bug: I've completed the packaging for 1.3.0-rc1 -- that took a lot more work than it should have because there are still unreleasable codec documentation files in the upstream tarball (and new unreleasable files too, argh!). [Each time I find new unreleasable files it means starting the work over, in order to keep the unreleasable files out of the Git history.] Unfortunately the resulting debdiff between the package before the Buster freeze and 1.3.0~rc1+dfsg-1 is about 10 MB in size. And it looks like it's a lot of real "sprinkled" changes throughout the code, not just the result of file re-ordering or repack file removal. It's a large amount of actual change. I doubt this package is going to get accepted by the Release Team, because upload after the freeze is meant for only small targeted fixes. I'll make the request to see if it's possible, but I expect that the chances of this being accepted to be very low. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#925464: new upstream release (1.3rc1)
Hello again Antoine. :) Antoine Beaupre: > Package: mumble > Version: 1.2.18-1+deb9u1 > Severity: normal Filed against stable rather than unstable; oops. ;-) > Upstream has finally got their act together and made a release on the > 1.3 branch. It's just an rc1, but maybe it would be better to ship > that with buster than the current git snapshot. That might need some > convincing with the release team, but I think it's worth the trouble. > > See: > > https://github.com/mumble-voip/mumble/issues/2865 > > A. Okay I've read through issue #2865 -- thank you for discussing the release issues there. I totally agree that it would be preferable to ship 1.3.0-rc1 rather than the release I had to do from git because: - the release from git doesn't come with a GPG signature, so no GPG verification can be done - DFSG tarball repacking required due to non-free documents in git submodules (which also wrecks GPG verification) - the release version numbers when shipping from git are terrible - the debian/watch file can't be used when making a tarball from git, at least when also needing to make DFSG modifications afterwards, AFAICT - when users write bug reports, they're for a version that doesn't exist upstream :( I'm willing to do the work needed to release this to Buster, assuming the Release Team are agreeable, due to all of the issues above. What I'll do to start with is have a look at the -rc1 tarball ASAP to see if it requires DFSG repacking. And thanks for your continued in Mumble, BTW. It helps me to know that doing the work I do helps others. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#921268: [mumble] Mumble's Audio Tuning Wizard doesn't play test samples/sounds, TTS is possibly also broken
forwarded 921268 https://github.com/mumble-voip/mumble/pull/3611 tags 921268 = fixed-upstream thanks This bug was caused by an error in the audio sample path: https://github.com/mumble-voip/mumble/commit/c49301b0cb2689657953aca0b874f5eecfac4566 As this is something that can be given a targeted fix I'll see if I can get a package with the fix uploaded before the full freeze. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#921617: mumble: Mumble memory use increases over time to unreasonable amounts
retitle 921617 Mumble echo canceler leaks memory forwarded 921617 https://github.com/mumble-voip/mumble/issues/3379 thanks Colomban Wendling: > Le 08/02/2019 à 16:54, Chris Knadle a écrit : >> Colomban Wendling: >>> Le 07/02/2019 à 16:56, Chris Knadle a écrit : >>>> […] >>>> >>>> Just to mention: this isn't the first report of "memory leak" on Mumble -- >>>> see >>>> Debian bug #683827. >>>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683827 >>>> >>>> I wasn't able to reproduce #683827 on newer versions of Mumble 1.2.x but >>>> wasn't >>>> sure what the underlying cause/issue was there, or what version of Mumble >>>> may >>>> have fixed that bug. >>> >>> The links you have there are interesting; for example >>> https://github.com/mumble-voip/mumble/issues/1074#issuecomment-20316 >>> suggests that it might be due to echo canceller and other apps "messing" >>> with PulseAudio. I do have echo canceller enabled (that I should >>> actually be able to disable as I'm using push-to-talk with a headset), >>> and am running at least one virtual machine which could be doing >>> something with PulseAudio. >>> >>> I'll try and do some tests next chance I get (probably next week). >> >> *nod* Okay. Yeah the echo canceler would be part of the Mumble binary, so >> if >> the canceler is misbehaving memory-wise then that would make sense. > > I tried without the echo canceller and it's behaving reasonably so far, > after 5 hours: it's using 109M resident memory, and peaked at 123M. > So it seems it's indeed the echo canceller that's leaking a lot. Okay. Thank you very much for testing and finding this, as it helps narrow down where the problem is. I'm re-titling the bug so that it will be easier for others to find when looking to find information about it. >> However if >> another virtual machine were causing issues with PulseAudio then that >> shouldn't >> cause memory expansion/leaking in the Mumble client binary (AFAIK). > > IIUC from the report I linked, some software alter the input sinks in a > way that confused the echo canceller. It'd say it's still a bug on the > canceller part, but it might be triggered only on some conditions that > don't normally happen, but that some software doing their own audio > input trigger -- not quite sure. *nod* Hmm. So I think the theory there is that the because other VMs interact with PulseAudio that it changes the interaction between PulseAudio and the Mumble echo canceler such that the echo canceler uses increasing memory. It feels like that "shouldn't happen", but then again that's the definition of a "bug" and this is a bug, so... maybe it's possible. I had a look at the open issues for mumble and found #3379 which is about Mumble echo cancellation on Windows: https://github.com/mumble-voip/mumble/issues/3379 also issue #3406 which shows the memory leak to be intermittent (if true that would be annoying, because that makes the root cause harder to find): https://github.com/mumble-voip/mumble/issues/3406 I'm marking this bug as related to Mumble issue #3379 upstream and adding an entry to the upstream bug pointing to this one so that upstream can see that this is likely affecting other OSes than Windows. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#921268: [mumble] Mumble's Audio Tuning Wizard doesn't play test samples/sounds, TTS is possibly also broken
Hello Mikaela. Mikaela Suomalainen: > Package: mumble > Version: 1.3.0~git20190125.440b173+dfsg-1 > Severity: normal > > --- Please enter the report below this line. --- > > Hi, > > I think this issue was introduced by 1.3.0~git20190114.9fcc588+dfsg-1. > When I open the audio wizard, the third screen is device tuning which > says "You should hear a voice sample. Change the slider below to the > lowest value which gives no interruptions or jitter in the sound", and > here I don't hear sound at all. I've tested this and I see the same behavior. > Later there is "Positional Audio" configuration, where the last phrase > is "You should hear the audio move between the channels". There is no > audio here either. I experience this issue on both headset and laptop > internal speaker/microphone, and also HDMI audio. I've tested and see the same behavior with this too. > I am not entirely sure when I should hear TTS, but I think it's also > broken as I don't hear messages while connecting and disconnecting to > server, which I think I heard previously. Text-To-Speech still works in my testing, but didn't at first and I found why. Check to be sure you have the 'speech-dispatcher' package installed. If not, install it. The Mumble client does not need re-loading to get TTS to work if speech-dispatcher wasn't installed before. speech-dispatcher isn't a dependency for Mumble and I think that's purposeful; there have been some bugs and occasional misbehavior related to speech-dispatcher such that I find it beneficial not to have it installed when it's not required. I'm not sure what's going on with the missing audio samples, but I've seen discussion about that in the #mumble IRC channel on irc.freenode.net, so there's a possibility that this might be by design. I'll ask upstream. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#921617: mumble: Mumble memory use increases over time to unreasonable amounts
Colomban Wendling: > Le 07/02/2019 à 16:56, Chris Knadle a écrit : >> […] >> >> Just to mention: this isn't the first report of "memory leak" on Mumble -- >> see >> Debian bug #683827. >>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683827 >> >> I wasn't able to reproduce #683827 on newer versions of Mumble 1.2.x but >> wasn't >> sure what the underlying cause/issue was there, or what version of Mumble may >> have fixed that bug. > > The links you have there are interesting; for example > https://github.com/mumble-voip/mumble/issues/1074#issuecomment-20316 > suggests that it might be due to echo canceller and other apps "messing" > with PulseAudio. I do have echo canceller enabled (that I should > actually be able to disable as I'm using push-to-talk with a headset), > and am running at least one virtual machine which could be doing > something with PulseAudio. > > I'll try and do some tests next chance I get (probably next week). *nod* Okay. Yeah the echo canceler would be part of the Mumble binary, so if the canceler is misbehaving memory-wise then that would make sense. However if another virtual machine were causing issues with PulseAudio then that shouldn't cause memory expansion/leaking in the Mumble client binary (AFAIK). >> Due to recent security bugs in Mumble I'm going to be preparing a version of >> Mumble 1.3 with Qt4 (targeted for Stretch) -- so there will be an >> opportunity to >> test that to see if it shows the same memory leak. > > I can also test if reverting to a previous version of Mumble helps; I'm > not sure which are the security issues but in my case I trust the server > so there might be no problem using an older version for testing. The two recent security issues relate to mumble-server specifically, not the client. One security issue has been resolved, another is described in Debian bug #919249 and on this Debian Secuirty page for CVE-2018-20743: https://security-tracker.debian.org/tracker/CVE-2018-20743 >> […] >> >> I don't personally know of a "good" way to debug memory leaks. As far as I >> know >> this involves running the target program via a debugger like GDB and figuring >> out how to watch memory allocations and frees. Unfortunately I don't have >> any >> experience with doing that [successfully] yet. > > Valgrind's memcheck is the best I know. I'll try to see if I can run > Mumble in it and find out what I can from there -- although it often is > a pain starting from nothing, as many toolkits and apps have gazillions > of innocent leaks cluttering the results. *headsmack* I keep forgetting about Valgrind. I can try playing with that too, assuming I can replicate the memory leak. > Thanks for the input, and I'll get back here with any data I can gather > on this. *nod* Thank you very much for your help. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#921617: mumble: Mumble memory use increases over time to unreasonable amounts
Colomban Wendling: > Package: mumble > Version: 1.3.0~git20190125.440b173+dfsg-1 > Severity: important > > Dear Maintainer, > > I use Mumble daily as a remote work team communication channel, so it's pretty > much open non-stop for one day at a time. Understood. I typically also leave the Mumble client open for long periods of time, but have not tried doing this with Mumble 1.3 yet. When possible I'll try to replicate this bug to see if I see the same behavior. > Since a few days, maybe a week, Mumble's memory usage is steadily growing to > crzay levels: right now, `top` report it's using 25% of my 12Go of memory > (resident memory shows 3g). This situation forces me to restart the client > every now and then, unfortunately at least a few times a day -- and > obviously is also a problem for overall use of resources. > I wouldn't say it started right away with the new Qt5 Mumble, but it could > have, I'm not completely sure. > > It wasn't always like that, and used to work fine. Just to mention: this isn't the first report of "memory leak" on Mumble -- see Debian bug #683827. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683827 I wasn't able to reproduce #683827 on newer versions of Mumble 1.2.x but wasn't sure what the underlying cause/issue was there, or what version of Mumble may have fixed that bug. Due to recent security bugs in Mumble I'm going to be preparing a version of Mumble 1.3 with Qt4 (targeted for Stretch) -- so there will be an opportunity to test that to see if it shows the same memory leak. > I cannot really provide credentials for the server, but I can do tests if > need be. There is no issue I can see on Mumble's stdout/stderr: > > 2019-02-07 10:49:42.966 libopus 1.3 from libopus.so.0 > 2019-02-07 10:49:42.967 CELT bitstream 800b from > /usr/lib/mumble/libcelt0.so.0.7.0 > 2019-02-07 10:49:42.970 Theme: "Mumble" > 2019-02-07 10:49:42.970 Style: "Lite" > 2019-02-07 10:49:42.970 --> qss: ":themes/Mumble/Lite.qss" > 2019-02-07 10:49:42.971 Locale is "fr_FR" (System: "fr_FR") > 2019-02-07 10:49:43.215 Database SQLite: "3.26.0" > 2019-02-07 10:49:43.219 Overlay: Listening on > "/run/user/1000/MumbleOverlayPipe" > 2019-02-07 10:49:43.252 Updating application palette > 2019-02-07 10:49:43.291 GlobalShortcutX: Using XI2 2.3 > 2019-02-07 10:49:44.697 AudioInput: Opus encoder set for VOIP > 2019-02-07 10:49:44.697 AudioInput: 23000 bits/s, 48000 hz, 480 sample > 2019-02-07 10:49:44.697 PulseAudio: Starting input > alsa_input.pci-_00_1b.0.analog-stereo > 2019-02-07 10:49:44.697 PulseAudio: Starting echo: > alsa_output.pci-_00_1b.0.analog-stereo.monitor > 2019-02-07 10:49:44.697 PulseAudio: Starting output: > alsa_output.pci-_00_1b.0.analog-stereo > 2019-02-07 10:49:44.699 AudioOutput: Initialized 2 channel 48000 hz mixer > 2019-02-07 10:49:44.699 AudioInput: Initialized mixer for 1 channel 44100 > hz mic and 0 channel 48000 hz echo > warning: The VAD has been replaced by a hack pending a complete rewrite > 2019-02-07 10:49:44.726 AudioInput: Initialized mixer for 1 channel 44100 > hz mic and 2 channel 48000 hz echo > warning: The VAD has been replaced by a hack pending a complete rewrite > 2019-02-07 10:49:44.736 AudioInput: ECHO CANCELLER ACTIVE > 2019-02-07 10:49:44.847 Database SQLite: "3.26.0" > 2019-02-07 10:49:44.848 OpenSSL Support: 1 (OpenSSL 1.1.1a 20 Nov 2018) > 2019-02-07 10:49:45.277 ServerHandler: TLS cipher preference is > "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA" > > Regards, > Colomban I don't personally know of a "good" way to debug memory leaks. As far as I know this involves running the target program via a debugger like GDB and figuring out how to watch memory allocations and frees. Unfortunately I don't have any experience with doing that [successfully] yet. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#920476: security issue: DoS due to changing # of allowed users in root channel
Package: mumble Version: 1.3.0~git20190114.9fcc588+dfsg-1 Severity: serious Tags: security fixed-upstream pending A vulnerability has been discovered whereby a remote unauthenticated user connected to the server can send a crafted packet to change the number of allowed users in the root channel to 0, thereby disallowing users to connect to the server and causing a Denial of Service. All version of mumble-server prior to the fix in Mumble issue #3586 on 2019-01-25 are affected. https://github.com/mumble-voip/mumble/issues/3585 A new upload of mumble is being prepared to fix this issue. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#920237: [mumble] lost list of server configurated
petrohs: > Package: mumble > Version: 1.3.0~git20190114.9fcc588+dfsg-1 > Severity: normal > > --- Please enter the report below this line. --- > [en] When updating the mumble client, the list of old servers > configurated does not exist, it was lost in the interface. (I found it > in ~/.local/share/data/Mumble/Mumble/.mumble.sqlite) > > [es] Al actualizar el cliente mumble, la lista de servidores registrados > ya no existe, se perdió en la interfaz. (Si lo encontré en > ~/.local/share/data/Mumble/Mumble/.mumble.sqlite) From what I can tell the default storage location of settings has changed between Mumble 1.2 and 1.3: Mumble 1.2: ~/.local/share/data/Mumble/Mumble/.mumble.sqlite Mumble 1.3: ~/.local/share/Mumble/Mumble/mumble.sqlite However looking at the source code in src/mumble/Database.cpp, the client looks for the "legacy" hidden filename "/.mumble.sqlite" and uses it if it's found, otherwise it uses "/mumble.sqlite" for new storage. (See lines 60 - 78). https://salsa.debian.org/pkg-voip-team/mumble/blob/debian/src/mumble/Database.cpp The "/data/Mumble" directory is searched for in Global.cpp and moved to "/Mumble" if it is found. (See lines 46 - 57) https://salsa.debian.org/pkg-voip-team/mumble/blob/debian/src/mumble/Global.cpp I've run into this bug myself so I verify the behavior you see. There must be some quirk in the code trying to pick up and move the old storage location which isn't doing what's expected. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#915768: mangler: B-D libg15-dev libg15daemon-client-dev are no longer available
tags 915768 + pending thanks I've applied the patch and uploaded 1.2.5-4.1 to the DELAYED/2 queue. This only removes the g15 Build-Depends and adds --disable-g15 to debian/rules. Willam: Being that there's been no response from the maintainer for this bug in over a month for a bug of severity 'serious' it seems like this package could use 'salvaging'. Have a look at the Debian Developer's Reference, section 5.12 here: http://sejnfjrq6szgca7v.onion/doc/manuals/developers-reference/ch05.en.html#package-salvaging If you still have interest in fixing the other minor bugs, which it looks to me like you do, then try contacting the maintainer and/or file an ITS bug. I'm willing to sponsor uploads for you. Seems like you're already familiar with Debian packaging, but feel free to contact me if I can be of further help. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#919453: mumble FTCBFS: builds for the wrong architecture
Lisandro Damián Nicanor Pérez Meyer:
> Hi everyone!
Greetings again Lisandro. :)
> El miércoles, 16 de enero de 2019 14:53:19 -03 Helmut Grohne escribió:
>> Hi Chris,
>>
> [snip]
>>> I had a chance to review the patch. The fix hinges on this function call:
>>>PKG_CONFIG = $$pkgConfigExecutable()
>>>
>>> Could you let me know where this function call exists, i.e. what package
>>> it's in so I can look at it? I haven't been able to find it, and to try
>>> to get a patch upstream I need to understand and be able to explain what
>>> this is for and what it does.
>>
>> Unfortunately, I cannot precisely answer that question. I'll have to
>> defer to Lisandro or Dmitry (both Cced here). In any case, the reason is
>> that your dependencies (aka .pc files) may be present for multiple
>> architectures and for cross building that matters. So you need to
>> somehow specify to pkg-config, which architecture you are interested in.
>> On Debian systems you do that by invoking a different pkg-config.
>> Typically, that's ${DEB_HOST_GNU_TYPE}-pkg-config. So I can tell, what
>> this call does (but not where it comes from): It returns the pkg-config
>> that the user (in this case dh_auto_configure) supplied to the build.
>>
>> A quick codesearch[1] reveals that it is defined somewhere in
>> qtbase-opensource-src, so it should come with any qmake installation
>> based on qt5.
>
> qmake as a build system has support for using pkgconfig. I have not used this
> myself (I strongly prefer CMake), but glazing at the code it's just the way
> qmake passes the path to pkgconfig.
Looking at the code (below), that sounds right.
This is what I was looking for:
root@code-devel:/# fgrep -r pkgConfigExecutable /usr/*
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf:defineReplace(pkgConfigExecutable)
{
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf:pkg_config =
$$pkgConfigExecutable()
root@code-devel:/# dpkg -S
/usr/lib/x85_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf
qt5-qmake:amd64: /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf
So it's part of the qt5-qmake package, thus part of Qt5 itself. That's most of
what I needed to know.
The code section in qt_functions.prf:
[...]
defineReplace(pkgConfigExecutable) {
isEmpty(PKG_CONFIG) {
!isEmpty(QMAKE_PKG_CONFIG): \
PKG_CONFIG = $$QMAKE_PKG_CONFIG
else: \
PKG_CONFIG = pkg-config
sysroot.name = PKG_CONFIG_SYSROOT_DIR
sysroot.value = $$PKG_CONFIG_SYSROOT_DIR
libdir.name = PKG_CONFIG_LIBDIR
libdir.value = $$PKG_CONFIG_LIBDIR
QT_TOOL_NAME = pkg-config
qtAddToolEnv(PKG_CONFIG, sysroot libdir, SYS)
}
equals(QMAKE_HOST.os, Windows): \
PKG_CONFIG += 2> NUL
else: \
PKG_CONFIG += 2> /dev/null
return($$PKG_CONFIG)
}
[...]
I'm satisfied. I'll open an issue with Mumble upstream to see if I can get the
patch incorporated for Mumble 1.3. The build for mumble
1.3.0~git20190114.9fcc588+dfsg-1 hasn't completed for 3 architectures, and I'd
like to wait the 5 days for the package to transition to Testing/Buster -- I
plan to upload a package with the patch after that.
Thanks very much for this work.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: OpenPGP digital signature
Bug#919453: mumble FTCBFS: builds for the wrong architecture
Helmut Grohne: > Source: mumble > Version: 1.3.0~git20190114.9fcc588+dfsg-1 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > mumble fails to cross build from source, because it calls the build > architecture qmake. It actually calls qmake twice: Once via > dh_auto_configure and once directly from debian/rules. The call via > dh_auto_configure uses the right qmake, but the wrong flags. Merging > those calls into one fixes this part. Then mumble hard codes the build > architecture pkg-config in a lot of places. Making those calls > substitutable should be upstreamable and makes mumble cross buildable. > Please consider applying the attached patch. > > Helmut I was not aware that dh_auto_configure is calling qmake such that there were duplicate calls; I'd like to fix that. I'd also like to have Mumble be cross buildable. I had a chance to review the patch. The fix hinges on this function call: PKG_CONFIG = $$pkgConfigExecutable() Could you let me know where this function call exists, i.e. what package it's in so I can look at it? I haven't been able to find it, and to try to get a patch upstream I need to understand and be able to explain what this is for and what it does. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#600276: mumble: Need to switch speech synthesis language according to translations
Mumble 1.3.0~git20190114.9fcc588+dfsg-1 was uploaded to Debian today which should contain a fix to this bug. I'm going to close the bug now -- if it doesn't work as expected, please re-open the bug. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#919249: security issue: instability and crash due to crafted message flooding
Package: mumble Version: 1.2.19-3 Severity: important Tags: security fixed-upstream fixed-in-experimental It is currently possible to cause mumble-server to freeze and/or crash by sending specifically it crafted commands, leading to a denial of service. The server usually automatically recovers, however it has been reported that in some instances it can take up to an hour after the attack has ended. The attack can be done remotely and does not need special permissions. All versions of mumble 1.2.x and 1.3.0 snapshots prior to 2018-08-31 are affected. signature.asc Description: OpenPGP digital signature
Bug#874683: fixed in mumble 1.3.0~2868~g44b9004+dfsg-1
Roland Hieber: > reopen 874683 > notfixed 874683 1.2.19-3 > found 874683 1.2.19-3 > thanks Ah. Very good that works and fixes the graph of fixed and notfixed versions. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#874683: fixed in mumble 1.3.0~2868~g44b9004+dfsg-1
notfixed 874683 1.2.19-3 thanks Roland Hieber: > > Hi, > > is it correct that this bug is fixed in mumble_1.2.19-3, or was there a > mixup in the changelog of that version, as it decends from the 1.3.0 > changelog? > > Cheers, > Roland Sorry for the confusion. To try to help clarify: Mumble 1.3.0~2868~g44b9004+dfsg-1 in Debian Experimental is built with Qt 5. Mumble 1.2.19-3 in Debian Unstable and Testing can only be built with Qt 4. (All Mumble 1.2.x versions can only be built with Qt 4.) It looks like this bug is incorrectly marked as fixed for 1.2.19-3; I'll see if I can change that to 'notfixed' via the email interface for the BTS. Thanks for letting me know. -- Chris -- Chris Knadle chris.kna...@coredump.us > On Thu, 20 Sep 2018 10:20:49 + Christopher Knadle > wrote: >> Source: mumble >> Source-Version: 1.3.0~2868~g44b9004+dfsg-1 >> >> We believe that the bug you reported is fixed in the latest version of >> mumble, which is due to be installed in the Debian FTP archive. >> >> A summary of the changes between this version and the previous one is >> attached. >> >> Thank you for reporting the bug, which will now be closed. If you >> have further comments please address them to 874...@bugs.debian.org, >> and the maintainer will reopen the bug report if appropriate. >> >> Debian distribution maintenance software >> pp. >> Christopher Knadle (supplier of updated mumble >> package) >> >> (This message was generated automatically at their request; if you >> believe that there is a problem with it please contact the archive >> administrators by mailing ftpmas...@ftp-master.debian.org) >> >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Format: 1.8 >> Date: Thu, 20 Sep 2018 05:50:27 + >> Source: mumble >> Binary: mumble mumble-server >> Architecture: source >> Version: 1.3.0~2868~g44b9004+dfsg-1 >> Distribution: experimental >> Urgency: medium >> Maintainer: Christopher Knadle >> Changed-By: Christopher Knadle >> Description: >> mumble - Low latency encrypted VoIP client >> mumble-server - Low latency encrypted VoIP server >> Closes: 874683 >> Changes: >> mumble (1.3.0~2868~g44b9004+dfsg-1) experimental; urgency=medium >> . >>* New upstream snapshot from 2018-08-30 >> Fixes wishlist bug "mumble: please package a QT5 version of mumble" >> (Closes: #874683) >> Thanks to Daniel Kahn Gillmor for reporting >> the bug and informing me about the pending Qt4 removal (also reported >> in #875058); sorry it took me so long to package this. >>* debian/control: >> - Update Build-Depends to use Qt5 dependencies >> - Remove Suggests: dbus, mumble-django packages for mumble-server >> - Add Suggests: libqt5sql5-sqlite for mumble-server >> - Update Standards-Version to 4.2.1 >>Changes: >> - Update debian/rules to enable DH_VERBOSE=1 to increase build >>verbosity as requested in Debian Policy § 4.9 >>* debian/copyright: >> - Add Files-Excluded section to document files removed from the upstream >>tarball for DFSG compliance. [The removals are for draft IETF >> documents >>for CELT, Opus, Speex codecs that have a restrictive license.] >
Bug#915273: mumble: sound glitches when starting mumble
Axel Regnat: > Not sure what you mean with "AppArmor audit daemon log" but I couldn't find > anything from apparmor in kern.log or sys.log when starting mumble. I also > updated to 1.3 like you suggested and the problem seems to be fixed. Thanks > for > your help. > > Axel You're very welcome. :) I'm glad Mumble 1.3 fixes this. Re: AppArmor audit daemon: When using AppArmor it's beneficial to get reports of when certain actions are blocked, such as using apparmor-notify, and I believe another way is to use auditd to log these events. As long as you have some way of knowing when AppArmor blocks an action, that's all I was looking for, so that you could debug if that was the reason for the issue. And thanks for marking and closing the bug. :) -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#915273: mumble: sound glitches when starting mumble
Axel R.: > Package: mumble > Version: 1.2.19-2+b1 > Severity: normal > > Dear Maintainer, > > whenever I start mumble for the first time after a boot I've sound glitches > which I can only resolve by restarting pulseaudio. I would appreciate any > help to find out what causes this or what I can do to fix this. I've no > problems with other software. Teamspeak for example doesn't cause this bug. > > Axel The #mumble IRC channel on irc.freenode.net would be a good place to ask about this -- there are users there familiar with PulseAudio issues that regularly help with them. I think I may have heard about this specific problem before in the IRC channel, though not positive. I have not seen this issue myself on Stretch or Sid. I also have not had issues with PulseAudio in general, and unfortunately I have not delved into PA enough to be able to troubleshoot audio issues with it at present. I see you have AppArmor enabled (which is cool to see); check the AppArmor audit daemon log to see if there are any blocked actions that might be related to Mumble and/or PulseAudio. Another option worth trying is the Mumble 1.3 package in Debian Experimental, since you've already got that repo enabled, to see if Mumble 1.3 fixes this bug. I'm also mentioning this because Mumble 1.2 is dependent on Qt 4, and Qt 4 is due to be removed before the release of Buster -- so Mumble 1.2 is close to being removed. Mumble 1.3 doesn't have a stable release so I can't upload it to Sid, and upstream development of Mumble 1.3 has come to a near standstill. I'll maintain a snapshot in Experimental until there's a stable release to upload. If the Mumble 1.3 snapshot in Experimental fixes this, let me know. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#912779: [src:mumble] FTBFS with boost1.67
Giovanni Mascellani: > Dear Maintainer, > > your package fails to build with boost1.67. You can find a build log > attached. If you want to attempt the build yourself, an updated version > of boost-defaults which brings in boost1.67 dependencies can be found > adding this line to your sources.list file: > > deb https://people.debian.org/~gio/reprepro unstable main > > This bug has severity whishlist for the moment, but it will raised to RC > as soon as version 1.67 of Boost is promoted to default. > > I have to say I do not completely understand why the package built fine > with previous version of boost (1.62): it seems to me that the problem > the attached patch fixes (the use of std::abs as a templated name, see > the path description for more details) should not depend at all from > boost. However, at least on my computer, the package builds with > boost1.62, fails with boost1.67 and build with boost1.67 and this patch. > > Please consider applying the attached patch as soon as boost1.67 is made > default in order to avoid FTBFS. > > Thanks and all the best, Giovanni. Hello, Giovanni. Thank you very much for your detailed bug report that includes build logs and a patch. :) I reviewed the build logs and the patch. I took some time to understand what static_cast does in the patch, because I think I haven't seen that before. https://stackoverflow.com/questions/28002/regular-cast-vs-static-cast-vs- dynamic-cast https://en.cppreference.com/w/cpp/language/static_cast At least initially the patch looks right to me. I'll include this patch in the next upload. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#887714: g15composer: Detect freetype2 using pkg-config
tags 887714 + pending
thanks
Hugh McMaster:
> A rebuild of your package with freetype 2.9.1 installed confirmed that your
> package will FTBFS once the new version of freetype enters unstable. In
> almost all cases, this build failure was caused by the configure script not
> detecting the freetype libraries, as freetype-config is not shipped in
> 2.9.1.
>
> Given the build failure and upcoming upload of freetype 2.9.1, I am raising
> the severity of this bug to Serious.
>
> Please use pkg-config to detect freetype.
I've prepared an NMU to fix this bug (as 3.2-2.1) and I'm attaching the
NMU diff to this message. I've uploaded it to DELAYED/5. Please let me know if
you'd like the upload delayed longer.
Thanks
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diff -u g15composer-3.2/debian/control g15composer-3.2/debian/control
--- g15composer-3.2/debian/control
+++ g15composer-3.2/debian/control
@@ -3,7 +3,7 @@
Priority: extra
Maintainer: Giacomo Catenazzi
Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libfreetype6-dev,
- libg15-dev, libg15render-dev (>= 1.2-3), libg15daemon-client-dev
+ libg15-dev, libg15render-dev (>= 1.2-3), libg15daemon-client-dev, pkg-config
Standards-Version: 3.8.2
Homepage: http://www.g15tools.com/
diff -u g15composer-3.2/debian/changelog g15composer-3.2/debian/changelog
--- g15composer-3.2/debian/changelog
+++ g15composer-3.2/debian/changelog
@@ -1,3 +1,12 @@
+g15composer (3.2-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/control:
+- Add pkg-config to Build-Depends
+ * patched configure and configure.in to use pkg-config (Closes: #887714)
+
+ -- Christopher Knadle Wed, 24 Oct 2018 04:20:30 +
+
g15composer (3.2-2) unstable; urgency=low
* Update policy, add ${misc:Depends}, add homepage
only in patch2:
unchanged:
--- g15composer-3.2.orig/configure
+++ g15composer-3.2/configure
@@ -3637,8 +3637,8 @@
#define TTF_SUPPORT 1
_ACEOF
- CFLAGS="$CFLAGS `freetype-config --cflags`"
- CXXFLAGS="$CXXFLAGS `freetype-config --cflags`"
+ CFLAGS="$CFLAGS `pkg-config --cflags freetype2`"
+ CXXFLAGS="$CXXFLAGS `pkg-config --cflags freetype2`"
FTLIB="-lfreetype"
ttf_support="yes"
else
only in patch2:
unchanged:
--- g15composer-3.2.orig/configure.in
+++ g15composer-3.2/configure.in
@@ -19,8 +19,8 @@
if [[[ "$enableval" = "yes" ]]]; then
AC_CHECK_LIB([g15render], [g15r_ttfLoad],
AC_DEFINE(TTF_SUPPORT, [1], [Define to 1 to enable FreeType2 support])
- CFLAGS="$CFLAGS `freetype-config --cflags`"
- CXXFLAGS="$CXXFLAGS `freetype-config --cflags`"
+ CFLAGS="$CFLAGS `pkg-config --cflags freetype2`"
+ CXXFLAGS="$CXXFLAGS `pkg-config --cflags freetype2`"
FTLIB="-lfreetype"
ttf_support="yes",
AC_MSG_ERROR(["libg15render does not support ttf functions. please reconfigure with --enable-ttf"])
signature.asc
Description: OpenPGP digital signature
Bug#892334: libg15render: Please use 'pkg-config' to find FreeType 2
tags 892334 + pending thanks Hugh McMaster : > A rebuild of your package with freetype 2.9.1 installed confirmed that your > package will FTBFS once the new version of freetype enters unstable. In > almost all cases, this build failure was caused by the configure script not > detecting the freetype libraries, as freetype-config is not shipped in > 2.9.1. > > Given the build failure and upcoming upload of freetype 2.9.1, I am raising > the severity of this bug to Serious. > > Please use pkg-config to detect freetype. I've prepared an NMU to fix this bug (as 1.3.0~svn316-2.4) and I'm attaching the NMU diff to this message. I've uploaded it to DELAYED/5. Please let me know if you'd like the upload delayed longer. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us diff -Nru libg15render-1.3.0~svn316/debian/changelog libg15render-1.3.0~svn316/debian/changelog --- libg15render-1.3.0~svn316/debian/changelog 2018-10-22 00:55:02.0 + +++ libg15render-1.3.0~svn316/debian/changelog 2018-10-22 00:10:18.0 + @@ -1,3 +1,15 @@ +libg15render (1.3.0~svn316-2.4) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: +- Add pkg-config and quilt to Build-Depends + * debian/patches: +- Add 01-pkg-config-configure-in.patch to use pkg-config (Closes: #892334) + * debian/source/format: +- Use 3.0 (quilt) format + + -- Christopher Knadle Mon, 22 Oct 2018 00:10:18 + + libg15render (1.3.0~svn316-2.3) unstable; urgency=medium * Non-maintainer upload. diff -Nru libg15render-1.3.0~svn316/debian/control libg15render-1.3.0~svn316/debian/control --- libg15render-1.3.0~svn316/debian/control 2018-10-22 00:55:02.0 + +++ libg15render-1.3.0~svn316/debian/control 2018-10-22 00:10:18.0 + @@ -3,7 +3,7 @@ Priority: optional Maintainer: Giacomo Catenazzi Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libtool, automake1.11, - libg15-dev, libusb-dev, libfreetype6-dev + libg15-dev, libusb-dev, libfreetype6-dev, pkg-config, quilt Standards-Version: 3.8.2 Homepage: http://www.g15tools.com diff -Nru libg15render-1.3.0~svn316/debian/patches/01-pkg-config-configure-in.patch libg15render-1.3.0~svn316/debian/patches/01-pkg-config-configure-in.patch --- libg15render-1.3.0~svn316/debian/patches/01-pkg-config-configure-in.patch 1970-01-01 00:00:00.0 + +++ libg15render-1.3.0~svn316/debian/patches/01-pkg-config-configure-in.patch 2018-10-22 00:10:18.0 + @@ -0,0 +1,11 @@ +--- a/configure.in b/configure.in +@@ -17,7 +17,7 @@ + AC_ARG_ENABLE(ttf, [ --enable-ttf enable FreeType2 support], + if [[[ "$enableval" = "yes" ]]]; then + AC_DEFINE(TTF_SUPPORT, [1], [Define to 1 to enable FreeType2 support]) +- CFLAGS="$CFLAGS `freetype-config --cflags`" ++ CFLAGS="$CFLAGS `pkg-config --cflags freetype2`" + FTLIB="-lfreetype" + ttf_support="yes" + else diff -Nru libg15render-1.3.0~svn316/debian/patches/series libg15render-1.3.0~svn316/debian/patches/series --- libg15render-1.3.0~svn316/debian/patches/series 1970-01-01 00:00:00.0 + +++ libg15render-1.3.0~svn316/debian/patches/series 2018-10-22 00:10:18.0 + @@ -0,0 +1 @@ +01-pkg-config-configure-in.patch diff -Nru libg15render-1.3.0~svn316/debian/source/format libg15render-1.3.0~svn316/debian/source/format --- libg15render-1.3.0~svn316/debian/source/format 1970-01-01 00:00:00.0 + +++ libg15render-1.3.0~svn316/debian/source/format 2018-10-22 00:10:18.0 + @@ -0,0 +1 @@ +3.0 (quilt) signature.asc Description: OpenPGP digital signature
