Bug#994580: zenity: Zenity --question return values inconsistent
Package: zenity Version: 3.30.0-2 Severity: normal Tags: a11y upstream Dear Maintainer, When calling Zenity with --question the return values SHOULD be 0 or 1 (or ever-increasing numbers if buttons are added). However, the return value is either nothing or 0. Example: someVar=$(zenity --question [blah] [blah]) && echo $someVar OR zenity --question [blah blah] && echo $? Please note: I have tried the latest Zenity version from sid and the problem persists. This can affect shell scripts for which Zenity was designed. There is an obvious workaround, [[ -z "$someVar" ]], the trouble will come when/if this is fixed. The better workaround, when considering more than two buttons as well, is a case statement so that any return except what which is fixed or unfixed, is handled instead. It will obviously still cause a little conflict, but it needs to be fixed, the sooner, the better. Obviously this an upstream problem, but it's an easy fix. Regards, J -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.8-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zenity depends on: ii libc6 2.28-10 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u3 ii libgtk-3-03.24.5-1 ii libnotify40.7.7-4 ii libpango-1.0-01.42.4-8~deb10u1 ii libwebkit2gtk-4.0-37 2.30.6-1~deb10u1 ii libx11-6 2:1.6.7-1+deb10u2 ii zenity-common 3.32.0-6 zenity recommends no packages. zenity suggests no packages. -- no debconf information
Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions
Package: inkscape Version: 1.0-1~bpo10+1 Severity: critical Tags: upstream Justification: breaks unrelated software Dear Maintainer, Inkscape crashes, recently causing Thunar to crash _too_. The crash happens when many undo and redo actions are performed consecutively. At first, I thought it was a one-time bug so I tried using the bpo. Once again, under the same conditions, Inkscape crashed. Finally, I tried using the 1.0 AppImage (to test "sterile" and see if this was Debian-specific or Inkscape in general). The result is the same. Since it wasn't a "world-ender" bug, I went back to using the native Debian bpo and decided to just save a lot (side-note: auto-save and recovery still occasionally fails). Earlier tonight, something serious happened; it crashed all instances of Thunar. Clearly this bug seems to be worse than I thought -- apologies for not reporting it sooner. Sadly, this bug is not absolutely reproducible. It has only happened a few times, always under the same conditions though. It may be related to other similar bugs involving memory access errors. I have noticed only complex SVGs do this (memory/cache?). The errors (see below) point to the problem being Inkscape-specific (the core lib), so it's very concerning that there's this "domino effect". Here's the relevant dmesg outputs: inkscape[18142]: segfault at 148 ip 7efbfefec5db sp 7ffb9620 error 4 in libinkscape_base.so[7efbfe58a000+bb] traps: inkscape[28062] general protection fault ip:7efbfeed39a1 sp:7ffb8520 error:0 in libinkscape_base.so[7efbfe58a000+bb] If I have time, I'll try running Inkscape and Thunar from two consoles and try to reproduce the error. Hopefully it'll shed some light on it. Hopefully still, I won't need to. Regards, Jason -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii libaspell150.60.7~20110707-6 ii libatk1.0-02.30.0-2 ii libatkmm-1.6-1v5 2.28.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.5-1 ii libdbus-1-31.12.20-0+deb10u1 ii libdbus-glib-1-2 0.110-4 ii libdouble-conversion1 3.1.0-3 ii libenchant1c2a 1.6.0-11.1+b1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgc1c2 1:7.6.4-0.4 ii libgcc11:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgdl-3-5 3.28.0-2 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglibmm-2.4-1v5 2.58.0-2 ii libgomp1 8.3.0-6 ii libgsl23 2.5+dfsg-6 ii libgslcblas0 2.5+dfsg-6 ii libgtk-3-0 3.24.5-1 ii libgtkmm-3.0-1v5 3.24.0-2 ii libgtkspell3-3-0 3.0.9-3 ii libharfbuzz0b 2.3.1-1 ii libice62:1.0.9-2 ii libjpeg62-turbo1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libmagick++-6.q16-88:6.9.10.23+dfsg-2.1+deb10u1 ii libmagickcore-6.q16-6 8:6.9.10.23+dfsg-2.1+deb10u1 ii libmagickwand-6.q16-6 8:6.9.10.23+dfsg-2.1+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-01.42.4-8~deb10u1 ii libpangoft2-1.0-0 1.42.4-8~deb10u1 ii libpangomm-1.4-1v5 2.42.0-2 ii libpng16-161.6.36-6 ii libpoppler-glib8 0.71.0-5 ii libpoppler82 0.71.0-5 ii libpotrace01.15-1 ii librevenge-0.0-0 0.0.4-6 ii libsigc++-2.0-0v5 2.10.1-2 ii libsm6 2:1.2.3-1 ii libsoup2.4-1 2.64.2-2 ii libstdc++6 8.3.0-6 ii libvisio-0.1-1 0.1.6-1+b2 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxml22.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2.2~deb10u1 ii python33.7.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages inkscape recommends: ii aspell 0.60.7~20110707-6 ii fig2dev 1:3.2.7a-5+deb10u3 ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii libimage-magick-perl 8:6.9.10.23+dfsg-2.1+deb10u1 ii libwmf-bin 0.2.8.4-14 ii python3-lxml 4.3.2-1 ii python3-numpy1:1.16.2-1 ii python3-scour0.37-2 Versions of packages inkscape suggests: pn dia pn
Bug#968205: tumbler: Tumbler daemon (tumblerd) using 100% CPU (single thread)
Package: tumbler Version: 0.2.3-1 Severity: important Tags: lfs upstream Dear Maintainer, The tumbler daemon uses massive amounts of CPU (90-100%) on a single thread sporadically. Once it does, even closing all applications does not work and the process requires manual termination. I believe it relates to lfs owing to bugs 788271 and 827427, _however_ the issue persists even _after_ closing large files or copy-completion, leaving termination. So, while triggered by large files, there is a secondary bug (IDK if I should report it separately). This is very an upstream problem since I've found serveral cases of it across multiple distributions (at least on GNU/LINUX, I've not seen mention on other systems) while browsing (it is good to check other distros when reporting problems). Possible diagnostics/fixes: 1) I believe there is a missing (or incorrectly implemented) sleep in the source which causes it to scan on a near (or full) per-clock cycle. Where sleeping for a few hundred ms or even a second would cause a "blink" for the user (depending, < 500ms is unotticeable), I believe it's a fair trade-off. 2) I would suggest that a files be checked for being "in use" and that if true, to continue using the already-cached thumbnail until released. This is the most elegant solution (and it would prevent, but not fix, the secondary bug). 3) As for the secondary problem, i.e. needing manual termination, the best "quick hack" is for it simply to check its resource use (yes it would kill itself under certain conditions, however there is no reason a calling process cannot exist to monitor it, killing and restarting as needed). It's a dirty-ish hack but would be a good temporary cure while the underlying code is being fixed. I hope this is of use. I realise that the maintainer(s) is/are not technically responsible, but this seems like a better way to get the upstream developer(s) to get something done (I saw a similar behaviour complaint dating back 5 years). Kind Regards, Jason -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tumbler depends on: ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libfreetype62.9.1-3+deb10u1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.36-6 ii libpoppler-glib80.71.0-5 ii libtumbler-1-0 0.2.3-1 ii tumbler-common 0.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 tumbler recommends no packages. Versions of packages tumbler suggests: pn tumbler-plugins-extra -- no debconf information
