Bug#1053674: RM: g3dviewer -- ROM; abandoned upstream; depends on gtk2
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:g3dviewer g3dviewer is dead upstream. It depends on gtk2 + libglade2 + libgtkglext1 - which are all deprecated. g3dviewer has no reverse dependencies and a low popcon. signature.asc Description: This is a digitally signed message part.
Bug#670796: dh-autoreconf: strange interaction with mkinstalldirs
Control: unblock 924973 by 670796 Control: unblock 1049821 by 670796 On Sunday, 29 April 2012 06:08:02 CEST Russ Allbery wrote: > I have a package (gnubg) which uses mkinstalldirs. After the first > build and clean cycle, mkinstalldirs has been deleted by > dh_autoreconf_clean. But then running autoreconf doesn't bring it > back, which means that the build fails. > > As near as I can tell, autoreconf updates mkinstalldirs if it exists, > but if it's been deleted, it doesn't copy it into the source tree, > which leads to build failures when the package is built twice in > sequence. As workaround, I am currently using following in g3dviewer: diff --git a/debian/rules b/debian/rules index 0ef8b15b5613ea736ecaaa72bc6b4b000de38017..a99803c6f7db41b04f40585e8095213a46da4850 100755 --- a/debian/rules +++ b/debian/rules @@ -7,8 +7,11 @@ export DEB_CPPFLAGS_MAINT_APPEND = -D_FILE_OFFSET_BITS=64 binary binary-arch binary-indep build build-arch build-indep clean install install-arch install-indep: dh $@ +override_dh_autoreconf: + dh_autoreconf -Xmkinstalldirs + override_dh_installdocs: dh_installdocs -A README NEWS TODO AUTHORS .PHONY: binary binary-arch binary-indep build build-arch build-indep clean install install-arch install-indep \ - override_dh_installdocs + override_dh_installdocs override_dh_autoreconf diff --git a/debian/source/options b/debian/source/options new file mode 100644 index ..039409ebff7151490cbd46057186153e1be682e4 --- /dev/null +++ b/debian/source/options @@ -0,0 +1 @@ +extend-diff-ignore = "(^|/)mkinstalldirs$" signature.asc Description: This is a digitally signed message part.
Bug#1049821: g3dviewer: Fails to build binary packages again after successful build
Control: merge 924973 1049821 On Wednesday, 16 August 2023 10:26:37 CEST you wrote: > This package fails to do build a binary-only build (not source) after a > successful build (dpkg-buildpackage ; dpkg-buildpackage -b). > > This is probably a clear violation of Debian Policy section 4.9 (clean > target), > but this is filed as severity:minor for now, because a discussion on > debian-devel showed that we might want to revisit the requirement of a working > 'clean' target. [...] > > /bin/bash: ../mkinstalldirs: No such file or directory Looks like #670796 (dh-autoreconf) which was reported against g3dviewer in #924973. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#967575: libg3d: depends on deprecated GTK 2
On Sunday, 23 July 2023 23:12:12 CEST Simon McVittie wrote: [...] > It builds successfully, but I'm intentionally not tagging this +patch > because I haven't confirmed that libg3d's gdk-pixbuf plugin still works > correctly with this change - please test carefully! Thanks for the patch. But you can test it by trying to open the attached file in g3dviewer. With the old version, you got a heightmap. But nothing will be loaded when your patch is applied. And since the functionality is gone, it might be better to simply remove the package libg3d-plugin-gdkpixbuf. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#1021862: mupen64plus: Backport SDL_SetVideoMode fix to Salsa
On Sunday, 16 October 2022 17:56:23 CEST Brendon wrote: > Oops. Consider me blind then. You can close this now. Sorry if this came across that way. I just wanted to let you confirm that this is the fix you are talking about. But it sounds like it is. Thanks, Sven signature.asc Description: This is a digitally signed message part.
Bug#1021862: mupen64plus: Backport SDL_SetVideoMode fix to Salsa
On Sunday, 16 October 2022 10:16:58 CEST you wrote: > Package: mupen64plus > Severity: important > X-Debbugs-Cc: ed7-aspire4...@hotmail.com > > mupen64plus is currently unusuable with the latest SDL (at least in bookworm). This is impossible. This package is a meta-package without dependency to SDL > > A fix has been patched into upstream: > https://github.com/mupen64plus/mupen64plus-core/pull/970 > > There are discussions of a new release: > https://github.com/mupen64plus/mupen64plus-core/issues/973 > but it's best to backport the patch to salsa for now just in case the > discussion goes nowhere. > > I don't know whether that alone fixes the problem though, but I'm pretty sure > it should still build. Can you please tell me what the difference is there to the version 2.5-9 of libmupen64plus2 [1] Kind regards, Sven https://tracker.debian.org/news/1372713/accepted-mupen64plus-core-25-9-source-into-unstable/ signature.asc Description: This is a digitally signed message part.
Bug#962582: libreoffice: Menu "Tools / Options..." doesn't open; the program freezes
On Thu, 05 Aug 2021 21:08:44 +0300 Teemu Likonen wrote: > I have more information about Libreoffice's freezes when "Tools / > Options..." is opened. There is "gpg" process running forever and taking > lots of CPU time. The "ps" command says that command line is: > > gpg --batch --no-sk-comments --status-fd 37 --no-tty --charset utf8 \ > --enable-progress-filter --exit-on-status-write-error --display :0 \ > --ttyname /dev/pts/0 --ttytype xterm-256color --logger-fd 41 \ > --with-colons --with-keygrip --list-secret-keys -- Can you run `sudo strace -p $PID_OF_GPG_PROCESS` to check if it tries to access a file and then fails doing that? If this is the case, please check with `ls -l /proc/$PID_OF_GPG_PROCESS/fd/`, which is the file behind the mentioned file descriptor in the strace output. If it is really failing because of this, please teardown the rules for apparmor with `sudo aa-teardown` and then restart libreoffice and try to go to the menu which was mentioned earlier. See also #955271 for a patch to /etc/./apparmor.d/usr.lib.libreoffice.program.soffice.bin and information how it will be fixed in future Debian versions Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#1011146: upgrade-system is marked for autoremoval from testing
On Thursday, 26 May 2022 08:38:04 CEST Ramon Fried wrote: > On Thu, 26 May 2022 09:31:00 +0300 > =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= > wrote: > > I'd really like to know how anyone could ever come to the conclusion > > that a package that has nothing to do with graphic drivers needs to be > > auto-removed. [...] > Same here: > > bitwise 0.43-1 is marked for autoremoval from testing on 2022-06-30 > > It (build-)depends on packages with these RC bugs: > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, > CVE-2022-28183, CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, > CVE-2022-28192 > https://bugs.debian.org/1011146 Seems to be a severe problem because even packages which only depend on debhelper were marked as auto-removal: https://sources.debian.org/src/ap51-flash/2022.0-1/debian/control/ So I would guess that (nearly) all maintainers received a lot of these mails one hour ago. But maybe it was just a temporary glitch Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#987529: buster-pu: package exactimage/1.0.2-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org X-Debbugs-CC: Moritz Mühlenhoff X-Debbugs-CC: Adrian Bunk Usertags: pu [ Reason ] The upload of openexr 2.2.1-4.1+deb10u1 to Debian Buster broke the build for pre-C++-11 packages which include the openexr headers. The build breaks with things like: In file included from /usr/include/c++/8/cstdint:35, from /usr/include/OpenEXR/ImfFrameBuffer.h:55, from /usr/include/OpenEXR/ImfInputFile.h:47, from codecs/openexr.cc:24: /usr/include/c++/8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. #error This file requires compiler and library support \ ^ The build system changes to switch from -std=gnu++98 to GCC-default from exactimage 1.0.2-8 was added to the Debian buster package to fix the FTBFS on buster. [ Impact ] Package fails to build under Debian Buster 10.6 (and newer) [ Tests ] The build was tested to verify that it actually builds now. Only minor tests were performed on the binaries to make sure that they don't immediately crash. [ Risks ] None known at the moment [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in stable [*] the issue is verified as fixed in unstable [ Other info ] See http://bugs.debian.org/968829 bug which was just recently re-opened for the regression in Debian Buster. I have not yet uploaded the change to stable but will do this after I get an approval for the attached change. Kind regards, Svendiff -Nru exactimage-1.0.2/debian/changelog exactimage-1.0.2/debian/changelog --- exactimage-1.0.2/debian/changelog 2019-02-03 17:49:58.0 +0100 +++ exactimage-1.0.2/debian/changelog 2021-04-25 07:57:10.0 +0200 @@ -1,3 +1,16 @@ +exactimage (1.0.2-1+deb10u1) buster; urgency=medium + + * debian/rules: +- Add -fpermissive to fix FTBFS due to missing C++11 "constexp" + * debian/patches: +- Add adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch, + added-fpermissive-where-currently-necessary.patch, + if-we-can-not-easily-use-the-input-module-name-for-C-FLAS.patch, + Updated-per-file-C-FLAGS-to-likely-final-delimiter.patch, + Fix build with C++11 and OpenEXR 2.5.x (Closes: #968829) + + -- Sven Eckelmann Sun, 25 Apr 2021 07:57:10 +0200 + exactimage (1.0.2-1) unstable; urgency=medium * New Upstream Version diff -Nru exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch --- exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch 1970-01-01 01:00:00.0 +0100 +++ exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch 2021-04-25 07:57:10.0 +0200 @@ -0,0 +1,38 @@ +From: rene +Date: Sun, 29 Sep 2019 19:42:13 + +Subject: * adapt for nicer per file _C*FLAGS per source input name + +Bug-Debian: https://bugs.debian.org/968580 +Origin: upstream, https://svn.exactcode.de/exact-image/trunk@2349 cfa9e8bd-72fe-0310-85ed-f28a7036cb6a +--- + api/Makefile | 2 +- + frontends/Makefile | 4 ++-- + 2 files changed, 3 insertions(+), 3 deletions(-) + +diff --git a/api/Makefile b/api/Makefile +index 243a27a..1240ab1 100644 +--- a/api/Makefile b/api/Makefile +@@ -9,7 +9,7 @@ CPPFLAGS += $(BARDECODEINCS) + LDFLAGS += $(BARDECODELIBS) + endif + +-objdir/api/api.o_CXXFLAGS := -fpermissive ++$(X_MODULE)/api.cc_CXXFLAGS := -fpermissive + + # we have an own install + _X_BUILD_IMPLICIT := $(_X_BUILD_IMPLICIT) +diff --git a/frontends/Makefile b/frontends/Makefile +index 875be16..3ebea5a 100644 +--- a/frontends/Makefile b/frontends/Makefile +@@ -15,7 +15,7 @@ DEPS = $(image_BINARY) $(codecs_BINARY) $(bardecode_BINARY) $(X_OUTARCH)/utility + CPPFLAGS += -I utility + #LDFLAGS += -lGL -lGLU -lglut -L/usr/X11/lib64 + +-objdir/frontends/bardecode.o_CXXFLAGS := -fpermissive +-objdir/frontends/econvert.o_CXXFLAGS := -fpermissive ++$(X_MODULE)/bardecode.cc_CXXFLAGS := -fpermissive ++$(X_MODULE)/econvert.cc_CXXFLAGS := -fpermissive + + include build/bottom.make diff -Nru exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch --- exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch 1970-01-01 01:00:00.0 +0100 +++ exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch 2021-04-25 07:57:10.0 +0200 @@ -0,0 +1,48 @@ +From: rene +Date: Sun, 29 Sep 2019 19:22:47 + +Subjec
Bug#982548: wpasupplicant: Missing support for WPA-EAP-SUITE-B(-192)
On Friday, 12 February 2021 09:48:12 CET Utkarsh Gupta wrote: > Hi Thorsten, [...] > Whilst working on the security update for stretch, do you think you > can accommodate this request for a bug fix as well? Unfortunately, it is not even fixed in unstable (2:2.9.0-17) nor experimental (2:2.9.0+git20200517+dd2daf0-1). So I not sure that LTS should do it before the wpasupplicant maintainers fixed it in the first place. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#982548: wpasupplicant: Missing support for WPA-EAP-SUI TE-B(-192)
Control: tags -1 - wontfix Control: reopen -1 On Fri, 12 Feb 2021 09:14:56 +0100 "Andrej Shadura" wrote: > Control: tag -1 wontfix > Control: fixed -1 2:2.6-4 [...] The version specified the first version where the problem was found. The problem was not fixed since then. Just tested it here with wpasupplicant 2:2.9.0-16. Line 6: invalid key_mgmt 'WPA-EAP-SUITE-B-192' Line 6: no key_mgmt values configured. Line 6: failed to parse key_mgmt 'WPA-EAP-SUITE-B-192'. Line 17: failed to parse network block. So I've just reopened the bug. And all affected versions are shown in this nice graph in the bug ticket. So as you you can see, the provided info even helps you to figure out what is affected - even when you will most likely fix only the problem for unstable. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#972651: buster-pu: package fastd/18-3+deb10u1
On Saturday, 24 October 2020 20:37:36 CET Adam D. Barratt wrote: > Please go ahead. Thanks, uploaded [1] with appended CVE in the changelog. Kind regards, Sven [1] https://release.debian.org/proposed-updates/buster_diffs/fastd_18-3+deb10u1.debdiff signature.asc Description: This is a digitally signed message part.
Bug#972651: buster-pu: package fastd/18-3+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
The new packet buffer code (and checks) in v20 revealed a long standing issue
in fastd: A buffer with an invalid packet will just leak.
This results in an assert with v20 and memory exhaustion in earlier versions.
While v21 (already in unstable) fixed it, the memory exhaustion is still a
problem for stable and oldstable.
[ Impact ]
The problem can be used to DoS a system. Only some handcrafted (invalid)
UDP packets have to be send to a server.
[ Tests ]
Tested on a server with an attacker which injects invalid packets on the
relevant UDP port. v20 "crashed" after a couple of packets. v18 (currently in
[old]stable) required a couple of minutes to exhaust all memory of the system.
Invalid packets can for example easily created using:
iperf -u -c target.server.example.net -p 1 -t 3000 -b 40M
The problem went completely away after v21 was installed or the proposed
upload from this ticket was installed.
The stability test of the fixed version is ongoing.
[ Risks ]
None known at the moment
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Other info ]
See http://bugs.debian.org/972521 for the unstable bug.
I have not yet uploaded the change to stable but will do this after I get an
approval for the attached change.
Kind regards,
Svendiff -Nru fastd-18/debian/changelog fastd-18/debian/changelog
--- fastd-18/debian/changelog 2018-01-08 20:48:21.0 +0100
+++ fastd-18/debian/changelog 2020-10-19 22:38:02.0 +0200
@@ -1,3 +1,12 @@
+fastd (18-3+deb10u1) buster; urgency=medium
+
+ * debian/patches:
+- Add 0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch,
+ Fix DoS'able memory leak when receiving too many invalid packets
+ (Closes: #972521)
+
+ -- Sven Eckelmann Mon, 19 Oct 2020 22:38:02 +0200
+
fastd (18-3) unstable; urgency=medium
* Update to new Debian policy and fix lintian problems.
diff -Nru fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch
--- fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch 1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch 2020-10-19 22:38:02.0 +0200
@@ -0,0 +1,43 @@
+From: Matthias Schiffer
+Date: Mon, 19 Oct 2020 21:08:16 +0200
+Subject: receive: fix buffer leak when receiving invalid packets
+
+For fastd versions before v20, this was just a memory leak (which could
+still be used for DoS, as it's remotely triggerable). With the new
+buffer management of fastd v20, this will trigger an assertion failure
+instead as soon as the buffer pool is empty.
+
+Origin: upstream, https://github.com/NeoRaider/fastd/commit/737925113363b6130879729cdff9ccc46c33eaea
+Bug-Debian: https://bugs.debian.org/972521
+---
+ src/receive.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/src/receive.c b/src/receive.c
+index 732d4a7..a3ecfe3 100644
+--- a/src/receive.c
b/src/receive.c
+@@ -186,6 +186,11 @@ static inline void handle_socket_receive_known(fastd_socket_t *sock, const fastd
+
+ case PACKET_HANDSHAKE:
+ fastd_handshake_handle(sock, local_addr, remote_addr, peer, buffer);
++ break;
++
++ default:
++ fastd_buffer_free(buffer);
++ pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
+ }
+ }
+
+@@ -211,6 +216,11 @@ static inline void handle_socket_receive_unknown(fastd_socket_t *sock, const fas
+
+ case PACKET_HANDSHAKE:
+ fastd_handshake_handle(sock, local_addr, remote_addr, NULL, buffer);
++ break;
++
++ default:
++ fastd_buffer_free(buffer);
++ pr_debug("received packet with invalid type from unknown address %I", remote_addr);
+ }
+ }
+
diff -Nru fastd-18/debian/patches/series fastd-18/debian/patches/series
--- fastd-18/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/series 2020-10-19 22:38:02.0 +0200
@@ -0,0 +1 @@
+0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch
signature.asc
Description: This is a digitally signed message part.
Bug#972652: stretch-pu: package fastd/18-2+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
The new packet buffer code (and checks) in v20 revealed a long standing issue
in fastd: A buffer with an invalid packet will just leak.
This results in an assert with v20 and memory exhaustion in earlier versions.
While v21 (already in unstable) fixed it, the memory exhaustion is still a
problem for stable and oldstable.
[ Impact ]
The problem can be used to DoS a system. Only some handcrafted (invalid)
UDP packets have to be send to a server.
[ Tests ]
Tested on a server with an attacker which injects invalid packets on the
relevant UDP port. v20 "crashed" after a couple of packets. v18 (currently in
[old]stable) required a couple of minutes to exhaust all memory of the system.
Invalid packets can for example easily created using:
iperf -u -c target.server.example.net -p 1 -t 3000 -b 40M
The problem went completely away after v21 was installed or the proposed
upload from this ticket was installed.
The stability test of the fixed version is ongoing.
[ Risks ]
None known at the moment
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Other info ]
See http://bugs.debian.org/972521 for the unstable bug.
I have not yet uploaded the change to stable but will do this after I get an
approval for the attached change.
Kind regards,
Svendiff -Nru fastd-18/debian/changelog fastd-18/debian/changelog
--- fastd-18/debian/changelog 2016-05-13 13:37:11.0 +0200
+++ fastd-18/debian/changelog 2020-10-19 22:42:50.0 +0200
@@ -1,3 +1,12 @@
+fastd (18-2+deb9u1) stretch; urgency=medium
+
+ * debian/patches:
+- Add 0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch,
+ Fix DoS'able memory leak when receiving too many invalid packets
+ (Closes: #972521)
+
+ -- Sven Eckelmann Mon, 19 Oct 2020 22:42:50 +0200
+
fastd (18-2) unstable; urgency=medium
* Fix operation under systemd (Closes: #823801).
diff -Nru fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch
--- fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch 1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch 2020-10-19 22:42:50.0 +0200
@@ -0,0 +1,43 @@
+From: Matthias Schiffer
+Date: Mon, 19 Oct 2020 21:08:16 +0200
+Subject: receive: fix buffer leak when receiving invalid packets
+
+For fastd versions before v20, this was just a memory leak (which could
+still be used for DoS, as it's remotely triggerable). With the new
+buffer management of fastd v20, this will trigger an assertion failure
+instead as soon as the buffer pool is empty.
+
+Origin: upstream, https://github.com/NeoRaider/fastd/commit/737925113363b6130879729cdff9ccc46c33eaea
+Bug-Debian: https://bugs.debian.org/972521
+---
+ src/receive.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/src/receive.c b/src/receive.c
+index 732d4a7..a3ecfe3 100644
+--- a/src/receive.c
b/src/receive.c
+@@ -186,6 +186,11 @@ static inline void handle_socket_receive_known(fastd_socket_t *sock, const fastd
+
+ case PACKET_HANDSHAKE:
+ fastd_handshake_handle(sock, local_addr, remote_addr, peer, buffer);
++ break;
++
++ default:
++ fastd_buffer_free(buffer);
++ pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
+ }
+ }
+
+@@ -211,6 +216,11 @@ static inline void handle_socket_receive_unknown(fastd_socket_t *sock, const fas
+
+ case PACKET_HANDSHAKE:
+ fastd_handshake_handle(sock, local_addr, remote_addr, NULL, buffer);
++ break;
++
++ default:
++ fastd_buffer_free(buffer);
++ pr_debug("received packet with invalid type from unknown address %I", remote_addr);
+ }
+ }
+
diff -Nru fastd-18/debian/patches/series fastd-18/debian/patches/series
--- fastd-18/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/series 2020-10-19 22:42:50.0 +0200
@@ -0,0 +1 @@
+0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch
signature.asc
Description: This is a digitally signed message part.
Bug#972521: fastd: DoS'able memory leak on invalid packets
Package: fastd
Severity: important
Version: 17-4
fastd doesn't free receive buffers for invalid packets. This can lead to
memory exhaustion or (with v20) to an assert. From the release text:
The new buffer management of fastd v20 revealed that received packets with
an
invalid type code were handled incorrectly, leaking the packet buffer. This
lead
to an assertion failure as soon as the buffer pool was empty, crashing
fastd.
Older versions of fastd are affected as well, but display a different
behaviour:
instead of crashing, the buffer leaks will manifest as a regular memory
leak.
This can still be used for Denial of Service attacks, so a patch for older
versions will be provided, for the case that users can't or do not want to
update to a newer version yet.
The fix can also be found inside the attached mail.
Kind regards,
Sven--- Begin Message ---
Faster than expected, there is a new release of fastd, fixing a critial
Denial of Service (fastd crash) vulnerability. All users of fastd v20 must
update.
In fastd v19 and older, the same vulnerablity exists, but exploiting it
will cause a memory leak rather than an instant crash. Users that can't or
do not want to update to v21 yet should apply the patch that is attached to
this mail.
The release notes can be found at:
https://fastd.readthedocs.io/en/stable/releases/v21.html
The new release can be obtained via Git from
https://github.com/NeoRaider/fastd
or as a tarball:
https://github.com/NeoRaider/fastd/releases/download/v21/fastd-21.tar.xz
SHA256: 942f33bcd794bcb8e19da4c30c875bdfd4d0f1c24ec4dcdf51237791bbfb0d4c
-- NeoRaider
From f6a2651fa91c472d04cb34264718f761669c8aa1 Mon Sep 17 00:00:00 2001
Message-Id:
From: Matthias Schiffer
Date: Mon, 19 Oct 2020 21:08:16 +0200
Subject: [PATCH] receive: fix buffer leak when receiving invalid packets
For fastd versions before v20, this was just a memory leak (which could
still be used for DoS, as it's remotely triggerable). With the new
buffer management of fastd v20, this will trigger an assertion failure
instead as soon as the buffer pool is empty.
(cherry picked from commit 737925113363b6130879729cdff9ccc46c33eaea)
---
src/receive.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/receive.c b/src/receive.c
index ba92802186fb..5696747162bd 100644
--- a/src/receive.c
+++ b/src/receive.c
@@ -170,6 +170,11 @@ static inline void handle_socket_receive_known(
case PACKET_HANDSHAKE:
fastd_handshake_handle(sock, local_addr, remote_addr, peer, buffer);
+ break;
+
+ default:
+ fastd_buffer_free(buffer);
+ pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
}
}
@@ -197,6 +202,11 @@ static inline void handle_socket_receive_unknown(
case PACKET_HANDSHAKE:
fastd_handshake_handle(sock, local_addr, remote_addr, NULL, buffer);
+ break;
+
+ default:
+ fastd_buffer_free(buffer);
+ pr_debug("received packet with invalid type from unknown address %I", remote_addr);
}
}
--
2.28.0
signature.asc
Description: OpenPGP digital signature
--- End Message ---
signature.asc
Description: This is a digitally signed message part.
Bug#951929: s3d: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'
On Sunday, 23 February 2020 09:07:09 CET Sven Eckelmann wrote: [...] > But I can confirm that the build breaks on sid with cmake 3.16.3-1 and libc6- > dev 2.29-10. I will poke around to find out why cmake isn't able anymore to > find libpthread.so and instead is trying (and failing) to do the build test > with libpthreads.so Ok, the problem was not pthread but sdl2. I've just scrolled over the relevant portion of the log. It seems like SDL2_INCLUDE_DIR is no longer set because it was moved to a path which is no longer searched by the cmake script. This should be easy to fix. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#951929: s3d: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'
On Sunday, 23 February 2020 08:28:53 CET Lucas Nussbaum wrote: > Source: s3d > Version: 0.2.2.1-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: buster sid > Usertags: ftbfs-20200222 ftbfs-buster Why was this marked for buster? This package version cannot be build for buster due to its build dependencies. But I can confirm that the build breaks on sid with cmake 3.16.3-1 and libc6- dev 2.29-10. I will poke around to find out why cmake isn't able anymore to find libpthread.so and instead is trying (and failing) to do the build test with libpthreads.so Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#949008: alfred ftbfs unknown type name ‘timestamp_t’
Control: tags -1 + patch On Wed, 15 Jan 2020 22:40:01 + peter green wrote: > alfred failed to build when binnmu'd for the libgps transition. > > > alfred-gpsd.c:85:3: error: unknown type name ‘timestamp_t’ [...] > > make[3]: *** [Makefile:87: alfred-gpsd.o] Error 1 Patch for this can be found at https://patchwork.open-mesh.org/patch/18070/ Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#936493: exactimage: Python2 removal in sid/bullseye
Thanks for the detailed information On Fri, 30 Aug 2019 07:16:43 + Matthias Klose wrote: [...] > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. The Python bindings are not really maintained much by upstream. It is possible to build the module for Python3 and I have placed the required changes for this in the Vcs debian/experimental branch. But there are still some problems in the way how the binary strings must be handled for two function (decodeImage, encodeImage). I hope to be able to discuss this with upstream. If upstream decides not to support python3 (or pyton at all), I might have to remove this package from Debian. But at the moment, there are now reverse dependencies to this package in Debian and the python-exactimage popcount is declining. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#927418: sysdig-dkms: Does not compile with Kernel 5.0 from Debian Experimental
Control: tag -1 + patch
On Fri, 19 Apr 2019 13:12:44 +0200 Axel Beckert wrote:
[...]
> DKMS make.log for sysdig-0.24.1 for kernel 5.0.0-trunk-amd64 (x86_64)
> Fri Apr 19 13:03:01 CEST 2019
> make: Entering directory '/usr/src/linux-headers-5.0.0-trunk-amd64'
> CC [M] /var/lib/dkms/sysdig/0.24.1/build/main.o
> CC [M] /var/lib/dkms/sysdig/0.24.1/build/dynamic_params_table.o
> CC [M] /var/lib/dkms/sysdig/0.24.1/build/fillers_table.o
> CC [M] /var/lib/dkms/sysdig/0.24.1/build/flags_table.o
> CC [M] /var/lib/dkms/sysdig/0.24.1/build/ppm_events.o
> /var/lib/dkms/sysdig/0.24.1/build/ppm_events.c: In function
> ‘ppm_copy_from_user’:
> /var/lib/dkms/sysdig/0.24.1/build/ppm_events.c:89:48: error: macro
> "access_ok" passed 3 arguments, but takes just 2
> if (likely(ppm_access_ok(VERIFY_READ, from, n)))
> ^
> In file included from
> /usr/src/linux-headers-5.0.0-trunk-common/include/linux/export.h:45,
> from
> /usr/src/linux-headers-5.0.0-trunk-common/include/linux/linkage.h:7,
> from
> /usr/src/linux-headers-5.0.0-trunk-common/arch/x86/include/asm/cache.h:5,
> from
> /usr/src/linux-headers-5.0.0-trunk-common/include/linux/cache.h:6,
> from
> /usr/src/linux-headers-5.0.0-trunk-common/include/linux/time.h:5,
> from
> /usr/src/linux-headers-5.0.0-trunk-common/include/linux/compat.h:10,
> from /var/lib/dkms/sysdig/0.24.1/build/ppm_events.c:12:
> /var/lib/dkms/sysdig/0.24.1/build/ppm_events.c:49:23: error: ‘access_ok’
> undeclared (first use in this function); did you mean ‘access_flags’?
The API incompatibilities with Linux 5.0 and 5.1 can be fixed with the
attached patch. It should now be possible to build the kernel module even
against Linux 5.3(-rc5).
Kind regards,
SvenFrom: Sven Eckelmann
Date: Fri, 30 Aug 2019 21:16:27 +0200
Subject: Fix build of sysdig-dkms against Linux 5.0-5.3 (Closes: #927418)
diff --git a/debian/patches/ftbfs-linux-5.0.patch b/debian/patches/ftbfs-linux-5.0.patch
new file mode 100644
index ..af8a22ceaaa77a5a92d8592595590b7cac6419e4
--- /dev/null
+++ b/debian/patches/ftbfs-linux-5.0.patch
@@ -0,0 +1,36 @@
+From: Colin Ian King
+Date: Thu, 31 Jan 2019 10:54:00 +
+Subject: Update for change to access_ok in Linux 5.0
+
+Linux 5.0 removed the 1st argument 'type' from the access_ok macro.
+Update the ppm_access_ok() macro to cater for this change for Linux
+5.0
+
+Bug: https://github.com/draios/sysdig/issues/1299
+sysdig-CLA-1.0-signed-off-by: Colin Ian King
+
+Signed-off-by: Colin Ian King
+
+Bug-Debian: https://bugs.debian.org/927418
+Origin: backport, https://github.com/draios/sysdig/commit/2c8f0263382bf64800faec5fba5cc3e005d9fb1e
+---
+ driver/ppm_events.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/driver/ppm_events.c b/driver/ppm_events.c
+index a101b7c..07c96c3 100644
+--- a/driver/ppm_events.c
b/driver/ppm_events.c
+@@ -46,7 +46,11 @@ or GPL2.txt for full copies of the license.
+ #ifdef access_ok_noprefault
+ #define ppm_access_ok access_ok_noprefault
+ #else
+-#define ppm_access_ok access_ok
++#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0)
++#define ppm_access_ok(type, addr, size) access_ok(type, addr, size)
++#else
++#define ppm_access_ok(type, addr, size) access_ok(addr, size)
++#endif
+ #endif
+
+ extern bool g_tracers_enabled;
diff --git a/debian/patches/ftbfs-linux-5.1.patch b/debian/patches/ftbfs-linux-5.1.patch
new file mode 100644
index ..77b39a6e39a9253fd76cea2d6d8c17a520b85e72
--- /dev/null
+++ b/debian/patches/ftbfs-linux-5.1.patch
@@ -0,0 +1,1594 @@
+From: Nathan Baker <7409217+natha...@users.noreply.github.com>
+Date: Thu, 23 May 2019 09:59:06 -0400
+Subject: Changes to build the kmod with 5.1 kernels [SMAGENT-1643] (#1413)
+
+[SMAGENT-1643] Changes to build the kmod with 5.1 kernels
+
+* The syscall_get_arguments function changed its parameters.
+* The mmap symbols changed header locations
+* Wrapped the kernel version check in a function
+
+Bug-Debian: https://bugs.debian.org/927418
+Origin: backport, https://github.com/draios/sysdig/commit/a6ab1e66fc05a02178e051ea2441633996d5871e
+---
+ driver/main.c | 21 ++-
+ driver/ppm.h | 2 +
+ driver/ppm_events.c | 47 ---
+ driver/ppm_fillers.c | 333 --
+ driver/ppm_flag_helpers.h | 3 +-
+ 5 files changed, 221 insertions(+), 185 deletions(-)
+
+diff --git a/driver/main.c b/driver/main.c
+index b2e320b..adce675 100644
+--- a/driver/main.c
b/driver/main.c
+@@ -216,6 +216,15 @@ do {\
+ pr_info(fmt, ##__VA_ARGS__); \
+ } while (0)
+
++inline void ppm_syscall_get_arguments(struct task_struc
Bug#938978: ITP: ap51-flash -- firmware flasher for ethernet connected routers and access points
Package: wnpp Severity: wishlist Owner: Sven Eckelmann X-Debbugs-CC: debian-de...@lists.debian.org * Package name: ap51-flash Version : 2019.0 Upstream Author : Marek Lindner * URL : https://github.com/ap51-flash/ap51-flash * License : GPL-3+ Programming Lang: C Description : firmware flasher for ethernet connected routers and access points ap51-flash is a tool to simplify the automatic firmware deployment for a multitude of home routers and wireless access points. . ap51-flash can identify target device(s), select the correct firmware image and perform the required communication to carry out the installation procedure. It works without the need for a local TFTP server or manual, target device specific network configuration. Note: The implementation currently only supports Architecture linux-any. But it should in theory be possible to port it to kfreebsd-any. signature.asc Description: This is a digitally signed message part.
Bug#928791: congress: FTBFS twice in a row: File exists: 'congress/tests/etc/keys'
Control: tag -1 + patch
Hi,
On Sat, 11 May 2019 11:34:23 +0200 Andreas Beckmann wrote:
[...]
> congress/experimental fails to build twice in a row:
>
> Traceback (most recent call last):
> File
> "/build/congress-9.0.0+dfsg1/congress/tests/api/test_datasource_model.py",
> line 45, in setUp
> self.ds_manager.add_datasource(self.datasource)
> File "/build/congress-9.0.0+dfsg1/congress/dse2/datasource_manager.py",
> line 71, in add_datasource
> secret_config_fields=driver_info.get('secret', []))
> File "/usr/lib/python3/dist-packages/tenacity/__init__.py", line 241, in
> wrapped_f
> return self.call(f, *args, **kw)
[...]
> FileExistsError: [Errno 17] File exists: 'congress/tests/etc/keys'
Seems like the package (or the pkg utilities) currently doesn't clean up in
the clean target. Interestingly, even dpkg-source currently fails after a
build finished. This is caused by following extra files/directories
* Congress.tokens
* build
* */__pycache__/
* congress/tests/etc/keys
The dpkg-source configuration of this package (debian/source/options)
currently ignores a lot of debian specific files. It would maybe make sense to
also to ignore __pycache__ this way.
build and Congress.tokens are part of the build and can just be cleaned using
dh_clean's debian/clean
congress/tests/etc/keys is slightly more interesting. It is part of the files
generated by the test suite. So congress/tests/api/test_datasource_model.py's
setUp() method could be changed to take care of this. But I am not familiar
with this package. But to fix the FTBS "twice in a row" problem, it is enough
to also delete the test artifact during clean.
Even when this patch is currently formatted like a NMU, it is not part of an
actual NMU.
Kind regards,
Svendiff -Nru congress-9.0.0+dfsg1/debian/changelog congress-9.0.0+dfsg1/debian/changelog
--- congress-9.0.0+dfsg1/debian/changelog 2019-07-17 15:31:05.0 +0200
+++ congress-9.0.0+dfsg1/debian/changelog 2019-08-28 21:53:11.0 +0200
@@ -1,3 +1,12 @@
+congress (9.0.0+dfsg1-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS twice in a row (Closes: #928791).
+- Ignore __pycache__ artifacts during dpkg-source.
+- Clean build and test artifacts.
+
+ -- Sven Eckelmann Wed, 29 Aug 2019 18:00:41 +0200
+
congress (9.0.0+dfsg1-3) unstable; urgency=medium
* Uploading to unstable.
diff -Nru congress-9.0.0+dfsg1/debian/clean congress-9.0.0+dfsg1/debian/clean
--- congress-9.0.0+dfsg1/debian/clean 1970-01-01 01:00:00.0 +0100
+++ congress-9.0.0+dfsg1/debian/clean 2019-08-28 21:38:13.0 +0200
@@ -0,0 +1,3 @@
+Congress.tokens
+build/
+congress/tests/etc/keys/
diff -Nru congress-9.0.0+dfsg1/debian/source/options congress-9.0.0+dfsg1/debian/source/options
--- congress-9.0.0+dfsg1/debian/source/options 2019-07-17 15:31:05.0 +0200
+++ congress-9.0.0+dfsg1/debian/source/options 2019-08-28 21:40:12.0 +0200
@@ -1,3 +1,4 @@
extend-diff-ignore = "^[^/]*[.]egg-info/"
extend-diff-ignore = "^congress/datalog/CongressParser.py"
extend-diff-ignore = "^congress/datalog/CongressLexer.py"
+extend-diff-ignore = "/__pycache__/"
signature.asc
Description: This is a digitally signed message part.
Bug#922767: libemf : FTBFS - mv: cannot stat 'refman.pdf': No such file or directory -
On Wed, 20 Feb 2019 13:51:13 +0100 "Thierry fa...@linux.ibm.com"
wrote:
[...]
> Current compilation fails with message
>
> /This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live
> 2019/dev/Debian) (preloaded format=pdflatex) restricted \write18
> enabled. entering extended mode (./refman.tex LaTeX2e <2018-12-01> mv:
> cannot stat 'refman.pdf': No such file or directory make[2]: ***
> [Makefile:870: doxygen-doc/libemf.pdf] Error 1 make[2]: Leaving
> directory '/<>' dh_auto_build: make -j4 all doxygen-doc
> doxygen-pdf returned exit code 2 make[1]: *** [debian/rules:13:
> override_dh_auto_build] Error 2/
>
> The command pdflatext refman.tex fails according to refman.log
> ! Misplaced \cr.
> \cr
>
> l.46 \end{DoxyParams}
[...]
I wanted to check this problem and cannot reproduce this problem. A quick
search revealed that this is most likely related to #920621. This also seems
to be reflected in the FTBFS reports from the reproducible-builds [1]. They
failed after the 2019-01-30 but started to work again after the upload of
texlive-extra 2018.20190227-1.
Can you please check again. I would assume this can be reassigned after
confirmation to texlive-latex-extra:
reassign 922767 texlive-latex-extra
forcemerge 920621 922767
affects 922767 src:libemf
thanks
Kind regards,
Sven
[1] https://tests.reproducible-builds.org/debian/history/libemf.html
signature.asc
Description: This is a digitally signed message part.
Bug#721410: PPC / ARM ?
On Saturday, 31 August 2013 12:17:12 CEST you wrote: > Package: mupen64plus-core > > As per release: > > http://code.google.com/p/mupen64plus/wiki/ReleasePage > > Makefiles: support for ARM, PPC, and MINGW architectures I just checked the 2.5.9 release and arm + PPC are still not officially supported. I was hoping that at least armhf is now considered working. I will close this for now with the option that armhf could be added (because it should have been matured) after testing. PPC (actually all big endian) still seems to be some bigger problem. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#711774: CVE-2015-3885
On Thursday, 4 June 2015 17:41:01 CEST you wrote: > I can drop the dcraw support in exactimage. But I want to avoid shipping > libraw patches which are not accepted by upstream and then give me even more > problems with René. The different view on libraw vs. dcraw couldn't be solved with upstream (yet). I will close this ticket for now but in case someone wants to spend time on it, the package is currently marked as RFA (because I don't use it anymore myself). Thanks, Sven signature.asc Description: This is a digitally signed message part.
Bug#806219: Build mupen64plus-ui-console everywhere
On Thursday, 26 November 2015 11:20:07 CEST you wrote: [...] > But my offer to add Mathieu Malaterre and/or Sérgio Benjamim when they want to > maintain the "not officially supported" armhf architecture in Debian is still > open. I've just uploaded the mupen64plus* packages to the pkg-games > (Debian Games Team) git repositories to have everything under the same team > umbrella. > > Just tell me and I merge the branch armhf_test in all repositories and add the > voluntaril(y|ies) to the uploaders. The offer to add another architecture based on the test code wasn't pursued. I will close this ticket now because the original request was not possible to fulfill in a sensible way. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#924973: g3dviewer: 'debian/rules clean' after build causes removal of mkinstalldirs
On Tuesday, 19 March 2019 11:30:07 CET Andreas Beckmann wrote: [...] > g3dviewer/experimental fails to build twice in a row. The first build > succeeds, but during subsequent debian/rules clean the following files > disappear: [...] > causing the second build to fail: > > [...] > Making install in po > make[4]: Entering directory '/build/g3dviewer-0.2.99.5~svn130/po' > if test -r ".././mkinstalldirs"; then \ > .././mkinstalldirs > /build/g3dviewer-0.2.99.5~svn130/debian/g3dviewer/usr/share; \ > else \ > /bin/bash ../mkinstalldirs > /build/g3dviewer-0.2.99.5~svn130/debian/g3dviewer/usr/share; \ > fi > /bin/bash: ../mkinstalldirs: No such file or directory > make[4]: *** [Makefile:136: install-data-yes] Error 127 > make[4]: Leaving directory '/build/g3dviewer-0.2.99.5~svn130/po' > [...] > > There is no explicit deletion command being shown during make distclean. > Full buildlog attached. Looks like dh-autoreconf (used by debhelper by default) bug #670796. Also disabling it doesn't really work here because we need the autoreconf stuff - and using --without autoreconf and then calling it explicitly in a subdirectory caused #924756. Kind regards, Sven [1] https://bugs.debian.org/670796 signature.asc Description: This is a digitally signed message part.
Bug#921121: 60.5.0esr-1~deb9u1 breaks Netflix playback
On Friday, 1 February 2019 21.15.13 CET Kathryn Tolsen wrote:
> Package: firefox-esr
> Version: 60.5.0esr-1~deb9u1
>
> Last night I upgraded and now it shows me a yellow banner saying "Firefox
> is installing components needed to play the audio or video on this page.
> Please wait." I waited about 20min, reloaded the page, still wouldn't work.
> I removed firefox-esr and manually downloaded and installed the last update
Problem is here that the wrong version of widevine is installed for
firefox-esr 60.5.0. You can manually fix this by downloading (please check the
in-sources list for non-x64 binary urls [1] on in firefox using
the URL chrome://global/content/gmp-sources/widevinecdm.json ):
#check first what your profile is called and manually save it as
$firefox_profile
ls -ld ~/.mozilla/firefox/*.default
mkdir test
cd test
wget
https://redirector.gvt1.com/edgedl/widevine-cdm/4.10.1196.0-linux-x64.zip
unzip 4.10.1196.0-linux-x64.zip
rm -rf "${firefox_profile}"/gmp-widevinecdm/*
mkdir "${firefox_profile}"/gmp-widevinecdm/1.4.8.1008/
cp libwidevinecdm.so LICENSE.txt manifest.json "${firefox_profile}"/gmp-
widevinecdm/1.4.8.1008/
After doing that, you can just go to https://demo.castlabs.com/ and play one
of the DRM versions. I have also verified this with netflix and some known DRM
shows on tvnow.de.
It is currently unknown to me why the browser still downloads 1.4.8.1008. Even
when removing my .mozilla directory. Is this inserted by some external
service which still thinks that 60.x.0 is compatible to 1.4.8.1008 and not to
4.10.1196.0? I would therefore guess that the aus service of Mozilla is broken
https://aus5.mozilla.org/update/3/GMP/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/
%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/
update.xml
In my case it is https://aus5.mozilla.org//update/3/GMP/60.5.0/20190130005301/
Linux_x86_64-gcc3/null/default/Linux%204.19.0-1-
amd64%20(GTK%203.24.4%2Clibpulse%2012.2.0)/default/default/update.xml and it
really references the wrong widevine version.
Does anyone know how to contact the admins of this service?
Kind regards,
Sven
[1] https://salsa.debian.org/mozilla-team/firefox/blob/
04bf94636bc267e2835ce35975feac8dd1f51a13/toolkit/content/gmp-sources/
widevinecdm.json
signature.asc
Description: This is a digitally signed message part.
Bug#911072: RFS: batctl/2018.4-2~bpo9+1 [BPO]
retitle 911072 RFS: batctl/2018.4-2~bpo9+1 [BPO] thanks On Monday, 15 October 2018 12:41:22 CET Sven Eckelmann wrote: [...] > I am looking for a sponsor for my backport of package "batctl" for > stretch-backports. It is required to use the netlink batadv commands > which were introduced with newer kernel version. There were multiple members > of the Freifunk community which observed this problem when they either used a > newer backports kernel or when they've build the external batman-adv > 2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an > example from yesterday: [...] I am still waiting for a sponsor. But the version 2018.4-2 migrated to testing and thus I would like to also update this RFS. Here is the updated information about the package: * Package name: batctl Version : 2018.4-2~bpo9+1 Upstream Author : Marek Lindner * URL : https://www.open-mesh.org/ * License : GPL-2 Section : net It builds those binary packages: batctl - B.A.T.M.A.N. advanced control and management tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/batctl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2018.4-2~bpo9+1.dsc More information about batctl can be obtained from https://open-mesh.org/. Changes since the last upload (stretch 2016.5-1): batctl (2018.4-2~bpo9+1) stretch-backports; urgency=medium . * Rebuild for stretch-backports. . batctl (2018.4-2) unstable; urgency=medium . * debian/patches: - Add batctl-Fix-parsing-of-optional-debug-table-command-parame.patch, Fix parsing of optional debug table command parameters . batctl (2018.4-1) unstable; urgency=medium . * New Upstream Version * debian/rules: - drop old config symbol CONFIG_BATCTL_BISECT - Enable new config symbol CONFIG_bisect_iv . batctl (2018.3-2) unstable; urgency=medium . * Upgraded to policy 4.2.1 - remove get-orig-source rule from debian/rules * debian/rules - Drop (now default) parameter --parallel for dch - Use pkg-info.mk to add the package version as internal batctl version . batctl (2018.3-1) unstable; urgency=medium . * New Upstream Version . batctl (2018.2-1) unstable; urgency=medium . * New Upstream Version . batctl (2018.1-1) unstable; urgency=medium . * New Upstream Version . batctl (2018.0-1) unstable; urgency=medium . * New Upstream Version * debian/control - Change Vcs-Git and Vcs-Browser to salsa.debian.org * debian/copyright: - Update copyright years - Adjust license of batman_adv.h . batctl (2017.4-1) unstable; urgency=medium . * New Upstream Version * Upgraded to policy 4.1.2 - Switch from priority extra to optional * Change documentation filename to README.rst * Change changelog filename to CHANGELOG.rst . batctl (2017.3-1) unstable; urgency=medium . * New Upstream Version * Upgraded to policy 4.0.1.0 - Switch from priority extra to optional * debian/patches: - Remove upstream merged batctl-Fix-error-message-when-traceroute-packet-send-fail.patch . batctl (2017.2-2) unstable; urgency=medium . * Upload to unstable * debian/patches: - Add batctl-Fix-error-message-when-traceroute-packet-send-fail.patch, Fix error message when traceroute packet send failed . batctl (2017.2-1) experimental; urgency=medium . * New Upstream Version * debian/control: - update to debhelper 10 * Upgraded to policy 4.0.0, no changes required * debian/rules - Remove ddeb migration conflict against pre-stretch package . batctl (2017.1-1) experimental; urgency=medium . * New Upstream Version . batctl (2017.0-1) experimental; urgency=medium . * New Upstream Version * debian/copyright: - Update copyright years The full upstream changelog can be found at https://git.open-mesh.org/batctl.git/blob/HEAD:/CHANGELOG.rst (or in the package under /usr/share/doc/batctl/changelog.gz) The source package has not change beside the debian/changelog. Regards, Sven Eckelmann signature.asc Description: This is a digitally signed message part.
Bug#911072: RFS: batctl/2018.4-1~bpo9+1 [BPO]
retitle 911072 RFS: batctl/2018.4-1~bpo9+1 [BPO] thanks On Monday, 15 October 2018 12:41:22 CET Sven Eckelmann wrote: [...] > I am looking for a sponsor for my backport of package "batctl" for > stretch-backports. It is required to use the netlink batadv commands > which were introduced with newer kernel version. There were multiple members > of the Freifunk community which observed this problem when they either used a > newer backports kernel or when they've build the external batman-adv > 2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an > example from yesterday: [...] I am still waiting for a sponsor. But the version 2018.4-1 migrated to testing and thus I would like to also update this RFS. Here is the updated information about the package: * Package name: batctl Version : 2018.4-1~bpo9+1 Upstream Author : Marek Lindner * URL : https://www.open-mesh.org/ * License : GPL-2 Section : net It builds those binary packages: batctl - B.A.T.M.A.N. advanced control and management tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/batctl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2018.4-1~bpo9+1.dsc More information about batctl can be obtained from https://open-mesh.org/. Changes since the last upload (stretch 2016.5-1): batctl (2018.4-1~bpo9+1) stretch-backports; urgency=medium . * Rebuild for stretch-backports. . batctl (2018.4-1) unstable; urgency=medium . * New Upstream Version * debian/rules: - drop old config symbol CONFIG_BATCTL_BISECT - Enable new config symbol CONFIG_bisect_iv . batctl (2018.3-2) unstable; urgency=medium . * Upgraded to policy 4.2.1 - remove get-orig-source rule from debian/rules * debian/rules - Drop (now default) parameter --parallel for dch - Use pkg-info.mk to add the package version as internal batctl version . batctl (2018.3-1) unstable; urgency=medium . * New Upstream Version . batctl (2018.2-1) unstable; urgency=medium . * New Upstream Version . batctl (2018.1-1) unstable; urgency=medium . * New Upstream Version . batctl (2018.0-1) unstable; urgency=medium . * New Upstream Version * debian/control - Change Vcs-Git and Vcs-Browser to salsa.debian.org * debian/copyright: - Update copyright years - Adjust license of batman_adv.h . batctl (2017.4-1) unstable; urgency=medium . * New Upstream Version * Upgraded to policy 4.1.2 - Switch from priority extra to optional * Change documentation filename to README.rst * Change changelog filename to CHANGELOG.rst . batctl (2017.3-1) unstable; urgency=medium . * New Upstream Version * Upgraded to policy 4.0.1.0 - Switch from priority extra to optional * debian/patches: - Remove upstream merged batctl-Fix-error-message-when-traceroute-packet-send-fail.patch . batctl (2017.2-2) unstable; urgency=medium . * Upload to unstable * debian/patches: - Add batctl-Fix-error-message-when-traceroute-packet-send-fail.patch, Fix error message when traceroute packet send failed . batctl (2017.2-1) experimental; urgency=medium . * New Upstream Version * debian/control: - update to debhelper 10 * Upgraded to policy 4.0.0, no changes required * debian/rules - Remove ddeb migration conflict against pre-stretch package . batctl (2017.1-1) experimental; urgency=medium . * New Upstream Version . batctl (2017.0-1) experimental; urgency=medium . * New Upstream Version * debian/copyright: - Update copyright years The full upstream changelog can be found at https://git.open-mesh.org/batctl.git/blob/HEAD:/CHANGELOG.rst (or in the package under /usr/share/doc/batctl/changelog.gz) The source package has not change beside the debian/changelog. Regards, Sven Eckelmann signature.asc Description: This is a digitally signed message part.
Bug#911072: retitle to RFS: batctl/2018.3-1~bpo8+1 [BPO]
On Tuesday, 30 October 2018 16:30:23 CET Bart Martens wrote: > retitle 911072 RFS: batctl/2018.3-1~bpo8+1 [BPO] > stop > > I see that the package at mentors has version 2018.3-1~bpo8+1 > so I retitle the RFS to match that version. This was wrong. The version on mentors was 2018.3-1~bpo9+1 (like you can also see in the link). The ticket 911071 was about the other backport (which was closed later because jessie-backports-sloppy is now closed). Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#911071: RFS: batctl/2018.3-1~bpo8+1 [BPO]
On Mon, 15 Oct 2018 12:41:15 +0200 Sven Eckelmann wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my backport of package "batctl" for > jessie-backports-sloppy. It is required to use the netlink batadv commands > which were introduced with newer kernel version. There were multiple members > of the Freifunk community which observed this problem when they either used a > newer backports kernel or when they've build the external batman-adv > 2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an > example from yesterday: [...] Closing this because jessie-backports-sloppy seems to have been closed (even when jessie LTS is still active) and uploads to it are rejected now. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#911071: RFS: batctl/2018.3-1~bpo8+1 [BPO]
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my backport of package "batctl" for
jessie-backports-sloppy. It is required to use the netlink batadv commands
which were introduced with newer kernel version. There were multiple members
of the Freifunk community which observed this problem when they either used a
newer backports kernel or when they've build the external batman-adv
2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an
example from yesterday:
https://zerobin.fff.community/?ae8511ae06bb09c0#0FvEHmbKsRIQhTsIfhs87iRSbJMtorJ+LRup0N2oz6o=
can anyone help me, why i can't look in he dat table?
ChristianD: is bat0 up ?
and is also ichtostVPN up?
yes and yews
it works fine
the complete mesh works fine, but i can't look into the dat
table
ChristianD: looks like you are using a batctl version which cannot
talk via netlink to batman-adv
(at least not to the dat cache)
please update to at least batctl 2018.1
or enable debugfs again in batman-adv
I am the current maintainer (with Simon) of batctl in Debian. And I also did
the jessie-backports uploads in the past. But this upload must now go through
NEW (tested this because I was not sure) and thus I need a sponsor for that.
* Package name: batctl
Version : 2018.3-1~bpo8+1
Upstream Author : Marek Lindner
* URL : https://www.open-mesh.org/
* License : GPL-2
Section : net
It builds those binary packages:
batctl - B.A.T.M.A.N. advanced control and management tool
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/batctl
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2018.3-1~bpo8+1.dsc
More information about batctl can be obtained from https://open-mesh.org/.
Changes since the last upload (jessie-backports 2018.0-1~bpo8+1):
batctl (2018.3-1~bpo8+1) jessie-backports-sloppy; urgency=medium
.
* Rebuild for jessie-backports-sloppy.
.
batctl (2018.3-1) unstable; urgency=medium
.
* New Upstream Version
.
batctl (2018.2-1) unstable; urgency=medium
.
* New Upstream Version
.
batctl (2018.1-1~bpo8+1) jessie-backports; urgency=medium
.
* Rebuild for jessie-backports.
.
batctl (2018.1-1) unstable; urgency=medium
.
* New Upstream Version
The full upstream changelog can be found at
https://git.open-mesh.org/batctl.git/blob/HEAD:/CHANGELOG.rst (or in the
package under /usr/share/doc/batctl/changelog.gz)
Regards,
Sven Eckelmann
signature.asc
Description: This is a digitally signed message part.
Bug#911072: RFS: batctl/2018.3-1~bpo9+1 [BPO]
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my backport of package "batctl" for
stretch-backports. It is required to use the netlink batadv commands
which were introduced with newer kernel version. There were multiple members
of the Freifunk community which observed this problem when they either used a
newer backports kernel or when they've build the external batman-adv
2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an
example from yesterday:
https://zerobin.fff.community/?ae8511ae06bb09c0#0FvEHmbKsRIQhTsIfhs87iRSbJMtorJ+LRup0N2oz6o=
can anyone help me, why i can't look in he dat table?
ChristianD: is bat0 up ?
and is also ichtostVPN up?
yes and yews
it works fine
the complete mesh works fine, but i can't look into the dat
table
ChristianD: looks like you are using a batctl version which cannot
talk via netlink to batman-adv
(at least not to the dat cache)
please update to at least batctl 2018.1
or enable debugfs again in batman-adv
I am the current (with Simon) maintainer of batctl in Debian. And I also did
the jessie-backports uploads in the past. But this upload must now go through
NEW (tested this because I was not sure) and thus I need a sponsor for that.
* Package name: batctl
Version : 2018.3-1~bpo9+1
Upstream Author : Marek Lindner
* URL : https://www.open-mesh.org/
* License : GPL-2
Section : net
It builds those binary packages:
batctl - B.A.T.M.A.N. advanced control and management tool
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/batctl
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2018.3-1~bpo9+1.dsc
More information about batctl can be obtained from https://open-mesh.org/.
Changes since the last upload (stretch 2016.5-1):
batctl (2018.3-1~bpo9+1) stretch-backports; urgency=medium
.
* Rebuild for stretch-backports.
.
batctl (2018.3-1) unstable; urgency=medium
.
* New Upstream Version
.
batctl (2018.2-1) unstable; urgency=medium
.
* New Upstream Version
.
batctl (2018.1-1) unstable; urgency=medium
.
* New Upstream Version
.
batctl (2018.0-1) unstable; urgency=medium
.
* New Upstream Version
* debian/control
- Change Vcs-Git and Vcs-Browser to salsa.debian.org
* debian/copyright:
- Update copyright years
- Adjust license of batman_adv.h
.
batctl (2017.4-1) unstable; urgency=medium
.
* New Upstream Version
* Upgraded to policy 4.1.2
- Switch from priority extra to optional
* Change documentation filename to README.rst
* Change changelog filename to CHANGELOG.rst
.
batctl (2017.3-1) unstable; urgency=medium
.
* New Upstream Version
* Upgraded to policy 4.0.1.0
- Switch from priority extra to optional
* debian/patches:
- Remove upstream merged
batctl-Fix-error-message-when-traceroute-packet-send-fail.patch
.
batctl (2017.2-2) unstable; urgency=medium
.
* Upload to unstable
* debian/patches:
- Add batctl-Fix-error-message-when-traceroute-packet-send-fail.patch,
Fix error message when traceroute packet send failed
.
batctl (2017.2-1) experimental; urgency=medium
.
* New Upstream Version
* debian/control:
- update to debhelper 10
* Upgraded to policy 4.0.0, no changes required
* debian/rules
- Remove ddeb migration conflict against pre-stretch package
.
batctl (2017.1-1) experimental; urgency=medium
.
* New Upstream Version
.
batctl (2017.0-1) experimental; urgency=medium
.
* New Upstream Version
* debian/copyright:
- Update copyright years
The full upstream changelog can be found at
https://git.open-mesh.org/batctl.git/blob/HEAD:/CHANGELOG.rst (or in the
package under /usr/share/doc/batctl/changelog.gz)
Regards,
Sven Eckelmann
signature.asc
Description: This is a digitally signed message part.
Bug#878572: Bug#895511: exactimage FTBFS with libevas-dev 1.20.7
On Donnerstag, 12. April 2018 19:21:14 CEST Andreas Metzler wrote: > So I do not expect efl to change back, re-introducing an optional > unfavoured API. This sounded differently in October 2017 [1]. But ok, please close the libevas-dev bug (#878572). We will most likely drop exactimage from Debian. Kind regards, Sven [1] https://sourceforge.net/p/enlightenment/mailman/message/36077810/ signature.asc Description: This is a digitally signed message part.
Bug#895511: exactimage FTBFS with libevas-dev 1.20.7
severity 878572 serious block 895511 by 878572 thanks On Donnerstag, 12. April 2018 11:08:47 CEST Adrian Bunk wrote: > Source: exactimage > Version: 1.0.1-1 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exactimage.html Thanks for bringing this up again. This is a long standing bug in libevas-dev. Increasing the severity for the libevas-dev bug now because they have uploaded the problematic version to unstable without fixing it. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#883882: libg3d FTCBFS: fails running libg3d-scan
On Freitag, 8. Dezember 2017 21:00:27 CET Helmut Grohne wrote: > Source: libg3d > Version: 0.0.8-22 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > libg3d fails to cross build from source, because the build fails running > libg3d-scan. This tool is part of the documentation build. Fortunately, > the documentation resides in an arch:all package, so we don't actually > need to build it during cross builds. Passing --disable-gtk-doc when no > arch:all packages are built fixes the cross build. Please consider > applying the attached patch. Sorry, this doesn't work: libg3d-doc: lintian output: 'no-copyright-file ', automatically rejected package. libg3d-doc: lintian output: 'empty-binary-package ', automatically rejected package. libg3d-doc: If you have a good reason, you may override this lintian tag. signature.asc Description: This is a digitally signed message part.
Bug#878572: exactimage: FTBFS in experimental: gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file or directory
severity 878572 normal thanks The broken [1] libevas-dev package has (luckily) not yet hit unstable. exactimage should therefore not yet be removed from testing for a FTBFS which neither happens in testing nor unstable. Kind regards, Sven [1] it now misses things which were previously present (+ required by edisplay) and its pkg-config files list more dependencies than the debian package (#878584) signature.asc Description: This is a digitally signed message part.
Bug#878584: [libevas-dev] Missing dependency for libecore-dev
Package: libevas-dev Version: 1.20.4-1 Severity: important pkg-config calls for evas currently fail with: $ pkg-config --cflags evas Package ecore was not found in the pkg-config search path. Perhaps you should add the directory containing `ecore.pc' to the PKG_CONFIG_PATH environment variable Package 'ecore', required by 'evas', not found The relevant line in evas.pc is: Requires.private: libpng >= 1.2.10 harfbuzz >= 0.9.0 fribidi >= 0.19.2 fontconfig >= 2.5.0 freetype2 >= 16.2.10 ecore >= 1.20.4 ector >= 1.20.4 emile >= 1.20.4 efl >= 1.20.4 eina >= 1.20.4 eet >= 1.20.4 eo >= 1.20.4 luajit >= 2.0.0 The libecore-dev dependency (and maybe more) is not reflected in the debian package dependencies. This causes build failures for other packages which depend on libevas-dev but not on libecore-dev. signature.asc Description: This is a digitally signed message part.
Bug#878572: exactimage: FTBFS in experimental: gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file or directory
On Samstag, 14. Oktober 2017 10:28:39 CEST Ross Vandegrift wrote: [...] > exactimage fails to build against EFL 1.20 from experimental: > > In file included from gfx/X11Helper.cc:36:0: > gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file > or directory > #include "Evas_Engine_Software_X11.h" > ^~~~ > compilation terminated. > make[3]: *** [objdir/gfx/X11Helper.o] Error 1 > build/bottom.make:54: recipe for target 'objdir/gfx/X11Helper.o' failed > make[3]: *** Waiting for unfinished jobs > edisplay/edisplay.cc:25:10: fatal error: Evas_Engine_Software_X11.h: No such > file or directory > #include "Evas_Engine_Software_X11.h" > ^~~~ > compilation terminated. > make[3]: *** [objdir/edisplay/edisplay.o] Error 1 > build/bottom.make:54: recipe for target 'objdir/edisplay/edisplay.o' failed Looks like evas was build without software-x11 backend support. Was this planned by the libevas-dev maintainers? Shouldn't this reported to them? edisplay requires this and can currently not used without it. So it would basically mean that this package has to be removed. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves
On Montag, 24. Juli 2017 16:34:34 CEST Ben Hutchings wrote: [...] > > Downgrading the kernel from linux-image-4.11.0-2-amd64 (4.11.11-1+b1) to > > linux-image-4.11.0-1-amd64 (4.11.6-1) fixed this. I wonder if the stack > > clash fix has broken ASan. > > The address space change that went into 4.11.11-1 and might have > triggered this is "binfmt_elf: use ELF_ET_DYN_BASE only for PIE" (CVE- > 2017-1000370, CVE-2017-1000371). This moved PIEs to lower addresses on > x86 (starting at 0x40 on i386 and 0x1 on amd4) while > keeping the dynamic linker in the mmap area. It seems like the behavior will be reverted [1] in the kernel and no change in GCC is necessary at the moment. Kind regards, Sven [1] https://lkml.kernel.org/r/20170807201542.GA21271@beast signature.asc Description: This is a digitally signed message part.
Bug#866868: [kjots] Fails to start via krunner or kde menu
Package: kjots Version: 4:5.0.1-2+b1 Severity: important Tags: patch stretch krunner and the KDE menu use the /usr/share/applications/org.kde.kjots.desktop file when the application has to be started. The most important part here is the Exec line: Exec=kjots -caption %d But this already shows the problem. kjots doesn't have a caption parameter and will therefore exit immediately with Unknown options: c, a, p, t, i, o, n. The correct Exec line must therefore be: Exec=kjots -qwindowtitle %c Please cherry pick this change from https://github.com/KDE/kjots/commit/d536dbdf606d18baa437d03a9852fa6bb7289953 and fix the problem in stretch. --- System information. --- Architecture: Kernel: Linux 4.9.0-3-amd64 Debian Release: 9.0 500 stable-debugdebug.mirrors.debian.org 500 stable httpredir.debian.org --- Package information. --- Depends(Version) | Installed -+-=== akonadi-server | 4:16.04.3-4 kio | 5.28.0-2 libc6 (>= 2.14) | libgcc1 (>= 1:3.0) | libgrantlee-templates5(>= 5.0.0) | libgrantlee-textdocument5 (>= 5.0.0) | libkf5akonadicore5(>= 4:15.12.0) | libkf5akonadinotes5(>= 15.07.90) | libkf5akonadiwidgets5 (>= 15.07.90) | libkf5bookmarks5 (>= 4.96.0) | libkf5configcore5(>= 4.98.0) | libkf5configgui5 (>= 4.97.0) | libkf5configwidgets5 (>= 4.96.0) | libkf5coreaddons5 (>= 4.100.0) | libkf5i18n5 (>= 4.97.0) | libkf5itemmodels5(>= 4.96.0) | libkf5kcmutils5 (>= 5.2.0+git20141003) | libkf5kiowidgets5(>= 4.96.0) | libkf5kontactinterface5 | libkf5mime5(>= 15.07.90) | libkf5parts5 (>= 4.96.0) | libkf5pimtextedit5 (>= 15.07.90) | libkf5textwidgets5(>= 5.1.0) | libkf5widgetsaddons5 (>= 4.96.0) | libkf5xmlgui5(>= 4.98.0) | libqt5core5a (>= 5.7.0) | libqt5dbus5 (>= 5.0.2) | libqt5gui5(>= 5.7.0) | libqt5printsupport5 (>= 5.0.2) | libqt5widgets5 (>= 5.2.0~alpha1) | libstdc++6(>= 4.1.1) | Package's Recommends field is empty. Package's Suggests field is empty. signature.asc Description: This is a digitally signed message part.
Bug#866706: [src:linux] ideapad_laptop: persistent rfkill on Lenovo V510-15IKB
tags 866706 + patch thanks On Samstag, 1. Juli 2017 08:18:40 CEST Sven Eckelmann wrote: [...] > But the problem is that the this device doesn't have an hardware rfkill > switch. The current workaround on Stretch is to unload the ideapad_laptop > module on this Laptop. I've submitted a patch to the kernel as https://patchwork.kernel.org/patch/9820729/. I've originally tested this with the kernel from Debian Stretch. But the version submitted to the kernel developers is based on * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e297046875f2c5a43684f54f0fd098249b4f293a * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f3bc53d843f92d6e7e7cf56ee79acec918e6421 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccc7179f4d9467947c94f4302d61cd5143842fcd * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9f40b56630a8702b5f7a61a770f9b73aa07464 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f2fe205c3b9b595dc50ee431230a45d03f9c2c These other patches basically fix the same problem for other models. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#866706: [src:linux] ideapad_laptop: persistent rfkill on Lenovo V510-15IKB
Package: src:linux Version: 4.9.30-2 Severity: normal Tags: stretch The ideapad_laptop module prevents the usage of WLAN. It assumes that the hardware rfkill switch is always active. 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 6: ideapad_wlan: Wireless LAN Soft blocked: no Hard blocked: yes 7: ideapad_bluetooth: Bluetooth Soft blocked: yes Hard blocked: yes Network-Manager will then disable the wifi functionality. And even when enabling the wifi functionality, network manager will not scan. But the problem is that the this device doesn't have an hardware rfkill switch. The current workaround on Stretch is to unload the ideapad_laptop module on this Laptop. --- System information. --- Architecture: Kernel: Linux 4.9.0-3-amd64 Debian Release: 9.0 500 stable-debugdebug.mirrors.debian.org 500 stable httpredir.debian.org 1 stable www.deb-multimedia.org signature.asc Description: This is a digitally signed message part.
Bug#833703: php5-exactimage: encodeImage() and encodeImageFile() segfault
tags 833703 + wontfix
tags 833703 - jessie
thanks
Hi,
The package is waiting for adoption - just in case you are interested.
On Montag, 8. August 2016 08:38:42 CET Sven Eckelmann wrote:
> > It seems that encodeImage() and encodeImageFile() don't work and produce a
> > segfault.
> >
> > $ php -d enable_dl=1 -r 'dl("ExactImage.so"); $im = null;
> > decodeImageFile($im, "/tmp/test.jpg"); encodeImage($im, "jpeg");'
> > PHP Fatal error: No matching function for overloaded 'encodeImage' in
> > Command line code on line 1
> > [1]29888 segmentation fault php -d enable_dl=1 -r
Not sure why you are doing it this way but this is wrong :)
Please try:
php -d enable_dl=1 -r 'dl("ExactImage.so"); $im = newImage();
decodeImageFile($im, "/tmp/test.jpg"); encodeImageFile($im, "/tmp/2.jpg", 75);'
or
php -d enable_dl=1 -r 'dl("ExactImage.so"); $im = newImage();
decodeImageFile($im, "/tmp/test.jpg"); encodeImage($im, "jpeg");'
> This package was removed in Stretch/Sid. So it would be good to discuss this
> with upstream. See your other bug report #833702.
I will now close this bug because the package doesn't exist in stretch
and your code is doing something wrong. I know that this is maybe not
really the way you expect the API should react to bogus inputs but fixing
the API is work for upstream.
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
Bug#843801: RFA: exactimage -- fast image manipulation programs
Package: wnpp Severity: normal X-Debbugs-CC: exact-im...@exactcode.de I request an adopter for the exactimage package. The package description is: ExactImage is a fast C++ image processing library. Unlike many other library frameworks it allows operation in several color spaces and bit depths natively, resulting in low memory and computational requirements. It would be best if someone actually using this package could take over its maintenance. signature.asc Description: This is a digitally signed message part.
Bug#842376: RFS: batctl/2016.4-1~bpo8+1 [BPO]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my backport of package "batctl" for jessie-backports. It is required to support the new tables added in recent Linux versions. It is also required to use the netlink batadv commands which were introduced with Linux 4.9. I was asked to do this backport by different Freifunk Communities. I am the current maintainer of batctl in Debian. * Package name: batctl Version : 2016.4-1~bpo8+1 Upstream Author : Marek Lindner <mareklind...@neomailbox.ch> * URL : https://www.open-mesh.org/ * License : GPL-2 Section : net It builds those binary packages: batctl - B.A.T.M.A.N. advanced control and management tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/batctl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2016.4-1~bpo8+1.dsc More information about batctl can be obtained from https://open-mesh.org/. Changes since the last upload (jessie 2014.3.0-2): batctl (2016.4-1~bpo8+1) jessie-backports; urgency=medium . * Rebuild for jessie-backports. . batctl (2016.4-1) unstable; urgency=medium . * New Upstream Version * debian/patches: - Remove upstream merged batctl-Fix-minor-typos-in-manpage.patch, batctl-Fix-unknown-macro-.Pp-in-manpage.patch . batctl (2016.3-1) unstable; urgency=medium . * New Upstream Version * debian/control - Add new dependency libnl-genl-3-dev * debian/copyright: - Add new files and copyright holders * debian/rules: - install CHANGELOG * debian/patches: - batctl-Fix-minor-typos-in-manpage.patch, Fix minor typos in manpage - batctl-Fix-unknown-macro-.Pp-in-manpage.patch, Fix unknown macro .Pp in manpage . batctl (2016.2-1) unstable; urgency=medium . * New Upstream Version * Download snapshots via https:// in debian/get-orig-source.sh * Reference repository only over https:// in debian/upstream/metadata * Upgraded to policy 3.9.8, no changes required . batctl (2016.1-1) unstable; urgency=medium . * New Upstream Version * Upgraded to policy 3.9.7, no changes required . batctl (2016.0-2) unstable; urgency=medium . * debian/control - Change Vcs-Git and Vcs-Browser to https:// * Change debian URLs to https:// * debian/upstream/signing-key.asc - Import new upstream RSA 4096 key 2DE9541A85CC87D5D9836D5E0C8A47A2ABD72DF9 * Sort debian control files with `wrap-and-sort -abst` . batctl (2016.0-1) unstable; urgency=medium . * New Upstream Version * Override the lintian warning about missing upstream changelog * Update copyright years in debian/copyright . batctl (2015.2-2) unstable; urgency=medium . * Switch upstream URLs to https:// * debian/control, debian/rules: - Drop batctl-dbg in favor of -dbgsym package . batctl (2015.2-1) unstable; urgency=medium . * New Upstream Version . batctl (2015.1-1) unstable; urgency=medium . * New Upstream Version . batctl (2015.0-2) unstable; urgency=medium . * Upload to unstable for Linux 3.16-4.1 . batctl (2015.0-1) experimental; urgency=medium . * New Upstream Version * Update years in debian/copyright . batctl (2014.4.0-1) experimental; urgency=medium . * New Upstream Version * Upgraded to policy 3.9.6, no changes required * Update years in debian/copyright * debian/patches: - Remove upstream merged manpage-hyphen-used-as-minus-sign.patch Regards, Sven Eckelmann signature.asc Description: This is a digitally signed message part.
Bug#833703: php5-exactimage: encodeImage() and encodeImageFile() segfault
tags 833703 + jessie
thanks
On Montag, 8. August 2016 14:28:36 CEST bohwaz wrote:
> Package: php5-exactimage
> Version: 0.8.9-7+deb8u2
> Severity: important
>
> Me again, sorry :)
>
> It seems that encodeImage() and encodeImageFile() don't work and produce a
> segfault.
>
> $ php -d enable_dl=1 -r 'dl("ExactImage.so"); $im = null;
> decodeImageFile($im, "/tmp/test.jpg"); encodeImage($im, "jpeg");'
> PHP Fatal error: No matching function for overloaded 'encodeImage' in
> Command line code on line 1
> [1]29888 segmentation fault php -d enable_dl=1 -r
>
> I'm attaching the strace.
This package was removed in Stretch/Sid. So it would be good to discuss this
with upstream. See your other bug report #833702.
I will close it right away because I may still want to have a look at it.
Maybe it is so trivial that it can be backported to Jessie.
Btw. a full backtrace would be more interesting when something crashes :)
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
Bug#833702: php5-exactimage: Duplicate function names between ExactImage and GD
tags 833702 + wontfix thanks On Montag, 8. August 2016 14:13:43 CEST bohwaz wrote: [...] > Not sure if this is something that should be reported upstream too. This package was removed in Stretch/Jessie. So this should be discussed with upstream. And I doubt that such a change can be backported to Jessie since it is really invasive. I will close it therefore in Debian. I have forwarded your bug report to upstream. Maybe you can discuss it there [1]. Kind regards, Sven [1] https://exactcode.com/opensource/exactimage/ search for "mailing list" signature.asc Description: This is a digitally signed message part.
Bug#833254: [python3-aiohttp] Fails to decompress HTTP bodies
Package: python3-aiohttp Version: 0.22.4-1 Severity: normal It looks like this version isn't able to parse the HTTP response headers correctly to detect the Content-Encoding for gzip compressed bodies. This causes problems like: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte when the caller tries to decode the (still gzip compressed) body as utf-8. This problem was introduced by v0.21.5-104-g7374777 [1] and is fixed in v0.22.4-54-g8145024 [2] Kind regards, Sven [1] https://github.com/KeepSafe/aiohttp/commit/73747771135bc50b67b13a9a9257f0eafb6d370a [2] https://github.com/KeepSafe/aiohttp/commit/81450244d05ec04884cdafc74fc927514eb5302a --- System information. --- Architecture: amd64 Kernel: Linux 4.6.0-1-amd64 Debian Release: stretch/sid 500 unstablehttpredir.debian.org 500 testing httpredir.debian.org 500 stable dl.google.com 1 unstablewww.deb-multimedia.org 1 experimentalhttpredir.debian.org --- Package information. --- Depends(Version) | Installed -+-=== python3 (<< 3.6) | 3.5.1-4 python3(>= 3.5~) | 3.5.1-4 python3-chardet | 2.3.0-2 python3-multidict| 2.0.0-1 python3:any(>= 3.4~) | libc6 (>= 2.4) | Package's Recommends field is empty. Package's Suggests field is empty. signature.asc Description: This is a digitally signed message part.
Bug#802174: ITP: batman-adv-kernelland -- source for the batman-advanced kernel module
On Sonntag, 18. Oktober 2015 02:48:24 CEST you wrote: [..] > * Package name: batman-adv-kernelland > Version : 2013.4.0 > * URL : http://www.open-mesh.net/ > * License : GPL > Programming Lang: C > Description : source for the batman-advanced kernel module > > This package provides the source code for the batman-adv-source kernel > modules. Kernel source or headers are required to compile these > modules. [...] Please don't reintroduce this package. It was removed in #627413 [1] after the linux(-2.6) maintainer Ben Hutchings requested its removal, The removal was justified by the integration in the mainline kernel. You also want to package a version which is ~3 years old. batman-adv had 11 releases since then as external module (backport) and 14 releases inside the linux kernel. Several rather bad problems were fixed in the meantime (and backported to older kernel versions by the awesome linux-stable maintainers). If you really, really, really, really, really, ... want to add something like batman-adv-legacy [2] (and no one else objects) then please do not use the names "batman-adv-kernelland", "batman-adv-dkms" and "batman-adv-source". It is rather confusing to have a module in Debian which overwrites the in-kernel one with a version that is really old and known to miss a lot of fixes. And about the fixes. Maybe someone interested in batman-adv-legacy could go through the maintenance patches [3,4,5,6,7,8,9,10,11,12,13,14,15] first and backport them. And please don't use the URL http://www.open-mesh.net/. The upstream homepage is https://www.open-mesh.org/ and I think batman-adv-legacy uses https://github.com/freifunk-gluon/batman-adv-legacy Kind regards, Sven [1] https://bugs.debian.org/627413 [2] https://github.com/freifunk-gluon/batman-adv-legacy [3] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/net/batman-adv?h=linux-3.12.y=fa59cdc603bfe56ab060084edbf3cab30f1ef7a7..linux-3.12.y [4] https://git.open-mesh.org/batman-adv.git/shortlog/135602880b28bc7cf12c60fec550a6122851f2e9?hp=v2013.4.0 [5] https://git.open-mesh.org/batman-adv.git/shortlog/15fb0fab51a3695738f65dfaab045e979fc89dce?hp=v2014.0.0 [6] https://git.open-mesh.org/batman-adv.git/shortlog/b53915310227cc9b029ba0fa5aae44e50a461f80?hp=v2014.1.0 [7] https://git.open-mesh.org/batman-adv.git/shortlog/21fa2647ad4547a48da1166a8fa2f951cd7163e2?hp=v2014.2.0 [8] https://git.open-mesh.org/batman-adv.git/shortlog/7d28d37061fe1ce8866e84a14806a92a5d3abf11?hp=v2014.4.0 [9] https://git.open-mesh.org/batman-adv.git/shortlog/7ad001a18d1a6e2fd19969fdd671efe99d75920f?hp=v2015.0 [10] https://git.open-mesh.org/batman-adv.git/shortlog/5019fc0faac0d8f0b377dbc7d27a3899c45237c3?hp=v2015.1 [11] https://git.open-mesh.org/batman-adv.git/shortlog/cee103946bb05db00e351cf8b5dee9c8aed8d5f8?hp=v2015.2 [12] https://git.open-mesh.org/batman-adv.git/shortlog/22d98bd45c01e978c9ae439b7d9d1f3c3c65b102?hp=v2016.0 [13] https://git.open-mesh.org/batman-adv.git/shortlog/f8fd441e1e30f3a274c9bf44cc33372d4065cbb6?hp=v2016.1 [15] https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/maint?hp=v2016.2 signature.asc Description: This is a digitally signed message part.
Bug#580872: [debian-maintainers] Annual ping for Sven Eckelmann
My last years annual ping wasn't processed yet. I will use this bug for my new annual ping. My contact information is now Sven Eckelmann <s...@narfation.org> with keyid 0xEC371482956781AF I am currently maintaining: * batctl [DM] * batmand [DM] * exactimage [DM] * g3dviewer [DM] * libg3d [DM] * mupen64plus [DM] * mupen64plus-audio-sdl [DM] * mupen64plus-core [DM] * mupen64plus-input-sdl [DM] * mupen64plus-rsp-hle [DM] * mupen64plus-rsp-z64 [DM] * mupen64plus-ui-console [DM] * mupen64plus-video-arachnoid [DM] * mupen64plus-video-glide64 [DM] * mupen64plus-video-glide64mk2 * mupen64plus-video-rice [DM] * mupen64plus-video-z64 [DM] * s3d [DM] > Sven Eckelmann wrote: > [...] > > > I was approved in bug #526484. signature.asc Description: This is a digitally signed message part.
Bug#815788: jessie-pu: package exactimage/0.8.9-7+deb8u2
On Wednesday 23 March 2016 21:27:02 Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2016-02-24 at 14:10 +0100, Sven Eckelmann wrote: > > I'd like to upload a new version of exactimage to stable/jessie. > > > > The exactimage package version in jessie is 0.8.9-7+deb8u1 at the moment. > > It was noticed that it is also affected by the security issue described > > in CVE-2015-8366 [1] (no-DSA [2]). This issue was resolved in > > libraw/jessie by an upload via jessie-pu [3]. > > Please go ahead. Uploaded. Thanks, Sven signature.asc Description: This is a digitally signed message part.
Bug#809647: batmand: please remove me from maintainers
tags 809647 + pending thanks On Saturday 02 January 2016 11:59:32 you wrote: > please remove me from the Maintainers: field of batmand, I haven't done much > (anything?) on it since 2009 or so and you are nicely taking care of it > anyway. Ok, the change is queued for 0.3.2-17. It can be found in the git repository as a0042c7e38233b0ffe0a02d9936be0a78dd406a5 Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#807500: [redmine] wiki page redirects cause redmine 500 error
Package: redmine Version: 3.0~20140825-5 Severity: normal Tags: patch jessie X-Debbugs-CC: s...@simonwunderlich.de We've just noticed "Redmine 500 errors" whenever someone tries to access a page which should be redirected to a different page. This happens always with the Debian Jessie version of Redmine. Internal error An error occurred on the page you were trying to access. If you continue to experience problems please contact your Redmine administrator for assistance. If you are the Redmine administrator, check your log files for details about the error. I have now modified the find_existing_or_new_page to use project_wiki_page_path for the redirect. This was enough to fix it here when logged in or logged out. You can find the modification in the attached patch. --- System information. --- Architecture: amd64 Kernel: Linux 4.2.0-1-amd64 Debian Release: stretch/sid 500 unstablehttpredir.debian.org diff --git a/app/controllers/wiki_controller.rb b/app/controllers/wiki_controller.rb index d6670e9..2515194 100644 --- a/app/controllers/wiki_controller.rb +++ b/app/controllers/wiki_controller.rb @@ -327,7 +327,7 @@ private def find_existing_or_new_page @page = @wiki.find_or_new_page(params[:id]) if @wiki.page_found_with_redirect? - redirect_to params.update(:id => @page.title) + redirect_to project_wiki_page_path(@project, @page.title) end end
Bug#802910: Bug#806219: Build mupen64plus-ui-console everywhere
On Wednesday 25 November 2015 16:25:56 Matthias Klose wrote: > > On Wednesday 25 November 2015 15:32:24 Matthias Klose wrote: > >> Package: src:mupen64plus-ui-console > >> Version: 2.5-1 > >> Severity: important > >> Tags: sid stretch patch > >> > >> Build mupen64plus-ui-console everywhere, it currently prevents migration of > >> mupen64plus-qt into testing. See #802910 or > >> https://tracker.debian.org/pkg/mupen64plus-qt. > >> > >> Patch at > >> http://launchpadlibrarian.net/227595473/mupen64plus-ui-console_2.5-1_2.5-1ubuntu1.diff.gz > >> > > > > But the dependency libmupen64plus2 is only available on amd64/i386. Upstream > > also only wants to officially support these architectures. There is also no > > dynarec support for arm64 and the arm platform is still marked as "not > > officially supported" in all mupen64plus upstream Makefiles. If you want > > arm64 > > support then I can add you to all mupen64plus packages as maintainer so you > > can implement it. > > fine, but maybe then the issue #802910 should be addressed differently. Yes, I will not upload mupen64plus-core to architectures which are known to be completely unsupported by mupen64plus and not working (like powerpc). So the mupen64plus-qt package has to be fixed to not build on architectures with missing runtime dependencies. But my offer to add Mathieu Malaterre and/or Sérgio Benjamim when they want to maintain the "not officially supported" armhf architecture in Debian is still open. I've just uploaded the mupen64plus* packages to the pkg-games (Debian Games Team) git repositories to have everything under the same team umbrella. Just tell me and I merge the branch armhf_test in all repositories and add the voluntaril(y|ies) to the uploaders. Btw. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#806219: Build mupen64plus-ui-console everywhere
tags 806219 + wontfix thanks On Wednesday 25 November 2015 15:32:24 Matthias Klose wrote: > Package: src:mupen64plus-ui-console > Version: 2.5-1 > Severity: important > Tags: sid stretch patch > > Build mupen64plus-ui-console everywhere, it currently prevents migration of > mupen64plus-qt into testing. See #802910 or > https://tracker.debian.org/pkg/mupen64plus-qt. > > Patch at > http://launchpadlibrarian.net/227595473/mupen64plus-ui-console_2.5-1_2.5-1ubuntu1.diff.gz > But the dependency libmupen64plus2 is only available on amd64/i386. Upstream also only wants to officially support these architectures. There is also no dynarec support for arm64 and the arm platform is still marked as "not officially supported" in all mupen64plus upstream Makefiles. If you want arm64 support then I can add you to all mupen64plus packages as maintainer so you can implement it. signature.asc Description: This is a digitally signed message part.
Bug#793200: [libfreeradius-client2] Fails to parse attribute list with unknown vendor as last attribute
Package: libfreeradius-client2
Version: 1.1.6-7
Severity: normal
Tags: patch
Cc: freeradius-de...@lists.freeradius.org
I have noticed that the attribute list is empty for radius packets like:
Radius Protocol
Code: Access-Accept (2)
Packet identifier: 0xe4 (228)
Length: 137
Authenticator: c43ca3c2765cfab8545e6e4a7f83ba9a
[This is a response to a request in frame 142]
[Time from request: 0.004763000 seconds]
Attribute Value Pairs
AVP: l=11 t=Vendor-Specific(26) v=Reserved(0)
VSA: l=5 t=Unknown-Attribute(27): 363030
Unknown-Attribute: 363030
AVP: l=12 t=Vendor-Specific(26) v=Wireless Broadband Alliance Ltd
(previous was 'Wi-Fi Alliance')(14122)
VSA: l=6 t=WISPr-Bandwidth-Max-Down(8): 124008
WISPr-Bandwidth-Max-Down: 124008
AVP: l=12 t=Vendor-Specific(26) v=Wireless Broadband Alliance Ltd
(previous was 'Wi-Fi Alliance')(14122)
VSA: l=6 t=WISPr-Bandwidth-Max-Up(7): 124007
WISPr-Bandwidth-Max-Up: 124007
AVP: l=6 t=Framed-Protocol(7): PPP(1)
Framed-Protocol: PPP (1)
AVP: l=6 t=Service-Type(6): Framed(2)
Service-Type: Framed (2)
AVP: l=46 t=Class(25):
8fdc089a0137000102000a010a2dd5a02756...
Class: 8fdc089a0137000102000a010a2dd5a02756...
AVP: l=12 t=Vendor-Specific(26) v=Microsoft(311)
VSA: l=6 t=MS-Link-Utilization-Threshold(14): 50
MS-Link-Utilization-Threshold: 50
AVP: l=12 t=Vendor-Specific(26) v=Microsoft(311)
VSA: l=6 t=MS-Link-Drop-Time-Limit(15): 120
MS-Link-Drop-Time-Limit: 120
The problem is that the vendor microsoft in my version was unknown.
The recursive attribute parser uses NULL as information for the caller that
its part of the parsing failed. But NULL is also returned when the last
attribute was from an unknown vendor. Instead it should only be skipped as
it is documented inside the function.
A proof of concept patch is attached which uses a special parameter which
is used to inform the caller about an error. The returned value is only
used as handler for the list.
--- System information. ---
Architecture: amd64
Kernel: Linux 4.0.0-2-amd64
Debian Release: stretch/sid
500 unstablehttpredir.debian.org
From: Sven Eckelmann s...@open-mesh.com
Date: Wed, 22 Jul 2015 12:24:47 +0200
Subject: [PATCH] radiusclient-ng: Don't drop attribute list when last attribute is from unknown vendor
The recursive attribute parser uses NULL as information for the caller that
its part of the parsing failed. But NULL is also returned when the last
attribute was from an unknown vendor. Instead it should only be skipped as
it is documented inside the function.
Introduce an extra parameter which is only used to store the error state
and leave the return value for the list item.
---
lib/avpair.c | 44 +---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/lib/avpair.c b/lib/avpair.c
index 979c0d9..7b215d2 100644
--- a/lib/avpair.c
+++ b/lib/avpair.c
@@ -154,6 +154,10 @@ VALUE_PAIR *rc_avpair_new (rc_handle *rh, int attrid, void *pval, int len, int v
return vp;
}
+static VALUE_PAIR *
+rc_avpair_gen_rec(rc_handle *rh, VALUE_PAIR *pair, unsigned char *ptr,
+int length, int vendorpec, int *recursive_error);
+
/*
*
* Function: rc_avpair_gen
@@ -168,6 +172,15 @@ VALUE_PAIR *
rc_avpair_gen(rc_handle *rh, VALUE_PAIR *pair, unsigned char *ptr,
int length, int vendorpec)
{
+ int recursive_error = 0;
+
+ return rc_avpair_gen_rec(rh, pair,ptr, length, vendorpec, recursive_error);
+}
+
+static VALUE_PAIR *
+rc_avpair_gen_rec(rc_handle *rh, VALUE_PAIR *pair, unsigned char *ptr,
+int length, int vendorpec, int *recursive_error)
+{
int attribute, attrlen, x_len;
unsigned char *x_ptr;
UINT4 lvalue;
@@ -178,22 +191,22 @@ rc_avpair_gen(rc_handle *rh, VALUE_PAIR *pair, unsigned char *ptr,
char hex[3];
if (length 2) {
- rc_log(LOG_ERR, rc_avpair_gen: received attribute with
+ rc_log(LOG_ERR, rc_avpair_gen_rec: received attribute with
invalid length);
goto shithappens;
}
attrlen = ptr[1];
if (length attrlen || attrlen 2) {
- rc_log(LOG_ERR, rc_avpair_gen: received attribute with
+ rc_log(LOG_ERR, rc_avpair_gen_rec: received attribute with
invalid length);
goto shithappens;
}
/* Advance to the next attribute and process recursively */
if (length != attrlen) {
- pair = rc_avpair_gen(rh, pair, ptr + attrlen, length - attrlen,
- vendorpec);
- if (pair == NULL)
+ pair = rc_avpair_gen_rec(rh, pair, ptr + attrlen, length - attrlen,
+ vendorpec, recursive_error);
+ if (*recursive_error)
return NULL;
}
@@ -205,7 +218,7 @@ rc_avpair_gen(rc_handle *rh, VALUE_PAIR *pair, unsigned char *ptr,
/* VSA */
if (attribute == PW_VENDOR_SPECIFIC) {
if (attrlen 4) {
- rc_log(LOG_ERR
Bug#711774: CVE-2015-3885
On Thursday 04 June 2015 16:39:21 Mathieu Malaterre wrote: Given the actual CVE-2015-3885 mess, could we actually please move on to libraw for the future ? ref: https://lists.debian.org/debian-lts/2015/06/msg00016.html Please don't use this mail as reference. At least acknowledge my response [1] to it. I can drop the dcraw support in exactimage. But I want to avoid shipping libraw patches which are not accepted by upstream and then give me even more problems with René. Kind regards, Sven [1] https://lists.debian.org/debian-lts/2015/06/msg00017.html signature.asc Description: This is a digitally signed message part.
Bug#786785: About the security issues affecting dcraw/ufraw/libraw/rawtherapee/rawstudio/exactimage/freeimage in Squeeze
On Wednesday 03 June 2015 10:04:19 PICCORO McKAY Lenz wrote: i cannot see recent activity arount those issues .. Here are my uploads: https://tracker.debian.org/news/686774 (unstable) https://tracker.debian.org/news/687131 (squeeze-lts) https://tracker.debian.org/news/687239 (jessie) https://tracker.debian.org/news/687578 (wheezy) Are you expecting more activity for exactimage? Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#786785: About the security issues affecting dcraw/ufraw/libraw/rawtherapee/rawstudio/exactimage/freeimage in Squeeze
On Wednesday 03 June 2015 10:41:38 PICCORO McKAY Lenz wrote: but exactimage its not the only affected, in fact u'r upload its the only activity in those issues of the CVE-2015-3885 Yes, but you've wrote to the bug tracking entry for the exactimage and therefore I had to assume that you are also referring to the activity in exactimage. There is also activity in other packages. For example freeimage, libraw, rawtherapee and ufraw received updates in sid. dcraw, darktable, freeimage, rawstudio and xbmc most likely still need a patch. It might be a good idea to check the bug tracker first and (if missing) post some patches for sid. The link to the documentation explaining how to contribute to LTS can be found in the initial mail. Do you have more specific questions? For example how you should post your changes in the packages for review/sponsorship? Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#786918: jessie-pu: package exactimage/0.8.9-7+deb8u1
Control: tags -1 + pending On Wednesday 27 May 2015 07:44:03 Adam D. Barratt wrote: Control: tags -1 + confirmed On 2015-05-26 20:05, Sven Eckelmann wrote: I'd like to upload the attached patch to stable-proposed-updates to fix #786785 (CVE-2015-3885). The security team marked this one as no-dsa but asked me to propose the fixes for a point release. Would this be ok? The change matches exactimage 0.9.1-5 + the backported dependency patch to get the ljpeg_start result validation after the ljpeg_start call. The latter change was in unstable before 0.9.1-5 and is required to test the patch. Please go ahead; thanks. Uploaded Thanks, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786919: wheezy-pu: package exactimage/0.8.5-5+deb7u4
Control: tags -1 + pending On Wednesday 27 May 2015 07:42:44 Adam D. Barratt wrote: Control: tags -1 + confirmed On 2015-05-26 20:05, Sven Eckelmann wrote: I'd like to upload the attached patch to oldstable-proposed-updates to fix #786785 (CVE-2015-3885). The security team marked this one as no-dsa but asked me to propose the fixes for a point release. Would this be ok? The change matches exactimage 0.9.1-5 + the backported dependency patch to get the ljpeg_start result validation after the ljpeg_start call. The latter change was in unstable before 0.9.1-5 and is required to test the patch. Please go ahead. Uploaded Thanks, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786918: jessie-pu: package exactimage/0.8.9-7+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
I'd like to upload the attached patch to stable-proposed-updates to fix
#786785 (CVE-2015-3885). The security team marked this one as no-dsa but asked
me to propose the fixes for a point release. Would this be ok? The change
matches exactimage 0.9.1-5 + the backported dependency patch to get the
ljpeg_start result validation after the ljpeg_start call. The latter change
was in unstable before 0.9.1-5 and is required to test the patch.
Just some information to the patch (taken from my mail to the security team):
The patch was not tested against any official special crafted image because
none was provided with the CVE. Instead a raw image was downloaded [1] and
modified to have the len at 0x13800+0x13801 set to 0. This causes an underflow
+ endless loop in the original version of dcraw. But this also showed that the
wheezy/jessie version of exactimage did ljpeg_start() + the jh.*
validation in the wrong order and thus made the jh.* validation read
uninintialized data from the stack. This additional problem was fixed in an
extra patch draw_jpeg_fix.patch. The original dcraw problem could be
reproduced after that jh.* patch was applied without the CVE fix. The test was
run via:
$ econvert -i RAW_CANON_EOS_5DMARK3.CR2 -o test.png
The versions of exactimage with both patches doesn't crash or hang anymore
when testing with the modified RAW_CANON_EOS_5DMARK3.CR2.
The patch is the one from rawstudio mentioned in CVE-2015-3885.
Kind regards,
Sven
[1] http://www.rawsamples.ch/raws/canon/RAW_CANON_EOS_5DMARK3.CR2diff -Nru exactimage-0.8.9/debian/changelog exactimage-0.8.9/debian/changelog
--- exactimage-0.8.9/debian/changelog 2014-08-30 15:47:09.0 +0200
+++ exactimage-0.8.9/debian/changelog 2015-05-25 19:23:02.0 +0200
@@ -1,3 +1,14 @@
+exactimage (0.8.9-7+deb8u1) jessie; urgency=medium
+
+ * Fix CVE-2015-3885: Integer overflow in the ljpeg_start function in dcraw
+ * debian/patches:
+- Add CVE-2015-3885.patch, Avoid overflow in ljpeg_start()
+ (Closes: #786785)
+- Add draw_jpeg_fix.patch, Fix execution order of ljpeg_start() and
+ result check
+
+ -- Sven Eckelmann s...@narfation.org Mon, 25 May 2015 17:45:27 +0200
+
exactimage (0.8.9-7) unstable; urgency=medium
* debian/rules:
diff -Nru exactimage-0.8.9/debian/patches/CVE-2015-3885.patch exactimage-0.8.9/debian/patches/CVE-2015-3885.patch
--- exactimage-0.8.9/debian/patches/CVE-2015-3885.patch 1970-01-01 01:00:00.0 +0100
+++ exactimage-0.8.9/debian/patches/CVE-2015-3885.patch 2015-05-25 19:23:02.0 +0200
@@ -0,0 +1,19 @@
+Description: Avoid overflow in ljpeg_start().
+Author: Anders Brander and...@brander.dk
+Origin: backport, https://github.com/rawstudio/rawstudio/commit/983bda1f0fa5fa86884381208274198a620f006e
+
+---
+diff --git a/codecs/dcraw.h b/codecs/dcraw.h
+index b115191c2f8f049e8ad933e0f83de52568413ec2..2f24f0f73744520a87cf6dc2eeb7dea84e83a563 100644
+--- a/codecs/dcraw.h
b/codecs/dcraw.h
+@@ -775,7 +775,8 @@ struct jhead {
+
+ int CLASS ljpeg_start (struct jhead *jh, int info_only)
+ {
+- int c, tag, len;
++ int c, tag;
++ ushort len;
+ uchar data[0x1];
+ const uchar *dp;
+
diff -Nru exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch
--- exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch 1970-01-01 01:00:00.0 +0100
+++ exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch 2015-05-25 19:23:02.0 +0200
@@ -0,0 +1,24 @@
+Description: Fix execution order of ljpeg_start() and result check
+Author: René Rebe r...@exactcode.de
+
+---
+diff --git a/codecs/dcraw.h b/codecs/dcraw.h
+index 2f24f0f73744520a87cf6dc2eeb7dea84e83a563..5584fef46c9759776475683a17d252b723a58ee5 100644
+--- a/codecs/dcraw.h
b/codecs/dcraw.h
+@@ -893,12 +893,12 @@ void CLASS lossless_jpeg_load_raw()
+ struct jhead jh;
+ ushort *rp;
+
+- if(jh.wide1 || jh.high1 || jh.clrs1 || jh.bits 1)
+-longjmp (failure, 2);
+-
+ if (!ljpeg_start (jh, 0)) return;
+ jwide = jh.wide * jh.clrs;
+
++ if(jh.wide1 || jh.high1 || jh.clrs1 || jh.bits 1)
++longjmp (failure, 2);
++
+ for (jrow=0; jrow jh.high; jrow++) {
+ rp = ljpeg_row (jrow, jh);
+ if (load_flags 1)
diff -Nru exactimage-0.8.9/debian/patches/series exactimage-0.8.9/debian/patches/series
--- exactimage-0.8.9/debian/patches/series 2014-08-30 15:47:09.0 +0200
+++ exactimage-0.8.9/debian/patches/series 2015-05-25 19:23:02.0 +0200
@@ -13,3 +13,5 @@
libgif.patch
ftbfs_evas_object.patch
perl_vendor_dir.patch
+CVE-2015-3885.patch
+draw_jpeg_fix.patch
Bug#786919: wheezy-pu: package exactimage/0.8.5-5+deb7u4
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
I'd like to upload the attached patch to oldstable-proposed-updates to fix
#786785 (CVE-2015-3885). The security team marked this one as no-dsa but asked
me to propose the fixes for a point release. Would this be ok? The change
matches exactimage 0.9.1-5 + the backported dependency patch to get the
ljpeg_start result validation after the ljpeg_start call. The latter change
was in unstable before 0.9.1-5 and is required to test the patch.
Just some information to the patch (taken from my mail to the security team):
The patch was not tested against any official special crafted image because
none was provided with the CVE. Instead a raw image was downloaded [1] and
modified to have the len at 0x13800+0x13801 set to 0. This causes an underflow
+ endless loop in the original version of dcraw. But this also showed that the
wheezy/jessie version of exactimage did ljpeg_start() + the jh.*
validation in the wrong order and thus made the jh.* validation read
uninintialized data from the stack. This additional problem was fixed in an
extra patch draw_jpeg_fix.patch. The original dcraw problem could be
reproduced after that jh.* patch was applied without the CVE fix. The test was
run via:
$ econvert -i RAW_CANON_EOS_5DMARK3.CR2 -o test.png
The versions of exactimage with both patches doesn't crash or hang anymore
when testing with the modified RAW_CANON_EOS_5DMARK3.CR2.
The patch is the one from rawstudio with a minor context adjustment to make it
apply in the wheezy version of exactimage.
Kind regards,
Sven
[1] http://www.rawsamples.ch/raws/canon/RAW_CANON_EOS_5DMARK3.CR2diff -Nru exactimage-0.8.5/debian/changelog exactimage-0.8.5/debian/changelog
--- exactimage-0.8.5/debian/changelog 2013-09-10 00:06:30.0 +0200
+++ exactimage-0.8.5/debian/changelog 2015-05-25 19:28:21.0 +0200
@@ -1,3 +1,14 @@
+exactimage (0.8.5-5+deb7u4) wheezy; urgency=medium
+
+ * Fix CVE-2015-3885: Integer overflow in the ljpeg_start function in dcraw
+ * debian/patches:
+- Add CVE-2015-3885.patch, Avoid overflow in ljpeg_start()
+ (Closes: #786785)
+- Add draw_jpeg_fix.patch, Fix execution order of ljpeg_start() and
+ result check
+
+ -- Sven Eckelmann s...@narfation.org Mon, 25 May 2015 17:57:23 +0200
+
exactimage (0.8.5-5+deb7u3) stable-security; urgency=high
* Add debian/patches/CVE-2013-1441.patch,
diff -Nru exactimage-0.8.5/debian/patches/CVE-2015-3885.patch exactimage-0.8.5/debian/patches/CVE-2015-3885.patch
--- exactimage-0.8.5/debian/patches/CVE-2015-3885.patch 1970-01-01 01:00:00.0 +0100
+++ exactimage-0.8.5/debian/patches/CVE-2015-3885.patch 2015-05-25 19:28:21.0 +0200
@@ -0,0 +1,19 @@
+Description: Avoid overflow in ljpeg_start().
+Author: Anders Brander and...@brander.dk
+Origin: backport, https://github.com/rawstudio/rawstudio/commit/983bda1f0fa5fa86884381208274198a620f006e
+
+---
+diff --git a/codecs/dcraw.h b/codecs/dcraw.h
+index 0436d34a40ee515a65513a7217dec97b3cde8946..8f56add58755843ace29b71c659b6173569f8e9a 100644
+--- a/codecs/dcraw.h
b/codecs/dcraw.h
+@@ -836,7 +836,8 @@ struct jhead {
+
+ int CLASS ljpeg_start (struct jhead *jh, int info_only)
+ {
+- int c, tag, len;
++ int c, tag;
++ ushort len;
+ uchar data[0x1], *dp;
+
+ init_decoder();
diff -Nru exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch
--- exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch 1970-01-01 01:00:00.0 +0100
+++ exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch 2015-05-25 19:28:21.0 +0200
@@ -0,0 +1,24 @@
+Description: Fix execution order of ljpeg_start() and result check
+Author: René Rebe r...@exactcode.de
+
+---
+diff --git a/codecs/dcraw.h b/codecs/dcraw.h
+index 8f56add58755843ace29b71c659b6173569f8e9a..66e32cf185f681657edda3c372b50b1d7b24b2c3 100644
+--- a/codecs/dcraw.h
b/codecs/dcraw.h
+@@ -954,12 +954,12 @@ void CLASS lossless_jpeg_load_raw()
+ int min=INT_MAX;
+ ushort *rp;
+
+- if(jh.wide1 || jh.high1 || jh.clrs1 || jh.bits 1)
+-longjmp (failure, 2);
+-
+ if (!ljpeg_start (jh, 0)) return;
+ jwide = jh.wide * jh.clrs;
+
++ if(jh.wide1 || jh.high1 || jh.clrs1 || jh.bits 1)
++longjmp (failure, 2);
++
+ for (jrow=0; jrow jh.high; jrow++) {
+ rp = ljpeg_row (jrow, jh);
+ for (jcol=0; jcol jwide; jcol++) {
diff -Nru exactimage-0.8.5/debian/patches/series exactimage-0.8.5/debian/patches/series
--- exactimage-0.8.5/debian/patches/series 2013-09-10 00:06:30.0 +0200
+++ exactimage-0.8.5/debian/patches/series 2015-05-25 19:28:21.0 +0200
@@ -12,3 +12,5 @@
optimize2bw_denoise.patch
CVE-2013-1438.patch
CVE-2013-1441.patch
+CVE-2015-3885.patch
+draw_jpeg_fix.patch
Bug#786785: exactimage: CVE-2015-3885: input sanitization flaw leading to buffer overflow
tags 786785 + pending thanks On Monday 25 May 2015 17:00:43 Salvatore Bonaccorso wrote: the following vulnerability was published for exactimage. CVE-2015-3885[0]: | Integer overflow in the ljpeg_start function in dcraw 7.00 and earlier | allows remote attackers to cause a denial of service (crash) via a | crafted image, which triggers a buffer overflow, related to the len | variable. 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-2015-3885 [1] http://www.ocert.org/advisories/ocert-2015-006.html Thanks a lot for your report and the references. The fix for unstable will be uploaded in some minutes. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#580872: [debian-maintainers] Annual ping for Sven Eckelmann
My last years annual ping wasn't processed yet. I will use this bug for my new annual ping. My contact information is now Sven Eckelmann s...@narfation.org with keyid 0xEC371482956781AF I am currently maintaining: * batctl [DM] * batman-adv-kernelland [DMUA] (only in oldstable) * batmand [DM] * exactimage [DM] * g3dviewer [DM] * libg3d [DM] * mupen64plus [DM] * mupen64plus-audio-sdl [DM] * mupen64plus-core [DM] * mupen64plus-input-sdl [DM] * mupen64plus-rsp-hle [DM] * mupen64plus-rsp-z64 [DM] * mupen64plus-ui-console [DM] * mupen64plus-video-arachnoid [DM] * mupen64plus-video-glide64 [DM] * mupen64plus-video-glide64mk2 * mupen64plus-video-rice [DM] * mupen64plus-video-z64 [DM] * s3d [DM] Sven Eckelmann wrote: [...] I was approved in bug #526484. signature.asc Description: This is a digitally signed message part.
Bug#732213: Bug#748614: [libkolab0] looses information about birthdays
reassign 748614 libkolab0 0.5.2-1
reassign 732213 libkolab0 0.5.2-1
forcemerge 748614 732213
retitle 748614 [libkolab0] looses information about birthdays
tags 748614 + patch upstream
forwarded 748614 https://issues.kolab.org/show_bug.cgi?id=2739
thanks
Hi,
the problem of the unsaved kaddressbook date-values doesn't seem to be in
libkolabxml1 or kdepim-runtime but in libkolab0. I've just created a patch to
fix it for me. Maybe this patch or a variation of it could be included as part
of the next libkolab upload. Please also include it in the upstream bug #2739.
Kind regards,
SvenFrom a90b7696d6e21d17d4dbe1225a2671704db92014 Mon Sep 17 00:00:00 2001
From: Sven Eckelmann s...@narfation.org
Date: Sun, 24 Aug 2014 22:14:20 +0200
Subject: [PATCH] Allow KDateTime with only valid date
The cDateTime class of libkolab returns true on .isValid() for an object with
only a valid date. But KDateTime and QDateTime only return true when both date
and time are valid. Still the conversion code relies on the fact that
KDateTime::isValid() would return true when date or date+time is true.
The code handling the conversion from/to KDateTime has to handle this
difference. Otherwise the conversion of Date-only value like KABC birthday or
anniversary would fail and therefore cause data loss.
---
conversion/commonconversion.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/conversion/commonconversion.cpp b/conversion/commonconversion.cpp
index 7accd22..09fc04a 100644
--- a/conversion/commonconversion.cpp
+++ b/conversion/commonconversion.cpp
@@ -67,13 +67,13 @@ KDateTime toDate(const Kolab::cDateTime dt)
date.setTimeSpec(getTimeSpec(dt.isUTC(), dt.timezone()));
}
Q_ASSERT(date.timeSpec().isValid());
-Q_ASSERT(date.isValid());
+Q_ASSERT(date.isValid() || date.date().isValid());
return date;
}
cDateTime fromDate(const KDateTime dt)
{
-if (!dt.isValid()) {
+if (!dt.isValid() !dt.date().isValid()) {
// qDebug() invalid datetime converted;
return cDateTime();
}
--
2.1.0
Bug#580872: [debian-maintainers] Annual ping for Sven Eckelmann
My last years annual ping wasn't processed yet. I will use this bug for my new annual ping. My contact information is now Sven Eckelmann s...@narfation.org with keyid 0xEC371482956781AF I am currently maintaining: * batctl [DM] * batman-adv-kernelland [DMUA] (only in oldstable) * batmand [DM] * exactimage [DM] * g3dviewer [DM] * libg3d [DM] * mupen64plus [DM] * mupen64plus-audio-sdl [DM] * mupen64plus-core [DM] * mupen64plus-input-sdl [DM] * mupen64plus-rsp-hle [DM] * mupen64plus-rsp-z64 [DM] * mupen64plus-ui-console [DM] * mupen64plus-video-arachnoid [DM] * mupen64plus-video-glide64 [DM] * mupen64plus-video-glide64mk2 * mupen64plus-video-rice [DM] * mupen64plus-video-z64 [DM] * s3d [DM] Sven Eckelmann wrote: [...] I was approved in bug #526484. signature.asc Description: This is a digitally signed message part.
Bug#745522: Please migrate to lcms2
tags 745522 + pending thanks On Tuesday 22 April 2014 17:36:33 Moritz Muehlenhoff wrote: As pre-announced in https://lists.debian.org/debian-devel/2013/12/msg00570.html it is planned to remove lcms1 for jessie. Please adapt your package. The severity will be bumped to RC-level before the jessie freeze. Thanks a lot for this reminder. I've completely missed the original mail. An upload will be made in some minutes. Kind regards, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733015: [libsdl2-2.0-0] SDL2 X11 driver buffer overflow with large X11 file descriptor
On Saturday 28 December 2013 13:39:08 Manuel A. Fernandez Montecelo wrote: Control: forwarded -1 https://bugzilla.libsdl.org/show_bug.cgi?id=2330 Thanks for the bug report and your efforts to improve Debian, I forwarded it upstream to the URL above. With the test case, I get: $ ./testkeys Couldn't initialize SDL: No available video device Thanks for your upload. Weird that you get this error message because it is just the default SDL2 test just with some open calls added to the beginning. I just uploaded 2.0.1 and it compiled fine for most architectures, so you will have it available soon. If you could test whether the bug and the fix still happens and communicate with upstream to make sure that they understand it and fix it, it would be great. It is still crashing here. I will add this information to the upstream bug report and add myself to Cc Thanks, Sven signature.asc Description: This is a digitally signed message part.
Bug#733015: [libsdl2-2.0-0] SDL2 X11 driver buffer overflow with large X11 file descriptor
On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
I have occasional crashes here caused by the X11 backend of SDL2. It seems
to be caused by the X11_Pending function trying to add a high number (
1024) file descriptor to a fd_set before doing a select on it to avoid busy
waiting on X11 events. This causes a buffer overflow because the file
descriptor is larger (or equal) than the limit FD_SETSIZE.
I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
It can be build + tested with:
$ gcc `sdl2-config --cflags` testkeys.c `sdl2-config --libs` -o testkeys
$ ./testkeys
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/pysdl2.git/*
Copyright (C) 1997-2013 Sam Lantinga slou...@libsdl.org
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely.
*/
/* Print out all the scancodes we have, just to verify them */
#include stdio.h
#include ctype.h
#include stdlib.h
#include string.h
#include SDL.h
#include sys/select.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int
main(int argc, char *argv[])
{
SDL_Scancode scancode;
int i;
for (i = 0; i 2*FD_SETSIZE; i++)
open(/dev/null, 0);
if (SDL_Init(SDL_INIT_VIDEO) 0) {
fprintf(stderr, Couldn't initialize SDL: %s\n, SDL_GetError());
exit(1);
}
for (scancode = 0; scancode SDL_NUM_SCANCODES; ++scancode) {
printf(Scancode #%d, \%s\\n, scancode,
SDL_GetScancodeName(scancode));
}
SDL_Quit();
return (0);
}
signature.asc
Description: This is a digitally signed message part.
Bug#733015: [libsdl2-2.0-0] SDL2 X11 driver buffer overflow with large X11 file descriptor
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch
I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number ( 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.
Attached is a possible workaround patch.
Please also keep in mind that fd_set are also used in following files which
may have similar problems.
src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c
--- System information. ---
Architecture: amd64
Kernel: Linux 3.11-2-amd64
Debian Release: jessie/sid
500 unstablehttp.debian.net
1 unstablewww.deb-multimedia.org
--- Package information. ---
Depends (Version) | Installed
==-+-==
libasound2 (= 1.0.16) |
libc6(= 2.15) |
libpulse0 (= 0.99.1) |
libts-0.0-0 (= 1.0) |
libx11-6 (= 2:1.2.99.901) |
libxcursor1 ( 1.1.2) |
libxext6 |
libxi6 (= 2:1.2.99.4) |
libxinerama1 |
libxrandr2(= 2:1.2.0) |
libxss1|
libxxf86vm1|
Package's Recommends field is empty.
Package's Suggests field is empty.Description: Don't add descriptor over FD_SETSIZE to fd_set
ConnectionNumber in X11_Pending may return a value outside of the range [0,
FD_SETSIZE). This value cannot be stored inside a fd_set and will crash the
program.
.
This buffer overflow problem occasionally happens when a lot of file
descriptors are used.
Author: Sven Eckelmann s...@narfation.org
---
diff --git a/src/video/x11/SDL_x11events.c b/src/video/x11/SDL_x11events.c
index 818ab2e21d96fa80c0b6ba72551198e5e9f925b2..5a983208a1a7c5d7d3a1a88bfac0c4337a2f4ed1 100644
--- a/src/video/x11/SDL_x11events.c
+++ b/src/video/x11/SDL_x11events.c
@@ -917,6 +917,9 @@ X11_Pending(Display * display)
fd_set fdset;
x11_fd = ConnectionNumber(display);
+if (x11_fd = FD_SETSIZE || x11_fd 0)
+return 0;
+
FD_ZERO(fdset);
FD_SET(x11_fd, fdset);
if (select(x11_fd + 1, fdset, NULL, NULL, zero_time) == 1) {
signature.asc
Description: This is a digitally signed message part.
Bug#732272: exactimage: FTBFS: /usr/bin/ld: cannot find -lungif
reassign 732272 libgif-dev 4.1.6-11 retitle Dangling symlink for libungif.so thanks Thanks for the bug report. On Monday 16 December 2013 09:29:25 Julien Cristau wrote: [...] /usr/bin/ld: cannot find -lungif collect2: error: ld returned 1 exit status Could you check this problem? The latest revision of giflib removed its libungif symlinks... Really? The link is still there but it is broken: $ ls -l /usr/lib/libungif.so lrwxrwxrwx 1 root root 15 Dec 7 19:36 /usr/lib/libungif.so - libgif.so.4.1.6 $ /usr/lib/libgif.so.4.1.6 ls: cannot access /usr/lib/libgif.so.4.1.6: No such file or directory $ ls -l /usr/lib/x86_64-linux-gnu/libgif.so.4.1.6 -rw-r--r-- 1 root root 36256 Dec 7 19:36 /usr/lib/x86_64-linux-gnu/libgif.so.4.1.6 So it seems the libgif-dev_4.1.6-11_amd64.deb is broken. Here is the content: drwxr-xr-x root/root 0 2013-12-07 19:36 ./ drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/ drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/share/ drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/share/doc/ drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/share/doc/libgif-dev/ -rw-r--r-- root/root 3112 2007-11-10 23:49 ./usr/share/doc/libgif-dev/NEWS.gz -rw-r--r-- root/root 9314 2007-11-10 23:52 ./usr/share/doc/libgif-dev/changelog.gz -rw-r--r-- root/root 2955 2013-12-07 18:45 ./usr/share/doc/libgif-dev/changelog.Debian.gz -rw-r--r-- root/root 2341 2013-12-07 18:45 ./usr/share/doc/libgif-dev/copyright -rw-r--r-- root/root 2615 2005-10-10 08:22 ./usr/share/doc/libgif-dev/ONEWS.gz -rw-r--r-- root/root 1022 2005-11-06 17:32 ./usr/share/doc/libgif-dev/AUTHORS -rw-r--r-- root/root 2917 2005-10-10 08:22 ./usr/share/doc/libgif-dev/TODO.gz drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/include/ -rw-r--r-- root/root 14474 2013-12-07 19:36 ./usr/include/gif_lib.h drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/lib/ drwxr-xr-x root/root 0 2013-12-07 19:36 ./usr/lib/x86_64-linux-gnu/ -rw-r--r-- root/root 51682 2013-12-07 19:36 ./usr/lib/x86_64-linux-gnu/libgif.a lrwxrwxrwx root/root 0 2013-12-07 19:36 ./usr/lib/libungif.la - libgif.la lrwxrwxrwx root/root 0 2013-12-07 19:36 ./usr/lib/libungif.so - libgif.so.4.1.6 lrwxrwxrwx root/root 0 2013-12-07 19:36 ./usr/lib/libungif.a - libgif.a lrwxrwxrwx root/root 0 2013-12-07 19:36 ./usr/lib/x86_64-linux-gnu/libgif.so - libgif.so.4.1.6 Maybe the maintainer of giflib can tell us whether the libungif.so link is in the wrong path or should never be there in the first place. Right now it just looks like a multiarch bug (which was introduced in 4.1.6-11) Kind regards, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732272: exactimage: FTBFS: /usr/bin/ld: cannot find -lungif
clone 732272 -1 reassign -1 exactimage 0.8.9-2 retitle -1 exactimage: Should not link against deprecated libungif tags -1 + pending thanks On Monday 16 December 2013 18:28:47 Thibaut GRIDEL wrote: Hello, I think there are 2 issues. If you agree we should split this one and provide 2 fixes. * Sven Eckelmann [2013-12-16 10:11]: Thanks for the bug report. On Mon, Dec 16, 2013 at 16:59:12 +0900, Nobuhiro Iwamatsu wrote: On Monday 16 December 2013 09:29:25 Julien Cristau wrote: /usr/bin/ld: cannot find -lungif collect2: error: ld returned 1 exit status Could you check this problem? 1) exactimage links against libungif which package was removed in 2005. giflib provided symlinks until then, but I think we should clean this nowadays. Seeing no reverse dependency on the provided libungif-dev, I (wrongly it seems) assumed that libungif symlinks had their days. I think exactimage should now link with libgif to be more consistent with its build-depends. Thanks for your reply. I will upload the fix for exactimage. Kind regards, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732119: [ttf-bitstream-vera] Please mark this package as Multi-Arch: foreign
Source: ttf-bitstream-vera
Version: 1.10-8
Severity: wishlist
Tags: patch
I just wanted to install mupen64plus-ui-console:i386 on amd64 to verify some
user problems and it failed because it could not find ttf-bitstream-vera:i386.
This package manager behavior seemed new to me but it seems the multiarch
documentation [1] agrees with it. This font package doesn't depend on other
architecture dependent packages (directly and indirectly) and should therefore
not break any assumption.
Can you please mark this package as 'Multi-Arch: foreign'. But please check
the documentation because I've just did a quick check after not reading it
for a long time.
Thanks
[1]
https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages--- debian/control.orig 2013-12-14 12:39:03.848670915 +0100
+++ debian/control 2013-12-14 12:27:34.928692522 +0100
@@ -7,6 +7,7 @@
Package: ttf-bitstream-vera
Architecture: all
+Multi-Arch: foreign
Depends: ${misc:Depends}
Description: The Bitstream Vera family of free TrueType fonts
This is a set of high-quality TrueType fonts created by Bitstream, Inc. and
Bug#729634: [libglew-dev] Wrong paths in glew.pc
Package: libglew-dev Version: 1.10.0-2 Severity: important Just got a lot of logs for failed builds of mupen64plus-video-z64 [1,2,3,4]. It seems that the paths in the glew.pc from libglew-dev are wrong. Here is a snippet: prefix=/build/glew-D_vCcR/glew-1.10.0/debian/tmp/usr exec_prefix=/build/glew-D_vCcR/glew-1.10.0/debian/tmp/usr/bin libdir=/build/glew-D_vCcR/glew-1.10.0/debian/tmp/usr/lib/i386-linux-gnu includedir=/build/glew-D_vCcR/glew-1.10.0/debian/tmp/usr/include/GL [1] https://buildd.debian.org/status/fetch.php?pkg=mupen64plus-video-z64arch=amd64ver=2.0.0-1%2Bb1stamp=1384467988file=log [2] https://buildd.debian.org/status/fetch.php?pkg=mupen64plus-video-z64arch=i386ver=2.0.0-1%2Bb1stamp=1384467590file=log [3] https://buildd.debian.org/status/fetch.php?pkg=mupen64plus-video-z64arch=kfreebsd-amd64ver=2.0.0-1%2Bb1stamp=1384469638file=log [4] https://buildd.debian.org/status/fetch.php?pkg=mupen64plus-video-z64arch=kfreebsd-i386ver=2.0.0-1%2Bb1stamp=1384470029file=log signature.asc Description: This is a digitally signed message part.
Bug#729695: batctl: vis_data option not working?
On Friday 15 November 2013 23:21:22 Petter Reinholdtsen wrote: Is the batctl vis_data option not working? I got a mesh with four nodes working, but vis_data do not output any information about the mesh. [...] Am I using it wrong, or what? You have to set one node as vis server using the vis_mode setting [1]. Otherwise no data from the whole network is gathered. Btw. this will be removed in upcoming versions (when the kernel looses support for visualization data gathering) and another tool called batadv-vis [2] from alfred [3] has to be used. Kind regards, Sven [1] http://www.open-mesh.org/projects/batman-adv/wiki/VisAdv [2] http://downloads.open-mesh.org/batman/manpages/batadv-vis.html [3] http://git.open-mesh.org/alfred.git signature.asc Description: This is a digitally signed message part.
Bug#726090: batctl: Add init.d script to enable batman-adv mesh node at boot?
tags 726090 + wontfix thanks Hi. Would it be an idea to include a boot script in the batctl package to make it possible to enable a batman-adm mesh node by just updating some values in /etc/default/batctl? I am against this approach because batctl is like bridge-utils (with some extra utilities). It is neither necessary to manage a bat0 device (you can use e.g. ip, rtnetlink or the sysfs interface) nor is it the debian way to manage network interfaces. It is nice for you when your init-hack is enough for you but from experience I can tell you that this only makes problems when interfaces go up/down or appear/disappear, ... Kind regards, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726090: batctl: Add init.d script to enable batman-adv mesh node at boot?
On Saturday 12 October 2013 10:25:09 Petter Reinholdtsen wrote: [Sven Eckelmann] I am against this approach OK. Just wanted to check if you were interested. Closing bug. Maybe you can check out the package ifupdown. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720815: mupen64plus-core: FTBFS: ../../src/api/vidext_sdl2_compat.h:547:34: error: 'SDL_Keysym' has no member named 'unicode'
fixed 720815 2.0-3 thanks On Sunday, August 25, 2013 03:21:54 PM you wrote: Source: mupen64plus-core Version: 2.0-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130825 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Sorry, this was fixed a long time ago (Sun, 25 Aug 2013 16:27:13 +0200) and I just did a copy+paste error when marking the bug as fixed in the changelog. Kind regards, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722138: [kde-telepathy-minimal] Missing Depends on kde-telepathy-desktop-applets
Package: kde-telepathy-minimal Version: 0.6.3 Severity: normal X-Debbugs-CC: lindner_ma...@yahoo.de The changelog of meta-kde-telepathy_0.6.3 said * Replace plasma-widget dependencies with new package kde-telepathy-desktop-applets but only the dependency to plasma-widget-telepathy-presence was removed and no dependency to kde-telepathy-desktop-applets was added. The relevant commit is ac816971fbd5ddee02323147869834f1e299 [1] (the replacing) and 319e330949d59743d8db4d384474407c91d233c5 [2] (dependencies were removed again). [1] http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-extras/kde-telepathy/meta-kde-telepathy.git;a=commit;h=ac816971fbd5ddee02323147869834f1e299 [2] http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-extras/kde-telepathy/meta-kde-telepathy.git;a=commit;h=319e330949d59743d8db4d384474407c91d233c5 --- System information. --- Architecture: i386 Kernel: Linux 3.10-2-686-pae Debian Release: jessie/sid 500 unstablehttp.debian.net 500 testing www.deb-multimedia.org 500 stable http.debian.net 1 experimentalhttp.debian.net --- Package information. --- Depends(Version) | Installed -+- kde-config-telepathy-accounts (= 0.6.3) | 0.6.3-1 kde-telepathy-approver(= 0.6.3) | 0.6.3-1 kde-telepathy-auth-handler(= 0.6.3) | 0.6.3-1 kde-telepathy-contact-list(= 0.6.3) | 0.6.3-1 kde-telepathy-integration-module (= 0.6.3) | 0.6.3-1 kde-telepathy-text-ui (= 0.6.3) | 0.6.3-1 telepathy-mission-control-5 (= 1:5.12) | 1:5.14.1-2 telepathy-connection-manager | Recommends(Version) | Installed ===-+-=== telepathy-gabble| 0.18.0-1 telepathy-salut | 0.8.1-1 telepathy-haze | 0.6.0-1 telepathy-logger| 0.8.0-2 Suggests (Version) | Installed ==-+-=== telepathy-rakia| 0.7.4-1 telepathy-idle | signature.asc Description: This is a digitally signed message part.
Bug#721410: PPC / ARM ?
tags 721410 + wontfix thanks On Saturday 31 August 2013 12:17:12 Mathieu Malaterre wrote: Package: mupen64plus-core As per release: http://code.google.com/p/mupen64plus/wiki/ReleasePage Makefiles: support for ARM, PPC, and MINGW architectures It would be nice to activate buildds on those archs. To the first two: * ARM (as in ARMel... not ARM as in big endian ARM) is not working well (trust me, I was involved in merging the patchset). Some weeks ago the team porting it to armel (mupen64plus-ae for android) were using it with the broken new dynamic recompiler and were not even able to make the interpreter() able to run basic programs. I fixed the major bug in the sign extension to get it the basic interpreter functionality able to run under Qemu just before the 2.0 release. Also the guy responsible for the broken new dynamic recompiler ran away and his code is something which should not be touched without an hazard suit. So I would not call it a good, tested port until the major problems are fixed * PPC is not really supported (yes, it is in the makefile but it just compiles and no one stepped up in making it really work and test stuff). The supported build targets by the mupen64plus maintainer are: * Linux: i386/amd64 with the old dynarec * Windows 32-bit using MinGW and the old dynarec (and sometimes also using a not perfectly specified version of Microsoft VisualC++) So I will not re-enable it on these architectures for this release. But I would be happy to do so for a future release when a upstream porter for these architectures are found and he/she can say with confidence that his/her port is in a good shape. To the last one: Did you just copy the MINGW part or are there really people starting to make a Debian MinGW architecture? Because this build environment support should actually work (it is used in the release). And it should even work on x86_64 with mingw64 (even when it is not official supported by the mupen64plus maintainer) And btw, the stuff in the release notes are partially wrong. Easy to test example: Try to use the rumble feature of mupen64plus-input-sdl with xboxdrv. It should give you the same result as you already get with the basic rumble test program from bug 713851. I hope this explains my current position. Please feel free to add corrections or add your own opinion. Thanks, Sven signature.asc Description: This is a digitally signed message part.
Bug#721409:
reopen 721409 = thanks On Saturday 31 August 2013 12:11:57 Mathieu Malaterre wrote: Looks like I missed the fact that mupen64plus is transitional package. Closing. But it has to be updated anyway for the package changes in mupen64plus 2.0. I was just waiting for the mupen64plus-video-glide64mk2... and it was just accepted signature.asc Description: This is a digitally signed message part.
Bug#721410: PPC / ARM ?
On Saturday 31 August 2013 13:11:17 Sven Eckelmann wrote: And btw, the stuff in the release notes are partially wrong. Easy to test example: Try to use the rumble feature of mupen64plus-input-sdl with xboxdrv. It should give you the same result as you already get with the basic rumble test program from bug 713851. I just took this as opportunity and uploaded a new revision [1] of mupen64plus-input-sdl with a temporary workaround. Kind regards, Sven [1] http://packages.qa.debian.org/m/mupen64plus-input-sdl/news/20130831T120419Z.html signature.asc Description: This is a digitally signed message part.
Bug#721236: CVE-2013-1438: exactimage: multiple vulnerabilities
tags 721236 + pending
thanks
On Thursday 29 August 2013 11:59:11 Raphael Geissert wrote:
I found a few vulnerabilities in dcraw and are all covered by the
CVE-2013-1438 id:
Specially crafted photo files may trigger a division by zero, an
infinite loop, or a null pointer dereference.
Alex Tutubalin, libraw upstream, has patched the vulnerabilities in
libraw and the patches should apply as-is to the vast majority of
embedders. For the details
http://www.openwall.com/lists/oss-security/2013/08/29/3
Please include the CVE id when fixing these vulnerabilities and
consider fixing them in old/stable via a {O,}SPU by following standard
procedures for stable release updates.
Thanks for the bug report. exactimage is affected by CVE-2013-1438 and will be
fixed soon in unstable. The differences to stable/oldstable are bigger and
have to be checked before an upload is prepared.
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
Bug#720157: [release.debian.org] hint mupen64plus-* for testing transition
Package: release.debian.org Severity: normal The mupen64plus packages switched from SDL 1.2 to SDL 2.0 and now breaks older versions of the core/plugins which were using SDL 1.2. This is necessary because using two different versions of SDL in the same process doesn't work (at least not as expected). Following source packages have to be hinted to go into testing at the same time: * mupen64plus-core/2.0-2 * mupen64plus-video-z64/2.0.0-1 * mupen64plus-video-rice/2.0-1 * mupen64plus-video-glide64/2.0.0-1 * mupen64plus-video-arachnoid/2.0.0-1 * mupen64plus-ui-console/2.0-1 * mupen64plus-input-sdl/2.0-1 * mupen64plus-audio-sdl/2.0-1 Thanks, Sven signature.asc Description: This is a digitally signed message part.
Bug#717801: Changing save slot using 0-9 keys is broken
On Thursday 25 July 2013 10:56:25 Milan Straka wrote: Package: libmupen64plus2 Version: 2.0-1 When upgrading libmupen64plus2 from 1.99.5-6 to 2.0-1, using 0-9 keys to change save slot stopped working. The reason is that the version 2.0-1 uses SDL 2.0 and uses scancodes instead of keysyms to test for keys 0-9, in the following way: src/main/eventloop.c:457 else if (keysym = SDL_SCANCODE_0 keysym = SDL_SCANCODE_9) main_state_set_slot(keysym - SDL_SCANCODE_0); Unfortunately, the values of scancodes for 0-9 are not sequential: SDL2/SDL_scancode.h:81 SDL_SCANCODE_1 = 30, SDL_SCANCODE_2 = 31, SDL_SCANCODE_3 = 32, SDL_SCANCODE_4 = 33, SDL_SCANCODE_5 = 34, SDL_SCANCODE_6 = 35, SDL_SCANCODE_7 = 36, SDL_SCANCODE_8 = 37, SDL_SCANCODE_9 = 38, SDL_SCANCODE_0 = 39, Therefore, keysym is never = SDL_SCANCODE_0 and = SDL_SCANCODE_9. According to SDL2 docs, The values in this enumeration are based on the USB usage page standard http://www.usb.org/developers/docs/;, so it is probably safe to assume that they will not be changed and so SDL_SCANCODE_1 to SDL_SCANCODE_9 are sequential, and test for SDL_SCANCODE_0 separately. Thanks a lot for the bug report. I will change it later when I have access to an actual PC (unfortunatelly, this can take quite long because I am currently on vacation). But I try my best to find some computing device were I can prepare the upload. signature.asc Description: This is a digitally signed message part.
Bug#715149: RFS: mupen64plus-video-glide64mk2/2.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package mupen64plus-video-glide64mk2 * Package name: mupen64plus-video-glide64mk2 Version : 2.0-1 Upstream Author : Richard 'Richard42' Goedeken rich...@fascinationsoftware.com * URL : https://code.google.com/p/mupen64plus/ * License : GPL-2+ Section : games It builds those binary packages: mupen64plus-video-glide64mk2 - Glide64Mk2 high-level graphics emulation for mupen64plus mupen64plus-video-glide64mk2-dbg - Glide64Mk2 graphics hle for mupen64plus debug symbols package To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mupen64plus-video-glide64mk2 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mupen64plus-video-glide64mk2/mupen64plus-video-glide64mk2_2.0-1.dsc This plugin is new in the mupen64plus 2.0 release. More information about mupen64plus-video-glide64mk2 can be obtained from https://code.google.com/p/mupen64plus/ and https://bitbucket.org/richard42/mupen64plus-video-glide64mk2 This package closes WNPP ITP bug #714994. I am only a Debian Maintainer and therefore need a sponsor to include this module/plugin of mupen64plus in Debian. Regards, Sven Eckelmann signature.asc Description: This is a digitally signed message part.
Bug#714994: ITP: mupen64plus-video-glide64mk2 -- Glide64Mk2 high-level graphics emulation for mupen64plus
Package: wnpp Severity: wishlist Owner: Sven Eckelmann s...@narfation.org * Package name: mupen64plus-video-glide64mk2 Version : 2.0 Upstream Author : Richard 'Richard42' Goedeken rich...@fascinationsoftware.com * URL : http://bitbucket.org/richard42/mupen64plus-video-glide64mk2/ * License : GPL-2+ Programming Lang: C Description : Glide64Mk2 high-level graphics emulation for mupen64plus High-level graphics emulation plugin for known microcodes based on Glide. This version includes a Glide-to-OpenGL wrapper which makes it independent of Voodoo cards. It supports advanced graphics effects of the N64 and loading of high resolution texture packs. . It is based on Glide64 Napalm which was ported to Linux and amd64. Work on packaging this plugin has started at http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-glide64mk2.git signature.asc Description: This is a digitally signed message part.
Bug#713851: [xboxdrv] Rumble with infinite replay doesn't play at all
On Sunday 23 June 2013 11:44:52 you wrote:
An easy example using SDL2 is attached. It can be compiled using
% gcc `sdl2-config --cflags --libs` infinite_rumble_xboxdrv_bug.c \
-o infinite_rumble_xboxdrv_bug
Ehrm, I forgot something.../*
Copyright (C) 1997-2011 Sam Lantinga slou...@libsdl.org
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely.
*/
/*
Copyright (c) 2011, Edgar Simo Serra
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the Simple Directmedia Layer (SDL) nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/*
* includes
*/
#include stdlib.h
#include stdio.h /* printf */
#include string.h /* strstr */
#include ctype.h /* isdigit */
#include SDL.h
#ifndef SDL_HAPTIC_DISABLED
#include SDL_haptic.h
static SDL_Haptic *haptic;
/**
* @brief The entry point of this force feedback demo.
* @param[in] argc Number of arguments.
* @param[in] argv Array of argc arguments.
*/
int
main(int argc, char **argv)
{
int i;
char *name;
int index;
SDL_HapticEffect efx[5];
int id[5];
int nefx;
unsigned int supported;
name = NULL;
index = -1;
if (argc 1) {
name = argv[1];
if ((strcmp(name, --help) == 0) || (strcmp(name, -h) == 0)) {
printf(USAGE: %s [device]\n
If device is a two-digit number it'll use it as an index, otherwise\n
it'll use it as if it were part of the device's name.\n,
argv[0]);
return 0;
}
i = strlen(name);
if ((i 3) isdigit(name[0]) ((i == 1) || isdigit(name[1]))) {
index = atoi(name);
name = NULL;
}
}
/* Initialize the force feedbackness */
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER | SDL_INIT_JOYSTICK |
SDL_INIT_HAPTIC);
printf(%d Haptic devices detected.\n, SDL_NumHaptics());
if (SDL_NumHaptics() 0) {
/* We'll just use index or the first force feedback device found */
if (name == NULL) {
i = (index != -1) ? index : 0;
}
/* Try to find matching device */
else {
for (i = 0; i SDL_NumHaptics(); i++) {
if (strstr(SDL_HapticName(i), name) != NULL)
break;
}
if (i = SDL_NumHaptics()) {
printf(Unable to find device matching '%s', aborting.\n,
name);
return 1;
}
}
haptic = SDL_HapticOpen(i);
if (haptic == NULL) {
printf(Unable to create the haptic device: %s\n,
SDL_GetError());
return 1;
}
printf(Device: %s\n, SDL_HapticName(i));
} else {
printf(No Haptic devices found!\n);
return 1;
}
/* We only want force feedback errors. */
SDL_ClearError();
if (SDL_HapticRumbleSupported(haptic) == SDL_FALSE) {
printf(\nRumble not supported!\n);
return 1;
}
if (SDL_HapticRumbleInit(haptic) != 0) {
printf(\nFailed to initialize rumble: %s\n, SDL_GetError());
return 1;
}
printf(Playing 2 second rumble at 0.5 magnitude... you will not feel it when using xboxdrv\n);
if (SDL_HapticRumblePlay(haptic, 0.5, SDL_HAPTIC_INFINITY) != 0) {
printf(\nFailed to play rumble: %s\n,
Bug#711822: Bug#713660: g3dviewer: FTBFS: gcc: error: unrecognized command line option '-V'
reassign 713660 libgtkglext1-dev 1.2.0-3 forcemerge 711822 713660 thanks On Saturday 22 June 2013 15:27:26 David Suárez wrote: Source: g3dviewer Version: 0.2.99.5~svn130-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130620 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. It is known and not caused by this package. The culprit is libgtkglext1-dev (see #711822). And you misread the log. It doesn't stop because of a '-V' but because the pkg-config failed and therefore the next test didn't had the gtk stuff from it in the cflags. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#713851: [xboxdrv] Rumble with infinite replay doesn't play at all
Package: xboxdrv Version: 0.8.5-1 Severity: normal I noticed a problem with xboxdrv when used together with mupen64plus-input- sdl. The memory/rumble pack switch effects were played but not the ingame effects. The big difference between the two are the length of the effect (or actually the replay.length because it is a FF_RUMBLE/FF_PERIODIC effect). Switching effects have a specific length and ingame effects have no length (aka infinite length) and are stopped when the emulated system requests them to be stopped. An easy example using SDL2 is attached. It can be compiled using % gcc `sdl2-config --cflags --libs` infinite_rumble_xboxdrv_bug.c \ -o infinite_rumble_xboxdrv_bug Please read more about the the SDL_HAPTIC_INFINITY at http://wiki.libsdl.org/moin.fcg/SDL_HapticRunEffect The infinite length is really set by replay.length as you can see at following places in the code: http://hg.libsdl.org/SDL/file/1516fe08e6ec/src/haptic/SDL_haptic.c#l758 http://hg.libsdl.org/SDL/file/1516fe08e6ec/src/haptic/linux/SDL_syshaptic.c#l576 Here the important part from the ff-memless driver which shows that effects are only stopped when the replay.length is != 0 (it is easier to understand than the iforce-ff driver because you don't need the secret hardware specs): http://lxr.free-electrons.com/source/drivers/input/ff-memless.c?v=3.8#L102 http://lxr.free-electrons.com/source/drivers/input/ff-memless.c?v=3.8#L367 You can also check out hid-pidff.c (pidff_set_effect_report) and compare it with the description of Duration for the value Null on page 15 of http://www.usb.org/developers/devclass_docs/pid1_01.pdf --- System information. --- Architecture: amd64 Kernel: Linux 3.9-1-amd64 Debian Release: jessie/sid 500 unstablewww.deb-multimedia.org 500 unstablehttp.debian.net 500 unstableftp.debian.org 500 testing http.debian.net 1 experimentalwww.deb-multimedia.org 1 experimentalhttp.debian.net --- Package information. --- Depends (Version) | Installed =-+-= libc6(= 2.4) | libdbus-1-3(= 1.0.2) | libdbus-glib-1-2(= 0.88) | libgcc1 (= 1:4.1.1) | libglib2.0-0 (= 2.14.0) | libstdc++6 (= 4.6) | libudev0 (= 146) | libusb-1.0-0 (= 2:1.0.8) | libx11-6 | Recommends (Version) | Installed ==-+-=== python | 2.7.5-2 python-dbus| 1.2.0-2 Package's Suggests field is empty. signature.asc Description: This is a digitally signed message part.
Bug#711774: exactimage: dcraw vs libraw ?
forwarded 711774 exact-im...@exactcode.de thanks On Sun, Jun 09, 2013 at 06:18:04PM +0200, Mathieu Malaterre wrote: exactimage uses convenient copy of dcraw, instead of relying on libs (eg. libraw). Could that be changed ? I haven't checked it in detail but libraw is not the same as the included modified version of dcraw [1]. I will not start to cripple exactimage in Debian by ripping out this part of the code but I will try to get in contact with upstream to find a way in getting a possible migration path to libraw to avoid too many differences between upstream and Debian version. See: §4.13 Convenience copies ofcode http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles Btw. did anyone actually try to tell the dcraw guys to switch to libraw? Kind regards, Sven [1] http://rene.rebe.de/2008-11-04/exactimage-065-updates-still-camera-raw-support/ signature.asc Description: Digital signature
Bug#711774: Re: [exact-image] Re: Bug#711774: exactimage: dcraw vs libraw ?
Just a small remark at the beginning: I didn't meant dcraw upstream with dcraw guys but the Debian maintainers for dcraw. And I really think it is a good question because the package is dead since 3 years and missing some updates from upstream. (Ok, the embedded copy of dcraw in exactimage seems to be older) On Sunday 09 June 2013 19:37:03 Rene Rebe wrote: I think dcraw did all the original research and he does not want to make it a library because he believes an executable to call is the unix way and a library he could boy change so flexible. This is why I embedded the not too big code to make it a simple built in library inside exact image. This is correct, but is not really about the problem here. Just to give more insight in what Mathieu Malaterre said: Embedded copies of code are bad when used in Distributions because (just some examples): * they increase the binary size when there would be shared object that could be used instead * they increase memory usage because different programs cannot share the loaded library * they are hard to maintain Ok, the first two points are easy to understand but the last one might be quite vague. So here an explanation with two different scenarios (actually it is the same example but with different impacts): dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans and EOS C500 support. Now all programs using an embedded copy have to be updated in Debian to bring these versions on par with the upstream one and fix outstanding bugs/request for EOS C500/X-Trans. This is not really trivial because the programs have to be identified first and then the maintainer has to be waken up. This is a lot of work and time spend on a task that is completely unnecessary. Therefore, it is better to use the library version when available. And yes, I am fully aware that interface changes are problems which can be a negative effect when switching to external libraries. Now to the part with a little more impact. Lets assume that dcraw has a bug which can be exploited quite easily (send a prepared image which causes some buffer overflows and so on). Now it is extreme important to find all versions of the embedded copy because otherwise it is a security risk. You don't really want to provide an web service doing raw image conversions when there might be a big security hole because the security bug was fixed in the original program/library but not in the embedded copy. So back to the main questions. Do you see a possible way to switch from your dcraw version to libraw and make more of the embedded copies optional? I know, the embedded copies from libjpeg for jpeg rotation are for example really hard because libjpeg doesn't export the necessary stuff. But it seemed to have caused some headaches for the previous maintainers of this package because no one updated the embedded copy of jpegint/transupp and it just crashed when used together with never versions of libjpeg like libjpeg8. And the current one in exactimage upstream still does. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#710599: RFS: exactimage/0.8.8-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package exactimage * Package name: exactimage Version : 0.8.8-2 Upstream Author : Rene Rebe r...@exactcode.de * URL : http://dl.exactcode.de/oss/exact-image/ * License : GPL-2 Section : graphics It builds those binary packages: edisplay - fast image manipulation programs (image viewer) exactimage - fast image manipulation programs exactimage-dbg - fast image manipulation library (debug symbols) libexactimage-perl - fast image manipulation library (Perl bindings) php5-exactimage - fast image manipulation library (PHP bindings) python-exactimage - fast image manipulation library (Python bindings) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/exactimage Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/e/exactimage/exactimage_0.8.8-2.dsc Changes since the last upload: exactimage (0.8.8-2) unstable; urgency=low . * debian/patches: - Add verbose_build.patch, Enforce simple verbose build for blhc - Add decode_before_read_stride.patch, Decode image before accessing the stride attribute for rotation (Closes: #523948) - Add tga_memcpy_signature.patch, Don't write outside tga signature array * debian/control - Remove Daniel Stender as maintainer (Closes: #708417) - Switch from libtiff-dev provided by oldlib libtiff4-dev to libtiff5-dev Regards, Sven Eckelmann signature.asc Description: This is a digitally signed message part.
Bug#710599: RFS: exactimage/0.8.8-2
On Saturday 01 June 2013 11:01:41 Sven Eckelmann wrote: * Package name: exactimage Version : 0.8.8-2 Was uploaded to unstable http://packages.qa.debian.org/e/exactimage/news/20130601T214824Z.html signature.asc Description: This is a digitally signed message part.
Bug#523948: exactimage: segmentation fault / double free
tags 523948 + pending
thanks
Hi,
First the good part: I can easily fix your special problem (see the attached
patch which will be uploaded with the next revision in Debian). Now the bad
one: This is just part of a bigger problem described in the the rest of the
mail.
On Monday 13 April 2009 21:30:56 you wrote:
Package: exactimage
Version: 0.7.1-1
Severity: normal
Econvert crashes when called as follows:
econvert -i 4000x3000.jpg --size 1280x1280 --rotate 270 -o zz.jpg
As said before, this one is not doing what you think. I've still had a look at
this problem and noticed that the handling of errors is... mostly missing.
Just as explanation what is happening here:
* image is loaded using the codecs (just imagine for now that this is a png
file to make it easier to understand without this extra raw jpeg
modification handling later on)
* size is applied - the raw data is deleted and set to NULL
* rotate (rot90 to be more exactly) tries to get the raw data - NULL is
returned, rot90 still tries to operate on it and will crash later
Handling the rawdata == NULL case in the rotate.cc doesn't really solve the
problem because it will just crash later on when it tries to write the stuff
to the output.
Now to the special problem showed by your example:
JPEG will not get decoded in the first step but a codec is used instead
but the rotation still wants to to operate on the raw data. So, how does it
come to this problem? Yes, the modified bit is set in step 2 and step 3 will
check it and try to operate on the raw data. These are now getting decoded...
which should not have happened in the first place (but this is rather low
priority). The code assumed that it is already decoded and the meta
information are already available before the getRawData call.
So, it looks slightly like the rawdata handling has to be checked in over 100
different place. Maybe upstream has a better idea. And maybe an explanation
what other reason there are to have to use --size (which kills all previous
loaded images) besides to define the size of the raw image to be loaded next.
Another quick hack for Debian would be to disable operation in econvert on
images which have: rawdata == 0 (modified || !hasCodec).
But maybe, this creates other problems and I am relativ sure this doesn't
solve problems in other components.
Kind regards,
SvenDescription: Decode image before accessing the stride attribute for rotation
Bug-Debian: http://bugs.debian.org/523948
Author: Sven Eckelmann s...@narfation.org
---
diff --git a/lib/rotate.cc b/lib/rotate.cc
index 86c639e4fa7cbd0ad158b785184b258300dac691..4c05ad6c8a052b59a53f2807189b4935e90aa230 100644
--- a/lib/rotate.cc
+++ b/lib/rotate.cc
@@ -33,9 +33,9 @@ void flipX (Image image)
if (!image.isModified() image.getCodec())
if (image.getCodec()-flipX(image))
return;
-
- const int stride = image.stride();
+
uint8_t* data = image.getRawData();
+ const int stride = image.stride();
switch (image.spp * image.bps)
{
case 1:
@@ -103,9 +103,9 @@ void flipY (Image image)
if (!image.isModified() image.getCodec())
if (image.getCodec()-flipY(image))
return;
-
- const unsigned int bytes = image.stride();
+
uint8_t* data = image.getRawData();
+ const unsigned int bytes = image.stride();
for (int y = 0; y image.h / 2; ++y)
{
int y2 = image.h - y - 1;
@@ -128,10 +128,9 @@ void rot90 (Image image, int angle)
bool cw = false; // clock-wise
if (angle == 90)
cw = true; // else 270 or -90 or whatever and thus counter cw
-
- int rot_stride = (image.h * image.spp * image.bps + 7) / 8;
uint8_t* data = image.getRawData();
+ int rot_stride = (image.h * image.spp * image.bps + 7) / 8;
uint8_t* rot_data = (uint8_t*) malloc(rot_stride * image.w);
switch (image.spp * image.bps)
signature.asc
Description: This is a digitally signed message part.
Bug#708417: RFA: exactimage -- image converter
owner 708417 ! thanks On Wednesday 15 May 2013 18:14:13 you wrote: Package: wnpp Severity: normal Looking for someone who adopts exactimage: http://packages.qa.debian.org/e/exactimage.html Just my two cents: This RFA doesn't affect my maintainership of exactimage. I didn't knew about Daniel Stender's plan to remove himself from the packaging team. I did the last two revisions (adoption upload with RC fixes for wheezy and the post-wheezy version bump) but still would be happy about a Co-Maintainer. Nevertheless, I will take ownership of this RFA (because there is actually nothing to adopt; just change of my role in debian/control) and remove Daniel Stender in the next upload. This upload will be done when enough other stuff was changed. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Bug#707011: nmu: batmand_0.3.2-13
On Monday 06 May 2013 23:07:31 Andreas Beckmann wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu batmand_0.3.2-13 . amd64 . -m Rebuild in a clean Debian sid environment. batmand/amd64 unsatisfiable Depends: libc6 (= 2.15) The first package post-freeze I noticed that was not build in sid but uploaded to sid. Thanks for the nmu. The package was uploaded from the wrong directory (the one containing the packages before sending it through the clean buildenv). The package received an upload in the meantime. Therefore, the request is not needed anymore. Thanks, Sven signature.asc Description: This is a digitally signed message part.
