Bug#947189: gthumb: segfaults when double clicking on the rotate to the right button
Package: gthumb Version: 3:3.8.0-2 Severity: normal Dear Maintainer, Steps to reproduce: * open gthumb * double click on a photo * open the "modify file" toolbar * double click on the "rotate to the right" button Expected outcome: the photo is rotated by 180° Actual outcome: gthumb segfaults. gdb is unable to print the whole backtrace with debug symbols (it hangs, using 100% of a CPU forever) so I put here both the backtrace without debug symbols of coredumpctl debug and the truncated backtrace by gdb: Signal: 11 (SEGV) Timestamp: Sun 2019-12-22 18:57:30 CET (10s ago) Command Line: gthumb Executable: /usr/bin/gthumb Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal- server.service Unit: user@1000.service User Unit: gnome-terminal-server.service Slice: user-1000.slice Owner UID: 1000 (plectrude) Boot ID: d283f182437547d9bb59f2fd1b4cf745 Machine ID: ca9798c5968d4333b3dd9b9d95d01001 Hostname: Mouah-PC Storage: /var/lib/systemd/coredump/core.gthumb.1000.d283f182437547d9bb59f2fd1b4cf745.9466.1577037450.lz4 Message: Process 9466 (gthumb) of user 1000 dumped core. Stack trace of thread 9466: #0 0x7fc47d80a310 g_signal_emit_valist (libgobject-2.0.so.0 + 0x2f310) #1 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #2 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #3 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #4 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #5 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #6 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #7 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #8 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #9 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #10 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #11 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #12 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #13 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #14 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #15 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #16 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #17 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #18 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #19 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #20 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #21 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #22 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #23 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #24 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #25 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #26 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #27 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #28 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #29 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #30 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #31 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #32 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #33 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #34 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #35 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #36 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #37 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0 + 0x3081f) #38 0x7fc47d7eedc4 g_closure_invoke (libgobject-2.0.so.0 + 0x13dc4) #39 0x7fc47d8024d4 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x274d4) #40 0x7fc47d80b18f g_signal_emit_valist (libgobject-2.0.so.0 + 0x3018f) #41 0x7fc47d80b81f g_signal_emit (libgobject-2.0.so.0
Bug#944427: duplicity: TypeError while restoring backup of file on external drive with giobackend
Package: duplicity
Version: 0.8.05-2
Severity: important
Tags: patch
Dear Maintainer,
Today I tried to restore directory from a backup with deja-dup. The restoration
always failed with the following traceback:
Traceback (innermost last):
File "/usr/bin/duplicity", line 107, in
with_tempdir(main)
File "/usr/bin/duplicity", line 93, in with_tempdir
fn()
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1521, in
main
action = commandline.ProcessCommandLine(sys.argv[1:])
File "/usr/lib/python3/dist-packages/duplicity/commandline.py", line 1216, in
ProcessCommandLine
backup, local_pathname = set_backend(args[0], args[1])
File "/usr/lib/python3/dist-packages/duplicity/commandline.py", line 1087, in
set_backend
globals.backend = backend.get_backend(bend)
File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 225, in
get_backend
obj = get_backend_object(url_string)
File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 211, in
get_backend_object
return factory(pu)
File "/usr/lib/python3/dist-packages/duplicity/backends/giobackend.py", line
81, in __init__
ensure_dbus()
File "/usr/lib/python3/dist-packages/duplicity/backends/giobackend.py", line
37, in ensure_dbus
lines = output.split(u'\n')
TypeError: a bytes-like object is required, not 'str'
The folder in question is on a secondary, ntfs drive. If I try to restore a
file on the main drive,
no error happens. This is probably because deja-dup does not use the gio
backend in this case.
The following patch fixes the problem for me:
--- /tmp/foo.py 2019-11-09 22:52:50.535057865 +0100
+++ /usr/lib/python3/dist-packages/duplicity/backends/giobackend.py
2019-11-09 22:53:22.780500816 +0100
@@ -33,7 +33,7 @@
# when required. So we make sure that such a bus exists and that our
# environment points to it.
if u'DBUS_SESSION_BUS_ADDRESS' not in os.environ:
-output = subprocess.Popen([u'dbus-launch'],
stdout=subprocess.PIPE).communicate()[0]
+output = subprocess.Popen([u'dbus-launch'],
stdout=subprocess.PIPE).communicate()[0].decode("utf8", errors="replace")
lines = output.split(u'\n')
for line in lines:
parts = line.split(u'=', 1)
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages duplicity depends on:
ii gnupg 2.2.17-3
ii libc6 2.29-2
ii librsync2 2.0.2-1
ii python33.7.3-1
ii python3-fasteners 0.12.0-5
ii python3-future 0.16.0-1
ii python3-lockfile 1:0.12.2-2
Versions of packages duplicity recommends:
ii python3-oauthlib 2.1.0-1
ii python3-paramiko 2.6.0-1
ii python3-pexpect 4.6.0-1
ii python3-urllib3 1.24.1-1
ii rsync 3.1.3-6+b1
Versions of packages duplicity suggests:
pn lftp
pn ncftp
pn par2
pn python3-boto
ii python3-pip 18.1-5
pn python3-swiftclient
pn tahoe-lafs
-- no debconf information
--- /tmp/foo.py 2019-11-09 22:52:50.535057865 +0100
+++ /usr/lib/python3/dist-packages/duplicity/backends/giobackend.py
2019-11-09 22:53:22.780500816 +0100
@@ -33,7 +33,7 @@
# when required. So we make sure that such a bus exists and that our
# environment points to it.
if u'DBUS_SESSION_BUS_ADDRESS' not in os.environ:
-output = subprocess.Popen([u'dbus-launch'],
stdout=subprocess.PIPE).communicate()[0]
+output = subprocess.Popen([u'dbus-launch'],
stdout=subprocess.PIPE).communicate()[0].decode("utf8", errors="replace")
lines = output.split(u'\n')
for line in lines:
parts = line.split(u'=', 1)
--- /tmp/foo.py 2019-11-09 22:52:50.535057865 +0100
+++ /usr/lib/python3/dist-packages/duplicity/backends/giobackend.py
2019-11-09 22:53:22.780500816 +0100
@@ -33,7 +33,7 @@
# when required. So we make sure that such a bus exists and that our
# environment points to it.
if u'DBUS_SESSION_BUS_ADDRESS' not in os.environ:
-output = subprocess.Popen([u'dbus-launch'],
stdout=subprocess.PIPE).communicate()[0]
+output = subprocess.Popen([u'dbus-launch'],
stdout=subprocess.PIPE).communicate()[0].decode("utf8", errors="replace")
lines = output.split(u'\n')
for line in lines:
parts = line.split(u'=', 1)
Bug#907260: roundcube: database table `session` is never cleaned and grows without limit
Package: roundcube
Version: 1.3.6+dfsg.1-1
Severity: normal
Dear Maintainer,
The table `session` of my roundcube database contained several months
worth of sessions, even though the lifetime of a session is 1200 seconds
(the default I think). This made this sole table more than 100MB.
Actual behavior: the last oldest row in the table is more than 8 months
old.
Expected behavior: the last oldest row in the table is not more than a
few days old (that is a few times $session_lifetime).
The reason of the problem seems to be the following: according to
https://github.com/roundcube/roundcubemail/issues/1864 roundcube relies
on vanilla php session gc. Debian disables it by setting
session.gc_probability to 0 and replaces it by a custom
phpsessionclean.{service,timer}. This script unfortunately only works on
sessions stored as files, and therefore does not clean roundcube
sessions.
I have implemented the following solution: roundcube ships a script to
gc manually: /usr/share/roundcube/bin/gc.sh
Unfortunately this script is slightly broken: when run I get
ERROR: Configuration error. Unsupported database driver:
According to strace, this script looks for roundcube's configuration
in /usr/share/roundcube/config/ instead of /etc/roundcube
Workaround:
ln -s /etc/roundcube/ /usr/share/roundcube/config
Similarly, I needed ln -s /tmp/ /usr/share/roundcube/temp
Then, bin/gc.sh works and I can make a systemd timer like
phpsessionclean:
# /etc/systemd/system/roundcube-gc.service
[Unit]
Description=Clean roundcube session table
[Service]
User=www-data
Type=oneshot
ExecStart=/usr/share/roundcube/bin/gc.sh
ProtectHome=true
ProtectSystem=true
PrivateTmp=true
# /etc/systemd/system/roundcube-gc.timer
[Unit]
Description=Clean roundcube session table every 30 mins
[Timer]
OnCalendar=*-*-* *:09,39:00
Persistent=true
[Install]
WantedBy=timers.target
I have been unable to trigger session gc by the vanilla php mechanism,
either in the nginx config or in /etc/php/7.2/fpm/php.ini, even with
session.gc_probability=1
session.gc_divisor=1
To sum up, it would be nice to fix bin/gc.sh and ship a timer to run it
periodically, possibly by default.
Thanks
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages roundcube depends on:
ii dpkg1.19.0.5+b1
ii roundcube-core 1.3.6+dfsg.1-1
roundcube recommends no packages.
roundcube suggests no packages.
Versions of packages roundcube-core depends on:
ii dbconfig-common 2.0.9
ii debconf [debconf-2.0] 1.5.69
ii dpkg1.19.0.5+b1
ii libmagic1 1:5.34-2
ii php 1:7.2+62
ii php-auth-sasl 1.0.6-3
ii php-common 1:62
ii php-intl1:7.2+62
ii php-mail-mime 1.10.2-0.1
ii php-net-sieve 1.4.1-1
ii php-net-smtp1.8.0-1
ii php-net-socket 1.0.14-2
ii php-pear1:1.10.5+submodules+notgz-1
ii php7.2 [php]7.2.9-1
ii php7.2-cli [php-cli]7.2.9-1
ii php7.2-intl [php-intl] 7.2.9-1
ii php7.2-json [php-json] 7.2.9-1
ii roundcube-pgsql 1.3.6+dfsg.1-1
ii ucf 3.0038
Versions of packages roundcube-core recommends:
ii nginx-full [httpd-cgi] 1.13.12-1
ii php-fpm 1:7.2+62
ii php-gd 1:7.2+62
ii php-pspell 1:7.2+62
ii php7.2-fpm [php-fpm]7.2.9-1
ii php7.2-gd [php-gd] 7.2.9-1
ii php7.2-pspell [php-pspell] 7.2.9-1
Versions of packages roundcube-core suggests:
pn php-crypt-gpg
pn php-net-ldap2
pn php-net-ldap3
ii roundcube-plugins 1.3.6+dfsg.1-1
-- debconf information:
roundcube/dbconfig-reinstall: false
roundcube/remote/port:
roundcube/remote/newhost: localhost
roundcube/pgsql/method: TCP/IP
roundcube/dbconfig-upgrade: true
roundcube/pgsql/authmethod-user: password
roundcube/mysql/admin-user:
roundcube/upgrade-error: abort
roundcube/missing-db-package-error: abort
roundcube/reconfigure-webserver: apache2, lighttpd
roundcube/hosts:
roundcube/db/basepath:
roundcube/upgrade-backup: true
roundcube/dbconfig-remove: true
roundcube/remove-error: abort
roundcube/install-error: abort
roundcube/internal/skip-preseed: false
roundcube/pgsql/authmethod-admin: ident
roundcube/language: en_US
roundcube/pgsql/changeconf: false
* roundcube/database-type: pgsql
roundcube/internal/reconfiguring: false
roundcube/db/dbname: roundcube
roundcube/mysql/method: Unix socket
roundcube/db/app-user: roundcube@localhost
roundcube/pgsql/no-empty-passwords:
roundcube/pgsql/manualconf:
Bug#889507: icingaweb2: Fails with php7.2
Package: icingaweb2 Version: 2.4.1-1 Severity: important Dear Maintainer, php is now 7.2 in testing and upgrading from 7.0 to 7.2 broke icingaweb2 exactly as decribed here: https://github.com/Icinga/icingaweb2/issues/3185 I applied the patch discussed above: https://github.com/Icinga/icingaweb2/pull/3315 and it solved the problem. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages icingaweb2 depends on: ii icingaweb2-common 2.4.1-1 ii php-dompdf0.6.2+dfsg-3 ii php-htmlpurifier 4.7.0-2 ii php-xml 1:7.2+60 ii php7.2-xml [php-xml] 7.2.1-1 Versions of packages icingaweb2 recommends: ii icingacli 2.4.1-1 ii icingaweb2-module-doc 2.4.1-1 ii icingaweb2-module-monitoring 2.4.1-1 ii nginx-full [httpd]1.13.8-1 ii php 1:7.2+60 ii php-imagick 3.4.3~rc2-2+b1 ii php-intl 1:7.2+60 ii php-ldap 1:7.2+60 ii php7.0 [php] 7.0.27-1 ii php7.0-cli [php-cli] 7.0.27-1 ii php7.0-intl [php-intl]7.0.27-1 ii php7.0-json [php-json]7.0.27-1 ii php7.0-ldap [php-ldap]7.0.27-1 ii php7.2 [php] 7.2.1-1 ii php7.2-cli [php-cli] 7.2.1-1 ii php7.2-intl [php-intl]7.2.1-1 ii php7.2-json [php-json]7.2.1-1 ii php7.2-ldap [php-ldap]7.2.1-1 icingaweb2 suggests no packages. -- no debconf information
