Bug#1073054: krita: Krita crashes when canceling the "Missing Color Profile" dialog
On Wed, 26 Jun 2024 10:19:27 +0200 Sune Stolborg Vuorela wrote: I'm not sure it is a severe enough bug to warrant a stable update for that though, so I guess we should just mark it as done in the trixie version. A more accurate version could be tracked down, but this is probably good enough. /Sune Hi, As Krita allows users to open multiple documents at once, any crash can take all other open (and potentially unsaved) work with it. Imagine happily working on a collage/mashup, trying quickly preparing another graphic in a new tab… And losing it all because you forgot the select a radio button before hitting enter on the import dialog. Just my 2¢ though. Best regards, Elias
Bug#1073054: krita: Krita crashes when canceling the "Missing Color Profile" dialog
Package: krita Version: 1:5.1.5+dfsg-2 Severity: normal X-Debbugs-Cc: e.batek+deb...@itkaufmann.at Dear Maintainer, Krita crashes when canceling the "Missing Color Profile" dialog. * What led up to the situation? I hit cancel on the “Missing Color Profile” dialog. * What exactly did you do (or not do) that was effective (or ineffective)? 1. I opened Krita 2. selected “New File” (Ctrl+N) 3. chose “Create from Clipboard” 4. got the “Missing Color Profile” dialog asking me to choose between “As Web (sRGB)” and “As on Monitor” 5. where I clicked “Cancel”. (Pressing [Enter] with no option selection has the same result.) * What was the outcome of this action? Krita crashed. * What outcome did you expect instead? I would expect the dialog to close, canceling the “Create from Clipboard” action. Backtrace ASSERT (krita): "clip" in file ./libs/ui/widgets/kis_image_from_clipboard_widget.cpp, line 80 Thread 1 "krita" received signal SIGABRT, Aborted. 0x756a9e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x756a9e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7565afb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x75645472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x75890c79 in QMessageLogger::fatal(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x76e7c8bc in ?? () from /lib/x86_64-linux-gnu/libkritaglobal.so.18 #5 0x77b6e6d8 in ?? () from /lib/x86_64-linux-gnu/libkritaui.so.18 #6 0x75ae8f4f in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x768fe838 in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #8 0x75ae8f7c in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x76854fc2 in QAbstractButton::clicked(bool) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #10 0x7685522a in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #11 0x768571a9 in QAbstractButton::click() () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #12 0x767a5bba in QWidget::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #13 0x76762fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #14 0x7676aed7 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x77cb9cfe in KisApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libkritaui.so.18 #16 0x75ab16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x767c0fa2 in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x76762fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #19 0x77cb9cfe in KisApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libkritaui.so.18 #20 0x75ab16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #21 0x75ab4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x75b0a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #23 0x734627a9 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x73462a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x73462acc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #26 0x75b09836 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #27 0x75ab017b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #28 0x7696bbb7 in QDialog::exec() () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #29 0x77cebf43 in KisMainWindow::slotFileNew() () from /lib/x86_64-linux-gnu/libkritaui.so.18 #30 0x75ae8f7c in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #31 0x7675c782 in QAction::triggered(bool) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #32 0x7675f3ab in QAction::activate(QAction::ActionEvent) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #33 0x7675ff7d in QAction::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #34 0x76762fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #35 0x77cb9cfe in KisApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libkritaui.so.18 #36 0x75ab16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #37 0x75f6c76b in QShortcutMap::dispatchEvent(QKeyEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #38 0x75f6d0bb in QShortcutMap::tryShortcut(QKeyEvent*) () from
Bug#1073000: ssh-askpass-gnome: No longer visually prompted to touch security key after upgrading to Bookworm
Package: ssh-askpass-gnome Version: 1:9.2p1-2+deb12u2 Severity: normal X-Debbugs-Cc: e.batek+deb...@itkaufmann.at Dear Maintainer, After upgrading my system from Bullseye to Bookworm, I’m no longer visually prompted to touch an attached security key (e.g. YubiKey) to confirm SSH logins etc. Instead the app just waits with no visual indicator that it expects user interaction. Luckily my YubiKey has an LED that blinks in this state, but apart from that there’s nothing that distinguishes the situation from a hanging program. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ssh-askpass-gnome depends on: ii libc6 2.36-9+deb12u7 ii libglib2.0-02.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii openssh-client 1:9.2p1-2+deb12u2 ssh-askpass-gnome recommends no packages. ssh-askpass-gnome suggests no packages. -- no debconf information
Bug#1013344: podman: The cgroupv2 manager is set to systemd but there is no systemd user session available
Package: podman Version: 3.0.1+dfsg1-3+deb11u1 Severity: minor X-Debbugs-Cc: e.batek+deb...@itkaufmann.at Dear Maintainer, * What led up to the situation? Podman, in the default installation, spits out a lot of warning messages. I couln’t find any information on that regard in the wiki[0]. * What exactly did you do (or not do) that was effective (or ineffective)? $ sudo apt install podman $ podman search --limit 3 quay.io/podman * What was the outcome of this action? > WARN[] The cgroupv2 manager is set to systemd but there is no systemd > user session available > WARN[] For using systemd, you may need to login using an user session > WARN[] Alternatively, you can enable lingering with: `loginctl > enable-linger 1000` (possibly as root) > WARN[] Falling back to --cgroup-manager=cgroupfs > WARN[] The cgroupv2 manager is set to systemd but there is no systemd > user session available > WARN[] For using systemd, you may need to login using an user session > WARN[] Alternatively, you can enable lingering with: `loginctl > enable-linger 1000` (possibly as root) > WARN[] Falling back to --cgroup-manager=cgroupfs * What outcome did you expect instead? No warning with no further configuration. I’ve found a kinda related upstream issue[1]. Is setting `cgroup_manager = "cgroupfs"`, as suggested along the upstream bug report, a reasonable configuration on Debian? Best regards, Elias -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii crun 0.17+dfsg-1 ii golang-github-containers-common 0.33.4+ds1-1+deb11u1 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u3 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii catatonit 0.1.5-2 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage pn docker-compose -- no debconf information [0] https://wiki.debian.org/Podman [1] https://github.com/containers/podman/issues/5906#issuecomment-1079587477
Bug#986866: apacheds: ApacheDS fails to start after clean install
Can confirm. Unfortunately, same here. Regards, Elias
