Bug#972270: Acknowledgement (sogo: Webmail loads indefinitely when opening message with invitation)
I see that this has been “Marked as fixed in versions sogo/4.0.8-1”. However, this version is not in buster – would it be possible to update it there? Thanks, Thomas -- Allgemeiner Studierendenausschuss (AStA) der RWTH Aachen Thomas Schneider IT-Administration Pontwall 3 52062 Aachen Deutschland Telefon: +49 241 80 93798 Web: https://www.asta.rwth-aachen.de
Bug#972270: sogo: Webmail loads indefinitely when opening message with invitation
Package: sogo Version: 4.0.7-1+deb10u1 Severity: important Dear Maintainer, When opening a mail with an attachment that has no file name, a part of SOGo crashes and the message does not show. This is a common case e. g. for calendar invitations. It has already been reported and fixed upstream. Please consider backporting the patch or upgrading to at least 4.0.8. Upstream report: https://sogo.nu/bugs/view.php?id=4702 Thanks, Thomas Schneider -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) 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 sogo depends on: ii adduser 3.118 ii gnustep-base-runtime 1.26.0-4+deb10u1 ii libc6 2.28-10 ii libcurl3-gnutls 7.64.0-4+deb10u1 ii libgcc1 1:8.3.0-6 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgnustep-base1.26 1.26.0-4+deb10u1 ii libgnutls30 3.6.7-4+deb10u5 ii liblasso3 2.6.0-2+b2 ii libmemcached111.0.18-4.2 ii libobjc4 8.3.0-6 ii libsbjson2.3 2.3.2-4+b1 ii libsope1 4.3.0-1asta1 ii lsb-base 10.2019051400 ii memcached 1.5.6-1.1 ii sogo-common 4.0.7-1+deb10u1 ii systemd 241-7~deb10u4 ii zip 3.0-11+b1 sogo recommends no packages. Versions of packages sogo suggests: pn postgresql | default-mysql-server | virtual-mysql-server -- no debconf information
Bug#965021: conntrackd: segfaults when not disabling internal cache
Package: conntrackd Version: 1:1.4.5-2 Severity: grave Justification: renders package unusable Dear Maintainer, I’m experiencing a problem with conntrackd. * What led up to the situation? I installed and configured conntrackd and simply started it. * What exactly did you do (or not do) that was effective (or ineffective)? I investigated the problem using gdb and valgrind. As the segfault happens in cache_ct_cmp(), by being passed a NULL pointer that it tries to dereference, I tried to disable the caches. Setting `DisableExternalCache on` led to the same behaviour. Setting `DisableInternalCache on` apparently fixed it, however this option is only available in NOTRACK mode (and I want to use FTFW mode). Since some hash related functions appear in the backtrace, I tried to change the value of HashSize and HashLimit. Based on more or less similar reports I found online, I tried disabling TCPWindowTracking and ExpectationSync. Neither one fixed the problem. * What was the outcome of this action? It segfaulted right after starting. Only with `DisableExternalCache on`, it produced any output (see below), without that, no output was produced. * What outcome did you expect instead? I expected it to work, or at least provide a sensible error message. *** /tmp/gdb.log # gdb -q --args conntrackd Reading symbols from conntrackd...Reading symbols from /usr/lib/debug/.build-id/ce/01eee7370eaa2a78b30857a5478c1b7f600bfe.debug...done. done. (gdb) r Starting program: /usr/sbin/conntrackd [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Tue Jul 14 16:48:55 2020] (pid=13845) [notice] disabling external cache Program received signal SIGSEGV, Segmentation fault. 0x55564ba1 in cache_ct_cmp (data1=0x0, data2=0x555afd60) at cache-ct.c:104 104 cache-ct.c: No such file or directory. (gdb) bt #0 0x55564ba1 in cache_ct_cmp (data1=0x0, data2=0x555afd60) at cache-ct.c:104 #1 0xf633 in hashtable_find (table=0x555a9810, data=data@entry=0x555afd60, id=) at hash.c:74 #2 0x5556434c in cache_find (c=c@entry=0x555a9710, ptr=ptr@entry=0x555afd60, id=id@entry=0x7fff9ec4) at cache.c:304 #3 0x55564378 in cache_update_force (c=0x555a9710, ptr=0x555afd60) at cache.c:279 #4 0x555663b8 in dump_handler (type=NFCT_T_UPDATE, data=, ct=0x555afd60) at ctnl.c:266 #5 dump_handler (type=NFCT_T_UPDATE, ct=0x555afd60, data=) at ctnl.c:257 #6 0x77ba47db in __callback (nlh=0x7fffa090, nfa=0x7fff9f50, data=0x555afd40) at callback.c:58 #7 0x7778805c in nfnl_step (h=h@entry=0x555afa20, nlh=nlh@entry=0x7fffa090) at libnfnetlink.c:1340 #8 0x77788823 in nfnl_process (h=h@entry=0x555afa20, buf=buf@entry=0x7fffa090 , len=len@entry=3604) at libnfnetlink.c:1385 #9 0x77788b8e in nfnl_catch (h=0x555afa20) at libnfnetlink.c:1539 #10 0x77ba562f in nfct_query (h=0x555afc00, qt=qt@entry=NFCT_Q_DUMP, data=data@entry=0x555772e4 ) at api.c:970 #11 0x55561f71 in nl_dump_conntrack_table (h=) at netlink.c:153 #12 0x5556661f in ctnl_init () at ctnl.c:456 #13 0xf505 in init () at run.c:301 #14 0xdf72 in main (argc=1, argv=0x7fffe428) at main.c:367 *** /tmp/valgrind.log # valgrind conntrackd ==13777== Memcheck, a memory error detector ==13777== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13777== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==13777== Command: conntrackd ==13777== [Tue Jul 14 16:44:45 2020] (pid=13777) [notice] disabling external cache ==13777== Invalid read of size 8 ==13777==at 0x113608: hashtable_find (hash.c:72) ==13777==by 0x118377: cache_update_force (cache.c:279) ==13777==by 0x11A3B7: dump_handler (ctnl.c:266) ==13777==by 0x11A3B7: dump_handler (ctnl.c:257) ==13777==by 0x4A5A7DA: __callback (callback.c:58) ==13777==by 0x4E8A05B: nfnl_step (libnfnetlink.c:1340) ==13777==by 0x4E8A822: nfnl_process (libnfnetlink.c:1385) ==13777==by 0x4E8AB8D: nfnl_catch (libnfnetlink.c:1539) ==13777==by 0x4A5B62E: nfct_query (api.c:970) ==13777==by 0x11A61E: ctnl_init (ctnl.c:456) ==13777==by 0x113504: init (run.c:301) ==13777==by 0x111F71: main (main.c:367) ==13777== Address 0x54af660 is 0 bytes after a block of size 32 alloc'd ==13777==at 0x4837B65: calloc (vg_replace_malloc.c:752) ==13777==by 0x113577: hashtable_create (hash.c:39) ==13777==by 0x117E8D: cache_create (cache.c:102) ==13777==by 0x121796: internal_cache_init (internal_cache.c:26) ==13777==by 0x11ADAC: init_sync (sync-mode.c:396) ==13777==by 0x11A52A: ctnl_init (ctnl.c:414) ==13777==by 0x113504: init (run.c:301) ==13777==by 0x111F71: main (main.c:367) ==13777== ==13777== Invalid read of size 8 ==13777==at 0x118BA1: cache_ct_cmp
Bug#946931: quassel-core: apparmor denials
Hello,
I stumbled upon the same issue and fixed it locally before searching the
BTS.
I agree on the change '/var/lib/quassel/** rwkl' (although AA convention
seems to be 'rwkl', but that’s just cosmetic), but I would suggest
adding '#include ' instead of
specifying the IDs manually.
Said 'abstractions/dbus-session-strict' does not allow access to
'@{PROC}/sys/kernel/random/boot_id', but I didn’t get any audit messages
about that after including the abstraction. I haven’t looked any
further into it, but maybe it isn’t needed?
Thanks,
qsx
Bug#932127: Reply
Hi, I must withdraw my previous statement > 4. Snapper + Grub works well in Arch Linux This is incorrect, means the bootloader must be modified manually in order to boot a specific snapshot. However Snapper + Grub works well in openSUSE, means the bootloader will load the snapshot that is defined as default. And Snapper will define a specific snapshot (created by Snapper) as default. You can check the current default snapshot with this command: btrfs subvolume get-default I don't know the differences of Grub running on openSUSE compared to other distributions. Regards Thomas
Bug#932127: Reply
Hi, the question was why I think this is a problem in the Grub packages. My answer to this is: 1. Grub is already considering existing Btrfs snapshots, because it includes this string in the Linux line: rootflags=subvol=@ 2. Grub is already adapting the Linux line after a snapshot is booted and Grub is reinstalled 3. Snapper is not the program responsible for booting a system 4. Snapper + Grub works well in Arch Linux Regards Thomas
Bug#886019: mtp-tools: mtp-detect returns error: ignoring libusb_claim_interface()
Package: mtp-tools Version: 1.1.13-1 Severity: important Dear Maintainer, After completing installation of Debian 9 I try to connect my Android Device "SONY Xperia Z3" that is running Android 8.0 and run mtp-detec$ This returns the following error: thomas@pc8-nb:~$ mtp-detect libmtp version: 1.1.13 Listing raw device(s) Device 0 (VID=0fce and PID=51ba) is a SONY Xperia Z3 MTP+ADB. Found 1 device(s): SONY: Xperia Z3 MTP+ADB (0fce:51ba) @ bus 2, dev 26 Attempting to connect device(s) ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface LIBMTP libusb: Attempt to reset device ignoring libusb_claim_interface() = -6LIBMTP PANIC: failed to open session on second attempt Unable to open raw device 0 OK. Then I tried another Android Device "Samsung Galaxy S4" that is running Android 6.0.1 to eliminate issues related to device or Android Vers$ Here the same errors are shown. Regards Thomas -- System Information: Distributor ID: Sparky Description:SparkyLinux Release:5 Codename: Nibiru Architecture: x86_64 Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mtp-tools depends on: ii libc62.25-5 ii libmtp9 1.1.13-1 mtp-tools recommends no packages. mtp-tools suggests no packages. -- no debconf information
