Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#991320: flameshot crashing on startup
33 views
Skip to first unread message
allan grossman
Jul 20, 2021, 11:20:03 AM7/20/21
to
Package: flameshot
Version: 0.9.0+ds1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: wizar...@gmail.com
Dear Maintainer,
* What led up to the situation?
Have flameshot gui -p /home/username/temp set in openbox autostart. Mapped hotkeys were not responding.
* What exactly did you do (or not do) that was effective (or
ineffective)?
This probably isn't a flameshot bug but I'm not sure where it goes - flameshot crashes when started in openbox autostart or from terminal session and have duplicated the error on two Sid machines. If you execute "dbus-update-activation-environment DISPLAY XAUTHORITY" flameshot gui will start for about half a second and then crash, which is better than running in a terminal session where it won't display GUI at all before crashing.
* What was the outcome of this action?
flameshot still not working.
* What outcome did you expect instead?
Expected flameshot to run as normal :)
-- System Information:
Debian Release: 11.0
APT prefers unstable
APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages flameshot depends on:
ii hicolor-icon-theme 0.17-2
ii libc6 2.31-13
ii libfmt7 7.1.3+ds1-5
ii libgcc-s1 10.2.1-6
ii libqt5core5a 5.15.2+dfsg-9
ii libqt5dbus5 5.15.2+dfsg-9
ii libqt5gui5 5.15.2+dfsg-9
ii libqt5network5 5.15.2+dfsg-9
ii libqt5svg5 5.15.2-3
ii libqt5widgets5 5.15.2+dfsg-9
ii libspdlog1 [libspdlog1-fmt7] 1:1.8.1+ds-2.1
ii libstdc++6 10.2.1-6
flameshot recommends no packages.
Versions of packages flameshot suggests:
ii ca-certificates 20210119
ii openssl 1.1.1k-1
-- no debconf information
Version: 0.9.0+ds1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: wizar...@gmail.com
Dear Maintainer,
* What led up to the situation?
Have flameshot gui -p /home/username/temp set in openbox autostart. Mapped hotkeys were not responding.
* What exactly did you do (or not do) that was effective (or
ineffective)?
This probably isn't a flameshot bug but I'm not sure where it goes - flameshot crashes when started in openbox autostart or from terminal session and have duplicated the error on two Sid machines. If you execute "dbus-update-activation-environment DISPLAY XAUTHORITY" flameshot gui will start for about half a second and then crash, which is better than running in a terminal session where it won't display GUI at all before crashing.
* What was the outcome of this action?
flameshot still not working.
* What outcome did you expect instead?
Expected flameshot to run as normal :)
-- System Information:
Debian Release: 11.0
APT prefers unstable
APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages flameshot depends on:
ii hicolor-icon-theme 0.17-2
ii libc6 2.31-13
ii libfmt7 7.1.3+ds1-5
ii libgcc-s1 10.2.1-6
ii libqt5core5a 5.15.2+dfsg-9
ii libqt5dbus5 5.15.2+dfsg-9
ii libqt5gui5 5.15.2+dfsg-9
ii libqt5network5 5.15.2+dfsg-9
ii libqt5svg5 5.15.2-3
ii libqt5widgets5 5.15.2+dfsg-9
ii libspdlog1 [libspdlog1-fmt7] 1:1.8.1+ds-2.1
ii libstdc++6 10.2.1-6
flameshot recommends no packages.
Versions of packages flameshot suggests:
ii ca-certificates 20210119
ii openssl 1.1.1k-1
-- no debconf information
Dennis Filder
Jul 20, 2021, 1:00:04 PM7/20/21
to
X-Debbugs-CC: allan grossman <wizar...@gmail.com>
I can't reproduce this under current Bullseye KDE/xorg -- flameshot
behaves absolutley normally. It could be a Wayland issue, and
flameshot's Wayland support is apparently still experimental.
Let us know if running flameshot like so fixes this for you:
GDK_BACKEND=x11 flameshot
Regards,
Dennis Filder
I can't reproduce this under current Bullseye KDE/xorg -- flameshot
behaves absolutley normally. It could be a Wayland issue, and
flameshot's Wayland support is apparently still experimental.
Let us know if running flameshot like so fixes this for you:
GDK_BACKEND=x11 flameshot
Regards,
Dennis Filder
allan
Jul 20, 2021, 2:30:03 PM7/20/21
to
This has only been broken for a couple of days - there's a strong
possibility that whatever broke it hasn't made it to Bullseye yet.
This appears to be an upstream bug because a Manjaro user running same
version of flameshot and Qt is experiencing same behavior and as
mentioned, it broke a couple of days ago.
--
we see things not as they are, but as we are.
-- anais nin
possibility that whatever broke it hasn't made it to Bullseye yet.
This appears to be an upstream bug because a Manjaro user running same
version of flameshot and Qt is experiencing same behavior and as
mentioned, it broke a couple of days ago.
we see things not as they are, but as we are.
-- anais nin
Boyuan Yang
Jul 20, 2021, 2:40:03 PM7/20/21
to
在 2021-07-20星期二的 13:16 -0500，allan写道：
been updated in unstable in the past few days. Please let me know if you have
any findings.
As the packager, I would be targeting on flameshot 0.10.0 when the freeze is
over and it would be meaningful if we could analyze whether it's still broken
with new release then.
Thanks,
Boyuan Yang
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.
This is exactly the merit of release freeze -- anyway, you may check what has
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.
been updated in unstable in the past few days. Please let me know if you have
any findings.
As the packager, I would be targeting on flameshot 0.10.0 when the freeze is
over and it would be meaningful if we could analyze whether it's still broken
with new release then.
Thanks,
Boyuan Yang
Dennis Filder
Jul 20, 2021, 3:00:04 PM7/20/21
to
X-Debbugs-CC: allan grossman <wizar...@gmail.com>
On Tue, Jul 20, 2021 at 01:16:39PM -0500, allan wrote:
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.
When exactly did it break and what packages did you install that could
have made it break? /var/log/apt/history.log should have the answer.
Again: Does running flameshot with GDK_BACKEND=x11 fix it for you --
yes or no? Do you run wayland or xorg?
Also, you say it crashes. How does it crash? Segfault? What is the
exact message? What is the output if you run it like this?:
catchsegv flameshot
You have to give us something to work with.
On Tue, Jul 20, 2021 at 01:16:39PM -0500, allan wrote:
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.
have made it break? /var/log/apt/history.log should have the answer.
Again: Does running flameshot with GDK_BACKEND=x11 fix it for you --
yes or no? Do you run wayland or xorg?
Also, you say it crashes. How does it crash? Segfault? What is the
exact message? What is the output if you run it like this?:
catchsegv flameshot
You have to give us something to work with.
allan
Jul 20, 2021, 4:00:04 PM7/20/21
to
Setting checkForUpdates=false resolved the issue. Thanks, Dennis :)
Dennis Filder
Jul 20, 2021, 4:00:04 PM7/20/21
to
X-Debbugs-CC: allan grossman <wizar...@gmail.com>
On Tue, Jul 20, 2021 at 02:16:16PM -0500, allan wrote:
> apt log shows qt libraries updated three days ago - these wouldn't
> have made it to Bullseye yet.
>
> Start-Date: 2021-07-17 08:52:52
> Requested-By: wizard (1000)
> Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64
> (14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64
> (5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3,
> automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic),
> libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64
> (20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6,
> automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic),
> libqt5multimediawidgets5:amd64 (5.15.2-3, automatic),
> qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic),
> libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic),
> qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic),
> libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic)
> End-Date: 2021-07-17 08:52:58
All those libraries are on my system already. I think this late in
the freeze some libraries get fast-tracked into testing on request.
> Backtrace:
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005]
> flameshot(+0x5e267)[0x55efcb2b6267]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1]
> ...
The only reason for flameshot to touch the network (which it
presumably does here) is to check for updates. Try setting
"checkForUpdates" to "false" in ~/.config/flameshot/flameshot.ini --
maybe this will preclude the codepath in question from being taken.
Let us know if this fixes it for you -- if not, then I don't really
see what more could be done here. Maybe running
strace -s2048 -f -e 'trace=%net' -o /tmp/flameshot.strace flameshot
will reveal what network facility it tries to contact before it crashes.
Regards,
Dennis.
On Tue, Jul 20, 2021 at 02:16:16PM -0500, allan wrote:
> apt log shows qt libraries updated three days ago - these wouldn't
> have made it to Bullseye yet.
>
> Start-Date: 2021-07-17 08:52:52
> Requested-By: wizard (1000)
> Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64
> (14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64
> (5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3,
> automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic),
> libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64
> (20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6,
> automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic),
> libqt5multimediawidgets5:amd64 (5.15.2-3, automatic),
> qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic),
> libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic),
> qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic),
> libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic)
> End-Date: 2021-07-17 08:52:58
All those libraries are on my system already. I think this late in
the freeze some libraries get fast-tracked into testing on request.
> Backtrace:
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005]
> flameshot(+0x5e267)[0x55efcb2b6267]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1]
> ...
The only reason for flameshot to touch the network (which it
presumably does here) is to check for updates. Try setting
"checkForUpdates" to "false" in ~/.config/flameshot/flameshot.ini --
maybe this will preclude the codepath in question from being taken.
Let us know if this fixes it for you -- if not, then I don't really
see what more could be done here. Maybe running
strace -s2048 -f -e 'trace=%net' -o /tmp/flameshot.strace flameshot
will reveal what network facility it tries to contact before it crashes.
Regards,
Dennis.
Dennis Filder
Jul 20, 2021, 5:00:03 PM7/20/21
to
X-Debbugs-CC: allan grossman <wizar...@gmail.com>
On Tue, Jul 20, 2021 at 02:54:26PM -0500, allan wrote:
> Setting checkForUpdates=false resolved the issue. Thanks, Dennis :)
Okay, that is good to know. I personally feel like that option should
be set to false by default in Debian (don't the pop-ups annoy the hell
out of people?).
Of course the segfault as a problem remains, but that is upstream's
issue.
Also I suspect I know why I couldn't reproduce this: I sit behind a
proxy, so maybe Qt's networking code behaves differently then. There
is a lot going on in the strace log, but the crash happened after the
hostname for api.github.com was resolved.
Regards.
On Tue, Jul 20, 2021 at 02:54:26PM -0500, allan wrote:
> Setting checkForUpdates=false resolved the issue. Thanks, Dennis :)
be set to false by default in Debian (don't the pop-ups annoy the hell
out of people?).
Of course the segfault as a problem remains, but that is upstream's
issue.
Also I suspect I know why I couldn't reproduce this: I sit behind a
proxy, so maybe Qt's networking code behaves differently then. There
is a lot going on in the strace log, but the crash happened after the
hostname for api.github.com was resolved.
Regards.
allan
Jul 21, 2021, 2:00:03 PM7/21/21
to
couldn't get past "start" -
wizard@wizard-laptop:~$ gdb flameshot
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from flameshot...
(No debugging symbols found in flameshot)
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Starting program: /usr/bin/flameshot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff2a64700 (LWP 122428)]
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
[New Thread 0x7ffff1e16700 (LWP 122429)]
[New Thread 0x7ffff15e5700 (LWP 122430)]
[New Thread 0x7ffff0a08700 (LWP 122431)]
[New Thread 0x7fffe3fff700 (LWP 122432)]
Thread 1 "flameshot" received signal SIGSEGV, Segmentation fault.
wizard@wizard-laptop:~$ gdb flameshot
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from flameshot...
(No debugging symbols found in flameshot)
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Starting program: /usr/bin/flameshot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff2a64700 (LWP 122428)]
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
[New Thread 0x7ffff1e16700 (LWP 122429)]
[New Thread 0x7ffff15e5700 (LWP 122430)]
[New Thread 0x7ffff0a08700 (LWP 122431)]
[New Thread 0x7fffe3fff700 (LWP 122432)]
Thread 1 "flameshot" received signal SIGSEGV, Segmentation fault.
allan
Jul 21, 2021, 2:10:03 PM7/21/21
to
no joy here either -
Reading symbols from flameshot...
(No debugging symbols found in flameshot)
(gdb) backtrace 5
No stack.
(gdb)
Reading symbols from flameshot...
(No debugging symbols found in flameshot)
No stack.
(gdb)
Dennis Filder
Jul 21, 2021, 2:50:03 PM7/21/21
to
X-Debbugs-CC: allan grossman <wizar...@gmail.com>
Okay, download the debug symbols from:
http://debug.mirrors.debian.org/debian-debug/pool/main/f/flameshot/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb
http://debug.mirrors.debian.org/debian-debug/pool/main/q/qtbase-opensource-src/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb
Put them in /tmp and make them world-readable, then install as root
(e.g. apt install /tmp/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb /tmp/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb).
Then run "gdb flameshot" again and type:
start
break Controller::handleReplyCheckUpdates(QNetworkReply*)
continue
break QAction::setText(QString const&)
continue
backtrace 5
The output should look like this.
#0 QAction::setText (this=0x5555558b52b0, text=...) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116
#1 0x00005555555b2267 in Controller::handleReplyCheckUpdates (this=0x555555642160 <Controller::getInstance()::c>, reply=0x7fffffffcbe0) at ./src/core/controller.cpp:195
#2 0x00007ffff6d755a6 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#3 0x00007ffff7dd5ad2 in QNetworkAccessManager::finished(QNetworkReply*) () from /lib/x86_64-linux-gnu/libQt5Network.so.5
#4 0x00007ffff7dd6e17 in ?? () from /lib/x86_64-linux-gnu/libQt5Network.so.5
Okay, download the debug symbols from:
http://debug.mirrors.debian.org/debian-debug/pool/main/f/flameshot/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb
http://debug.mirrors.debian.org/debian-debug/pool/main/q/qtbase-opensource-src/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb
Put them in /tmp and make them world-readable, then install as root
(e.g. apt install /tmp/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb /tmp/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb).
Then run "gdb flameshot" again and type:
start
break Controller::handleReplyCheckUpdates(QNetworkReply*)
continue
break QAction::setText(QString const&)
continue
backtrace 5
The output should look like this.
#0 QAction::setText (this=0x5555558b52b0, text=...) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116
#1 0x00005555555b2267 in Controller::handleReplyCheckUpdates (this=0x555555642160 <Controller::getInstance()::c>, reply=0x7fffffffcbe0) at ./src/core/controller.cpp:195
#2 0x00007ffff6d755a6 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#3 0x00007ffff7dd5ad2 in QNetworkAccessManager::finished(QNetworkReply*) () from /lib/x86_64-linux-gnu/libQt5Network.so.5
#4 0x00007ffff7dd6e17 in ?? () from /lib/x86_64-linux-gnu/libQt5Network.so.5
allan
Jul 21, 2021, 5:50:03 PM7/21/21
to
> No, it shows exactly what I was looking for:
this is why i should listen to developers. i would have been tearing
stuff apart already :)
flameshot worked properly the last time i used it and for at least a
year before, last time i used it was maybe five days before i filed
the bug.
network here is 200/10mb and latency usually runs 40-50ms which ain't
great but ain't awful either.
i think what i'll do is shut off everything but 802.11b and play a
little which may take a little network configurating if i can't do it
on the wireless kernel module or connman; i can't think of a way to
add latency as i'm already doing wireless. happy to do the appimage
thing (that would eliminate openbox, right?) but i really would rather
not install snap infrastructure.
may be noon est or so before i'm able to play with this again so
thanks and have a good evening.
this is why i should listen to developers. i would have been tearing
stuff apart already :)
flameshot worked properly the last time i used it and for at least a
year before, last time i used it was maybe five days before i filed
the bug.
network here is 200/10mb and latency usually runs 40-50ms which ain't
great but ain't awful either.
i think what i'll do is shut off everything but 802.11b and play a
little which may take a little network configurating if i can't do it
on the wireless kernel module or connman; i can't think of a way to
add latency as i'm already doing wireless. happy to do the appimage
thing (that would eliminate openbox, right?) but i really would rather
not install snap infrastructure.
may be noon est or so before i'm able to play with this again so
thanks and have a good evening.
allan
Jul 21, 2021, 6:00:04 PM7/21/21
to
oh - almost forgot. on the tray icon -
[General]
disabledTrayIcon=true
drawColor=#00ff00
drawThickness=9
savePath=/media/internal/temp
startupLaunch=false
# checkForUpdates=false
[General]
disabledTrayIcon=true
drawColor=#00ff00
drawThickness=9
savePath=/media/internal/temp
startupLaunch=false
# checkForUpdates=false
allan
Jul 22, 2021, 5:40:03 PM7/22/21
to
many thanks, dennis - if you need anything else feel free to reach out.
On Thu, Jul 22, 2021 at 3:33 PM Dennis Filder <d.fi...@web.de> wrote:
>
> Okay, I can reproduce the crash now with that setting.
On Thu, Jul 22, 2021 at 3:33 PM Dennis Filder <d.fi...@web.de> wrote:
>
> Okay, I can reproduce the crash now with that setting.
0 new messages