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#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#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#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#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#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#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#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#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#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#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#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#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#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
Bug#910665: FTBFS on Debian sid
I'm looking at the build logs of the build failure, and I see that zeroc-ice 3.7.1-2 from June built correctly, but the 3.7.1-2+b1 binNMU fails to build. https://buildd.debian.org/status/logs.php?pkg=zeroc-ice=amd64 I'm trying to figure out: which source dependency was uploaded such that a binNMU was triggered? The build error happens when building within a python-3 directory, so I'm guessing this issue is python3 related. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#893604: mumble: Add support to build with upcoming Ice 3.7.0 release
Jose Gutierrez de la Concha: [...] > With Ice 3.7.0 IceUtil library was removed, I fixed the .pro file to not > longer include it in the link libraries, you might want to check Ice > Version < 3.7 and add it, but I'm not sure what is the best way to do this > check with qmake. Probably it is better to report this upstream and keep > the patch for debian until upstream fixes it. I've been trying to figure out how to conditionally change the CONFIG options based on checking whether the Ice version is >= 3.7 basically using this for the compare (dpkg returns status 0 on success, 1 for false or otherwise) dpkg --compare-versions $(slice2html -v) ge 3.7 ICE_VERSION_LESSTHAN_37 := $? Qt 5.6 and up has a QVersionNumber class, but Qt 4.8 doesn't have that: https://doc.qt.io/Qt-5/qversionnumber.html ... so this seems tricky to do with qmake in Qt 4.8 alone. At this point it's probably best to report this upstream, and for now have the Mumble backport in Debian carry an additional patch difference. :-/ (I try to avoid that if possible.) Another thing that's causing some delay in uploading a fix is that the VCS for Mumble needs to change from Alioth to Salsa and I'm still working on that transition. (I've uploaded ssh keys for Salsa but haven't gotten ssh to work.) -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#831184: mumble: FTBFS with GCC 6, seems Ice related
tags 831184 + patch pending
thanks
Attached are two patches (thanks to Mikkel Krautz for finding the
solution and for the c++11 patch) both which fix the build. Unless
there's an objection I'm going to use the patch to build with c++03
because that's what Mumble upstream tests Mumble with.
Thanks
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Description: Fix FTBFS bug with GCC 6
Mumble expcets -std=c++03 but doesn't explicitly set this in order to allow
the compiler to choose, and g++-6 defaults to -std=gnu++14. zeroc-ice ships
both c++03 and c++11 libs, and the c++03 libs are the default. The
combination leads to c++11 linking errors unless the -std is explicity set.
Additionally the location of the c++11 libs differs depending on whether
the architecture is 32-bit or 64-bit, so this needs to be specified as well.
Author: Mikkel Krautz <mik...@krautz.dk>
Bugs-Debian: https://bugs.debian.org/831184
Bugs-Mumble: https://github.com/mumble-voip/mumble/issues/2494
Last-Updated: 2016-08-11
--- a/compiler.pri
+++ b/compiler.pri
@@ -89,6 +89,14 @@
QMAKE_LFLAGS *= $(shell dpkg-buildflags --get LDFLAGS)
QMAKE_CFLAGS *= -Wfatal-errors -fvisibility=hidden
QMAKE_CXXFLAGS *= -Wfatal-errors -fvisibility=hidden
+ QMAKE_CXXFLAGS *= -std=c++11
+
+ # ZeroC Ice's C++11 libs are in /usr/lib/$triple/c++11 on Debian.
+ MULTIARCH_TRIPLE = $$system($${QMAKE_CXX} -print-multiarch)
+ !isEmpty(MULTIARCH_TRIPLE) {
+ QMAKE_LIBDIR *= /usr/lib/$${MULTIARCH_TRIPLE}/c++11
+ }
+
!CONFIG(quiet-build-log) {
QMAKE_CFLAGS *= -Wshadow -Wconversion -Wsign-compare
QMAKE_CXXFLAGS *= -Wshadow -Woverloaded-virtual -Wold-style-cast -Wconversion -Wsign-compare
Description: Fix FTBFS bug with GCC 6
Mumble expcets -std=c++03 but doesn't explicitly set this in order to allow
the compiler to choose, and g++-6 defaults to -std=gnu++14. zeroc-ice ships
both c++03 and c++11 libs, and the c++03 libs are the default. The
combination leads to c++11 linking errors unless the -std is explicity set.
Author: Mikkel Krautz <mik...@krautz.dk>
Bugs-Debian: https://bugs.debian.org/831184
Bugs-Mumble: https://github.com/mumble-voip/mumble/issues/2494
Last-Updated: 2016-08-11
--- a/compiler.pri
+++ b/compiler.pri
@@ -89,6 +89,8 @@
QMAKE_LFLAGS *= $(shell dpkg-buildflags --get LDFLAGS)
QMAKE_CFLAGS *= -Wfatal-errors -fvisibility=hidden
QMAKE_CXXFLAGS *= -Wfatal-errors -fvisibility=hidden
+ QMAKE_CXXFLAGS *= -std=c++03
+
!CONFIG(quiet-build-log) {
QMAKE_CFLAGS *= -Wshadow -Wconversion -Wsign-compare
QMAKE_CXXFLAGS *= -Wshadow -Woverloaded-virtual -Wold-style-cast -Wconversion -Wsign-compare
signature.asc
Description: OpenPGP digital signature
Bug#832599: Fails to start after upgrade
gregor herrmann:
[...]
> But I also started looking at deb-systemd-helper (in
> init-system-helpers) and found an interesting example:
>
> https://sources.debian.net/src/isatapd/0.9.7-2/debian/postinst/?hl=12#L12
>
> Maybe this is the way to go?
> (And if yes: "disable" or "mask"?)
The code in the above link is what I expected to help: sourcing in the
/etc/default file, and having systemd enable or disable the service in
the postinst.
I just had a look at the way this is being done in the vsftpd package;
it Buidl-Depends on dh-systemd, and in the debian/rules file it has:
dh ${@} --parallel --with=systemd
which is the same as you have in iodine, except for the --parallel...
where it differes slightly is in debian/postinst where it has the
following snippet in the "configure" case:
if [ -f "systemd-tmpfiles" ]
then
systemd-tmpfiles --create --exclude-prefix=/dev
fi
;;
When the package installs, it appears dh_systemd_enable modifies the
vsftpd.postinst file (thus the file in /var/lib/dpkg info differs from
that of the source package after installation -- ugh) which removes the
above snippet and adds the following after the case statement:
---
# Automatically added by dh_systemd_enable
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask vsftpd.service >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled vsftpd.service; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable vsftpd.service >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need
to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state vsftpd.service >/dev/null || true
fi
# End automatically added section
# Automatically added by dh_installinit
if [ -x "/etc/init.d/vsftpd" ]; then
update-rc.d vsftpd defaults >/dev/null
invoke-rc.d vsftpd start || exit $?
fi
# End automatically added section
---
The 'purge' case of the vsftpd.postrm has this:
---
purge)
#
# purge systemd files
#
rm -f /etc/systemd/system/vsftpd.service
rm -f /etc/systemd/system/multi-user.target.wants/vsftpd.service
rm -f
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/vsftpd.service
rm -f
/var/lib/systemd/deb-systemd-helper-enabled/vsftpd.service.dsh-also
rm -f /var/lib/systemd/deb-systemd-helper-masked/vsftpd.service
if [ -d
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ ]; then
rmdir --ignore-fail-on-non-empty
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/
fi
if [ -d /var/lib/systemd/deb-systemd-helper-enabled ]; then
rmdir --ignore-fail-on-non-empty
/var/lib/systemd/deb-systemd-helper-enabled
fi
if [ -d /var/lib/systemd/deb-systemd-helper-masked ]; then
rmdir --ignore-fail-on-non-empty
/var/lib/systemd/deb-systemd-helper-masked
fi
;;
---
and after installation the file in /var/lib/dpkg/info/vsftpd.postrm has
the entirety of the above snippet removed, with the following added
after the case statement:
---
# Automatically added by dh_installinit
if [ "$1" = "purge" ] ; then
update-rc.d vsftpd remove >/dev/null
fi
# In case this system is running systemd, we make systemd reload the
unit files
# to pick up changes.
if [ -d /run/systemd/system ] ; then
systemctl --system daemon-reload >/dev/null || true
fi
# End automatically added section
# Automatically added by dh_systemd_enable
if [ "$1" = "remove" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper mask vsftpd.service >/dev/null
fi
fi
if [ "$1" = "purge" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper purge vsftpd.service >/dev/null
deb-systemd-helper unmask vsftpd.service >/dev/null
fi
fi
# End automatically added section
# Automatically added by dh_installdebconf
if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
db_purge
fi
# End automatically added secti
Bug#831184: mumble: FTBFS with GCC 6, seems Ice related
Greetings.
Unfortunately Mumble in Debian won't compile with GCC-6 right now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831184
After talking to Mikkel Krautz (mumble upstream) I tried adding the
following to the unix {} block in murmur.pro:
QMAKE_CXXFLAGS *= -std=c++11
but unfortunately this doesn't seem to help. I'm adding the maintainers
of zero-ice hoping that we can jointly track down how to fix this.
Thanks.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
partital build failure log (with the excepiton of the -std=c++11 switch
it looks the same as the log Lucas Nussbaum supplied in the bug):
---
[...]
g++ -c -include release/murmurd -m64 -pipe -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -Wfatal-errors
-fvisibility=hidden -g -std=c++11 -O2 -Wall -W -D_REENTRANT
-DNO_UPDATE_CHECK -DPLUGIN_PATH=/usr/lib/mumble
-DMUMBLE_VERSION=1.2.16-1 -DHAVE_LIMITS_H -DHAVE_ENDIAN_H
-DRESTRICT=__restrict__ -D_FORTIFY_SOURCE=2
-DMUMBLE_VERSION_STRING=1.2.16 -DMURMUR -DUSE_DBUS -DUSE_ICE
-DUSE_BONJOUR -D_REENTRANT -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_XML_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtXml
-I/usr/include/qt4/QtSql -I/usr/include/qt4 -I/usr/include/qt4/QtDBus
-I../../src -I. -I/usr/include/speech-dispatcher -I../bonjour -Irelease
-I/usr/include/avahi-compat-libdns_sd -o release/moc_BonjourServer.o
release/moc_BonjourServer.cpp
g++ -m64 -Wl,-z,relro -Wl,-z,relro -Wl,-z,now -Wl,-O1 -o
../../release/murmurd release/ACL.o release/Group.o release/Channel.o
release/Connection.o release/User.o release/Timer.o release/CryptState.o
release/OSInfo.o release/Net.o release/SSL.o release/Version.o
release/main.o release/Server.o release/ServerUser.o release/ServerDB.o
release/Register.o release/Cert.o release/Messages.o release/Meta.o
release/RPC.o release/UnixMurmur.o release/DBus.o release/MurmurIce.o
release/BonjourServiceRegister.o release/BonjourServer.o
release/Mumble.pb.o release/Murmur.o release/moc_ACL.o
release/moc_Channel.o release/moc_Connection.o release/moc_Server.o
release/moc_ServerUser.o release/moc_Meta.o release/moc_UnixMurmur.o
release/moc_DBus.o release/moc_MurmurIce.o
release/moc_BonjourServiceRegister.o release/moc_BonjourServer.o
-L../../release -L/usr/lib/x86_64-linux-gnu -lprotobuf -lcap -lIce
-lIceUtil -lQtDBus -lssl -lcrypto -ldns_sd -lavahi-common -lavahi-client
-lpthread -lQtSql -lQtXml -lQtNetwork -lQtCore
release/Murmur.o: In function
`IceInternal::Cpp11FnCallbackNC::~Cpp11FnCallbackNC()':
/usr/include/Ice/Proxy.h:95: undefined reference to `vtable for
IceInternal::Cpp11FnCallbackNC'
/usr/include/Ice/Proxy.h:95: undefined reference to `vtable for
IceInternal::Cpp11FnCallbackNC'
/usr/include/Ice/Proxy.h:95: undefined reference to `vtable for
IceInternal::Cpp11FnCallbackNC'
/usr/include/Ice/Proxy.h:95: undefined reference to `vtable for
IceInternal::Cpp11FnCallbackNC'
/usr/include/Ice/Proxy.h:95: undefined reference to `vtable for
IceInternal::Cpp11FnCallbackNC'
release/Murmur.o:/usr/include/Ice/Proxy.h:95: more undefined references
to `vtable for IceInternal::Cpp11FnCallbackNC' follow
release/Murmur.o: In function `Cpp11CB':
/<>/src/murmur/Murmur.cpp:7028: undefined reference to
`IceInternal::Cpp11FnCallbackNC::Cpp11FnCallbackNC(std::function const&, std::function const&)'
[...]
---
Bug#832599: Fails to start after upgrade
gregor herrmann:
> On Sat, 30 Jul 2016 18:40:21 +0000, Chris Knadle wrote:
>
> Hi Chris!
:)
>>>>> After the upgrade, chosing not to auto-start the daemon, I get this:
>
> So madduck has set START_IODINED to false in /etc/default/iodine
>
>>>>> ● iodined.service - A daemon for tunneling traffic over DNS queries
>>>>>Loaded: loaded (/lib/systemd/system/iodined.service; disabled; vendor
>>>>> preset: enabled)
>>>>>Active: activating (auto-restart) (Result: exit-code) since Wed
>>>>> 2016-07-27 13:17:34 CEST; 4ms ago
>>>>> Docs: man:iodined(8)
>>>>> Process: 2277 ExecStartPre=/bin/sh -xc test ${START_IODINED} = true
>>>>> (code=exited, status=1/FAILURE)
>
> and the new /lib/systemd/system/iodined.service exists with 1 because
> START_IODINED != true
>
>> Unfortunately I don't see what the failure is about.
>
> See above :)
Yep, got it. i.e. ... this behavior is unfortunately expected.
>> Something to note about this: systemd spitting out such a failure *does
>> not* mean that the service didn't start. One still needs to do a 'ps
>> -ef' and look for the service to make sure it's not running.
>
> Interesting ... but still, this failure means that dpkg aborts the
> upgrade, so we have a problem here.
O. :-( Yeah that's obviously an issue that needs a solution.
> (And if the service runs its unwanted.)
>>>>> Please use systemd masking instead of the silly shell test and
>>>>> /etc/default/* file variable to control whether the daemon should be
>>>>> started.
>>> Sounds good, I just haven't found yet how to do this from the
>>> packaging side.
>> Enabling/disabling a service via an /etc/default file is not meant to be
>> done with systemd:
>> https://wiki.ubuntu.com/SystemdForUpstartUsers#A.2Fetc.2Fdefault_files_which_enable.2Fdisable_jobs
>
> Right. And
>
> "There is no clean way to evaluate these in a systemd unit. You can
> check them in ExecStartPre=, but that would mean that the unit will
> be in "failed" state if the service gets disabled that way, and so,
> is not desirable."
>
> matches what we see here.
I see that now.
What I think might be helpful here is the dh-systemd package,
specifically the dh_systemd_enable command:
Package: dh-systemd
[...]
Description-en: debhelper add-on to handle systemd unit files
dh-systemd provides a debhelper sequence addon named 'systemd' and the
dh_systemd_enable/dh_systemd_start commands.
.
The dh_systemd_enable command adds the appropriate code to the
postinst, prerm and postrm maint scripts to properly enable/disable
systemd service files.
The dh_systemd_start command deals with start/stop/restart on upgrades
for systemd-only service files.
Because basically what I think you want to happen is:
- systemd (in general) ignores the enable/disable environment
variable in the /etc/default file (because 'disabled' causes
problems), but will use any other environment variables
(This is what I see being done in Debian packages that
support systemd.)
- The postinst script runs 'systemctl enable iodined.service'
upon installation, and I think this could be done conditionally
based on the contents of the enable/disable env variable in
the /etc/default file.
I've had a quick look at the Debian Policy Manual, and /etc/default
files are discussed near the end of section 9.3.2, but it doesn't
discuss this in relation to systemd.
I've been considering this same issue ever since bug #780300.
>> I'm running systemd (and have for several years) and am happy to help
>> with this if I can.
>
> Thanks!
Glad to help where I can.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: OpenPGP digital signature
Bug#832599: Fails to start after upgrade
gregor herrmann:
> Control: tag -1 + help
>
> On Wed, 27 Jul 2016 13:19:44 +0200, martin f krafft wrote:
>
>> > After the upgrade, chosing not to auto-start the daemon, I get this:
>> >
>> > Setting up iodine (0.7.0-5) ...
>> > Job for iodined.service failed because the control process exited with
>> > error code.
>> > See "systemctl status iodined.service" and "journalctl -xe" for details.
>> > invoke-rc.d: initscript iodined, action "start" failed.
>> > ● iodined.service - A daemon for tunneling traffic over DNS queries
>> >Loaded: loaded (/lib/systemd/system/iodined.service; disabled; vendor
>> > preset: enabled)
>> >Active: activating (auto-restart) (Result: exit-code) since Wed
>> > 2016-07-27 13:17:34 CEST; 4ms ago
>> > Docs: man:iodined(8)
>> > Process: 2277 ExecStartPre=/bin/sh -xc test ${START_IODINED} = true
>> > (code=exited, status=1/FAILURE)
> Thanks for the bug report, and sorry for this mess.
> I guess that's what I got from trying to support systemd users
> without knowing enough about it ...
Unfortunately I don't see what the failure is about.
Something to note about this: systemd spitting out such a failure *does
not* mean that the service didn't start. One still needs to do a 'ps
-ef' and look for the service to make sure it's not running.
>> > Please use systemd masking instead of the silly shell test and
>> > /etc/default/* file variable to control whether the daemon should be
>> > started.
> Sounds good, I just haven't found yet how to do this from the
> packaging side.
Enabling/disabling a service via an /etc/default file is not meant to be
done with systemd:
https://wiki.ubuntu.com/SystemdForUpstartUsers#A.2Fetc.2Fdefault_files_which_enable.2Fdisable_jobs
> (Bcc'ing some people who might be able to help. If we don't come up
> with something working soon, I guess I'll drop the systemd stuff
> again and wait until we have proper socket activation; cf. the
> discussion in #830074).
I'm running systemd (and have for several years) and am happy to help
with this if I can.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Bug#827020: mumble: build-depends on libzeroc-ice35-dev which is no longer built
Greetings. > Your package build-depends on libzeroc-ice35-dev but that package is > no longer built by src:zeroc-ice. You should probably build-depend > on libzeroc-ice-dev now. I've been in regular contact with zeroc-ice upstream and Ondřej Surý lately, so I knew about the pending zeroc-ice binary package naming changes. I'm trying to see if I can make a Mumble 1.2.16-1 upload ASAP to update the zeroc-ice dependencies. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#821639: src:zeroc-ice: PHP 7.0 Transition
Jose Gutierrez de la Concha: > Hi Ondřej, > > I have been looking over the patches included in ice3.5 package, I think > most of the patches are not longer required with 3.6, see comments below [...] > add-dpkg-buildflags > > is this really required? we build packages with dh and the flags are > being set without need to patch the 3.6 build system. This patch is for adding Hardening flags, and was required because hardening-wrapper didn't work with GCC 5 and zeroc-ice depended on it, causing a bug whereby zeroc-ice was removed from Testing. More info on Hardening here: https://wiki.debian.org/Hardening Using 'dh' in debian/rules does not automatically harden in many cases because it's common for Makefiles to hard-set build flags past what dh sets; for instance this line that the patch changes from zeroc-ice 3.5.1: CPPFLAGS = literally removes any CPPFLAGS that 'dh' would have set. The best way I know of to test the hardening flags is to use 'blhc' on the log of the build (in the 'blhc' package) -- the best result is no warning output. Try running blhc on your zeroc-ice 3.6 build logs. > hurd-fixes > > We haven't tested hurd at this point I looked through the list of archived bugs for zeroc-ice and couldn't find what this patch is related to. (Too bad this patch didn't have DEP3 headers.) Hurd isn't an official release architecture for Debian, so "it's good if it can be made to work where feasible". [...] > Let me know your thoughts on this One other thing I should mention for clarity is that Debian *Sid* is the target distribution -- because all uploads to go Sid. *If* no serious bugs get reported then the package automatically transitions to Testing (currently named "Stretch") in about 5 days (assuming "urgency=medium" is used in the changelog entry, which is the default). So right now Stretch generally follows Sid with a 5-day delay, but that will drastically change when the freeze comes in November. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#821532: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition
The PHP 5 -> 7 transition: there was one eregi() call and one ereg() call
which are functions deprecated in PHP 5.3.-0 removed from PHP 7.0.0. With
those fixed the mlmmj-php-web and mlmmj-php-web-admin packages work fine.
debdiff attached.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diffstat for mlmmj-1.2.18.1 mlmmj-1.2.18.1
README.source|1
changelog| 30
control | 13 +++
copyright|6 +--
docs |1
patches/05_fix_displayed_full_paths.diff |6 +--
patches/06_fix-php-web-for-php7.diff | 35 +++
patches/07_fix-crontab-suggestions.diff | 56 +++
patches/series |4 +-
rules| 44 ++--
10 files changed, 170 insertions(+), 26 deletions(-)
diff -Nru mlmmj-1.2.18.1/debian/changelog mlmmj-1.2.18.1/debian/changelog
--- mlmmj-1.2.18.1/debian/changelog 2014-05-31 10:44:56.0 -0400
+++ mlmmj-1.2.18.1/debian/changelog 2016-05-24 22:28:54.0 -0400
@@ -1,3 +1,33 @@
+mlmmj (1.2.18.1-2) unstable; urgency=medium
+
+ * debian/control
+- Add myself to Uploaders
+- Depend on PHP 7 rather than PHP 5 (Closes: #821532, #821533)
+- Update Standards-Version to 3.9.8 (no changes needed)
+- Update Vcs-Browser and Vcs-Git links with https version
+ * debian/copyright
+- Update from DEP5 to copyright 1.0 format
+- Update BSD keyword to BSD-4-clause
+ * debian/docs:
+- Remove debian/README.source (file removed)
+ * debian/patches:
+- Update 05_fix_displayed_full_paths.diff for line offset fuzz
+- Reorder series file to apply patches in numeric order
+- Add 06_fix-php-web-for-php7.diff to fix mlmmj web packages for PHP 7.0
+- Add 07_fix-crontab-suggestions.diff to fix the crontab instructions to
+ include the user (root) to run the crontab entry, and inform the user
+ that the Debian package already includes a crontab entry
+ (Closes: #804436)
+ * debian/rules:
+- Update to split up package building for arch and indep so that
+ binary-arch doesn't produce "arch: all" packages which is supposed
+ to happen only in the binary-indep target
+ * debian/README.source:
+- Remove file as it is no longer necessary; stated that the package is
+ using dpatch which isn't the case as of 1.2.17-4
+
+ -- Christopher Knadle <chris.kna...@coredump.us> Wed, 11 May 2016 22:46:20
-0400
+
mlmmj (1.2.18.1-1) unstable; urgency=medium
* New upstream release (Closes: #749959).
diff -Nru mlmmj-1.2.18.1/debian/control mlmmj-1.2.18.1/debian/control
--- mlmmj-1.2.18.1/debian/control 2014-05-31 10:44:56.0 -0400
+++ mlmmj-1.2.18.1/debian/control 2016-05-24 22:27:47.0 -0400
@@ -2,11 +2,12 @@
Section: mail
Priority: optional
Maintainer: MLMMJ packaging team <pkg-mlmmj-de...@lists.alioth.debian.org>
-Uploaders: Thomas Goirand <z...@debian.org>
+Uploaders: Thomas Goirand <z...@debian.org>,
+ Christopher Knadle <chris.kna...@coredump.us>
Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1.1~)
-Standards-Version: 3.9.5
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-mlmmj/mlmmj.git
-Vcs-Git: http://anonscm.debian.org/git/pkg-mlmmj/mlmmj.git
+Standards-Version: 3.9.8
+Vcs-Browser: https://anonscm.debian.org/gitweb/?p=pkg-mlmmj/mlmmj.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-mlmmj/mlmmj.git
Homepage: http://mlmmj.org/
Package: mlmmj
@@ -35,7 +36,7 @@
Package: mlmmj-php-web
Architecture: all
-Depends: ${misc:Depends}, mlmmj, php5
+Depends: ${misc:Depends}, mlmmj, php
Description: web interface for mlmmj, written in php
A web based tool for mlmmj written in php, so that your users can subscribe
or unsubscribe through some HTML forms, which sometimes, might be more
@@ -43,7 +44,7 @@
Package: mlmmj-php-web-admin
Architecture: all
-Depends: ${misc:Depends}, mlmmj, php5
+Depends: ${misc:Depends}, mlmmj, php
Description: administrative web interface for mlmmj, written in php
This web based administrative tool for mlmmj written in php will help you
to configure each mailing list individualy, through the web. You will be
diff -Nru mlmmj-1.2.18.1/debian/copyright mlmmj-1.2.18.1/debian/copyright
--- mlmmj-1.2.18.1/debian/copyright 2014-05-31 10:44:56.0 -0400
+++ mlmmj-1.2.18.1/debian/copyright 2016-05-11 23:05:13.0 -0400
@@ -1,4 +1,4 @@
-Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file=240
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: mlmmj
Upstream-Contact: MLMMJ <ml...@mlmmj.org>
Source: http://www.mlmmj.org
@@ -14,7 +14,7 @@
Files: src/find_email_adr.c
Copyright: (c) 1980, 1993, The Regents of the
Bug#821533: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition
Ondřej Surý: > php7.7 sounds odd, but it's result of this command: > > a2query -m | sed -n 's/^\(php[\.0-9]*\) (enabled.*)/\1/p' > > Hmm, I'll speak with apache2 maintainers how to solve this. It looks > like you need to install apache2 first and then install > libapache2-mod-php7.0. Yeah that was it. I really appreciate the help, I'm not sure I would have figured that out. Removing libapache2-mod-php7.0 required removing php as well as mlmmj-php-web, etc temporarily, reinstalling libapache2-mod-php7.0 after apache2 works fine. > Unfortunatelly you should not depend on apache2 package: > > https://lintian.debian.org/tags/apache2-module-depends-on-real-apache2-package.html Hmm. If that's the case then I'm guessing the way to fix this dependency issue would involve splitting off certain things from the apache2 package into yet another binary package. :-/ Ugh. Thanks much. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#821532: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition
Ondřej Surý: > The code is postinst is correct. This should switch to prefork when > a2query -M returns anything else then prefork or itk: > > mpm=$(a2query -M) > case "$(a2query -M)" in > prefork|itk) return 0;; > *) if apache2_switch_mpm prefork; then return 0; fi;; > esac > Could you check your apt.log for: > > ERROR: $PHP_MODULE module already enabled, not enabling PHP > @PHP_VERSION@ > > or > > ERROR: Could not switch to prefork MPM, not enabling PHP @PHP_VERSION@ Hmm. Well I don't have an apt.log, but I found this in /var/log/apt/term: Creating config file /etc/php/7.0/apache2/php.ini with new version Setting up libapache2-mod-php7.0 (7.0.6-10) ... Warning: Could not load Apache 2.4 maintainer script helper Something to note: /usr/share/apache2/apache2-maintscript-helper is part of the 'apache2' package, which libapache2-mod-php7.0 doesn't depend on. (It currently depends on apache2-api and apache2-bin.) After installing this I found Apache2 wasn't running and then loaded the apache2 package, then tried making links in /etc/apache2/mods-enabled to /etc/apache2/mods-available/php7.0.conf and php7.0.load, leading to the Apache2 error concerning the PHP module not being threadsafe. Later on in /var/log/apt/term when upgrading libapache2-mod-php7.0: Setting up libapache2-mod-php7.0 (7.0.6-12) ... ERROR: php7.7 module already enabled, not enabling PHP 7.0 ? php7.7? That sounds odd. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#821532: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition
I have a patch to switch mlmmj to use PHP 7.0 instead of PHP 5 (that change
is trivial -- literally php5 -> php), but I'm running into a snag testing
the resulting binary packages: trying to load Apache2 with PHP 7.0 fails to
start with the error message:
"Apache is running as threaded MPM, but your PHP module is not compiled
to be threadsafe. You need to recompile PHP."
and looking at the README.Debian.gz for libapache2-mod-php7.0, the document
only discusses PHP 5. :-/ I'm having a look at the php7.0 source
package... libapache2-mod-php.postinst.extra seems to test for mpm but I'm
suspecting that this needs tweaking for how Apache2 is currently packaged in
Sid. ('a2query -M' returns 'event' which is not a case that's being looked
for, and Apache2 isn't split into mpm/prefork packages anymore.)
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: OpenPGP digital signature
Bug#821639: src:zeroc-ice: PHP 7.0 Transition
Ondřej Surý:
> Hi Chris,
>
> thanks for taking care of this.
>
> You can either try to backport PHP portion of 3.7.0-alpha0 to 3.6.2[*],
> or check with upstream if they can finish 3.7.0 before stretch freeze
> and if they can make it package 3.7.0-alpha0 right away.
>
> * - or ask upstream to include this update in 3.6.X
The reason I'm involved here is that mumble depends on zeroc-ice and is
going to removed with it if this bug isn't handled.
I looked at a 'diff -U 1' (1 line of context) of the PHP code between 3.5.1
and 3.7.0-alpha0 and it's ~10k lines; this is not something that would be
reasonable as a patch in an NMU. I don't think uploading a new version of
the software as an NMU is in this case either -- someone would have to be
familiar with using the software before they'd be comfortable sponsoring an
NMU upload and this is a package with niche use.
Instead the best plan I know of at the moment is removing any PHP
dependencies from the package for now -- meaning commenting out php5-dev +
php-zeroc-ice dependencies and the entire php-zeroc-ice section in
debian/control and not shipping the php-zeroc-ice binary package for now.
There are no packages that depend on php-zeroc-ice in Debian, so this
shouldn't cause any known breakage. It's not normally what I'd do but I
don't see a better option.
A debdiff of this is attached.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diff -Nru zeroc-ice-3.5.1/debian/changelog zeroc-ice-3.5.1/debian/changelog
--- zeroc-ice-3.5.1/debian/changelog2016-03-04 23:17:37.0 -0500
+++ zeroc-ice-3.5.1/debian/changelog2016-05-09 07:28:11.0 -0400
@@ -1,3 +1,26 @@
+zeroc-ice (3.5.1-6.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+- Temporarily remove PHP support and the php-zeroc-ice package, as
+ PHP 5 is being removed from Debian and the current zeroc-ice package
+ as well as the available upstream zeroc-ice release tarballs are
+ not compatible with PHP 7. Upstream git tag v3.7.0-alpha0 seems
+ to be the first version that supports PHP 7.
+ (Closes: #821723, #821639)
+
+ [ Christopher Knadle ]
+ * debian/changelog summary
+ * debian/NEWS:
+- Add entry explaining the necessity of removing PHP support
+
+ [ Gregor Herrmann ]
+ * debian/control:
+- Comment out php-dev dependency and php-zeroc-ice package
+ * debian/rules:
+- Comment out PHP references to keep PHP code from being built
+
+ -- Christopher Knadle <chris.kna...@coredump.us> Sun, 08 May 2016 04:53:21
-0400
+
zeroc-ice (3.5.1-6.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru zeroc-ice-3.5.1/debian/control zeroc-ice-3.5.1/debian/control
--- zeroc-ice-3.5.1/debian/control 2016-03-04 21:59:26.0 -0500
+++ zeroc-ice-3.5.1/debian/control 2016-05-08 21:50:18.0 -0400
@@ -13,7 +13,7 @@
zlib1g-dev | libz-dev,
python-all-dev (>= 2.3.5-11),
python3-all-dev,
- php5-dev (>= 5.4.0~rc6),
+# php5-dev (>= 5.4.0~rc6),
ruby-dev,
ruby,
libqt4-dev,
@@ -44,7 +44,7 @@
libzeroc-ice3.5-cil (>= ${binary:Version}),
python-zeroc-ice (>= ${binary:Version}),
python3-zeroc-ice (>= ${binary:Version}),
-php-zeroc-ice (>= ${binary:Version}),
+# php-zeroc-ice (>= ${binary:Version}),
libzeroc-ice3.5-java (>= ${binary:Version}),
${misc:Depends}
Recommends: libzeroc-ice35-dbg (>= ${binary:Version})
@@ -492,7 +492,7 @@
ice35-translators (= ${binary:Version}),
python-zeroc-ice (= ${binary:Version}),
python3-zeroc-ice (= ${binary:Version}),
-php-zeroc-ice (= ${binary:Version}),
+# php-zeroc-ice (= ${binary:Version}),
ruby-zeroc-ice (= ${binary:Version}),
icebox (= ${binary:Version}),
${misc:Depends}
@@ -554,26 +554,26 @@
information in the ZeroC home page (http://www.zeroc.com/ice.html)
and in the non-free package zeroc-ice-manual.
-Package: php-zeroc-ice
-Architecture: any
-Section: php
-Depends: php5-cli (>= 5.4.0~rc6-1) | php5 (>= 5.4.0~rc6-1),
-${shlibs:Depends}, ${misc:Depends}, ${php:Depends}
-Recommends: ice35-slice | ice-slice
-Description: Ice for PHP extension
- Ice, the Internet Communications Engine, is a middleware for the
- practical programmer developed by ZeroC Inc. A high-performance
- Internet communications platform, Ice includes a wealth of layered
- services and plug-ins.
- .
- Ice is built on concepts which will be familiar to CORBA programmers,
- and supports a wide variety of programming languages and runtime
- platforms.
- .
- This package contains the PHP extension module required to
- run/develop applications with Ice for PHP. You will find further
- information in the ZeroC home page (http://www.zeroc.com/ice.html)
- and in the non-free package zeroc-ic
Bug#821639: src:zeroc-ice: PHP 7.0 Transition
Update: none of the zeroc-ice release tarballs (including the current 3.6.2 tarball) seem to support PHP 7 as best I can tell. The v3.7.0-alpha0 tag in the upstream git repository does. https://github.com/zeroc-ice/ice/tree/v3.7.0-alpha0 In the v3.7.0-alpha0 tag, php/src has separate "php5" and "php7" directories and code to choose which of these to use during the compile based on what's available on the system it's built with. None of the 3.6 series seems to have this. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#804436: mlmmj: installs incorrectly formatted job to /etc/crontab when creating a list
severity 804436 important retitle 804436 mlmmj: tells user to add malformed entry to /etc/crontab thanks > I recently moved all of my email setup to a new machine. I installed mlmmj, > and when I created a list, it added the following /line to /etc/crontab: > > 0 */2 * * * "/usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/tvcadmin/" > > This led to another job failing to run - its crontab entry is: > > 1 0 * * * root/usr/local/bin/simplebackup > > The mlmmj-maintd job ran, but the simplebackup job was never started. As for > the other jobs listed, I am unsure whether they ran or not. > > When I amended the mlmmj-maintd job thus, the problem was resolved: > > 0 */2 * * * root/usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/tvcadmin/ > > The problem appears to be that mlmmj creates the crontab entry without > specifying the user name. It should either specify the user name or put the > entry in the user's crontab. I just found this bug the other day when I installed mlmmj on Sid to do some testing and found the bug report by way of how-can-i-help... and I think I've figured out what's going on. mlmmj does not install anything to /etc/crontab -- instead it installs a cronjob at /etc/cron.d/mlmmj that contains this (which works fine): 0 */2 * * * root /usr/bin/test -x /usr/bin/mlmmj-maintd && /usr/bin/mlmmj-maintd -F -d /var/spool/mlmmj This runs mlmmj-maintd every half hour for all mlmmj mailing lists that reside under /var/spool/mlmmj -- meaning that adding separate mlmmj-maintd entries to /etc/crontab is not necessary. However after running '/usr/bin/mlmmj-make-ml -L testlist2 -s /var/spool/mlmmj -a -c mlmmj' to create a mailing list it outputs the following text: If you're not starting mlmmj-maintd in daemon mode, don't forget to add this to your crontab: 0 */2 * * * "/usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/testlist2/" and this is the bug: it tells the admin running the mailing list to modify /etc/crontab when it's not necessary to do so, and in a way that will break things. It's not obvious that the cron job added in /etc/cron.d/mlmmj exists and runs mlmmj-maintd on all mailing lists as this isn't mentioned in the README.Debian.gz. Furthermore because it's done as a cron job this would not be considered "daemon mode" and thus even if the user found this out they still may be misled into thinking that adding the malformed entry into /etc/crontab is needed. It seems like this package needs a patch to either modify the text output concerning the crontab entry or remove it, and I'm not sure which is better. I'm considering making a patch an uploading it via a sponsored NMU. Because of the RC bug severity and lack of response, mlmmj has been missing from Testing for the last 3-1/2 months. This seems to be an indication that the maintainer is too busy for the package, so I'm considering filing an ITA to adopt the package. Thomas: this okay with you? -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#815775: #815775: zeroc-ice: FTBFS against ruby2.3
zeroc-ice seems to build fine without listing libmono2.0-cil and mono-gmcs in the Build-Depends. NMU prepared; debdiff attached. P.S. the maintainers for zeroc-ice in Debian have not been heard from in some time. (2 years) :-( -- Chris -- Chris Knadle chris.kna...@coredump.us diff -Nru zeroc-ice-3.5.1/debian/changelog zeroc-ice-3.5.1/debian/changelog --- zeroc-ice-3.5.1/debian/changelog2015-11-21 02:41:17.0 -0500 +++ zeroc-ice-3.5.1/debian/changelog2016-03-04 23:17:37.0 -0500 @@ -1,3 +1,16 @@ +zeroc-ice (3.5.1-6.4) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: +- Remove dependencies to fix FTBFS bug: + libmono2.0-cil, + mono-gmcs + (Closes: #815775) + [Note: the Ubuntu source packages zeroc-ice upstream ships have + far fewer Build-Depends.] + + -- Christopher Knadle <chris.kna...@coredump.us> Fri, 04 Mar 2016 21:54:19 -0500 + zeroc-ice (3.5.1-6.3) unstable; urgency=medium * Non-maintainer upload. diff -Nru zeroc-ice-3.5.1/debian/control zeroc-ice-3.5.1/debian/control --- zeroc-ice-3.5.1/debian/control 2015-11-19 23:39:06.0 -0500 +++ zeroc-ice-3.5.1/debian/control 2016-03-04 21:59:26.0 -0500 @@ -18,7 +18,6 @@ ruby, libqt4-dev, Build-Depends-Indep: mono-devel | c-sharp-2.0-compiler, -libmono2.0-cil, pkg-config, default-jdk | java-gcj-compat, libjgoodies-looks-java (>= 2.5.2), @@ -27,7 +26,6 @@ libdb5.3-java (>= 5.1.4~) | libdb-java (>= 5.1.4~), ant, ant-optional, -mono-gmcs, cli-common-dev (>= 0.8~) Standards-Version: 3.9.6 Homepage: http://www.zeroc.com/
Bug#798023: cssutils: FTBFS with Python 3.5
The attached patch implements the same fix used upstream and fixes this
FTBFS bug.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Description: Fix octal escape on Python 3.5
Origin: https://bitbucket.org/cthedot/cssutils/pull-requests/15/fix-octal-escape-on-python-35/diff
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798023
Bug-Upstream: https://bugs.python.org/issue22362
Last-Updated: 2016-01-21
--- a/setup.py
+++ b/setup.py
@@ -50,7 +50,7 @@
package_dir={'':'src'},
packages=find_packages('src'),
test_suite='cssutils.tests', #'nose.collector'
-tests_require='mock',
+tests_require=['mock', 'pbr < 1.7.0'],
entry_points={
'console_scripts': [
'csscapture_py2 = cssutils.scripts.csscapture:main',
--- a/setup3.py
+++ b/setup3.py
@@ -55,7 +55,7 @@
package_dir={'':'src3'},
packages=find_packages('src3'),
test_suite='cssutils.tests', #'nose.collector'
-tests_require='mock',
+tests_require=['mock', 'pbr < 1.7.0'],
entry_points={
'console_scripts': [
'csscapture = cssutils.scripts.csscapture:main',
--- a/src/cssutils/profiles.py
+++ b/src/cssutils/profiles.py
@@ -102,7 +102,7 @@
'nmstart': r'[_a-z]|{nonascii}|{escape}',
'nonascii': r'[^\0-\177]',
'unicode': r'\\[0-9a-f]{1,6}(\r\n|[ \n\r\t\f])?',
-'escape': r'{unicode}|\\[ -~\200-\777]',
+'escape': r'{unicode}|\\[ -~\u0080-\u01ff]',
# 'escape': r'{unicode}|\\[ -~\200-\417]',
'int': r'[-]?\d+',
'nmchar': r'[\w-]|{nonascii}|{escape}',
signature.asc
Description: OpenPGP digital signature
Bug#798023: cssutils: FTBFS with Python 3.5
Revised patch to minimize the diff, update the Origin, and add the Author.
Thanks
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Description: Fix octal escape on Python 3.5
Origin: https://bitbucket.org/cthedot/cssutils/commits/866a29f7e03447199ba22fb114d42a7aab027db9/raw/
Author: Daniel <kingdr...@gmx.de>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798023
Bug-Upstream: https://bugs.python.org/issue22362
Last-Updated: 2016-01-21
--- a/src/cssutils/profiles.py
+++ b/src/cssutils/profiles.py
@@ -102,7 +102,7 @@
'nmstart': r'[_a-z]|{nonascii}|{escape}',
'nonascii': r'[^\0-\177]',
'unicode': r'\\[0-9a-f]{1,6}(\r\n|[ \n\r\t\f])?',
-'escape': r'{unicode}|\\[ -~\200-\777]',
+'escape': r'{unicode}|\\[ -~\u0080-\u01ff]',
# 'escape': r'{unicode}|\\[ -~\200-\417]',
'int': r'[-]?\d+',
'nmchar': r'[\w-]|{nonascii}|{escape}',
signature.asc
Description: OpenPGP digital signature
Bug#804487: rebuilding openssl_1.0.2d-1 exhibits the same issue
Control: severity -1 important I've been trying some regression tests [removing the new CONFARGS in debian/rules, removing disable_sslv3_test.patch] -- and eventually tried rebuilding openssl_1.0.2d-1 as a check and I see the same issue after building Mumble with it. In other words: re-compiling the version of openssl + mumble prior to the bug now exhibits the bug too. It looks now like the changes to the openssl_1.0.2d-3 package aren't the cause of the behavior change. The logs for openssl builds show some differences since openssl_1.0.2d-1 was last built in July -- new packages pulled in: dh-strip-nonteterminism libfile-stripnondeterminism-perl libtimedate-perl libarchive-zip-perl [These get pulled in when building openssl_1.0.2d-1 now too, where they didn't at the time it was built on the buildds.] And of course gcc/g++ 5.2.1 is used vs gcc 4.9.3 previously. I'd like to try building openssl_1.0.2d-1 with gcc-4.9 to see if the behavior change was due to gcc-5 -- if there's an easy way to specify that please let me know. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#497471: sarge images have syslinux binaries without source
For what it's worth, syslinux-2.04 source is available here: https://www.kernel.org/pub/linux/utils/boot/syslinux/2.xx/ This is a list files shown for version 2.04: syslinux-2.04.lsm 20-Oct-2011 19:13 3.0K syslinux-2.04.lsm.sign 20-Oct-2011 19:13 836 syslinux-2.04.tar.bz2 20-Oct-2011 19:08 309K syslinux-2.04.tar.gz20-Oct-2011 19:08 379K syslinux-2.04.tar.sign 20-Oct-2011 19:08 836 syslinux-2.04.tar.xz20-Oct-2011 19:08 257K syslinux-2.04.zip 20-Oct-2011 19:13 462K syslinux-2.04.zip.sign 20-Oct-2011 19:13 836 Hopefully there's a way of verifying that this is the correct source for what was shipped with the Sarge images. GPL license compliance requires that users be able to get the source for the binary upon request -- so I believe what's required to handle this bug is verification and documentation. I'd like to think that can be done with some kind of errata file placed /next to/ the Sarge images in the archive rather than having to rebuild the Sarge images themselves. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#804363: Wrong Debian release for this bug?
David McMackins:
> The BTS now shows this as a bug in 1.2.10-2, but that's the version that
> I have been rolling back to so I don't have this problem. It's
> 1.2.10-2+b1 that has the problems.
Yes, unfortunately the BTS doesn't understand the 1.2.10-2+b1 version number
(i.e. doesn't understand binNMUs) so the best option is version 1.2.10-2 but
with a tag for Sid only.
Thankfully I've got a patch (attached) which fixes both mumble-server and
the mumble client, and I'm about to upload 1.2.10-3.
It's still not clear how/why a rebuild with openssl_1.0.2d-3 would have
caused an issue, and I'm discussing this in #804487 and I'm planning to do a
few regression tests to see if I can narrow down the cause.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Description: the SSL library must be initialized, otherwise mumble and
mumble-server both fail to find the available ciphers after a rebuild
with openssl_1.0.2d-3. The two calls used are based on:
https://wiki.openssl.org/index.php/SSL/TLS_Client#Initialization
Author: Colomban Wendling <lists@herbesfolles.org>
Christohper Knadle <chris.kna...@coredump.us>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804363
Bug-Mumble: https://github.com/mumble-voip/mumble/issues/1876
Last-Updated: 2015-11-10
--- a/src/mumble/main.cpp
+++ b/src/mumble/main.cpp
@@ -170,6 +170,9 @@
os_init();
#endif
+ SSL_library_init();
+ SSL_load_error_strings();
+
bool bAllowMultiple = false;
QUrl url;
if (a.arguments().count() > 1) {
--- a/src/murmur/main.cpp
+++ b/src/murmur/main.cpp
@@ -203,6 +203,9 @@
qsrand(QDateTime::currentDateTime().toTime_t());
qInstallMsgHandler(murmurMessageOutput);
+ SSL_library_init();
+ SSL_load_error_strings();
+
#ifdef Q_OS_WIN
Tray tray(NULL, );
#endif
Bug#804487: [Pkg-openssl-devel] Bug#804487: openssl_1.0.2d-3 breaks mumble and mumble-server after binNMU
Kurt Roeckx: > On Sun, Nov 08, 2015 at 10:26:42PM +0000, Chris Knadle wrote: >> Package: openssl >> Version: 1.0.2d-3 >> Severity: serious >> >> Greetings. >> >> I'm marking this bug as 'serious' because the upgrade to 1.0.2d-3 seems to >> have broken mumble, though it's unclear why that would be. >> >> After a binNMU with openssl_1.0.2d-3 mumble and mumble-server are unable to >> find the available list of SSL ciphers, and unusable -- mumble-server quits, >> and mumble cannot find the user's SSL certificate to connect to servers >> with. mumble_1.2.10-2 compiled against libssl-dev 1.0.2d-1 worked okay. >> >> A debdiff between openssl_1.0.2d-1 and openssl_1.0.2d-3 seems reasonable (to >> me)... "pulling at straws" I see some changes in version-script.patch, and >> in the debian/rules file I see three new CONFARGS: "no-ssl3-method >> enable-rfc3779 enable-cms" and I'm not sure what the latter two confargs do. >> >> We're trying to figure out the problem with the mumble package in bug >> #804363. Although the breakage may have been triggered by the openssl >> upgrade it looks like mumble and mumble-server both seem to be missing an >> `SSL_library_init()` call, so this issue isn't clear yet. > > You really should call SSL_library_init() (or > OpenSSL_add_ssl_algorithms(), SSLeay_add_ssl_algorithms()) as > early as possible, clearly before calling other OpenSSL function, > see the manpage. Everybody dealing with the mumble bug agrees that SSL should be initialized before making SSL calls -- the reason I opened #804487 is to try to figure out /what/ caused mumble_1.2.10-2+b1 to break, when mumble_1.2.10-2 works. And I just tested -- mumble_1.2.10-2 works with openssl_1.0.2d-3. snapshot.debian.org has the before-and-after binNMU here: http://snapshot.debian.org/package/mumble/1.2.10-2/ I'm looking at and comparing the build logs, and one of the things I see is that the build pulled in both libssl1.0.0 and libssl1.0.2, where the prior build only pulled in libssl1.0.0. ldd shows that only libssl1.0.2 is linked in the resulting 'mumble' binary. That doesn't sound right. Mainly I was looking at this because upstream mentioned that previously Qt4 handled the SSL initialization, so I was looking at the qt -dev packages to see if the versions had changed between the builds -- which they didn't. > The "no-ssl3-method" really is the only change that applications > could have a problem with. It just drops SSLv3_* methods that > doesn't affect mumble. enable-cms is actually the default and din't > change anything. enable-rfc3779 shouldn't break anything, but > maybe it does when you didn't initialyze the library? I suppose this is testable -- I could make a custom openssl package with and without these options, put that in a local repo used by sbuild, and rebuild mumble, install it, and test it repeatedly. Sounds tedious but might be worth doing -- if I try it I'll let you know the results. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#804363: updating where bug is found
notfound #804363 mumble/1.2.10-2 found #804363 mumble/1.2.10-2+b1 thanks Making an attempt to get the BTS to understand that mumble in Testing is fine and that it's the binNMU version in Sid that's broken. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#804487: [Pkg-openssl-devel] Bug#804487: openssl_1.0.2d-3 breaks mumble and mumble-server after binNMU
Kurt Roeckx: > On Mon, Nov 09, 2015 at 07:58:30PM +0000, Chris Knadle wrote: >> >> Everybody dealing with the mumble bug agrees that SSL should be initialized >> before making SSL calls -- the reason I opened #804487 is to try to figure >> out /what/ caused mumble_1.2.10-2+b1 to break, when mumble_1.2.10-2 works. >> And I just tested -- mumble_1.2.10-2 works with openssl_1.0.2d-3. >> snapshot.debian.org has the before-and-after binNMU here: > > I assume you mean 1.0.2d-1 there. The soname changed between -1 > and -3 you actually get a different binary package. Let me be more specific: mumble_1.2.10-2 that was built with openssl_1.0.2d-1 works fine with openssl 1.0.2d-3 installed -- yet mumble_1.2.10-2+b1 that was /built/ with openssl_1.0.2d-3 does not. >>http://snapshot.debian.org/package/mumble/1.2.10-2/ >> >> I'm looking at and comparing the build logs, and one of the things I see is >> that the build pulled in both libssl1.0.0 and libssl1.0.2, where the prior >> build only pulled in libssl1.0.0. ldd shows that only libssl1.0.2 is linked >> in the resulting 'mumble' binary. That doesn't sound right. > > It's one of your build dependencies that was probably still using > libssl1.0.0 and probably isn't anymore. That shouldn't case any > issue. Okay. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#804487: [Pkg-openssl-devel] Bug#804487: openssl_1.0.2d-3 breaks mumble and mumble-server after binNMU
Kurt Roeckx: > On Mon, Nov 09, 2015 at 09:36:46PM +0000, Chris Knadle wrote: >> Kurt Roeckx: >>> On Mon, Nov 09, 2015 at 07:58:30PM +, Chris Knadle wrote: >>>> >>>> Everybody dealing with the mumble bug agrees that SSL should be initialized >>>> before making SSL calls -- the reason I opened #804487 is to try to figure >>>> out /what/ caused mumble_1.2.10-2+b1 to break, when mumble_1.2.10-2 works. >>>> And I just tested -- mumble_1.2.10-2 works with openssl_1.0.2d-3. >>>> snapshot.debian.org has the before-and-after binNMU here: >>> >>> I assume you mean 1.0.2d-1 there. The soname changed between -1 >>> and -3 you actually get a different binary package. >> >> Let me be more specific: mumble_1.2.10-2 that was built with >> openssl_1.0.2d-1 works fine with openssl 1.0.2d-3 installed -- yet >> mumble_1.2.10-2+b1 that was /built/ with openssl_1.0.2d-3 does not. > > Please note the "openssl" binary package version doesn't change > anything. You don't depend on it, you use the library. > > Mumble_1.2.10-2 uses the binary package "libssl1.0.0" (version > 1.0.2d-1) while mumble_1.2.10-2+b1 uses libssl1.0.2 (version > 1.0.2d-3). Ah. Yes -- verified. I guess that leaves only the openssl regression testing. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#804363: mumble: SSL connection aborts with "unable to allocate SSL_CTX"
Chris Knadle: [...] >> So, please fix the code to properly init LibSSL as required -- or >> whatever the proper fix is. > > Just off-the-top-of-my-head based on what you found with [1] it looks like > this could be fixed by adding init_openssl_library(); to line 52 of > src/SSL.cpp and then a blank line. I'm attaching a patch that I'm about to > try that does this. Mumble won't compile with the patch I suppled. I'm going to report this upstream and then look at this again tomorrow. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#804363: mumble: SSL connection aborts with "unable to allocate SSL_CTX"
Colomban Wendling:
> Package: mumble
> Version: 1.2.10-2+b1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Since last upgrade (the rebuild, +b1, oddly enough) Mumble aborts
> trying to connect to any server:
The +b1 is a binNMU, meaning that the same exact code is being recompiled
after a library upgrade, and in this case I believe the auto-openssl
transition triggered the binNMU:
https://release.debian.org/transitions/html/auto-openssl.html
>> OpenSSL Support: 1 (OpenSSL 1.0.2d 9 Jul 2015)
>> MumbleSSL: unable to allocate SSL_CTX
>> Invalid 'net/sslciphers' config option. Either the cipher string is invalid
>> or none of the ciphers are available:: "EECDH+AESGCM:AES256-SHA:AES128-SHA"
>> Abandon
Yep, I confirm this.
Additionally, mumble-server quits on startup because of the same issue.
> I do not have altered the net/sslciphers option, and ciphers look fine:
>
>> $ openssl ciphers "EECDH+AESGCM:AES256-SHA:AES128-SHA"
>> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA
>
> Anyway, after digging a lot, it appears that Mumble forgets to call
> `SSL_library_init()` [1]. Injecting such a call early in the run fixes
> the issue:
>
>> $ gdb mumble
>> GNU gdb (Debian 7.10-1) 7.10
>> [...snip...]
>> Reading symbols from mumble...Reading symbols from
>> /usr/lib/debug/.build-id/d7/713cd5f7d3cbaaa65bcdbe9bb1cc45b6478eb1.debug...done.
>> done.
>> (gdb) break main
>> Breakpoint 1 at 0x43eda0: file main.cpp, line 136.
>> (gdb) run
>> Starting program: /usr/bin/mumble
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>
>> Breakpoint 1, main (argc=1, argv=0x7fffe028) at main.cpp:136
>> 136 main.cpp: No such file or directory.
>> (gdb) call SSL_library_init()
>> $1 = 1
>> (gdb) continue
>> Continuing.
>> [...snip...]
>> OpenSSL Support: 1 (OpenSSL 1.0.2d 9 Jul 2015)
>> ServerHandler: TLS cipher preference is
>> "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA"
>
> And everything seem to work fine.
Thanks for taking the time to find this -- it should be very helpful in
figuring out the fix.
> Without this, not only Mumble aborts trying to connect to servers, but
> it also fails to check and generate user certificates. This throws the
> existing user certificate away on each startup, losing some
> unreproducible and potentially important data.
Ugh. Mumble normally automatically makes a backup of certs when the user
makes a new one (in ~/Documents, I believe) so hopefully that data isn't
lost permanently. [But yes I consider this a grave issue too.]
> So, please fix the code to properly init LibSSL as required -- or
> whatever the proper fix is.
Just off-the-top-of-my-head based on what you found with [1] it looks like
this could be fixed by adding init_openssl_library(); to line 52 of
src/SSL.cpp and then a blank line. I'm attaching a patch that I'm about to
try that does this.
>
> Regards,
> Colomban
>
>
> [1] https://wiki.openssl.org/index.php/SSL/TLS_Client#Initialization
Thanks very much for reporting this. Great work.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Description: the SSL library must be initialized, otherwise mumble and
mumble-server both fail to find the available ciphers fail to start
Author: Colomban Wendling <lists@herbesfolles.org>
Christohper Knadle <chris.kna...@coredump.us>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804363
Last-Updated: 2015-11-08
--- a/src/SSL.cpp
+++ b/src/SSL.cpp
@@ -49,6 +49,8 @@
QByteArray csbuf = cipherString.toLatin1();
const char *ciphers = csbuf.constData();
+ init_openssl_library();
+
meth = SSLv23_server_method();
if (meth == NULL) {
qWarning("MumbleSSL: unable to get SSL method");
signature.asc
Description: OpenPGP digital signature
Bug#804363: mumble: SSL connection aborts with "unable to allocate SSL_CTX"
Chris Knadle:
> Chris Knadle:
> [...]
>>> So, please fix the code to properly init LibSSL as required -- or
>>> whatever the proper fix is.
>>
>> Just off-the-top-of-my-head based on what you found with [1] it looks like
>> this could be fixed by adding init_openssl_library(); to line 52 of
>> src/SSL.cpp and then a blank line. I'm attaching a patch that I'm about to
>> try that does this.
The attached patch seems to work for allowing mumble and mumble-server to
find the SSL cipher list; however even with this fix I'm not able to load my
saved SSL certificate from a stored .p12 file. I'm wondering if the
SSL_library_init() might need to be done earlier.
I've reported this as upstream #1876
https://github.com/mumble-voip/mumble/issues/1876
Although this (mostly) works I want to be sure it's the right fix before
doing an upload, and I'd like to have a look at a 'debdiff' of the changes
made to the OpenSSL package to see if I can figure out all of what's been
removed between the versions.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Description: the SSL library must be initialized, otherwise mumble and
mumble-server both fail to find the available ciphers fail to start
Author: Colomban Wendling <lists@herbesfolles.org>
Christohper Knadle <chris.kna...@coredump.us>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804363
Last-Updated: 2015-11-08
--- a/src/SSL.cpp
+++ b/src/SSL.cpp
@@ -49,6 +49,8 @@
QByteArray csbuf = cipherString.toLatin1();
const char *ciphers = csbuf.constData();
+ SSL_library_init();
+
meth = SSLv23_server_method();
if (meth == NULL) {
qWarning("MumbleSSL: unable to get SSL method");
signature.asc
Description: OpenPGP digital signature
Bug#804487: openssl_1.0.2d-3 breaks mumble and mumble-server after binNMU
Package: openssl Version: 1.0.2d-3 Severity: serious Greetings. I'm marking this bug as 'serious' because the upgrade to 1.0.2d-3 seems to have broken mumble, though it's unclear why that would be. After a binNMU with openssl_1.0.2d-3 mumble and mumble-server are unable to find the available list of SSL ciphers, and unusable -- mumble-server quits, and mumble cannot find the user's SSL certificate to connect to servers with. mumble_1.2.10-2 compiled against libssl-dev 1.0.2d-1 worked okay. A debdiff between openssl_1.0.2d-1 and openssl_1.0.2d-3 seems reasonable (to me)... "pulling at straws" I see some changes in version-script.patch, and in the debian/rules file I see three new CONFARGS: "no-ssl3-method enable-rfc3779 enable-cms" and I'm not sure what the latter two confargs do. We're trying to figure out the problem with the mumble package in bug #804363. Although the breakage may have been triggered by the openssl upgrade it looks like mumble and mumble-server both seem to be missing an `SSL_library_init()` call, so this issue isn't clear yet. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#801265: verified that the 14.08.2 release has the fix
Verified that the 14.08.2 release fixes the compile. (Thanks Tobias)
The upgrade is quick because the patches still all apply without
modification. I'm including a debdiff of what I did to test this in case it
saves some maintainer time.
-- Chris, KB2IQN
--
Chris Knadle
chris.kna...@coredump.us
diffstat for svxlink-14.08.1 svxlink-14.08.2
debian/changelog |8
src/CMakeLists.txt |1 +
src/cmake/Modules/FindSIGC2.cmake|5 +
src/misc/CMakeLists.txt |2 +-
src/misc/CppStdCompat.h | 10 ++
src/svxlink/ChangeLog| 19 +++
src/svxlink/modules/echolink/QsoImpl.cpp | 11 ++-
src/svxlink/svxlink/LinkManager.cpp | 22 --
src/svxlink/svxlink/LinkManager.h|3 ++-
src/svxlink/svxlink/svxlink.cpp |4 ++--
src/svxlink/trx/Emphasis.h | 17 +
src/svxlink/trx/SigLevDetTone.h |9 +
src/svxlink/trx/ToneDetector.h | 13 +++--
src/svxlink/trx/Voter.h | 27 ++-
src/versions |6 +++---
15 files changed, 108 insertions(+), 49 deletions(-)
diff -Nru svxlink-14.08.1/debian/changelog svxlink-14.08.2/debian/changelog
--- svxlink-14.08.1/debian/changelog2015-07-28 14:05:12.0 -0400
+++ svxlink-14.08.2/debian/changelog2015-11-03 00:27:13.0 -0500
@@ -1,3 +1,11 @@
+svxlink (14.08.2-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release from 2015-11-02
+Fixes failure to compile with C++11 (Closes: #801265)
+
+ -- Christopher Knadle <chris.kna...@coredump.us> Tue, 03 Nov 2015 00:25:45
-0500
+
svxlink (14.08.1-1) unstable; urgency=medium
* New upstream version
diff -Nru svxlink-14.08.1/src/cmake/Modules/FindSIGC2.cmake
svxlink-14.08.2/src/cmake/Modules/FindSIGC2.cmake
--- svxlink-14.08.1/src/cmake/Modules/FindSIGC2.cmake 2015-04-30
04:36:03.0 -0400
+++ svxlink-14.08.2/src/cmake/Modules/FindSIGC2.cmake 2015-11-02
16:59:27.0 -0500
@@ -4,11 +4,16 @@
# SIGC2_INCLUDE_DIRS - The libsigc++-2 include directories
# SIGC2_LIBRARIES- The libraries needed to use libsigc++-2
# SIGC2_DEFINITIONS - Compiler switches required for using libsigc++-2
+# SIGC_CXX_FLAGS - Required C++ specific compiler switches
find_package(PkgConfig)
pkg_check_modules(PC_SIGC2 sigc++-2.0)
set(SIGC2_DEFINITIONS ${PC_SIGC2_CFLAGS_OTHER})
+if(${PC_SIGC2_VERSION} VERSION_GREATER "2.5.0")
+ set(SIGC2_CXX_FLAGS "--std=c++11")
+endif()
+
find_path(SIGC2_CONFIG_INCLUDE_DIR sigc++config.h
HINTS ${PC_SIGC2_INCLUDEDIR} ${PC_SIGC2_INCLUDE_DIRS}
)
diff -Nru svxlink-14.08.1/src/CMakeLists.txt svxlink-14.08.2/src/CMakeLists.txt
--- svxlink-14.08.1/src/CMakeLists.txt 2015-04-30 04:36:03.0 -0400
+++ svxlink-14.08.2/src/CMakeLists.txt 2015-11-02 16:59:27.0 -0500
@@ -305,6 +305,7 @@
find_package(SIGC2 REQUIRED)
include_directories(${SIGC2_INCLUDE_DIRS})
add_definitions(${SIGC2_DEFINITIONS})
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${SIGC2_CXX_FLAGS}")
set(LIBS ${LIBS} ${SIGC2_LIBRARIES})
# Find the chown utility
diff -Nru svxlink-14.08.1/src/misc/CMakeLists.txt
svxlink-14.08.2/src/misc/CMakeLists.txt
--- svxlink-14.08.1/src/misc/CMakeLists.txt 2015-04-30 04:36:03.0
-0400
+++ svxlink-14.08.2/src/misc/CMakeLists.txt 2015-11-02 16:59:27.0
-0500
@@ -1,4 +1,4 @@
-set(EXPINC common.h)
+set(EXPINC common.h CppStdCompat.h)
# Copy exported include files to the global include directory
foreach(incfile ${EXPINC})
diff -Nru svxlink-14.08.1/src/misc/CppStdCompat.h
svxlink-14.08.2/src/misc/CppStdCompat.h
--- svxlink-14.08.1/src/misc/CppStdCompat.h 1969-12-31 19:00:00.0
-0500
+++ svxlink-14.08.2/src/misc/CppStdCompat.h 2015-11-02 16:59:27.0
-0500
@@ -0,0 +1,10 @@
+#ifndef CPP_STD_COMPAT_INCLUDED
+#define CPP_STD_COMPAT_INCLUDED
+
+#if __cplusplus >= 201102L
+ #define CONSTEXPR constexpr
+#else
+ #define CONSTEXPR const
+#endif
+
+#endif /* CPP_STD_COMPAT_INCLUDED */
diff -Nru svxlink-14.08.1/src/svxlink/ChangeLog
svxlink-14.08.2/src/svxlink/ChangeLog
--- svxlink-14.08.1/src/svxlink/ChangeLog 2015-04-30 04:36:03.0
-0400
+++ svxlink-14.08.2/src/svxlink/ChangeLog 2015-11-02 16:59:27.0
-0500
@@ -1,3 +1,22 @@
+ 1.4.3 -- 02 nov 2015
+--
+
+* SvxLink now compile in C++11 mode with GCC and other compilers that
+ understand the -std=c++11 compiler switch. The compiler switch will
+ automatically be turned on if a version of libsigc++ greater than 2.5.0 is
+ detected since those versions require C++11 to be enabled.
+
+
+
+ 1.4.2 -- 06 jun 2015
+--
+
+* Bugfix: The logic linking would cause a crash under some circumstan
Bug#802390: mumble-server: No init script or systemd unit
Sunil Mohan: > Daniel, thank you for the bug report. > >> Verified. It seems this was missed in the switch from individual >> debhelper calls to dh in debian/rules. >> >> Thanks very much for reporting this. Will fix ASAP. > > Thank you for the quick response and fix. It would you really nice to > have the fixed package uploaded soon as we are planning to show Mumble > during FreedomBox Demo on Oct 30. FreedomBox is currently running on > sid :( I'll do my best. I'm trying to track down an issue with dpkg-buildflags concerning one file being shipped that may partially be missing the FORTIFY flag. At least some functions are fortified but there doesn't seem to be a good verification tool to know if lintian is reporting a false-positive or if there's a QMAKE file missing dpkg-buildflags. >> I have a systemd unit file written for mumble-server, BTW, but I'm >> unclear how to include it alongside the init script. If anyone has a >> hint about that, please send it to this bug report. Thanks. > > The init script and systemd unit should both be shipped. systemd will > simply ignore the init script when a unit with the same name is > present[1]. (If you want a different name to the systemd unit that is > possible too with 'Alias=' option). > > After you are done with basic stuff in the unit file, consider adding > security features to the unit file[2]. This will bring many of the > security advantages of containers without containers. This will be > pretty sweet thing for FreedomBox :) There are a few wrinkles with shipping a systemd unit file. - There's a bug with mumble-server startup under systemd and upstart (#780300). You can see the service file I created in testing the bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=49;filename=mumble-server.service;bug=780300 Using a setting of "host=::" is a workaround, but I don't consider that a true solution to the bug. - mumble-server ships an /etc/default/mumble-server file to disable the daemon by default, and there's no clean way under systemd to disable a unit based on the contents of an environment variable in a file. https://wiki.ubuntu.com/SystemdForUpstartUsers#A.2BAC8-etc.2BAC8-default_files_which_enable.2BAC8-disable_jobs - As discussed on [debian-devel] in the "init script, installed but not activated" thread, it's tricky to ship a systemd service file that isn't active by default. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#802390: mumble-server: No init script or systemd unit
Chris Knadle: > Daniel Gnoutcheff: >> Package: mumble-server >> Version: 1.2.10-1 >> Severity: normal >> >> In jessie, the mumble-server package shipped a /etc/init.d/mumble-server >> init script. This is no longer present in stretch, nor is there a >> systemd unit to replace it. > > Verified. It seems this was missed in the switch from individual debhelper > calls to dh in debian/rules. It's a simple fix; the call to dh_installinit was made in the wrong order in override_dh_installinit. Moving the call to the end of that section fixes the issue. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#791319: upload made and is in NEW queue
I'm just making a quick note that an NMU zeroc-ice is in the NEW queue so that others finding this bug know that this is in progress. https://ftp-master.debian.org/new/zeroc-ice_3.5.1-6.1.html -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#793987: torbirdy 0.1.4-0.1 available on mentors.debian.net
Greetings. I loaded xul-ext-torbirdy this evening wherein I was notified of this bug by the how-can-i-help package, so I decided to put together a new upload. It's available at mentors.debian.net: https://mentors.debian.net/package/torbirdy I verified it works on Sid, but you might want to verify that the result works on Icedove in Stretch as I didn't get a chance to do that. Side note: I tried adding a GPG check to the debian/watch file like this: version=3 opts=pgpsigurlmangle=s/$/.sig/ \ https://www.torproject.org/dist/torbirdy/torbirdy-([0-9].+).xpi \ debian xpi-repack (along with adding the signing GPG key as an ASCII armored debian/upstream/signing-key.asc file) but unfortunately the GPG check + xpi-repack don't seem to play well together, and results in an error message of not finding the .xpi.asc file even though it gets downloaded. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, 2015-03-22 at 20:35 +, Colin Watson wrote: Anyway, I would appreciate it if people could refrain from filling my mailbox further about this bug. :-) One last thing perhaps. O:-) Colin: my apologies for adding work [especially so if any of the work added is unnecessary]. I'm sure you meant well; I do too. On 03/22/2015 06:18 PM, Christoph Anton Mitterer wrote: [...] I haven't had time to deal with it over the last couple of days (Debian developer in having a social life shocker!), but in brief I intend to revert the offending change in its entirety as it's clearly causing far more trouble than it can possibly be worth. I'll post further rationale when I get half a chance. Well I don't really care that much, as said my intention was just to improve defaults for others. But to be honest, and without intending to offend any of the others,... it kinda seems to me that people make a mountain out of a molehill. Christoph: there may be a lack of empathy in your response statements. Please try to put yourself in the user's shoes -- the issue looks very different from that perspective. [I'm likewise considering this from the maintainer perspective.] The change is really little, for well grounded security reasons it's actually intended by upstream that non env vars are send/accepted unless explicitly allowed by the admin. So people who complain now likely just abused that hole in Debian's default all the years, which is however no grant for a right to do so forever. Again: at least for me, it's not about /this/ particular change, it's about changes happening to user-modified configs on upgrades without dpkg prompting. sshd_config is literally /the/ most important config file on systems for me, and therefore it's also the file that's most sensitive. [ssh_config similarly.] In terms of the /particular/ changes made to ssh_config and sshd_config in this case, I made the assumption that it was for good reasons and with good intentions so that's why I didn't object to that. But... at the same time I keep in mind that the road to hell is paved with good intentions. (Which could also include me strongly objecting.) It feels a bit like the systemd debate where a loud minority started an outcry about things which in reality probably didn't even affect them. Since you mention it, I'll just say that the systemd debate is another place marked by arguments that often lack empathy and understanding of the the other person's perspective. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: openssh-server: modifies the user configuration
On Sat, 2015-03-21 at 07:12 +0100, Christoph Anton Mitterer wrote: On Sat, 2015-03-21 at 00:51 -0400, Chris Knadle wrote: § 10.7.3 Behavior Configuration file handling must conform to the following behavior: • local changes must be preserved during a package upgrade Well, strictly speaking, if the user had let that option at it's Debian default, than there wasn't a local change. This argument doesn't work. If the configuration the /user/ set gets changed without any notification, then what that says to the user is that /they/ don't control those config files. In the worst case, there are settings in ssh_config and sshd_config that are simple yes/no. So this argument could be used to switch a setting to no if the default was yes unless the user did so already. :-/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: openssh-server: modifies the user configuration
On 03/21/2015 03:33 PM, Christoph Anton Mitterer wrote: [...] Get a new firefox version, and the whole binary blob profile may completely be upgraded, old algos disabled etc. pp. So, as soon as the file is modified, it must be considered that the configuration has been chosen by the admin and mustn't be modified automatically. This is at least how debconf behaves. Even if you say that *any* modification of *any* part of the whole abstract configuration would need the whole configuration to be considered locally modified, then this wouldn't work out in practise. I'll give the example of what happens with the Exim MTA. A new config file comes down with the new version of Exim, and local modifications are detected, whereby dpkg prompts for what to do. The user/admin chooses keep local configuration, whereby the new configuration file is stored locally as .dpkg-new and the user/admin chooses how to do whatever config migration is necessary. This way the user has their original configuration and the new default, and they can do a diff to figure out what needs to be altered. What's happening now with openssh is that the config files are changed in-place, so the user can't tell what happened after it already happened... and yet that's the first question that was asked in this bug. :-/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: openssh-server: modifies the user configuration
The issue here is that the openssh-server package modifies two config files in /etc without any warning to the user, and that's a clear Policy violation IMHO: § 10.7.3 Behavior Configuration file handling must conform to the following behavior: • local changes must be preserved during a package upgrade Changing the default config file /for new installs/ is fine, but changing user-made modifications to config files is not. In this case openssh-server modifies both /etc/ssh_config and /etc/sshd_config and dpkg doesn't say a thing about it. The *particular changes made* aren't the issue at all: the issue is the slippery slope problem, and that's why I think the Policy is written exactly how it is. If it's okay to modify a user's changes here, then it's okay to do it elsewhere. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737739: mumble: CVE-2014-0044 CVE-2014-0045
On Wednesday, February 05, 2014 16:10:36 Salvatore Bonaccorso wrote: Source: mumble Version: 1.2.3-349-g315b5f5-2.2 Severity: grave Tags: security upstream fixed-upstream Hi Mumble has released a new upstream version fixing CVE-2014-0044 and CVE-2014-0045. See upstream commits at: https://github.com/mumble-voip/mumble/commit/850649234d11685145193a59d72d984 29e4f9ba7 https://github.com/mumble-voip/mumble/commit/d3be3d7b96a5130e4b20f23e327b04 0ea4d0b079 Upstream announces at http://mumble.info/security/Mumble-SA-2014-001.txt http://mumble.info/security/Mumble-SA-2014-002.txt Regards, Salvatore Thanks for fixing this. As these commits were authored only 5 days ago I'd think the current 1.2.4-0.1 package in Sid and Jessie have this issue too, unless there's some other mitigating factor with the stable 1.2.4 version. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737739: mumble: CVE-2014-0044 CVE-2014-0045
On Wednesday, February 05, 2014 22:16:32 Salvatore Bonaccorso wrote:
Hi Chris,
On Wed, Feb 05, 2014 at 11:09:00AM -0500, Chris Knadle wrote:
On Wednesday, February 05, 2014 16:10:36 Salvatore Bonaccorso wrote:
Source: mumble
Version: 1.2.3-349-g315b5f5-2.2
Severity: grave
Tags: security upstream fixed-upstream
Hi
Mumble has released a new upstream version fixing CVE-2014-0044 and
CVE-2014-0045. See upstream commits at:
https://github.com/mumble-voip/mumble/commit/850649234d11685145193a59d72
d984 29e4f9ba7
https://github.com/mumble-voip/mumble/commit/d3be3d7b96a5130e4b20f23e327
b04
0ea4d0b079
Upstream announces at
http://mumble.info/security/Mumble-SA-2014-001.txt
http://mumble.info/security/Mumble-SA-2014-002.txt
Regards,
Salvatore
Thanks for fixing this.
As these commits were authored only 5 days ago I'd think the current
1.2.4-0.1 package in Sid and Jessie have this issue too, unless there's
some other mitigating factor with the stable 1.2.4 version.
Yes it is also as it's supporting Opus; reason is that I concentrated
first on the wheezy-security upload.
Okay. Currently there's ABI breakage in protobuf 2.5.0-7 which will be fixed
with the -9 upload once it's finished being built; I have to wait for that
before we can upload a new 1.2.4 mumble package fixes. I've got both of the
CVE patches queued for the next upload which I'm looking to do this weekend,
but if you'd like to do a security fix on 1.2.4-0.1 after the protobuf -9
build go ahead and do so.
-- Chris
--
Chris Knadle
chris.kna...@coredump.usDescription: Fix denial-of-service vulnerability
CVE-2014-0044: A malformed Opus voice packet sent to a Mumble client
could trigger a NULL pointer dereference or an out-of-bounds array
access, leading to a crash (Denial of Service).
Author: Mikkel Krautz mik...@krautz.dk
Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737739
Origin: upstream
Applied-Upstream: commit 850649234d11685145193a59d72d98429e4f9ba7
Last-Update: 2014-02-05
--- a/src/mumble/AudioOutputSpeech.cpp
+++ b/src/mumble/AudioOutputSpeech.cpp
@@ -148,8 +148,15 @@
int size;
pds size;
size = 0x1fff;
+ if (size == 0) {
+ return;
+ }
const QByteArray qba = pds.dataBlock(size);
+ if (size != qba.size() || !pds.isValid()) {
+ return;
+ }
+
const unsigned char *packet = reinterpret_castconst unsigned char*(qba.constData());
#ifdef USE_OPUS
Description: Fix heap-based buffer overflow vulnerability
CVE-2014-0045: A malformed Opus voice packet sent to a Mumble client
could trigger a heap-based buffer overflow. This causes a client crash
(Denial of Service) and can potentially be used to execute arbitrary
code.
Author: Mikkel Krautz mik...@krautz.dk
Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737739
Origin: upstream
Applied-Upstream: commit d3be3d7b96a5130e4b20f23e327b040ea4d0b079
Last-Update: 2014-02-05
--- a/src/mumble/AudioOutputSpeech.cpp
+++ b/src/mumble/AudioOutputSpeech.cpp
@@ -342,6 +342,10 @@
pOut,
iAudioBufferSize,
0);
+ if (decodedSamples 0) {
+ decodedSamples = iFrameSize;
+ memset(pOut, 0, iFrameSize * sizeof(float));
+ }
#endif
} else {
if (qba.isEmpty()) {
@@ -391,6 +395,10 @@
} else if (umtType == MessageHandler::UDPVoiceOpus) {
#ifdef USE_OPUS
decodedSamples = opus_decode_float(opusState, NULL, 0, pOut, iFrameSize, 0);
+ if (decodedSamples 0) {
+ decodedSamples = iFrameSize;
+ memset(pOut, 0, iFrameSize * sizeof(float));
+ }
#endif
} else {
speex_decode(dsSpeex, NULL, pOut);
Bug#737223: mumble: run time linker fails on new libprotobuf8
With the upload of libprotobuf8 2.5.0-9 in unstable this bug should be fixed for all release architectures. (protobuf requires gcc = 4.7 so mumble will not work on ia64 or sparc right now). -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737223: mumble: run time linker fails on new libprotobuf8
On Monday, February 03, 2014 14:23:33 Gonéri Le Bouder wrote: Hi all, Okay, we've figured out that this is an issue with libprotobuf8. mumble 1.2.4-0.1 works with libprotobuf8 2.5.0-3 and -5, but not -6 or -7. I just rebuilt mumble and that was enough to get it working. ii libprotobuf-dev:amd64 2.5.0-7 amd64protocol buffers C++ library (development files) ii libprotobuf-lite8:amd64 2.5.0-7 amd64protocol buffers C++ library (lite version) rc libprotobuf7 2.4.1-3 amd64protocol buffers C++ library ii libprotobuf8:amd642.5.0-7 amd64protocol buffers C++ library ii mumble1.2.4-0.1 amd64Low latency VoIP client To me, this is just an ABI breakage from libprotobuf8. A simple bin-NMU should be enough to resolve the situation. Best regards, It looks like you're right... it looks like I made a subtle goof with cowbuilder as to why the build was repeatedly failing. Thanks for reporting that it builds correctly. Unfortunately the package for i386 is also broken, and I think you've pointed out the core issue -- the ABI changed between the -5 and -7 versions, but the only packages in Debian that were rebuilt were the architectures that didn't build -- namely ia64 and sparc. Thus I believe mumble 1.2.4-0.1+b1 is likely broken for all architectures except ia64 and sparc right now. Is there a method to get Debian's buildd's to triger a rebuild of the mumble package? -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#737246: libprotobuf8: 2.5.0-7 breaks mumble
On Friday, January 31, 2014 23:41:01 Chris Knadle wrote: On Friday, January 31, 2014 15:21:53 Robert Edmonds wrote: Chris Knadle wrote: severity 737246 grave thanks It's probably related to #736801 I guess. Unfortunately this is not related to #736801 as best I can tell; recompiling mumble locally with libprotobuf8 2.5.0-7 has the same result. This means mumble is currently borked. :-( -- Chris In that case, it looks like my changes in 2.5.0-6 / -7 are just broken. Yes -3 and -5 work, -6 / -7 do not. Correction: mumble will work when built against protobuf 2.5.0-7 ; someone reported this to me and it took me a while but I was able to verify it -- apparently I had some complications with cowbuilder I didn't know I had. My apologies for being in error on this. Is there a way to get Debian's buildd's to rebuild the package? BTW I believe this is a situation where the ABI changed between protobuf 2.5.0-5 and -7 but the name (i.e. the number in the name) of the library should have changed to trigger the Debian buildd's to rebuild the package. At least that's the way I interpret the text in Debian Policy section 8.1. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737246: libprotobuf8: 2.5.0-7 breaks mumble
On Friday, January 31, 2014 15:21:53 Robert Edmonds wrote: Chris Knadle wrote: severity 737246 grave thanks It's probably related to #736801 I guess. Unfortunately this is not related to #736801 as best I can tell; recompiling mumble locally with libprotobuf8 2.5.0-7 has the same result. This means mumble is currently borked. :-( -- Chris In that case, it looks like my changes in 2.5.0-6 / -7 are just broken. Most likely we need to revert back to the approach in 2.5.0-5 but fix the atomic code so that it works on the architectures with older default gcc versions. I'll see if I can get that done in the next day or so. I'll have a look at the protobuf snapshots at snapshot.debian.org to see if I can understand what's going on. Maybe as a first check I'll build mumble 1.2.4-0.1 against protobuf 2.5.0-5 for sid/amd64 to see that the result works. Thanks much. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737223: mumble: run time linker fails on new libprotobuf8
On Friday, January 31, 2014 14:54:58 Chris Knadle wrote: severity 737223 grave thanks The latest unstable patch that relinked mumble client with the new libprotobuf8 is broken: It's not a patch that did this, it's a new version of protobuf that came in causing a rebuild of the mumble package. zsh% mumble mumble: symbol lookup error: mumble: undefined symbol: _ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE zsh% Okay, we've figured out that this is an issue with libprotobuf8. mumble 1.2.4-0.1 works with libprotobuf8 2.5.0-3 and -5, but not -6 or -7. Looks like the mumble package doesn't require rebuilding to fix this, just the protobuf package does. Robert should be able to fix this in the next couple of days. See #737246 for updates. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737223: Bug#737246: libprotobuf8: 2.5.0-7 breaks mumble
On Friday, January 31, 2014 15:21:53 Robert Edmonds wrote: Chris Knadle wrote: severity 737246 grave thanks It's probably related to #736801 I guess. Unfortunately this is not related to #736801 as best I can tell; recompiling mumble locally with libprotobuf8 2.5.0-7 has the same result. This means mumble is currently borked. :-( -- Chris In that case, it looks like my changes in 2.5.0-6 / -7 are just broken. Yes. 2.5.0-3 and -5 work, -6 and -7 don't. Most likely we need to revert back to the approach in 2.5.0-5 but fix the atomic code so that it works on the architectures with older default gcc versions. I'll see if I can get that done in the next day or so. Doing a 'debdiff' between the -5 and -6 version I see what you're talking about. [No code differences between -6 and -7.] The -488 patch removes the GoogleOnceInitImpl() function and references to it but somehow this symbol _ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE is still expected by mumble even when building it anew. Anyway if there's a way in which I can lend a hand, let me know. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737246: libprotobuf8: 2.5.0-7 breaks mumble
On Friday, January 31, 2014 15:21:53 Robert Edmonds wrote: Chris Knadle wrote: severity 737246 grave thanks It's probably related to #736801 I guess. Unfortunately this is not related to #736801 as best I can tell; recompiling mumble locally with libprotobuf8 2.5.0-7 has the same result. This means mumble is currently borked. :-( -- Chris In that case, it looks like my changes in 2.5.0-6 / -7 are just broken. Yes -3 and -5 work, -6 / -7 do not. However concerning the changes made to fix #736801 (build failures on ia64 and sparc), as of Wednesday (2014-01-29) it was announced in [debian-devel-announce] that ia64 and sparc are no longer release architectures. sparc is apparently still using gcc-4.6 as the default compiler, and the kernel in stable does not work. This means that Britney will allow package migrations into Testing regardless if packages for these two architectures are broken. Today it was announced the ia64 architecture was removed from Testing, and is likely to be removed from Sid as well soon. Most likely we need to revert back to the approach in 2.5.0-5 but fix the atomic code so that it works on the architectures with older default gcc versions. I'll see if I can get that done in the next day or so. Issues with ia64 can be ignored now, and under the circumstances sparc is questionable. I think you have the option of using the 2.5.0-5 package as it was if you wish. I'm not trying to rush a fix here though -- I'm mainly mentioning this because I'm wondering from the maintainer point of view if the effort to patch the protobuf source specifically for these two architectures is worth the effort. Obviously I didn't know these architecture changes were coming when I filed #736801 on the 26th. ;-) Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726860: mumble: build-depends on obsolete zeroc-ice packages.
On Monday, November 04, 2013 00:55:35 Petter Reinholdtsen wrote: [Chris Knadle] If you know of a DD that is familiar with the Mumble package and would be willing to sponsor an upload of it, let me know. I'm not very familiar with Mumble (only a user) Familiarity from the user standpoint is the main thing I'm looking for. :-) but if you want me to sponsor it, my preferences are available from URL: http://www.hungry.com/~pere/debian-sponsoring.html . All of these preferences seem reasonable to me. I'll contact you in a couple of days. At this point mainly I want to check which bug #'s the new upload will close, check the Mumble upstream bug tracker relating to the DEP3 headers on a quilt patch I've included, and remove the unnecessary (= 1.42) on the libboost-dev dependency. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726860: mumble: build-depends on obsolete zeroc-ice packages.
On Sunday, November 03, 2013 19:37:51 Petter Reinholdtsen wrote: Hi. Thus RC bug caused mumble to be removed from testing the other day. Mumble also depends on libboost-dev (= 1.42) which is causing the package to come up with an 'unknown' status concerning the libboost 1.54 migration. http://release.debian.org/transitions/html/boost1.54.html Is a new upload planned soon to fix it. Yes. See #728545. If you know of a DD that is familiar with the Mumble package and would be willing to sponsor an upload of it, let me know. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728545 -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726860: mumble: build-depends on obsolete zeroc-ice packages
Mumble 1.2.3-349-g315b5f5-2.2 in Debian compiles fine with zeroc-ice 35, without any changes to the Mumble source required. The dependency on g++ 4.6 can also be removed at the same time. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704870: opus: cve-2013-0899
tags 704870 + patch
thanks
Gregor -- thanks for finding the links.
The .diff just had different line numbers, so would likely apply with fuzz,
but I made a quick patch that doesn't agaist the git repo.
I would have made a quilt patch, but this looks like a package in 1.0 format.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
From d5aeb4fa4ff5e93deb7641359678d91b49fae4b0 Mon Sep 17 00:00:00 2001
From: Christopher Knadle chris.kna...@coredump.us
Date: Mon, 8 Apr 2013 17:59:28 -0400
Subject: [PATCH] fix for CVE-2013-0899
Fix possible overflow padding by feeding ~16 MB of 0xff bytes to the decoder
Thanks to Gregor Herrmann for finding these links with more detail:
https://code.google.com/p/chromium/issues/detail?id=160480
http://git.xiph.org/?p=opus.git;a=commitdiff;h=9345aaa5ca1c2fb7d62981b2a538e0ce20612c38
---
src/opus_decoder.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/opus_decoder.c b/src/opus_decoder.c
index 24869e7..7d2219d 100644
--- a/src/opus_decoder.c
+++ b/src/opus_decoder.c
@@ -596,16 +596,14 @@ static int opus_packet_parse_impl(const unsigned char *data, opus_int32 len,
/* Padding flag is bit 6 */
if (ch0x40)
{
- int padding=0;
int p;
do {
if (len=0)
return OPUS_INVALID_PACKET;
p = *data++;
len--;
-padding += p==255 ? 254: p;
+len -= p==255 ? 254: p;
} while (p==255);
- len -= padding;
}
if (len0)
return OPUS_INVALID_PACKET;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part.
Bug#702102: fails to upgrade (cowbuilder) chroot
On Tuesday, March 26, 2013 08:46:08, Michael Biebl wrote: Am 26.03.2013 09:48, schrieb Junichi Uekawa: not enough information in the bug, 702811 seems to be a better bug. Say what? Have you read the full bug report, including the analysis that it is because of /run/shm vs /dev/shm? Related to this, a patch was incorporated from the following email to handle another bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700591#5 Based on the idea that it's somehow this patch that's causing this new problem, I'm pulling at straws to try to help figure out why. You mentioned you have /run/shm but not /dev/shm. Based on that I'm looking at the following logic from the patch: +if [ $DEB_BUILD_ARCH_OS = linux ] [ $USEDEVSHM = yes ]; then + SHM_PATH=run/shm + [ ! -d /$SHM_PATH ] SHM_PATH=dev/shm This looks to me like it's checking if /run/shm exists (and is a directory), and if it doesn't then blindly uses /dev/shm instead. This seems reasonable but I'm wondering if there's some way for this test to fail. If /run/shm were a /device/ rather than a directory or a softlink to a directory, that would be one way for that to happen. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702102: Acknowledgement (fails to upgrade (cowbuilder) chroot)
On Wednesday, March 20, 2013 15:25:26, Michael Biebl wrote: from IRC: jcristau i ran into that one today, i think. had to set a variable in pbuilderrc to tell it to not bother mounting shm jcristau iirc it tries to check whether /run/shm exists on the host to decide whether to use /dev/shm or /run/shm in the chroot jcristau which makes no sense at all That's the problem indeed. I don't have /run/shm (but /dev/shm), and pbuilder trips over that. Symptoms match: I have /run/shm as well as /dev/shm, and both directories seem bound together. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702102: [pbuilder] seems to work for alternate location
installed.) Preparing to replace libpam-modules-bin 1.1.3-7.1 (using .../libpam-modules-bin_1.1.3-9_amd64.deb) ... Unpacking replacement libpam-modules-bin ... Replacing files in old package libpam-modules:amd64 ... Setting up libpam-modules-bin (1.1.3-9) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libpam-modules:amd64 1.1.3-7.1 (using .../libpam-modules_1.1.3-9_amd64.deb) ... Unpacking replacement libpam-modules:amd64 ... Setting up libpam-modules:amd64 (1.1.3-9) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libmpfr4:amd64 3.1.0-5 (using .../libmpfr4_3.1.1-1_amd64.deb) ... Unpacking replacement libmpfr4:amd64 ... Preparing to replace sysv-rc 2.88dsf-39 (using .../sysv-rc_2.88dsf-41_all.deb) ... Unpacking replacement sysv-rc ... Setting up sysv-rc (2.88dsf-41) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace initscripts 2.88dsf-39 (using .../initscripts_2.88dsf-41_amd64.deb) ... Unpacking replacement initscripts ... Setting up initscripts (2.88dsf-41) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libpam-runtime 1.1.3-7.1 (using .../libpam-runtime_1.1.3-9_all.deb) ... Unpacking replacement libpam-runtime ... Setting up libpam-runtime (1.1.3-9) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libboost-iostreams1.49.0 1.49.0-3.1 (using .../libboost-iostreams1.49.0_1.49.0-3.2_amd64.deb) ... Unpacking replacement libboost-iostreams1.49.0 ... Preparing to replace binutils 2.22-7.1 (using .../binutils_2.22-8_amd64.deb) ... Unpacking replacement binutils ... Preparing to replace linux-libc-dev:amd64 3.2.35-2 (using .../linux-libc-dev_3.2.39-2_amd64.deb) ... Unpacking replacement linux-libc-dev:amd64 ... Setting up libmpfr4:amd64 (3.1.1-1) ... Setting up libboost-iostreams1.49.0 (1.49.0-3.2) ... Setting up binutils (2.22-8) ... Setting up linux-libc-dev:amd64 (3.2.39-2) ... Setting up perl-modules (5.14.2-18) ... Setting up perl (5.14.2-18) ... Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Reading package lists... Building dependency tree... Reading state information... Package 'ccache' is not installed, so not removed aptitude is already the newest version. build-essential is already the newest version. dpkg-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. I: Copying back the cached apt archive contents I: new cache content diffutils_1%3a3.2-8_amd64.deb added I: new cache content perl_5.14.2-18_amd64.deb added I: new cache content perl-base_5.14.2-18_amd64.deb added I: new cache content sysvinit_2.88dsf-41_amd64.deb added I: new cache content sysvinit-utils_2.88dsf-41_amd64.deb added I: new cache content libpam0g_1.1.3-9_amd64.deb added I: new cache content libpam-modules-bin_1.1.3-9_amd64.deb added I: new cache content libpam-modules_1.1.3-9_amd64.deb added I: new cache content libmpfr4_3.1.1-1_amd64.deb added I: new cache content initscripts_2.88dsf-41_amd64.deb added I: new cache content libpam-runtime_1.1.3-9_all.deb added I: new cache content libboost-iostreams1.49.0_1.49.0-3.2_amd64.deb added I: new cache content binutils_2.22-8_amd64.deb added I: new cache content linux-libc-dev_3.2.39-2_amd64.deb added I: unmounting dev/pts filesystem I: unmounting run/shm filesystem I: unmounting proc filesystem - removing cowbuilder working copy - Moving work directory [/deb-chroots/cow-buildplace//cow.32420] to final location [/deb-chroots/amd64-sid-base.cow] and cleaning up old copy forking: rm -rf /deb-chroots/cow-buildplace//cow.32420-32420-tmp == Post the cowbuilder command line you're using if you think it might be significant. Maybe there's an option you're using that I'm not that is triggering the bug? -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: amd64 Kernel: Linux 3.7.7-c2d-crk-1 Debian Release: 7.0 500 unstablewww.deb-multimedia.org 500 unstableftp.us.debian.org 500 unstabledownload.jitsi.org 500 testing security.debian.org 500 testing ftp.us.debian.org 500 stable dl.google.com 1 experimentalftp.us.debian.org --- Package information. --- Depends (Version) | Installed =-+-= coreutils(= 4.5.8-1) | 8.20-3 debootstrap | 1.0.46 OR cdebootstrap | dpkg-dev | 1.16.9 debianutils (= 1.13.1) | 4.3.4 wget | 1.14-1 debconf (= 0.5) | 1.5.49 OR debconf-2.0 | Recommends (Version) | Installed
Bug#696011: virtualbox: kernel modules fail to build against linux kernel v3.7
Unfortunately I find that even with the patch, the VirtualBox modules will not compile when built with upstream Linux 3.6.11 and 3.7.4 from the linux-stable Git tree. They build fine against upstream 3.5.7. ... kmk[3]: Entering directory `/home/cknadle/src/LinuxDev/linux-3.6.11' LD /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/built-in.o CC [M] /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/linux/VBoxPci- linux.o CC [M] /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPci.o In file included from /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPciInternal.h:34:0, from /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPci.c:38: include/linux/iommu.h: In function ‘iommu_group_alloc’: include/linux/iommu.h:272:2: error: implicit declaration of function ‘ERR_PTR’ [-Werror=implicit-function-declaration] include/linux/iommu.h:272:2: warning: return makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors kmk[3]: *** [/home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPci.o] Error 1 kmk[3]: *** Waiting for unfinished jobs kmk[3]: Leaving directory `/home/cknadle/src/LinuxDev/linux-3.6.11' kmk[3]: Entering directory `/home/cknadle/src/LinuxDev/linux-3.6.11' kmk[3]: *** Exiting with status 2 kmk[2]: *** [/home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci] Error 2 kmk[2]: Leaving directory `/home/cknadle/src/LinuxDev/linux-3.6.11' kmk[1]: *** [_module_/home/cknadle/src/LinuxDev/modules/virtualbox] Error 2 kmk[1]: Leaving directory `/home/cknadle/src/LinuxDev/linux-3.6.11' kmk: *** [binary-modules] Error 2 kmk: Leaving directory `/home/cknadle/src/LinuxDev/modules/virtualbox' make[1]: *** [kdist_build] Error 2 make[1]: Leaving directory `/home/cknadle/src/LinuxDev/modules/virtualbox' Module /home/cknadle/src/LinuxDev/modules/virtualbox failed. Hit return to Continue ... kmk[3]: Entering directory `/home/cknadle/src/LinuxDev/linux-3.7.4' LD /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/built-in.o CC [M] /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/linux/VBoxPci- linux.o CC [M] /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPci.o In file included from /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPciInternal.h:34:0, from /home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPci.c:38: include/linux/iommu.h: In function ‘iommu_group_alloc’: include/linux/iommu.h:272:2: error: implicit declaration of function ‘ERR_PTR’ [-Werror=implicit-function-declaration] include/linux/iommu.h:272:2: warning: return makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors kmk[3]: *** [/home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci/VBoxPci.o] Error 1 kmk[3]: *** Waiting for unfinished jobs kmk[3]: Leaving directory `/home/cknadle/src/LinuxDev/linux-3.7.4' kmk[3]: Entering directory `/home/cknadle/src/LinuxDev/linux-3.7.4' kmk[3]: *** Exiting with status 2 kmk[2]: *** [/home/cknadle/src/LinuxDev/modules/virtualbox/vboxpci] Error 2 kmk[2]: Leaving directory `/home/cknadle/src/LinuxDev/linux-3.7.4' kmk[1]: *** [_module_/home/cknadle/src/LinuxDev/modules/virtualbox] Error 2 kmk[1]: Leaving directory `/home/cknadle/src/LinuxDev/linux-3.7.4' kmk: *** [binary-modules] Error 2 kmk: Leaving directory `/home/cknadle/src/LinuxDev/modules/virtualbox' make[1]: *** [kdist_build] Error 2 make[1]: Leaving directory `/home/cknadle/src/LinuxDev/modules/virtualbox' Module /home/cknadle/src/LinuxDev/modules/virtualbox failed. Hit return to Continue -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696011: virtualbox: kernel modules fail to build against linux kernel v3.7
Hi. The current vbox-kompat-3.6-3.7.patch won't cleanly apply after the
virtualbox source package was updated for a CVE vulnerability, so I'm
attaching another version that does. This new patch doesn't change anything
else, so won't fix compiling virtualbox modules against Linux 3.8.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diff -Nru virtualbox-4.1.18-dfsg/debian/changelog virtualbox-4.1.18-dfsg/debian/changelog
--- virtualbox-4.1.18-dfsg/debian/changelog 2012-10-18 22:41:45.0 +0200
+++ virtualbox-4.1.18-dfsg/debian/changelog 2012-12-15 17:21:29.0 +0100
@@ -1,3 +1,11 @@
+virtualbox (4.1.18-dfsg-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * fix kernel module compilation against v3.6 and v3.7
+(closes: #696011).
+
+ -- aptosid aptosid@aptosid Sat, 15 Dec 2012 17:20:57 +0100
+
virtualbox (4.1.18-dfsg-2) unstable; urgency=high
[ John Paul Adrian Glaubitz ]
diff -Nru virtualbox-4.1.18-dfsg/debian/patches/37-kcompat-3.6.patch virtualbox-4.1.18-dfsg/debian/patches/37-kcompat-3.6.patch
--- virtualbox-4.1.18-dfsg/debian/patches/37-kcompat-3.6.patch 1970-01-01 01:00:00.0 +0100
+++ virtualbox-4.1.18-dfsg/debian/patches/37-kcompat-3.6.patch 2012-12-15 17:15:33.0 +0100
@@ -0,0 +1,21 @@
+Description: Fix module FTBFS with kernel 3.6.
+Author: Stefan Lippers-Hollmann s@gmx.de
+Bug-Debian: #696011
+
+partially backport upstream patches for kernel 3.6:
+
+r42784 | vboxsync | 2012-08-12 22:31:36 +0200 (So, 12. Aug 2012) | 2 Zeilen
+Linux 3.6-rc1 compile fix, spaces
+
+--- a/src/VBox/Additions/linux/drm/vboxvideo_drm.c
b/src/VBox/Additions/linux/drm/vboxvideo_drm.c
+@@ -103,7 +103,9 @@ static struct drm_driver driver =
+ {
+ /* .driver_features = DRIVER_USE_MTRR, */
+ .load = vboxvideo_driver_load,
++#if LINUX_VERSION_CODE KERNEL_VERSION(3, 6, 0)
+ .reclaim_buffers = drm_core_reclaim_buffers,
++#endif
+ /* As of Linux 2.6.37, always the internal functions are used. */
+ #if LINUX_VERSION_CODE KERNEL_VERSION (2, 6, 37) !defined(DRM_RHEL61)
+ .get_map_ofs = drm_core_get_map_ofs,
diff -Nru virtualbox-4.1.18-dfsg/debian/patches/38-kcompat-3.7.patch virtualbox-4.1.18-dfsg/debian/patches/38-kcompat-3.7.patch
--- virtualbox-4.1.18-dfsg/debian/patches/38-kcompat-3.7.patch 1970-01-01 01:00:00.0 +0100
+++ virtualbox-4.1.18-dfsg/debian/patches/38-kcompat-3.7.patch 2012-12-15 15:57:37.0 +0100
@@ -0,0 +1,55 @@
+Description: Fix module FTBFS with kernel 3.7.
+Author: Stefan Lippers-Hollmann s@gmx.de
+Bug-Debian: #696011
+
+backport upstream patches for kernel 3.7:
+
+r43637 | vboxsync | 2012-10-15 13:14:33 +0200 (Mo, 15. Okt 2012) | 2 Zeilen
+Linux 3.7 fixes
+
+r43674 | vboxsync | 2012-10-18 10:54:34 +0200 (Do, 18. Okt 2012) | 2 Zeilen
+configure: fix compilation test for Linux 3.7 headers
+
+--- a/Config.kmk
b/Config.kmk
+@@ -2550,7 +2550,11 @@ if1of ($(KBUILD_TARGET), linux)
+$(kernelpath)/include/asm-x86/mach-default \
+$(kernelpath)/arch/x86/include \
+$(kernelpath)/arch/x86/include/asm/mach-default \
++ $(kernelpath)/arch/x86/include/uapi \
+$(kernelpath)/arch/x86/include/generated \
++ $(kernelpath)/arch/x86/include/generated/uapi \
++ $(kernelpath)/include/uapi \
++ $(kernelpath)/include/generated/uapi \
+$(kernelpath)/include
+ endif
+ endif
+--- a/configure
b/configure
+@@ -1614,7 +1614,8 @@ EOF
+ cat $ODIR.tmp_src.c $LOG
+ echo using the following command line: $LOG
+ echo $CC -O -Wall -o $ODIR.tmp_out $ODIR.tmp_src.c -nostdinc -I$LINUX/include $LOG
+- $CC -O -Wall -o $ODIR.tmp_out $ODIR.tmp_src.c -nostdinc -I$LINUX/include $LOG 21
++ $CC -O -Wall -o $ODIR.tmp_out $ODIR.tmp_src.c -nostdinc -I$LINUX/include \
++ -I$LINUX/include/generated/uapi $LOG 21
+ if [ $? -ne 0 ]; then
+ echo
+ echo Linux kernel headers not found at $LINUX
+--- a/src/VBox/Runtime/r0drv/linux/memobj-r0drv-linux.c
b/src/VBox/Runtime/r0drv/linux/memobj-r0drv-linux.c
+@@ -1448,7 +1448,13 @@ DECLHIDDEN(int) rtR0MemObjNativeMapUser(
+
+ #if defined(VBOX_USE_INSERT_PAGE) LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
+ rc = vm_insert_page(vma, ulAddrCur, pMemLnxToMap-apPages[iPage]);
+-vma-vm_flags |= VM_RESERVED; /* This flag helps making 100% sure some bad stuff wont happen (swap, core, ++). */
++/* Thes flags help making 100% sure some bad stuff wont happen (swap, core, ++).
++ * See remap_pfn_range() in mm/memory.c */
++#if LINUX_VERSION_CODE = KERNEL_VERSION(3, 7, 0)
++vma-vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
++#else
++vma-vm_flags |= VM_RESERVED;
++#endif
+ #elif LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 11)
+ rc = remap_pfn_range
Bug#691169: virtualbox kernel modules fail to build against linux kernel v3.{6,7}
Just want to note here that a patch for the virtualbox source package to modify the source to compile against Linux 3.7 is in #696011, curtesy of Stefan Lippers-Hollmann. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688634: roundcube sqlite - mysql transition hint
I'm also using roundcube-sqlite, so I'm going to have to deal with the transition to either roundcube-mysql or roundcube-pgsql. I found some hints from someone that did the transition from sqlite - mysql back in 2007: http://www.howtoforge.com/forums/showpost.php?p=70929postcount=3 Below I'm going to make some notes in []'s on indented lines to update a couple of the commands based on what I see. 7th May 2007, 07:46 aqua I tried updating the sqlite database in order for the new roundcube version to work work with the current release of roundcube. The original packager of this package used sqlite, not sqlite3. So excuting the above SQL statement didn't work. I didn't want to use sqlite or sqlite3, because I am much more comfortable with mysql. I will document here what i did to convert my sqlite database to mysql, so that myself and my customer don't lose our contacts, etc. This has another advantage also, which is that you don't accidently over wright you database when you upgrade, and you could use tools like phpmyadmin to administer your database. In theory an SQL dump from one database should be easily imported into another, but that is not the case. 1) Find your sqlite database, which lives in /home/admispconfig/ispconfig/web/roundcubemail [For Debian Squeeze the roundcube sqlite database is in: /var/lib/dbconfig-common/sqlite/roundcube/roundcube] 2) Install sqlite. sudo apt-get install sqlite 3) Dump the SQL, but only the insert-statements: sqlite sqlite.db .dump | grep 'INSERT INTO' sql.dump That should give you a file with bunch of insert statement. Now you have all your data. [sqlite roundcube .dump | fgrep 'INSERT INTO' sql.dump] 4) Look in the current roundcube directory. This should be a folder call SQL. In it should be a file called mysql.initial.sql. This file contains the information schema for mysql. 5) Create a new database from the ispconfig panel. Using phpmyadmin, upload mysql.initial.sql. This should setup your database. 6) Also using phpmyadmin, upload your sql.dump file. Now your database should contain all your data. I did have some difficulty with this step though, some lines from INSERT INTO identities lines would refuse to be inserted, because they would be missing a ') from the end of the line. If phpmyadmin throws and error, find the line and fix the mistake. There is no harm from reuploading the file again, ie your data won't be duplicated. 7) Until now, we haven't made any drastic changes to your roundcube installation. But we will, so make backups, especially your sqlite.db file. [s/sqlite.db/roundcube/] tbc... -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688634: roundcube sqlite - mysql transition hint
On Saturday, January 19, 2013 09:02:56, Holger Levsen wrote: Hi Chris, Hi Holger. thanks for your howto. Much appreciated! cheers, Holger It's a start. If I find anything better I'll be sure to pass it along. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691169: virtualbox-dkms: fails to build kernel-module with kernel 3.6.3
This is what I get when DKMS tries to build the module for Linux v3.7.1 built from the upstream linux-stable repo. git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git $ cat /var/lib/dkms/virtualbox/4.1.18/build/make.log DKMS make.log for virtualbox-4.1.18 for kernel 3.7.1-c2d-crk-1 (x86_64) Fri Dec 28 13:06:04 EST 2012 make: Entering directory `/home/cknadle/src/LinuxDev/linux-stable' LD /var/lib/dkms/virtualbox/4.1.18/build/built-in.o LD /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/built-in.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/SUPDrv.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/SUPDrvSem.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/alloc-r0drv.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/initterm-r0drv.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/memobj-r0drv.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/mpnotification-r0drv.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/powernotification-r0drv.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeMapUser’: /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1451:38: error: ‘VM_RESERVED’ undeclared (first use in this function) /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1451:38: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o] Error 1 make[1]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv] Error 2 make: *** [_module_/var/lib/dkms/virtualbox/4.1.18/build] Error 2 make: Leaving directory `/home/cknadle/src/LinuxDev/linux-stable' -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691535: undefined symbol: glPopClientAttrib
1.0.1c 10 May 2012) Text Talking did not fit (+11/-2): (+7.85938/-2.25). Scaling to 0.89. Text Whisper did not fit (+11/-2): (+7.85938/-2.25). Scaling to 0.89. ALSAAudioOutput: Destroyed AudioInput: 4 bits/s, 48000 hz, 480 sample CELT PulseAudio: Starting input alsa_input.pci-_00_05.0.analog-stereo 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 AudioInput: 4 bits/s, 48000 hz, 480 sample CELT 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 No GL-related errors, so I think we're clear with this fix AFAICT. :-) -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691535: mumble: diff for NMU version 1.2.3-349-g315b5f5-2.2
On Sunday, November 11, 2012 15:34:05, gregor herrmann wrote: Hi Ron, as discussed, I've now uploaded -2.2 with the -lGL patch to unstable. Debdiff of the actual upload attached for your convenience. Awesome. :-) Just a quick note: I just rebuilt the -2.2 with cowbuilder and tested the version on an i386 VM; looks great, no unexpected errors. [The G15Daemon error seems to be related to a Logitech G15 keyboard, which I don't use so I don't have the daemon for it installed or running. :-P] Thanks all. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691535: undefined symbol: glPopClientAttrib
On Friday, November 09, 2012 11:18:06, Ron wrote: On Thu, Nov 08, 2012 at 11:33:09PM -0500, Chris Knadle wrote: ... The fact that the /documentation/ is wrong or that the program doesn't follow what the documentation says -- yes I agree that needs fixing. That's not a fact, it's a failure on your part to comprehend what it does and/or how it works if you think that it is somehow wrong or inaccurate. And it's not an agreement, since nobody else has or is suggesting that the documentation or intended mode of use has any indication of being wrong. Both the documentation and 'program' look perfectly fine and they don't need fixing at all. They should work just peachy as is if the library wasn't fatally broken. Spreading your misunderstanding of them to other users however would very much be a new bug. Do not change the documentation of this - the only thing broken in respect to it would appear to be your rhetorical device. Regardless of my misunderstanding, I did agree that it should be fixed. The point that I was trying to make was that the current required LD_PRELOAD=libGL didn't match the documentation, and I also agreed with you that it wasn't sane to change the documentation to require having users do that. :-/ I don't think I was being at all unreasonable. When you focus on yelling at me in writing like the above, it really hurts my incentive to help you. it only works with /certain/ 3D games. For instance the FAQ states that on Windows it only works for 32-bit applications that use DirectX 9 or 10, and not 11: http://mumble.sourceforge.net/FAQ/English#The_overlay_does_not_work_in _game_X You're arguing that the reason it is broken on Debian is not because of the obvious missing DT_NEEDED bug -- but rather because the games that you like to play must have been using DirectX 11? /lol/ The above is a misinterpretation and seems quite disrespectful. You had a description of Mumble doing crazy overlay shit which made it seem like you might not be very familiar with the feature, so I tried to /help/ by explaining the behavior on Windows to explain it's behavior of where I see it work, and how often it does. Your reply twisted this attempt to help you into trying to make fun of me, and I really don't appreciate that. On Friday, November 09, 2012 21:58:28, Ron wrote: On Sat, Nov 10, 2012 at 02:30:03AM +0100, gregor herrmann wrote: On Fri, 09 Nov 2012 09:51:05 +1030, Ron wrote: ... The term trivial triggered me into trying it myself. I'd hoped so :) I've got a small mountain of backlog still to dig through right now, and this still isn't anywhere near the top of it just yet, so that's much appreciated! If you're overloaded and need help, it's much better to ask for it than to try to forcably push the work off on someone else. Please try to ask next time. of the LP bug and by Chris now. So the priority is probably fine. That kind of depends on whether it's considered acceptable for the mumble-overlay / preloading libmumble described in the README to be completely broken for Wheezy. Since that clearly can't work as it is documented if libmumble can't be loaded because of a broken DT_NEEDED. Ok, so the problem is not starting mumble itself, as reported by dkg, but mumble-overlay / preloading libmumble ... Yeah, he spotted one symptom, but that's not really the primary problem that he actually brought to light here. So I guess the two interesting questions remaining now are: - Does it actually work! It does. First time I've ever seen it work. I'm attaching the quilt patch I used to add the -lGL dependency in overlay_gl.pro. I then did: $ mumble-overlay armagetronad ... and the overlay shows up over the main screen of the game. [Armagetronad is a free light-cycle game vaguely similar from the movie Tron from 1982.] - and when do we want to upload it if it does ... We should probably also contact upstream about this too, because the latest version of mumble in upstream's Git repo doesn't have this fix. You should be able to do the preload trick from the README with any app that calls glXSwapBuffers(), and if you also set MUMBLE_OVERLAY_DEBUG=1 in your environment, it should bark a bunch of debug messages at you when it is doing things. If that works, we're looking good. If not, it might be back to the drawing board for a slightly different solution ... Looks like that works too: - $ export MUMBLE_OVERLAY_DEBUG=1 $ mumble-overlay armagetronad set MumbleOverlay: Mumble overlay library loaded MumbleOverlay: Iterating dlsym table 0x7f4a5b9e3348 0x7f4a5b9e36f0 39 MumbleOverlay: Original dlsym at 0x7f4a5b9e4030 MumbleOverlay: Request for symbol posix_memalign ((nil):0x7f4a5b9e4030) MumbleOverlay: Request for symbol memalign ((nil):0x7f4a5b9e4030) MumbleOverlay: Request for symbol malloc (0x7f4a5c8e29a8
Bug#675971: Bug#691098: unblock: mumble/1.2.3-349-g315b5f5-2.1 [pre-approval request]
On Monday, October 22, 2012 07:39:24, Julien Cristau wrote: On Mon, Oct 22, 2012 at 13:35:09 +0200, gregor herrmann wrote: On Mon, 22 Oct 2012 12:30:34 +0200, Julien Cristau wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I'd like to request a pre-approval for a future unblock of a not-yet-uploaded NMU of mumble. IMO the package needs to be in sid before we consider it. Thanks for your quick reply! I was under the impression that the release team prefers to assess the situation before an upload in more complicated situations, but I'm happy to upload the NMU to a DELAYED queue later today. I guess I don't consider this a complicated situation. Either the new version is ok, or we release without mumble. Neither the current version in sid nor the current version in wheezy are suitable anyway, AIUI. That's correct. The 348-1 currently in Wheezy will not build due to library changes in Wheezy, and the 349-2 in Sid cannot communicate with the existing Mumble userbase. Thanks much. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#618712: mv ASL-oct2010 ASL fix
Greetings. Bumped into this, as I'm taking an ASL class. When extracting the ASL lessons in the tar.gz file of https://launchpad.net/gally-asl the files extract into a ASL-oct2010/ directory. However gally expects this to be in a directory called ASL in either ~/.kde/share/apps/gally/ for just your user, or in /usr/share/kde4/apps/gally/ for installing system-wide. I've tested both, both seem to work. In other words, what's needed is to do: mv ASL-oct2010 ASL after extracting into one of the two locations above. I'll also make not that what the .tar.gz installs is fairly minimal -- signs for the alphabet, a few countries, and a few salutations. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: patches for fixing RC bug, intent to upload NMU
tags 675971 patch
thanks
Greetings.
CCing the tech-ctte and release-team, as the intent is to coordinate with both
for approval to upload this NMU.
Ron, I tried contacting you about a month ago but I haven't heard back from
you since the TC decision on Aug 30th. I tried contacting Thorvald (the only
other uploader) in early Sept (he is very busy so I knew this was a long shot)
and he replied that he wanted a few days to try to contact you, but I haven't
heard back from him since then either.
I contacted Gregor Hermann and with his help we created a minimal diff for a
new upload targeted for Wheezy, as requested in TC #682010. I'm posting it
here to give you a chance to review it if you wish. Unless you wish to
discuss it, this will be uploaded soon to a DELAYED/XX queue at which time
there will be an additional notification posted here.
Three patches attached:
mumble-celt.diff-- the fix for #675971
mumble-349-rules.diff -- (optional) fix debian/rules to remove the Ice/
directory in the 'clean' target to allow
repeat building
mumble-349-defuzz.diff -- (optional) Removes fuzz from two quilt patches
in the current package
Thanks.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diff -Nru mumble-1.2.3-349-g315b5f5/debian/changelog mumble-1.2.3-349-g315b5f5/debian/changelog
--- mumble-1.2.3-349-g315b5f5/debian/changelog 2012-07-08 13:42:05.0 -0400
+++ mumble-1.2.3-349-g315b5f5/debian/changelog 2012-10-04 21:03:18.0 -0400
@@ -1,3 +1,31 @@
+mumble (1.2.3-349-g315b5f5-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix Cannot communicate with the vast majority of Mumble servers due
+to lack of required baseline codec:
+re-enable using the bundled celt library:
+ debian/patches/series:
+ - add 07-use-embedded-celt-baseline patch
+ debian/patches/07-use-embedded-celt-baseline:
+ - build Celt 0.7.1 and not 0.11.0
+ debian/mumble.install:
+ - ship Celt 0.7.1 library from the embedded source
+ debian/rules:
+ - re-enable Celt using the bundled 0.7.1 version
+ debian/patches/20-add-opus-threshold-option:
+ - fix src/murmur/Meta.cpp to set default iOpusThreshold=100 to only
+ switch from Celt to Opus if 100% of connected clients support Opus
+ (instead of 1%)
+ - fix murmur.ini example for opusthreshold option to =100
+ (instead of =1)
+ - add #opusthreshold=100 comments to murmur.ini.system (shipped as
+ etc/mumble-server.ini) to match murmur.ini example
+Closes: #675971.
+This implements the TC decision in #682010.
+[Thanks to Gregor Hermann for his help and guidance.]
+
+ -- Christopher Knadle chris.kna...@coredump.us Thu, 04 Oct 2012 11:45:05 -0400
+
mumble (1.2.3-349-g315b5f5-2) unstable; urgency=low
* Drop the hard dep on boost-1.46, that's been removed now. Closes: #678759
diff -Nru mumble-1.2.3-349-g315b5f5/debian/mumble.install mumble-1.2.3-349-g315b5f5/debian/mumble.install
--- mumble-1.2.3-349-g315b5f5/debian/mumble.install 2012-07-08 13:42:05.0 -0400
+++ mumble-1.2.3-349-g315b5f5/debian/mumble.install 2012-10-04 21:02:08.0 -0400
@@ -1,6 +1,6 @@
release/mumble usr/bin/
release/libmumble.so* usr/lib/mumble/
-#release/libcelt0.so.?.?.? usr/lib/mumble/
+release/libcelt0.so.?.?.? usr/lib/mumble/
release/plugins/lib*.so usr/lib/mumble/
icons/mumble.xpm usr/share/pixmaps/
icons/mumble.svg usr/share/icons/hicolor/scalable/apps/
diff -Nru mumble-1.2.3-349-g315b5f5/debian/patches/07-use-embedded-celt-baseline mumble-1.2.3-349-g315b5f5/debian/patches/07-use-embedded-celt-baseline
--- mumble-1.2.3-349-g315b5f5/debian/patches/07-use-embedded-celt-baseline 1969-12-31 19:00:00.0 -0500
+++ mumble-1.2.3-349-g315b5f5/debian/patches/07-use-embedded-celt-baseline 2012-10-04 21:02:08.0 -0400
@@ -0,0 +1,13 @@
+# build and bundle in only celt 0.7.1 if celt is embedded
+--- a/main.pro
b/main.pro
+@@ -12,7 +12,8 @@
+ SUBDIRS *= speexbuild
+ }
+ !CONFIG(no-bundled-celt) {
+-SUBDIRS *= celt-0.7.0-build celt-0.11.0-build
++SUBDIRS *= celt-0.7.0-build
++SUBDIRS -= celt-0.11.0-build
+ }
+
+ CONFIG(opus) {
diff -Nru mumble-1.2.3-349-g315b5f5/debian/patches/20-add-opus-threshold-option mumble-1.2.3-349-g315b5f5/debian/patches/20-add-opus-threshold-option
--- mumble-1.2.3-349-g315b5f5/debian/patches/20-add-opus-threshold-option 2012-07-08 13:42:05.0 -0400
+++ mumble-1.2.3-349-g315b5f5/debian/patches/20-add-opus-threshold-option 2012-10-04 21:02:08.0 -0400
@@ -8,7 +8,7 @@
+# Amount of users with Opus support needed to force Opus usage, in percent.
+# 0 = Always enable Opus, 100 = enable Opus if it's supported by all clients.
-+#opusthreshold=1
++#opusthreshold=100
+
# Regular expression used to validate channel names
# (note that you
Bug#675971: #675971 -- are you willing to help?
Ron --- I know you'd like the celt 0.7.1 library to be removed from Wheezy. Are you willing to help put together an upload a new mumble package containing embedded celt 0.7.1 (as the tech-ctte has outlined) so that can happen? What version of mumble do you think is appropriate for this purpose? -- -- Chris Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
