Bug#1010546: tldr-py: tdlr update fails ("master" should be "main")

[Antoine Amarilli]

Package: tldr-py
Version: 0.7.0-4
Severity: important

Dear Maintainer,

Running "tldr update" fails with the following:

$ tldr update
Check for updates...
fatal: ambiguous argument 'master': unknown revision or path not in the working 
tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
Traceback (most recent call last):
  File "/usr/bin/tldr", line 33, in 
sys.exit(load_entry_point('tldr.py==0.7.0', 'console_scripts', 'tldr')())
  File "/usr/lib/python3/dist-packages/click/core.py", line 1128, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1053, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1659, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 1395, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 754, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/tldr/cli.py", line 114, in update
local = subprocess.check_output('git rev-parse master'.split()).strip()
  File "/usr/lib/python3.10/subprocess.py", line 420, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', 'rev-parse', 'master']' 
returned non-zero exit status 128.

I guess a branch was renamed from "master" to "main".

This may be related: https://github.com/lord63/tldr.py/issues/49

Best,

-- 
Antoine Amarilli


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tldr-py depends on:
ii  python33.10.4-1+b1
ii  python3-click  8.0.3-1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-yaml   5.4.1-1+b1

Versions of packages tldr-py recommends:
ii  git  1:2.35.1-1

tldr-py suggests no packages.

-- debconf-show failed

Bug#956611: mutt: Segfault when exiting with IMAP

[Antoine Amarilli]

Package: mutt
Version: 1.13.2-1
Severity: normal

Dear Maintainer,

When opening an IMAP server with mutt, restarting the server, and exiting mutt,
then mutt reproducibly segfaults. This problem does not appear with the current
mutt version from upstream, and is probably one of the IMAP issues that were
patched upstream in the latest bugfix releases that Debian doesn't have yet.

Would it be possible to update the Debian mutt version to the latest release
from upstream? Many thanks!




-- Package-specific info:
Mutt 1.13.2 (2019-12-18)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.4.0-4-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-21' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean 
--enable-link-mutex
Thread model: posix
gcc version 9.2.1 20191130 (Debian 9.2.1-21) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-uhtbne/mutt-1.13.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-uhtbne/mutt-1.13.2=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd 

Bug#955136: openshot: Newer version 2.5.1 available from upstream

[Antoine Amarilli]

PS: I should point out that I have been experiencing a data corruption
issue with the currently packaged version,
<https://github.com/OpenShot/openshot-qt/issues/3171#issuecomment-605117577>
with the corresponding bug apparently fixed in the latest version, so it
would really be a good idea to ship the updated version if possible. :)

Thanks!

-- 
Antoine Amarilli


On Fri, Mar 27, 2020 at 06:26:24PM +0100, Antoine Amarilli wrote:
> Package: openshot
> Version: 2.4.3+dfsg1-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Openshot 2.5.1 is available from upstream, would it be possible to package 
> this
> version?
> 
> Many thanks!
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages openshot depends on:
> ii  openshot-qt  2.4.3+dfsg1-1
> 
> openshot recommends no packages.
> 
> openshot suggests no packages.
> 
> -- no debconf information


signature.asc
Description: PGP signature

Bug#955136: openshot: Newer version 2.5.1 available from upstream

[Antoine Amarilli]

Package: openshot
Version: 2.4.3+dfsg1-1
Severity: wishlist

Dear Maintainer,

Openshot 2.5.1 is available from upstream, would it be possible to package this
version?

Many thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openshot depends on:
ii  openshot-qt  2.4.3+dfsg1-1

openshot recommends no packages.

openshot suggests no packages.

-- no debconf information

Bug#948364: audacity leaks memory and crashes

[Antoine Amarilli]

Hi,

Other important points that I just found:

- The leak only occurs under Wayland (I'm using sway and XWayland), not
  with Xorg (tested with i3)

- The leak only occurs when the Audacity window is visible. If it is not
  onscreen, the memory usage doesn't seem to grow.

(I reiterate that the problem doesn't occur when compiling Audacity
myself from source, so it's not a general issue of Audacity not working
under Wayland -- the problem must be with the specific versions of
libraries that I used, or with the packaging, compilation options,
etc.)

Besides, looking at audacity's memory with pmap, what changes when
memory gets allocated is that lines of the following form get added:

> 7f806403864037403740 rw-s- /memfd:gdk-wayland (deleted)

Best,

-- 
Antoine Amarilli



On Sat, Mar 21, 2020 at 06:56:45PM +0100, Antoine Amarilli wrote:
> Hi,
> 
> I am still having this bug as of today, which makes Audacity unusable. I
> compiled Audacity 2.3.3 from source and it doesn't seem to have the same
> problem.
> 
> So the problem may be in the Debian packaging, or in the use of
> different library versions than what I did.
> 
> Here is some information about my build:
> 
> $ ldd ./audacity 
> linux-vdso.so.1 (0x7ffe2415d000)
> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7f234d943000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f234d922000)
> libwx_gtk2u_html-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0 (0x7f234d643000)
> libwx_gtk2u_qa-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0 
> (0x7f234d414000)
> libwx_gtk2u_adv-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0 (0x7f234d026000)
> libwx_gtk2u_core-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 (0x7f234c78c000)
> libwx_baseu_net-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0 (0x7f234c53e000)
> libwx_baseu-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 
> (0x7f234c09f000)
> libavcodec.so.58 => /usr/lib/x86_64-linux-gnu/libavcodec.so.58 
> (0x7f234ab0d000)
> libavformat.so.58 => /usr/lib/x86_64-linux-gnu/libavformat.so.58 
> (0x7f234a899000)
> libavutil.so.56 => /usr/lib/x86_64-linux-gnu/libavutil.so.56 
> (0x7f234a774000)
> libid3tag.so.0 => /usr/lib/x86_64-linux-gnu/libid3tag.so.0 
> (0x7f234a755000)
> libmad.so.0 => /usr/lib/x86_64-linux-gnu/libmad.so.0 (0x7f234a733000)
> libSoundTouch.so.1 => /usr/lib/x86_64-linux-gnu/libSoundTouch.so.1 
> (0x7f234a71c000)
> libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 
> (0x7f234a671000)
> libvorbisfile.so.3 => /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 
> (0x7f234a666000)
> libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 
> (0x7f234a638000)
> libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x7f234a42d000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f234a428000)
> libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 
> (0x7f2349fdc000)
> libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
> (0x7f2349f25000)
> libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
> (0x7f2349efe000)
> libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 
> (0x7f2349ea2000)
> libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 
> (0x7f2349d7b000)
> libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 
> (0x7f2349c82000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2349c77000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7f2349aaa000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2349965000)
> libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1 (0x7f2349939000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f234991d000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f234975d000)
> /lib64/ld-linux-x86-64.so.2 (0x7f234ec09000)
> libwx_baseu_xml-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0 (0x7f234954d000)
> libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 
> (0x7f2349503000)
> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f23493c1000)
> libnotify.so.4 => /usr/lib/x86_64-linux-gnu/libnotify.so.4 
> (0x7f23493b7000)
> libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 
> (0x7f23493a5000)
> libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x7f2349285000)
> libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 
> (0x7f2349

Bug#948364: audacity leaks memory and crashes

[Antoine Amarilli]

b/x86_64-linux-gnu/libidn2.so.0 (0x7f2343a4b000)
libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 
(0x7f23438c9000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f23438b3000)
libnettle.so.7 => /usr/lib/x86_64-linux-gnu/libnettle.so.7 (0x7f2343878000)
libhogweed.so.5 => /usr/lib/x86_64-linux-gnu/libhogweed.so.5 
(0x7f234383f000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f23437ba000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f234369d000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f234367a000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f234362e000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x7f23435cd000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f23435a)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f2343588000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7f2343483000)
libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x7f2343479000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f2343275000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f234306d000)
libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x7f2343053000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x7f2343013000)
libicudata.so.63 => /usr/lib/x86_64-linux-gnu/libicudata.so.63 
(0x7f2341622000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f2341542000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
(0x7f234150f000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f2341509000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f23414fa000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f23414f3000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7f234149d000)
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f234140d000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 
(0x7f23413df000)

$ apt-cache policy of some relevant packages:
libwxbase3.0-0v5:
  Installed: 3.0.4+dfsg-4~bpo9+1
  Candidate: 3.0.4+dfsg-15
  Version table:
 3.0.4+dfsg-15 650
650 http://debian.proxad.net/debian testing/main amd64 Packages
600 http://debian.proxad.net/debian unstable/main amd64 Packages
 *** 3.0.4+dfsg-4~bpo9+1 100
100 http://debian.proxad.net/debian stretch-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 3.0.2+dfsg-4 500
500 http://debian.proxad.net/debian stretch/main amd64 Packages
libwxgtk-webview3.0-0v5:
  Installed: 3.0.4+dfsg-4~bpo9+1
  Candidate: 3.0.4+dfsg-4~bpo9+1
  Version table:
 *** 3.0.4+dfsg-4~bpo9+1 100
100 http://debian.proxad.net/debian stretch-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 3.0.2+dfsg-4 500
500 http://debian.proxad.net/debian stretch/main amd64 Packages
libwxgtk3.0-0v5:
  Installed: 3.0.4+dfsg-4~bpo9+1
  Candidate: 3.0.4+dfsg-14
  Version table:
 3.0.4+dfsg-14 600
600 http://debian.proxad.net/debian unstable/main amd64 Packages
 *** 3.0.4+dfsg-4~bpo9+1 100
100 http://debian.proxad.net/debian stretch-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 3.0.2+dfsg-4 500
500 http://debian.proxad.net/debian stretch/main amd64 Packages

I hope this helps. I can provide more information if needed.

Best regards,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#948364: audacity leaks memory and crashes

[Antoine Amarilli]

Package: audacity
Version: 2.3.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

On my system, audacity seems to be leaking memory during playback. To reproduce,
record anything, then play it repeatedly, or in a loop (Maj+play). The memory
usage of audacity in top grows steadily (around 16 MB/s) until audacity gets OOM
killed or crashes the system.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages audacity depends on:
ii  audacity-data 2.3.3-1
ii  libasound21.1.9-1
ii  libavcodec58  7:4.2.1-2+b1
ii  libavformat58 7:4.2.1-2+b1
ii  libavutil56   7:4.2.1-2+b1
ii  libc6 2.29-3
ii  libexpat1 2.2.9-1
ii  libflac++6v5  1.3.3-1
ii  libflac8  1.3.3-1
ii  libgcc1   1:9.2.1-21
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.4-1
ii  libgtk-3-03.24.13-1
ii  libid3tag00.15.1b-14
ii  liblilv-0-0   0.24.4~dfsg0-1
ii  libmad0   0.15.1b-10
ii  libmp3lame0   3.100-3
ii  libogg0   1.3.2-1+b1
ii  libportaudio2 19.6.0-1
ii  libportsmf0   0.1~svn20101010-5
ii  libsndfile1   1.0.28-6
ii  libsoundtouch12.1.2+ds1-1
ii  libsoxr0  0.1.3-1
ii  libstdc++69.2.1-21
ii  libsuil-0-0   0.10.4-2
ii  libtwolame0   0.4.0-2
ii  libvamp-hostsdk3v52.9.0-1
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libvorbisfile31.3.6-2
ii  libwxbase3.0-0v5  3.0.4+dfsg-15
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-15

audacity recommends no packages.

Versions of packages audacity suggests:
pn  ladspa-plugin  

-- debconf-show failed

Bug#946648: Chromium randomly crashes in the latest version.; crashes within a few minutes

[Antoine Amarilli]

Hi,

I can also reproduce the crashes (segfaults) on two different machines.
The version is 79.0.3945.79-1

This makes chromium essentially unusable.

Regards,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#938719: Python3 supported upstream

[Antoine Amarilli]

Hi,

It appears that trash-cli supports Python3 upstream: Fedora has fixed
the issue in 2017.
<https://bugzilla.redhat.com/show_bug.cgi?id=1413527>.

Would it be possible to do the same for Debian? Thanks!

-- 
Antoine Amarilli




signature.asc
Description: PGP signature

Bug#945352: reptyr: missing arm64 build

[Antoine Amarilli]

Package: reptyr
Severity: wishlist

Dear Maintainer,

Would it be possible to have an arm64 build of reptyr?

I have checked that it works fine to clone the upstream source
https://github.com/nelhage/reptyr
compile with make, and that the resulting binary indeed works as intended.

Many thanks!

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-5-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#830726: closed by Chris Lamb (Bug#830726: fixed in xtrlock 2.12)

[Antoine Amarilli]

Looks good to me! Thanks again for all your work on this.

Best,

-- 
Antoine Amarilli


On Wed, Oct 16, 2019 at 12:57:16AM -, Chris Lamb wrote:
> Hi Antoine,
> 
> > Looks great! There's a grammar problem "This fix does not the situation"
> > but it doesn't matter.
> 
> Whoops, fixed in:
> 
>   
> https://salsa.debian.org/debian/xtrlock/commit/e578040d4bedf81874cc2bf1c62d6643b36b527d
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-


signature.asc
Description: PGP signature

Bug#830726: closed by Chris Lamb (Bug#830726: fixed in xtrlock 2.12)

[Antoine Amarilli]

Looks great! There's a grammar problem "This fix does not the situation"
but it doesn't matter.

Best,

-- 
Antoine Amarilli


On Mon, Oct 14, 2019 at 07:13:05PM -, Chris Lamb wrote:
> Hi Antoine,
> 
> <https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff>?
> > I see nothing, unless you mean the source code comment?
> 
> Yes, the source code comment. I've expanded the (released) changelog
> entry here:
> 
>   
> https://salsa.debian.org/debian/xtrlock/commit/34e6c7c6c33ce6b7510172a2e05e710a99fdc146
> 
> … so this visibility will be in subsequent releases at the very least.
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-


signature.asc
Description: PGP signature

Bug#830726: closed by Chris Lamb (Bug#830726: fixed in xtrlock 2.12)

[Antoine Amarilli]

Hi Chris,

On Sat, Oct 12, 2019 at 07:13:05PM -, Chris Lamb wrote:
> > Thanks for fixing this and pushing it! Is the final fix also supposed to
> > address the case of an attacker plugging in a new USB multitouch device?
> 
> Alas not; I received no input from upstream after repeated pings so I
> pushed ahead.

Alright -- too bad.

> > If the latter -- should this be pointed out as a known limitation or
> > vulnerability of the package?
> 
> Indeed. I did write that here:
> 
>   
> https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff
> 
> ... but I would concede that is not very visible.

Sorry I'm not too sure of what you mean, what is it that you wrote about
known limitations in
<https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff>?
I see nothing, unless you mean the source code comment?

In principle I would think there ought to be some kind of record
(besides the discussion on this bug report) that the problem isn't
really fixed. But to be honest I don't care too much personally as I'm
migrating from X to wayland so phasing out xtrlock on my machines. And
it's already great you could push out that fix which addresses most of
the concerns.

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: closed by Chris Lamb (Bug#830726: fixed in xtrlock 2.12)

[Antoine Amarilli]

Hi Chris,

Thanks for fixing this and pushing it! Is the final fix also supposed to
address the case of an attacker plugging in a new USB multitouch device?
or is it just the latest patch I had tested (with the weird quirks when
a new device appears)?

If the latter -- should this be pointed out as a known limitation or
vulnerability of the package?

Best,

-- 
Antoine Amarilli



On Fri, Oct 11, 2019 at 07:57:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the xtrlock package:
> 
> #830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events
> 
> It has been closed by Chris Lamb .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Chris Lamb 
>  by
> replying to this email.
> 
> 
> -- 
> 830726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830726
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Fri, 11 Oct 2019 19:52:58 +
> From: Chris Lamb 
> To: 830726-cl...@bugs.debian.org
> Subject: Bug#830726: fixed in xtrlock 2.12
> Message-Id: 
> 
> Source: xtrlock
> Source-Version: 2.12
> 
> We believe that the bug you reported is fixed in the latest version of
> xtrlock, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 830...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Chris Lamb  (supplier of updated xtrlock package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> Format: 1.8
> Date: Fri, 11 Oct 2019 12:41:39 -0700
> Source: xtrlock
> Architecture: source
> Version: 2.12
> Distribution: unstable
> Urgency: medium
> Maintainer: Matthew Vernon 
> Changed-By: Chris Lamb 
> Closes: 830726
> Changes:
>  xtrlock (2.12) unstable; urgency=medium
>  .
>* CVE-2016-10894: Attempt to grab multitouch devices which are not
>  intercepted via XGrabPointer. (Closes: #830726)
>* Bump Standards-Version to 4.4.1.
> Checksums-Sha1:
>  9a78849e65046057a84e060b9f2c03a571de6fb8 1602 xtrlock_2.12.dsc
>  90fde89622bd85ad2454de1308b10499b66f00e3 20620 xtrlock_2.12.tar.xz
>  4e69677968fc27410bed3b0b54a0945c65a9948f 6187 xtrlock_2.12_amd64.buildinfo
> Checksums-Sha256:
>  21c9bb1a25121afc7adbd1e96694a8390544e09437d296e83a96b6245f88aa7f 1602 
> xtrlock_2.12.dsc
>  13b634dc6c23a35386e683163d2b8be76de2229e1cd7fb82517cb8e388e278ba 20620 
> xtrlock_2.12.tar.xz
>  f645e51a15122f1767f25d2580bab930aa248740be79d9a941caf674c9f3207a 6187 
> xtrlock_2.12_amd64.buildinfo
> Files:
>  5966c685ad31b3b00fa85d674c490eb7 1602 x11 optional xtrlock_2.12.dsc
>  49adf9b39eed6ea717462f5171da5a30 20620 x11 optional xtrlock_2.12.tar.xz
>  79be2ba64b7d7d76096b3028a2aacc88 6187 x11 optional 
> xtrlock_2.12_amd64.buildinfo
> 

> Date: Sun, 10 Jul 2016 16:18:41 -0400
> From: Antoine Amarilli 
> To: Debian Bug Tracking System 
> Subject: xtrlock does not block multitouch events
> Message-ID: <146818192189.12824.5554238893763808868.report...@gamma.a3nm.net>
> X-Mailer: reportbug 6.6.6
> 
> Package: xtrlock
> Version: 2.8
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> xtrlock appears not to block multitouch events when the session is locked, so
> that any user stumbling upon a locked session can still input multitouch 
> events.
> 
> One could imagine that this could constitute a security vulnerability 
> (requiring
> physical access to the machine).
> 
> Steps to reproduce (on a computer with a suitably configured touchscreen):
> 
> 1. Open chromium (my example of a program that processes multitouch events) 
> and
> put it in fullscreen mode.
> 2. Check that you can pinch and zoom (put two fingers of the screen and move
> them closer or further apart to change the zoom level).
> 3. Run xtrlock to lock the session.
> 4. With xtrlock running, put one finger on the screen and leave it there (the
> mouse pointer with the xtrlock lock icon follows that finger). While doing 
> this,
> perform the pinch and zoom with two other fingers.
> 
> Observed result:
> 
> The pinch and zoom is taken into account by chromium even though the session 
> is
> loc

Bug#935377: run-mailcap: "my" variable $file masks earlier declaration in same scope

[Antoine Amarilli]

Hi,

I can confirm that this problem is still present. I get this message
when running "xdg-open", which apparently calls run-mailcap for some
reason.

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#939768: gimp: After the last upgrade, GIMP crashes when creating a new image or opening an existing one.

[Antoine Amarilli]

I was also affected by this and could fix the problem with:

  sudo apt install -t unstable libgegl-0.4-0

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

Thanks again for your work on this!

On Sun, Sep 08, 2019 at 09:32:20AM +0100, Chris Lamb wrote:
> I can partly reproduce this, as well as some other strange behaviour
> upon "plugging in" a device that, like your descriptions, are quite involved
> to explain!
> 
> > So the regrab doesn't actually solve things. What is even weirder is
> > that this problem with the screen not being "correctly" grabbed will
> > persist on future xtrlock runs
> […]
> > Can you reproduce this pretty weird behavior? Does it make any sense to
> > you?
> 
> I did once actually but I think I dismissed it as some kind of weird
> errant process or just an issue as I was doing lot of recompilation,
> etc. etc. Hmpf.

Glad that you can reproduce these weird problems and confirm that I not
alone in seeing them. ;-P

> > [The exact same behavior seems to occur if I replace xinput
> > enable/disable with the corresponding play with the authorized file.]
> 
> I am pleased that we can also get the same behaviour using xinput vs
> "authorized" as I would have more confidence that the latter emulates
> Eve plugging in a external USB device versus xinput in terms of
> abstraction layers.

Agreed, plus as the latter doesn't work for you it would have been more
complicated to figure things out. ;)

> I'm a little stuck on how to proceed code-wise so my next steps are to
> contact the maintainers of the Input Extension and see if they have
> any insight.

This sounds like a good idea -- also I wonder if the weird behavior
"xtrlock persistently puts an input in a strange state" doesn't reveal a
bug someplace else...

As this is getting a bit open-ended, though, do you think it could be
worth it to release one of these patches soon (the first one, or the
second one with the missing initializations I pointed out) as a first
step that fixes the vulnerability at least when Eve cannot plug in new
devices?

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#931645: mcomix: Fails to start with python-pil (>= 6.0.0)

[Antoine Amarilli]

Hi,

This bug makes mcomix completely unusable. Would it be possible to
integrate the proposed patch? Many thanks!

PS: Related discussion on an upstream bugtracker:
<https://sourceforge.net/p/mcomix/bugs/116/>

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

tty which might have a login session on).

I agree we shouldn't try excessively hard, but what you describe here
isn't really an xtrlock vulnerability: xtrlock is about locking the X
display, not TTYs. Security-conscious users should know that TTYs exist
out of the X session, and wouldn't leave a logged-in session in a TTY.
By contrast, problems with multitouch are xtrlock failing to do its job.

Best,

-- 
Antoine Amarilli




signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

On Wed, Aug 21, 2019 at 03:52:44PM -0700, Chris Lamb wrote:
> > I've been working on an updated patch that detects new devices and
> > blocks them too. However, "grabbing" devices during the processing of
> > these "device hierarchy changed" events appears to do something funny
> > and actually disables all input entirely for me
> 
> Whilst I've fixed that bit at least, the new attached patch doesn't
> grab devices that are renabled via "xinput enable" although we do
> successfully detect that "edge" event now.

Cool! I'm not sure whether this other edge case is important -- are
there situations where an attacker in front of a locked computer could
manage to pull this off?

Oh, and if we can detect the edge event, can't we grab the devices
somehow -- in the worst case, just by restarting xtrlock?

Another question (but that's probably being too paranoid): with
approaches that grab new devices as they show up, are there risks of a
timing attack where the attacker could be able to do some events before
xtrlock can grab the device? (Probably not as a human, but imagining a
malicious device that would regularly simulate disconnections.) The
question is, does xtrlock have any guarantee that it can grab the device
before events from the device will be processed?

> Antoine, how did you find the right /sys/bus/usb/devices/FOO directory?
> I'm only using xinput as I can't seem to locate my touchpad under
> /sys/bus.

Well, pretty clumsily. I did "lsusb -t -v". I found the touchscreen
there, with its ID (04f3:000a). Then I did something like:

  cd /sys/bus/usb/devices
  for a in *; do
echo $a;
cat $a/idVendor
  done

... and went to the folder having the right ID -- and tried to disable
it and saw that I had found the right one.

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

Thanks for writing the patch! I tested it on
<https://salsa.debian.org/debian/xtrlock.git>. For some reason it didn't
apply cleanly to debian/rules, but it did apply fine to xtrlock.c and I
manually added -DMULTITOUCH to debian/rules to enable it.

So, the patch works fine on my machine. All input from the touchscreen
seems to be blocked (in particular touching the touchscreen no longer
moves the mouse cursor with the lock icon).

However, I think I see a problem with the patch's design. If I
understand correctly, the patch makes xtrlock grab all devices
initially. But if the attacker plugs in a new device after xtrlock is
started (e.g., an USB multitouch trackpad), then it wouldn't be grabbed,
right?

I can't try out this exact scenario because I don't have such a USB
device, and I can't easily disconnect my laptop's touchscreen. However,
I have tried blocking the touchscreen by writing 0 to
/sys/bus/usb/devices/3-1.5/authorized (the touchscreen then disappears
from the output of xinput). If I run "sleep 10 ; echo 1 | sudo tee
authorized" in the background and run xtrlock (to simulate plugging in
the touchscreen after 10 seconds), then sure enough, once the
touchscreen is "plugged" it is not grabbed by xtrlock and the initial
problem still occurs.

Of course the patch is already a big improvement, but do you have any
idea about how to address this problem with new devices being plugged in
while xtrlock is running?

Best,

-- 
Antoine Amarilli


On Fri, Aug 16, 2019 at 05:46:07PM -0700, Chris Lamb wrote:
> Chris Lamb wrote:
> 
> > Patch attached that works for me on my Dell XPS 13
> 
> Antoine, does the patch attached to:
> 
>   https://bugs.debian.org/830726#43
> 
> … also work for you? If so, I will go ahead and upload.
> 
> 
> Best wishes,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-


signature.asc
Description: PGP signature

Bug#933311: bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol: _ZN7leveldb4port5Mutex6UnlockEv

[Antoine Amarilli]

Hi,

I am also affected by this. bitcoin-qt just fails to start with this
error, so it cannot be used at all.

Regards,

-- 
Antoine Amarilli

Bug#830726: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

I can still reproduce this. I just booted an USB key with a live Debian
stable image from
https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/debian-live-10.0.0-amd64-standard.iso.torrent
on the affected hardware (Lenovo IdeaPad Yoga 13 with an ELAN
touchscreen). It booted to a TTY, so I apt-get installed xserver-xorg,
openbox, slim, chromium, xtrlock, started a graphical session, and I
could reproduce the problem: run chromium, run xtrlock, press one finger
on the screen (the mouse pointer with the padlock icon moves to that
finger), then interact with chromium with the other fingers.

The problem is not actually limited to multitouch events in Chromium
(i.e., not just pinch and zoom), as I can e.g. minimize chromium by
tapping the minimize icon with the second finger while the first finger
"holds" the xtrlock icon, and generally interact with the chromium
interface (though not all interface elements work, for some reason).

I can only see this problem with chromium; I cannot interact with other
windows (e.g., xterm, firefox) in this way. This may be linked to the
fact that the chromium window is not decorated, i.e., it does not have
the openbox decorations.

Are you sure you tried to reproduce it with multiple fingers as above?
Are you sure you are using a touchscreen with multitouch support?

Now that I notice this is not limited to multitouch events, this looks
to me like a genuine vulnerability affecting xtrlock when such hardware
is present (or can be plugged in): an attacker can, e.g., completely
mess around with the chromium settings while the session is "locked" by
xtrlock.

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#921688: Updates

[Antoine Amarilli]

Hello everyone,

This bug has been open and the electrum package has been unusable for
almost 6 months now. Tristan, are you planning on packaging a new
version at some point, or is the package no longer maintained?

Thanks for your work on this!

Best regards,

-- 
Antoine Amarilli


On Sun, Jun 02, 2019 at 06:55:48PM +0200, Antoine Amarilli wrote:
> Hi,
> 
> Are there any updates on packaging a new version of electrum in Debian?
> 
> Many thanks for your work on this!
> 
> Best,
> 
> -- 
> Antoine Amarilli
> 


signature.asc
Description: PGP signature

Bug#921688: Updates

[Antoine Amarilli]

Hi,

Are there any updates on packaging a new version of electrum in Debian?

Many thanks for your work on this!

Best,

-- 
Antoine Amarilli

Bug#929112: libstd-rust-1.32: Packaging a more recent rust version

[Antoine Amarilli]

Package: libstd-rust-1.32
Version: 1.32.0+dfsg1-3
Severity: wishlist

Dear Maintainer,

Version 1.34.2 of Rust is now available from upstream
, would it be possible to package it?

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libstd-rust-1.32 depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6

libstd-rust-1.32 recommends no packages.

libstd-rust-1.32 suggests no packages.

-- debconf-show failed

Bug#901148: Bug still present

[Antoine Amarilli]

Hi,

I'm still affected by this (must close timidity and restart pulseaudio
after a reboot), and judging from the comment
https://superuser.com/questions/1312163/dummy-output-instead-of-audio-device-on-debian-9/1346784?noredirect=1#comment2168375_1346784
I'm not the only person affected. So afaict the bug is still present.

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#640150: Bug still exists

[Antoine Amarilli]

I had this bug occur today when trying to run evince after an upgrade. The
message told me to run the command:

  gdk-pixbuf-query-loaders > 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache

But this doesn't work because it needs to be done as root and because
the full path to the command should be specified (it is even more
confusing as command-not-found gdk-pixbuf-query-loaders or apt-cache
search gdk-pixbuf-query-loaders return nothing). Specifically:

  sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders | sudo 
tee /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache

The error message should be clarified accordingly (and there's also a
question of why this command wasn't run during the upgrade process in
the first place).

-- 
Antoine Amarilli

Bug#913760: python3-electrum: Add Depends on libsecp256k1-0 for faster signing and verification

[Antoine Amarilli]

Shouldn't this be a Recommends rather than a Depends, as the package is
supposed to work without it?

-- 
Antoine Amarilli

Bug#925378: apt-daily service slows down the machine, should use higher niceness

[Antoine Amarilli]

Package: apt
Version: 1.8.0~rc2
Severity: minor

Dear Maintainer,

My machine (Raspberry Pi 3) is significantly slowed down when the apt-daily
service runs. As this is a batch service, in my opinion it should be started
with a higher niceness so that it has less adverse effects on performance of
more relevant tasks.

Would it be a good idea to set up the service so as to have a higher niceness?

Many thanks!

-- 
Antoine Amarilli


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-2-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2018.1
ii  gpgv2.2.12-1
ii  libapt-pkg5.0   1.8.0~rc2
ii  libc6   2.28-6
ii  libgcc1 1:8.2.0-16
ii  libgnutls30 3.6.6-2
ii  libseccomp2 2.3.3-3
ii  libstdc++6  8.2.0-16

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-6
ii  dpkg-dev1.19.2
ii  gnupg   2.2.12-1
ii  gnupg2  2.2.12-1
ii  powermgmt-base  1.33

-- debconf-show failed

Bug#920204: devede: Format for custom chapters is not clear

[Antoine Amarilli]

Package: devede
Version: 4.8.0-1
Severity: minor

Dear Maintainer,

When setting up custom chapters in a video file (in the Files list, after having
selected a file, click on Properties, then in the General tab you have "Manual
chapter list (split by comma in mm:ss format)"), the precise format to specify
is very confusing:

- When providing a custom list of chapters, if a chapter is longer than the
  value of the previous item "Size (in minutes) for each chapter", then
  apparently the gaps are cut. E.g., if you provide "10:00,20:00" as custom
  chapters and the size is "5" then a chapter gets inserted at "15:00". This is
  not especially intuitive and not explained anywhere.
  
  So when manual chapter breaks are provided they should not be automatically
  split like this, or at least it should be clearly explained.

- For positions after the one-hour mark, you need to describe them, e.g., as
  "64:42", not "1:04:42". If you provide them as "1:04:42" then it is silently
  parsed as "1:04" ignoring the ":42". This is not clearly explained. Also, it
  seems like chapters beyond the 1:20:00 mark are ignored.

  IMO the best fix would be to accept values such as "1:04:42", and in any case
  the contents of the field should be parsed and validated to avoid mysterious
  failures.

(By the way, there is a possible workaround to these problems but it's really
ugly: start producing the DVD, then pkill -STOP devede, edit
xml_data/dvdauthor.xml to change the chapter list, then pkill -CONT devede.)

Best,

-- 
Antoine Amarilli

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devede depends on:
ii  dvdauthor0.7.0-2
ii  ffmpeg   7:4.1-1
ii  fonts-freefont-ttf   20120503-8
ii  genisoimage  9:1.1.11-3+b2
ii  gir1.2-gtk-3.0   3.24.3-1
ii  imagemagick  8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2
ii  mplayer  2:1.3.0-8+b4
ii  mpv  0.29.1-1
ii  python3  3.7.1-3
ii  python3-dbus 1.2.8-2+b3
ii  python3-gi-cairo 3.30.4-1
ii  python3-pkg-resources40.6.2-1
ii  python3-urllib3  1.24-1
ii  vcdimager2.0.1+dfsg-3

devede recommends no packages.

Versions of packages devede suggests:
pn  mencoder  

-- debconf-show failed

Bug#913214: libcurl3-gnutls: Connexion to a git server fails on "400 Bad Request"

[Antoine Amarilli]

Dear maintainer,

Would it be possible to update to curl 7.63.0 to fix this issue? Many
thanks!

Samuel, in the meantime my workaround is to downgrade to 7.60.0-1:

  sudo apt install libcurl3=7.60.0-1

Best regards,

-- 
Antoine Amarilli

Bug#909543: unattended-upgrades: should not depend on python3-cairo and other graphical packages via python3-gi

[Antoine Amarilli]

Package: unattended-upgrades
Version: 1.5
Severity: wishlist

Dear Maintainer,

unattended-upgrades depends on python3-gi which depends on python3-cairo. This
is annoying because, on headless machines, it means that installing
unattended-upgrades will install libcairo2 and other graphical stuff as a
dependency.

The reason why unattended-upgrades depends on python3-gi seems to be because
unattended-upgrades uses it to check whether the current network connection is
metered, and avoid performing the upgrades in that case.

A simple solution would be instead to change the code to work if python3-gi is
not installed (by assuming that the current network connection is not metered),
and change python3-gi to be a Recommends of unattended-upgrades rather than a
Depends. This would intuitively sense because metered connections are usually
only an issue on desktop systems (not headless systems), where (one hopes)
python3-gi would be installed.

Alternatively, a better fix would be to see whether the check for a metered
connection couldn't be performed differently, without depending on python3-gi.

Best,

-- 
Antoine Amarilli


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  gir1.2-glib-2.01.58.0-1
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  powermgmt-base 1.33
ii  python33.6.6-1
ii  python3-apt1.6.2
ii  python3-gi 3.30.1-1
ii  ucf3.0038
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-130

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1
ii  exim4-daemon-light [mail-transport-agent]  4.91-7
ii  needrestart3.3-1

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed [not included]

-- debconf information excluded

Bug#801805: isc-dhcp-client: Error 'Unable to set up timer: out of range' when system time too far in future

[Antoine Amarilli]

I just had the exact same problem, so this issue still exist. It was
especially confusing that NetworkManager indicated that the connection
to the network was successful, despite the fact that dhclient had
failed.

One simple idea to improve things would be to point out in dhclient's
error message that the problem may be related to the system clock. That
way, at least calling dhclient manually may put the user on the right
track.

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#904441: Same problem with Asus Zenbook

[Antoine Amarilli]

Hi all,

I am having the same problem with my Asus Zenbook: it booted fine with
linux-image-4.16.0-2-amd64 but wasn't booting with
linux-image-4.17.0-1-amd64. The specific problem was that the boot
sequence hung and near the end the following was displayed (copying from
a screen capture):

  sd 0:0:0:0: [sda] Synchronizing SCSI cache
  sd 0:0:0:0: [sda] Stopping disk

The laptop model is "ASUSTeK COMPUTER INC. UX330UAK" as reported during
boot:

Aug  7 12:18:15 zeta kernel: [9.374427] asus_nb_wmi: Identified laptop 
model 'ASUSTeK COMPUTER INC. UX330UAK'
Aug  7 12:18:15 zeta kernel: [9.374495] asus_wmi: Initialization: 0x1
Aug  7 12:18:15 zeta kernel: [9.374538] asus_wmi: BIOS WMI version: 9.0
Aug  7 12:18:15 zeta kernel: [9.374576] asus_wmi: SFUN value: 0x2021
Aug  7 12:18:15 zeta kernel: [9.375536] input: Asus WMI hotkeys as 
/devices/platform/asus-nb-wmi/input/input11
Aug  7 12:18:15 zeta kernel: [9.375646] asus_wmi: Number of fans: 0

And to give some info about the SSD:

$ cat /sys/bus/scsi/devices/0:0:0:0/model 
Micron_1100_MTFD
$ cat /sys/bus/scsi/devices/0:0:0:0/rev  
A020

Adding "dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0" to the boot
parameters in grub works around the problem for now, thanks for
suggesting this!

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#845987: Planet is still broken

[Antoine Amarilli]

Hi,

I'm also hitting this bug, planet is currently unusable on Debian
stable. Would it be possible to upload the patch?

Thanks!

-- 
Antoine Amarilli

Bug#850061: lighttpd: should support reloading configuration without restarting

[Antoine Amarilli]

Package: lighttpd
Version: 1.4.43+git20161216-1
Severity: minor

Dear Maintainer,

The way lighttpd is packaged by Debian does not seem to make it possible to
reload lighttd's configuration without restarting it (terminating any ongoing
client connections).

Specifically, sending SIGHUP to lighttpd does not appear to make it reload its
configuration, and running systemctl force-reload lighttpd.service makes it
restart, which kills ongoing connections.

I think it would be preferable to run lighttpd using the lighttpd-angel program
(which is part of the lighttpd distribution, and also shipped by Debian), which
makes it possible to restart a new lighttpd with the new configuration while
leaving the old one around to finish handling ongoing connections.

More information:



Using lighttpd-angel, it should be possible to ask lighttpd to reload its
configuration without terminating ongoing connections.

Thanks!


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental'), (600, 'unstable'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lighttpd depends on:
ii  init-system-helpers  1.46
ii  libattr1 1:2.4.47-2
ii  libbz2-1.0   1.0.6-8
ii  libc62.24-8
ii  libfam0  2.7.0-17.2
ii  libpcre3 2:8.39-2
ii  libssl1.11.1.0c-2
ii  lsb-base 9.20161125
ii  mime-support 3.60
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages lighttpd recommends:
ii  spawn-fcgi  1.6.4-1

Versions of packages lighttpd suggests:
ii  apache2-utils  2.4.25-1
pn  lighttpd-doc   
ii  openssl1.1.0c-2
pn  php5-cgi   
pn  rrdtool

-- Configuration Files:
/etc/lighttpd/lighttpd.conf changed [not included]

-- no debconf information

Bug#849583: pelican: New upstream version 3.7.0

[Antoine Amarilli]

Package: pelican
Version: 3.6.3-1
Severity: normal

Dear Maintainer,

Upstream has published version 3.7.0 two weeks ago.



Would it be possible to package it? Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pelican depends on:
ii  libpython2.7-stdlib [python-argparse]  2.7.13~rc1-1
ii  python 2.7.11-2
ii  python-blinker 1.3.dfsg2-1
ii  python-dateutil2.5.3-2
ii  python-docutils0.12+dfsg-2
ii  python-feedgenerator   1.9-1
ii  python-jinja2  2.8-1
ii  python-markdown2.6.7-1
ii  python-pkg-resources   28.7.1-1
ii  python-pygments2.1.3+dfsg-1
ii  python-six 1.10.0-3
ii  python-tz  2016.7-0.2
ii  python-unidecode   0.04.19-1
pn  python:any 

pelican recommends no packages.

Versions of packages pelican suggests:
ii  pandoc   1.17.2~dfsg-3
pn  pelican-doc  
ii  python-bs4   4.5.1-1

-- debconf-show failed

Bug#810896: Workaround

[Antoine Amarilli]

Based on a few months of usage without encountering the problem, it
appears that I can work around this problem by using the driver located
at <https://github.com/lwfinger/rtl8723au> rather than the driver
currently shipped with the kernel. This is an acceptable workaround for
my purposes, but still it probably means that the kernel version of the
driver has a problem.

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: xtrlock does not block multitouch events

[Antoine Amarilli]

Package: xtrlock
Version: 2.8
Severity: normal
Tags: upstream

Dear Maintainer,

xtrlock appears not to block multitouch events when the session is locked, so
that any user stumbling upon a locked session can still input multitouch events.

One could imagine that this could constitute a security vulnerability (requiring
physical access to the machine).

Steps to reproduce (on a computer with a suitably configured touchscreen):

1. Open chromium (my example of a program that processes multitouch events) and
put it in fullscreen mode.
2. Check that you can pinch and zoom (put two fingers of the screen and move
them closer or further apart to change the zoom level).
3. Run xtrlock to lock the session.
4. With xtrlock running, put one finger on the screen and leave it there (the
mouse pointer with the xtrlock lock icon follows that finger). While doing this,
perform the pinch and zoom with two other fingers.

Observed result:

The pinch and zoom is taken into account by chromium even though the session is
locked.

Expected result:

The event should not be seen by chromium while the session is locked.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xtrlock depends on:
ii  libc6 2.22-13
ii  libx11-6  2:1.6.3-1

xtrlock recommends no packages.

xtrlock suggests no packages.

-- debconf-show failed

Bug#819413: pdftk: NullPointerException when trying to open a directory

[Antoine Amarilli]

Package: pdftk
Version: 2.02-3
Severity: minor

Dear Maintainer,

pdftk fails messily with a non-helpful NullPointerException when run on a
directory by mistake.

To reproduce, run e.g. "pdftk ."

I obtain the following result:

Unhandled Java Exception in main():
java.lang.NullPointerException
   at gnu.gcj.runtime.NameFinder.lookup(libgcj.so.15)
   at java.lang.Throwable.getStackTrace(libgcj.so.15)
   at java.lang.Throwable.stackTraceString(libgcj.so.15)
   at java.lang.Throwable.printStackTrace(libgcj.so.15)
   at java.lang.Throwable.printStackTrace(libgcj.so.15)

I would expect an error to be displayed. For instance, when running the command
"pdftk does_not_exist" where "does_not_exist" is a nonexistent file, the output
is:

Error: Unable to find file.
Error: Failed to open PDF file: 
   does_not_exist
Done.  Input errors, so no output created.

The output when trying to open a directory should be similar.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pdftk depends on:
ii  libc6   2.22-3
ii  libgcc1 1:5.3.1-12
ii  libgcj154.9.3-12
ii  libstdc++6  5.3.1-12

pdftk recommends no packages.

Versions of packages pdftk suggests:
ii  poppler-utils [xpdf-utils]  0.38.0-2

-- debconf-show failed

Bug#810896: linux-image-4.3.0-1-amd64: crashes when using eduroam wifi with driver rtl8723au

[Antoine Amarilli]

Package: src:linux
Version: 4.3.3-5
Severity: normal

Dear Maintainer,

I am experiencing frequent lockups on my laptop using linux-image-4.3.0-1-amd64
(though I already experienced the same problem with earlier kernel versions).
The problem seems to be triggered only when using WiFi, and more specifically
when using the eduroam network <https://en.wikipedia.org/wiki/Eduroam> -- I do
not have the problem when using a home WPA network.

Logs of the errors encountered (from syslog) are attached. Though some are in
the graphical stack, I would suspect that the problem is caused by the WiFi
driver rtl8723au. In particular log0 seems to be about this driver, and log1 is
specific to wpa_supplicant.

The problem often occurs a few seconds/minutes after associating to the eduroam
network, in which cases the display freezes (sometimes partially, e.g., display
is no longer updated but using the keyboard/mouse does not work). Magic SysRq
sometimes works and sometimes doesn't. Sadly I am not aware of a way to
reproduce the crash reliably.

Please ignore the "Unknown key pressed" spam in the Kernel log below, which is
caused by another issue
<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1227996>.

Thanks!

-- 
Antoine Amarilli

-- Package-specific info:
** Version:
Linux version 4.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160101 (Debian 5.3.1-5) ) #1 SMP Debian 4.3.3-5 (2016-01-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 
root=UUID=e3b76e5e-ee21-46dd-b5e2-a4b17f0a00b0 ro cgroup_enable=memory 
i915.enable_execlists=0 resume=UUID=fbf08c76-a232-4d9a-8d4e-70032070617a

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[  881.574297] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  881.574309] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  881.579348] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  881.579358] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  882.582798] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  882.582813] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  882.587597] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  882.587611] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  883.599962] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  883.599976] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  883.605018] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  883.605028] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  884.623318] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  884.623331] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  884.628378] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  884.628387] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  885.630411] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  885.630422] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  885.635440] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  885.635450] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  886.648435] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  886.648452] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  886.653449] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  886.653462] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  887.655401] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  887.655414] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  887.660420] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  887.660430] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  888.663387] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  888.663400] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  888.668417] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  888.668428] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  889.670599] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  889.670616] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  889.675624] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  889.675636] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  890.707890] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  890.707903] atkbd serio0: Use 'setkeycodes e03e ' to make it known.
[  890.712942] atk

Bug#810896: Further info

[Antoine Amarilli]

I should also point out that similar problems with the driver were
reported earlier, for instance
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765685>

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#806948: #806948

[Antoine Amarilli]

It is annoying to get spam from cron because of this issue, I already
edited the script to fix this, but it would be great if a fix could be
pushed.

That said, while the proposed patch is the correct way to replace the
deprecated option by the equivalent options suggested by the man, I'm a
bit surprised to see --allow-remove-essential here. I'm not sure about
the context, but from the manpage, it looks like this is potentially
dangerous, and I don't see why it is a good idea here. Same remark for
--allow-unauthenticated given on the same line and elsewhere in the
apticron script, it looks like this could be a security risk.

Best,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#802100: gnupg should fetch keys using hkps by default

[Antoine Amarilli]

Package: gnupg
Version: 1.4.19-5
Severity: wishlist

Dear Maintainer,

By default, gpg requests keys using HKP server . This allows a
passive attacker to obtain information about the keys requested by the user,
which may be harmful in terms of privacy.

I think that gpg should be using an HKPS server by default. See e.g.,
<https://help.riseup.net/en/security/message-security/openpgp/best-practices#use-the-sks-keyserver-pool-instead-of-one-specific-server-with-secure-connections>

See also a similar bug for dirmngr:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784286>.

Best regards,

-- 
Antoine Amarilli


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gpgv  1.4.19-5
ii  libbz2-1.01.0.6-8
ii  libc6 2.19-22
ii  libreadline6  6.3-8+b3
ii  libusb-0.1-4  2:0.1.12-27
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  gnupg-curl 1.4.19-5
ii  libldap-2.4-2  2.4.42+dfsg-2

Versions of packages gnupg suggests:
ii  eog   3.18.0-1
pn  gnupg-doc 
ii  imagemagick   8:6.8.9.9-6
ii  libpcsclite1  1.8.14-1
ii  parcimonie0.9-3

-- debconf-show failed

Bug#802020: gnupg: PINENTRY_USER_DATA environment variable is not sent to pinentry

[Antoine Amarilli]

Package: gnupg
Version: 1.4.19-5
Severity: normal

The manpage of gpg states that the PINENTRY_USER_DATA environment variable is
passed via gpg-agent to pinentry. However this doesn't seem to be true. Setting
pinentry-program in ~/.gnupg-gpg-agent.conf to a script that dumps its
environment to a file, I don't see any PINENTRY_USER_DATA when calling gpg with
the following invocation:

  gpg --sign testfile

However, the exact same thing works with gpg2.

Looking around in the source tree for gnupg, I'm confused because it seems like
PINENTRY_USER_DATA isn't mentioned anywhere except in the doc. (It occurs in
gnupg2, however.) Unless I'm getting something wrong, PINENTRY_USER_DATA should
be removed from the gnupg documentation, or support for that variable should be
actually implemented.

-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gpgv  1.4.19-5
ii  libbz2-1.01.0.6-8
ii  libc6 2.19-22
ii  libreadline6  6.3-8+b3
ii  libusb-0.1-4  2:0.1.12-27
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  gnupg-curl 1.4.19-5
ii  libldap-2.4-2  2.4.42+dfsg-2

Versions of packages gnupg suggests:
ii  eog   3.18.0-1
pn  gnupg-doc 
ii  imagemagick   8:6.8.9.9-6
ii  libpcsclite1  1.8.14-1
ii  parcimonie0.9-3

-- debconf-show failed

Bug#801476: python3-lxml: Cannot import lxml.html.soupparser.fromstring, depends on outdated BeautifulSoup

[Antoine Amarilli]

Package: python3-lxml
Version: 3.4.4-1+b1
Severity: normal

Dear Maintainer,

When trying to perform the following with Python 3:

  from lxml.html.soupparser import fromstring

The following error is raised:

  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/lxml/html/soupparser.py", line 7, in 

  from BeautifulSoup import \
  ImportError: No module named 'BeautifulSoup'

According to StackOverflow <http://stackoverflow.com/q/14042023>, this is
because the currently packaged version of python3-lxml depends on version 3 of
BeautifulSoup. However, Debian ships version 4 of that module (python3-bs4).
According to the same source, recent lxml versions know how to use version 4 of
BeautifulSoup, see e.g.,
<https://github.com/lxml/lxml/blob/master/src/lxml/html/soupparser.py>.

I think this change should be ported to the Debian version (or the Debian
version updated) so that python3-lxml works with python3-bs4.

-- 
Antoine Amarilli


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-lxml depends on:
ii  libc6   2.19-22
ii  libxml2 2.9.2+zdfsg1-4
ii  libxslt1.1  1.1.28-2+b2
ii  python3 3.4.3-6
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages python3-lxml recommends:
ii  python3-bs4   4.4.0-1
ii  python3-html5lib  0.999-3

Versions of packages python3-lxml suggests:
pn  python-lxml-doc   
pn  python3-lxml-dbg  

-- no debconf information

Bug#739271: Bug still occurs

[Antoine Amarilli]

I can still reproduce this bug on xpdf 3.03 (3.03-17+b1). Key bindings
commands in xpdfrc are silently ignored, which is pretty confusing.

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#792669: dovecot-sieve: sieve-test segfaults with editheader

[Antoine Amarilli]

Package: dovecot-sieve
Version: 1:2.2.18-1
Severity: normal

Dear Maintainer,

On my system, sieve-test segfaults on the following minified Sieve script:

require [editheader];
addheader foo bar;
if header :is foo baz { }

To reproduce, put the above script in script.sieve and do the following:

echo  mail
cat  dovecot.conf EOF
plugin {
  sieve_extensions = +editheader
}
EOF
sieve-test -c dovecot.conf script.sieve mail

The sieve-test command should segfault.

Here is a backtrace:

#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x77b747c7 in _header_right_trim (raw=0x3 error: Cannot access 
memory at address 0x3)
at sieve-message.c:492
#2  sieve_message_header_stringlist_next_item (_strlist=0x5575d120, 
str_r=0x7fffe940)
at sieve-message.c:556
#3  0x77b8b371 in sieve_stringlist_next_item (str_r=0x7fffe940, 
strlist=0x5575d120)
at sieve-stringlist.h:44
#4  sieve_match (renv=renv@entry=0x55791ab0, 
mcht=mcht@entry=0x7fffe9d0, 
cmp=cmp@entry=0x7fffe9b0, value_list=0x5575d120, 
key_list=0x5575d0c8, 
exec_status=exec_status@entry=0x7fffe99c) at sieve-match.c:181
#5  0x77b91730 in tst_header_operation_execute (renv=0x55791ab0, 
address=0x55791af8)
at tst-header.c:193
#6  0x77b828f7 in sieve_interpreter_operation_execute 
(interp=0x55791a80)
at sieve-interpreter.c:542
#7  sieve_interpreter_continue (interp=interp@entry=0x55791a80, 
interrupted=interrupted@entry=0x0)
at sieve-interpreter.c:573
#8  0x77b82a4a in sieve_interpreter_start 
(interp=interp@entry=0x55791a80, 
result=optimized out, interrupted=interrupted@entry=0x0) at 
sieve-interpreter.c:604
#9  0x77b82a7b in sieve_interpreter_run (interp=0x55791a80, 
result=0x55798e00)
at sieve-interpreter.c:615
#10 0x77b94f8f in sieve_run (sbin=0x5577aeb0, 
result=result@entry=0x7fffeae0, 
msgdata=0x7fffebc0, senv=senv@entry=0x7fffebf0, 
ehandler=0x557799e0, 
flags=optimized out) at sieve.c:335
#11 0x77b959cc in sieve_test (sbin=optimized out, msgdata=optimized 
out, 
senv=0x7fffebf0, ehandler=optimized out, stream=0x5578b6f0, 
flags=optimized out, 
keep=0x0) at sieve.c:496
#12 0x77d7 in main (argc=6, argv=0x55764390) at sieve-test.c:295

sieve-test used to work fine on the (non-minified) script on which it now
segfaults, so this bug was probably introduced by a recent version.

-- Package-specific info:

dovecot configuration
-
# 2.2.18: /etc/dovecot/dovecot.conf
# OS: Linux 4.0.0-2-amd64 x86_64 Debian stretch/sid 
mail_location = mbox:~/mail:INBOX=/var/mail/%u
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox Sent Messages {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  driver = pam
}
plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
}
ssl = no
userdb {
  driver = passwd
}

-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.2.18-1
ii  libc6 2.19-18
ii  ucf   3.0030

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.2.18-1
ii  dovecot-dbg1:2.2.18-1
pn  dovecot-devnone
pn  dovecot-gssapi none
pn  dovecot-imapd  none
pn  dovecot-ldap   none
pn  dovecot-lmtpd  none
pn  dovecot-managesieved   none
pn  dovecot-mysql  none
pn  dovecot-pgsql  none
pn  dovecot-pop3d  none
ii  dovecot-sieve  1:2.2.18-1
pn  dovecot-sqlite none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786590: dwb: segfaults with libwebkitgtk-3.0-0 2.4.9-1

[Antoine Amarilli]

Package: dwb
Version: 20150419git-1
Followup-For: Bug #786590

I can reproduce this bug with a later version of dwb and the same version of
libwebkitgtk. To make dwb segfault, it suffices to run it and press the keys
O, a, enter, d.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dwb depends on:
ii  libc6   2.19-18
ii  libcairo2   1.14.2-2
ii  libgdk-pixbuf2.0-0  2.31.4-2
ii  libglib2.0-02.44.1-1
ii  libgnutls-deb0-28   3.3.15-6
ii  libgtk-3-0  3.14.13-1
ii  libjavascriptcoregtk-3.0-0  2.4.9-1
ii  libpango-1.0-0  1.36.8-3
ii  libsecret-1-0   0.18.2-1
ii  libsoup2.4-12.50.0-2
ii  libwebkitgtk-3.0-0  2.4.9-1
ii  libx11-62:1.6.3-1

Versions of packages dwb recommends:
ii  wget   1.16.3-2+b2
ii  xterm  318-2

dwb suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786871: evince segfaults on PS document that is correctly rendered with Okular

[Antoine Amarilli]

Package: evince
Version: 3.14.1-2
Severity: normal

Dear Maintainer,

Opening the file http://www.inf.ed.ac.uk/teaching/courses/ads/Lectures/lec16.ps
with evince results in a segfault.

The same file seems to render correctly with Okular which seems to be using the
same PS rendering library (libspectre), so my understanding is that this is an
evince-specific bug and not a bug of the underlying library.

Regards,

-- 
Antoine Amarilli


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evince depends on:
ii  evince-common  3.14.1-2
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  libatk1.0-02.16.0-2
ii  libc6  2.19-18
ii  libcairo-gobject2  1.14.2-2
ii  libcairo2  1.14.2-2
ii  libevdocument3-4   3.14.1-2
ii  libevview3-3   3.14.1-2
ii  libgdk-pixbuf2.0-0 2.31.4-1
ii  libglib2.0-0   2.44.1-1
ii  libgtk-3-0 3.14.5-1
ii  libnautilus-extension1a3.14.2-1
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libsecret-1-0  0.18.2-1
ii  libxml22.9.1+dfsg1-5
ii  shared-mime-info   1.3-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages evince recommends:
ii  dbus-x11  1.8.18-1
pn  gvfs  none

Versions of packages evince suggests:
pn  nautilus  none
ii  poppler-data  0.4.7-3
ii  unrar 1:5.2.7-0.1

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785452: openjdk-7-jre-headless: not really headless, indirectly depends on libx11-6 and others

[Antoine Amarilli]

Package: openjdk-7-jre-headless
Severity: normal

Dear Maintainer,

openjdk-7-jre-headless depends (in version 7u79-2.5.5-1~deb8u1) on libpulse0,
which depends (in version 5.0-13) on libx11-6, libx11-xcb1, libxcb1, libxtst6,
themselves depending on other X-related packages. Hence the
openjdk-7-jre-headless package is not really headless -- I cannot install it
on my headless server without installing loads of GUI-related packages.

I am not sure how to solve this, but I guess one should check whether there is
good reason for these dependencies, or whether one could package separately a
headless version of libpulse0?

Thanks!

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761023: bb: Visual stops when audio starts under pulseaudio

[Antoine Amarilli]

On Sun, Apr 12, 2015 at 12:03:00AM +0200, Axel Beckert wrote:
 Antoine Amarilli wrote:
  It makes me wonder; would it make sense, instead of disabling the music
  by default, to have a wrapper that runs bb with this hack, so that the
  music can work? (Otherwise the user need to find and read the README to
  find out about this, which is not ideal...)
 
 Yes, that idea came to me, too, and may be a valid fix for this bug
 (which is still open), BUT it's definitely out of scope for the Jessie
 release.

Sure. I was suggesting this in general, I don't know anything about
specific milestones. :)

 The fix I'm imagining would be a wrapper script which does the
 following:
 
 * Checking if it runs under X and PulseAudio is active.
 * If so, use the above mention commandline.
 * Else just start bb normaly.

Indeed I had missed that pulseaudio depended on pulseaudio-utils, so
it's reasonable to assume that pasuspender is available whenever
pulseaudio is run and there was no reason to worry. Sorry for the
confusion. Your suggestion looks fine to me.

-- 
Antoine Amarilli



signature.asc
Description: Digital signature

Bug#761023: bb: Visual stops when audio starts under pulseaudio

[Antoine Amarilli]

On Fri, Apr 10, 2015 at 07:29:57PM -0400, Anthony DeRobertis wrote:
 If you do a README.Debian update to fix that typo, here is another
 thing to add—this makes bb work on my PA system:
 
 pasuspender -- env PULSE_SERVER= bb
 
 pasuspender makes PulseAudio release the sound hardware, then setting
 PULSE_SERVER= to blank makes bb not connect to PA (falling back to ALSA
 instead, which works).

That's very nice, thanks!

It makes me wonder; would it make sense, instead of disabling the music
by default, to have a wrapper that runs bb with this hack, so that the
music can work? (Otherwise the user need to find and read the README to
find out about this, which is not ideal...)

Of course, the devil is in the details: implementing this solution would
require pasuspender, hence pulseaudio-utils; however having bb depend on
pulseaudio-utils would be strange as the hack is only needed because of
pulseaudio itself. Ideally the wrapper could be smarter and only disable
the music when pulseaudio seems in use but pasuspender is not installed,
but that's not so easy because bb does not seems to have flags to
control the music from the command-line when running it.

So I don't know if that's a reasonable idea, but I wanted to make the
suggestion.

-- 
Antoine Amarilli



signature.asc
Description: Digital signature

Bug#761023: Typo in README.Debian

[Antoine Amarilli]

Thanks for mitigating this issue, but I wanted to point out the
following typo in /usr/share/doc/bb/README.Debian: turned of should
be turned off.

Best,

-- 
Antoine Amarilli



signature.asc
Description: Digital signature

Bug#771045: Acknowledgement (linux-image-3.16.0-4-amd64: System randomly freezes using Kernel 3.16 and radeon)

[Antoine Amarilli]

It seems like the bug was already reported in mesa:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774784
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775264

Otherwise, I confirm that I have been running with Mesa 10.3.4 for
two weeks on the machine that used to crash occasionally, and not
encountered any crash since.

In case anyone also needs to install Mesa by hand and does not know how
to do so, I have documented the process:
http://a3nm.net/blog/debian_mesa.html.



signature.asc
Description: Digital signature

Bug#771045: Acknowledgement (linux-image-3.16.0-4-amd64: System randomly freezes using Kernel 3.16 and radeon)

[Antoine Amarilli]

I have rebuilt and installed Mesa version 10.3.4 (for amd64 and i386)
which includes a patch http://patchwork.freedesktop.org/patch/36714/
that is supposed to help. I will post back in 2 weeks to say whether I
still got a crash or not with this newer version.

-- 
Antoine Amarilli


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771045: Acknowledgement (linux-image-3.16.0-4-amd64: System randomly freezes using Kernel 3.16 and radeon)

[Antoine Amarilli]

I am also affected by this bug. I attached what seems to be the relevant
part of syslog when the bug occurs. I don't know how to reproduce the
bug, but it tends to crash my computer about every week. It tends to
trigger more often when playing video or using Skype. The machine
freezes and the screen goes blank after a few seconds.

My video card is reported by lshw as:

  product: Heathrow XT [Radeon HD 7870M]

I can provide more information if needed.

Jan  5 12:09:57 sampi kernel: [146.023044] radeon :01:00.0: ring 0 
stalled for more than 10496msec
Jan  5 12:09:57 sampi kernel: [146.023051] radeon :01:00.0: GPU lockup 
(waiting for 0x00017ad6 last fence id 0x00017ad5 on ring 0)
Jan  5 12:09:57 sampi kernel: [146.023057] radeon :01:00.0: failed to 
get a new IB (-35)
Jan  5 12:09:57 sampi kernel: [146.559117] radeon :01:00.0: Saved 5917 
dwords of commands on ring 0.
Jan  5 12:09:57 sampi kernel: [146.559186] radeon :01:00.0: GPU 
softreset: 0x006C
Jan  5 12:09:57 sampi kernel: [146.559197] radeon :01:00.0:   
GRBM_STATUS   = 0xA0003028
Jan  5 12:09:57 sampi kernel: [146.559199] radeon :01:00.0:   
GRBM_STATUS_SE0   = 0x0006
Jan  5 12:09:57 sampi kernel: [146.559201] radeon :01:00.0:   
GRBM_STATUS_SE1   = 0x0006
Jan  5 12:09:57 sampi kernel: [146.559202] radeon :01:00.0:   
SRBM_STATUS   = 0x2AC0
Jan  5 12:09:57 sampi kernel: [146.559259] radeon :01:00.0:   
SRBM_STATUS2  = 0x
Jan  5 12:09:57 sampi kernel: [146.559261] radeon :01:00.0:   
R_008674_CP_STALLED_STAT1 = 0x
Jan  5 12:09:57 sampi kernel: [146.559263] radeon :01:00.0:   
R_008678_CP_STALLED_STAT2 = 0x0001
Jan  5 12:09:57 sampi kernel: [146.559265] radeon :01:00.0:   
R_00867C_CP_BUSY_STAT = 0x0002
Jan  5 12:09:57 sampi kernel: [146.559267] radeon :01:00.0:   
R_008680_CP_STAT  = 0x80010243
Jan  5 12:09:57 sampi kernel: [146.559268] radeon :01:00.0:   
R_00D034_DMA_STATUS_REG   = 0x44483146
Jan  5 12:09:57 sampi kernel: [146.559270] radeon :01:00.0:   
R_00D834_DMA_STATUS_REG   = 0x44C84246
Jan  5 12:09:57 sampi kernel: [146.559272] radeon :01:00.0:   
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x
Jan  5 12:09:57 sampi kernel: [146.559274] radeon :01:00.0:   
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x
Jan  5 12:09:58 sampi kernel: [1460001.083260] radeon :01:00.0: 
GRBM_SOFT_RESET=0xDDFF
Jan  5 12:09:58 sampi kernel: [1460001.083314] radeon :01:00.0: 
SRBM_SOFT_RESET=0x00100140
Jan  5 12:09:58 sampi kernel: [1460001.084463] radeon :01:00.0:   
GRBM_STATUS   = 0x3028
Jan  5 12:09:58 sampi kernel: [1460001.084465] radeon :01:00.0:   
GRBM_STATUS_SE0   = 0x0006
Jan  5 12:09:58 sampi kernel: [1460001.084467] radeon :01:00.0:   
GRBM_STATUS_SE1   = 0x0006
Jan  5 12:09:58 sampi kernel: [1460001.084469] radeon :01:00.0:   
SRBM_STATUS   = 0x20C0
Jan  5 12:09:58 sampi kernel: [1460001.084525] radeon :01:00.0:   
SRBM_STATUS2  = 0x
Jan  5 12:09:58 sampi kernel: [1460001.084528] radeon :01:00.0:   
R_008674_CP_STALLED_STAT1 = 0x
Jan  5 12:09:58 sampi kernel: [1460001.084530] radeon :01:00.0:   
R_008678_CP_STALLED_STAT2 = 0x
Jan  5 12:09:58 sampi kernel: [1460001.084532] radeon :01:00.0:   
R_00867C_CP_BUSY_STAT = 0x
Jan  5 12:09:58 sampi kernel: [1460001.084533] radeon :01:00.0:   
R_008680_CP_STAT  = 0x
Jan  5 12:09:58 sampi kernel: [1460001.084535] radeon :01:00.0:   
R_00D034_DMA_STATUS_REG   = 0x44C83D57
Jan  5 12:09:58 sampi kernel: [1460001.084537] radeon :01:00.0:   
R_00D834_DMA_STATUS_REG   = 0x44C83D57
Jan  5 12:09:58 sampi kernel: [1460001.084672] radeon :01:00.0: GPU reset 
succeeded, trying to resume
Jan  5 12:09:58 sampi NetworkManager[784]: info (wlan0): supplicant interface 
state: starting - down
Jan  5 12:09:58 sampi kernel: [1460001.113559] [drm] probing gen 2 caps for 
device 8086:151 = 261ad03/e
Jan  5 12:09:58 sampi kernel: [1460001.113564] [drm] PCIE gen 3 link speeds 
already enabled
Jan  5 12:09:58 sampi kernel: [1460001.116459] [drm] PCIE GART of 1024M enabled 
(table at 0x00276000).
Jan  5 12:09:58 sampi kernel: [1460001.116795] radeon :01:00.0: WB enabled
Jan  5 12:09:58 sampi kernel: [1460001.116799] radeon :01:00.0: fence 
driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x8800cde5ec00
Jan  5 12:09:58 sampi kernel: [1460001.116802] radeon :01:00.0: fence 
driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x8800cde5ec04
Jan  5 12:09:58 sampi kernel: [1460001.116805] radeon :01:00.0: fence 
driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x8800cde5ec08
Jan  5 12:09:58 sampi kernel: [1460001.116807] radeon 

Bug#774529: parcimonie: please split parcimonie-applet to a different package

[Antoine Amarilli]

Package: parcimonie
Version: 0.8.4-1
Severity: wishlist

Dear Maintainer,

parcimonie depends on libgtk3-perl, which means that it cannot be installed on a
headless system without including a bunch of dependencies. The reason for this
seems to be the presence of parcimonie-applet in the parcimonie package;
however, for the core functionality of parcimonie, no graphical dependencies
should be required.

Would it be possible to split parcimonie-applet to its own package, so that
parcimonie itself can be installed on headless systems?

Thanks!

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages parcimonie depends on:
ii  libclone-perl0.37-1+b1
ii  libconfig-general-perl   2.56-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-which-perl   1.09-1
ii  libglib-perl 3:1.305-2
ii  libgnupg-interface-perl  0.50-3
ii  libgtk3-perl 0.018-1
ii  liblist-moreutils-perl   0.33-2+b1
ii  liblocale-gettext-perl   1.05-8+b1
ii  libmoo-perl  1.006001-1
ii  libmoox-late-perl0.015-1
ii  libmoox-options-perl 4.012-1
ii  libnamespace-clean-perl  0.25-1
ii  libnet-dbus-glib-perl0.33.0-1+b4
ii  libnet-dbus-perl 1.0.0-2+b2
ii  libpango-perl1.226-2
ii  libpath-tiny-perl0.058-1
ii  libtime-duration-parse-perl  0.11-1
ii  libtry-tiny-perl 0.22-1
ii  libtype-tiny-perl1.04-1
ii  libtypes-path-tiny-perl  0.005-1
ii  perl 5.20.1-4
ii  perl-modules 5.20.1-4
ii  torsocks 2.0.0-3

Versions of packages parcimonie recommends:
ii  gnupg-curl  1.4.18-6
ii  tor 0.2.5.10-1

parcimonie suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771724: python-pygments: pygmentize fails when writing UTF-8 to output files

[Antoine Amarilli]

Package: python-pygments
Version: 2.0~rc1.a2bc2bd+dfsg-1
Severity: normal

Dear Maintainer,

When pygmentize is asked to write its output to a file, and the output contains
UTF-8 characters, the program crashes.

To reproduce:

  echo é  foo.html
  pygmentize -o out.tex foo.html

Resulting in the following error:

*** Error while highlighting:
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: 
ordinal not in range(128)
   (file /usr/lib/python2.7/dist-packages/pygments/formatters/latex.py, line 
411, in format_unencoded)

Note that I couldn't reproduce this problem when testing against revision 3562
of the upstream repository. Also, pygmentize from Debian is essentially
unchanged from this repository (except for the shebang), so I think the problem
is not in the pygmentize program itself but in the pygments library packaged.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-pygments depends on:
ii  python  2.7.8-2
pn  python:any  none

Versions of packages python-pygments recommends:
ii  python-chardet2.3.0-1
ii  python-pkg-resources  5.5.1-1

Versions of packages python-pygments suggests:
pn  ttf-bitstream-vera  none

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#385702: w3m rejects valid cookies based on false assumptions

[Antoine Amarilli]

w3m 0.5.3 includes an option to work around this problem for specific
domains (function check_avoid_wrong_number_of_dots_domain in cookie.c).
However, this is not a satisfactory solution, so the problem still
stands.

-- 
Antoine Amarilli



signature.asc
Description: Digital signature