On Sat, 10 Feb 2024 11:01:54 +0100 Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
> I do not use ssr much myself, and have not had time to test.
I applied the upstream commit in git branch fix-1040375-glinject and
tested it on Bookworm, but alas, the .so file still segfaults with a
useless
Hello,
I am not maintainer of stlcmd, just tried to collect some more information.
This crash seems to be a stack overflow because of a recursive function call.
There is a comment near that recursive call, which could be interesting here.
And this issue seems not to be a packaging issue in
On Sat, 28 Oct 2023 12:52:30 +0200 Tobias Frost wrote:
Control: tags -1 confirmed
Here's a backtrace when clicking on Settings -> System.
Thread 1 "blastem" received signal SIGSEGV, Segmentation fault.
tern_foreach_int (head=, fun=0x555c12a0 ,
data=0x7fffd7f0, keybuf=0x7fffd8c0
Hello,
this seems to be the same issue as here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069102
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069092
And the fix seems to be prepared here:
https://salsa.debian.org/kernel-team/linux/-/commit/37a0ac93027302ffbfae41ddc844312e88e72eef
On Tue, 05 Dec 2023 23:39:39 + Witold Baryluk
wrote:
Thread 1 "doomsday" received signal SIGSEGV, Segmentation fault.
0x75419e83 in _XFlush () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0 0x75419e83 in _XFlush () at /lib/x86_64-linux-gnu/libX11.so.6
#1
Hello,
I am not a samba maintainer, just trying to collect some more information.
As far as I see the crash happens
because "cli_credentials_get_password(creds)" in line 62
returns a null pointer, which gets forwarded to
the call to strlcpy without further check.
Kind regards,
Bernhard
(rr)
On Fri, 1 Dec 2023 00:26:27 +0100 Lucy wrote:
#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)
#4 0x557d83358770 n/a (baloo_file + 0x13770)
#5 0x557d8335885d n/a (baloo_file + 0x1385d)
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)
#7 0x7fbe9cadd6f0
On Tue, 19 Dec 2023 20:22:43 +0100 Eduard Bloch wrote:
#7 0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510)
#8 0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)
#9 0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)
#10
Am 04.05.24 um 13:46 schrieb Bernhard Übelacker:
These end in some boost::asio functions:
boost::asio::detail::scheduler::concurrency_hint() const at
/usr/include/boost/asio/detail/scheduler.hpp:142
Forgot to attach how I got there:
debugging.txt
And for reference the upstream ticket
Hello,
I am not the maintainer of libuhd, just tried to get some more
information from the provided dmesg Code lines.
These end in some boost::asio functions:
boost::asio::detail::scheduler::concurrency_hint() const at
/usr/include/boost/asio/detail/scheduler.hpp:142
Unfortunately this
Hello,
I am not maintainer of gnome-nettool, just tried to debug this issue.
gnome-nettool collects the information from an execution
of a dig command [1] and parses the output.
Unfortunately the parsing is done into some fixed size arrays
and the dig output overflows those.
E.g. the destination
Hello,
I am just trying to get the source line from the dmesg code line.
[ 97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11
(core 5, socket 0)
[ 97.073799] Code: 00 31 c0 e9 54 ff ff ff
On Fri, 2 Feb 2024 00:58:31 -0800 Josh Triplett wrote:
Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04
sp 7ffc5ad85ed8 error 4 in
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4,
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f
Hello,
just tried to extract the backtrace from the attached core dump.
Kind regards,
Bernhard
Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1
Hello Cláudio,
I am not maintainer of the din package, just reading through some crash reports.
Unfortunately I cannot follow your claim "The crash occurred in the module
libzstd.so.1".
None of the 5 threads show a frame inside libzstd.
It seems just listed in the Module list.
Thread 166294
Hello,
I am no maintainer, just tried to reproduce this issue which I could
inside a minimal Bullseye amd64 qemu VM with the instructions
from the linked Ubuntu bug.
I could not reproduce it within Bookworm or Trixie/testing.
Without "LogLevel DEBUG" it was also not observable.
Unfortunately
On Sat, 24 Feb 2024 23:55:18 + =?utf-8?q?Lucas_L=C3=B3pez?=
wrote:
I copied the example server file /usr/share/doc/vtun/examples/vtund-server.conf
into
/etc/vtund.conf and enabled server mode in /etc/default/vtun. When I start the
service
with systemctl I get the following error on the
Hello,
I found this one interesting and tried to reproduce it,
and hit this issue quite reliable with an unstable armel chroot,
inside an armhf unstable qemu VM,
or with a Android/LineageOS with real arm CPU.
Unfortunately valgrind is no longer built for armel, and a local armel rebuild
shows
Hello,
tried to reproduce the issue and got on a first run this stack:
(gdb) bt
#0 iter_thread_int (fth=0x157681210) at rect.c:500
#1 0x7fffaa36bad0 in iter_thread_float () at rect.c:253
#2 0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at
pthread_create.c:444
#3
Hello,
I tried to find some more information, with the help of a prebuilt full-system
VM image.
On Thu, 4 Apr 2024 21:00:59 + (UTC) Thorsten Glaser wrote:
Sometimes, it does not crash with a smashed stack but instead:
Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ...
BDB0002
Hello ng,
On Wed, 22 Nov 2023 22:47:01 -0300 ng wrote:
[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3,
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28
Hello Olly,
(gdb) bt
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2 0x7fa842435472 in __GI_raise (sig=sig@entry=6)
control: forwarded 993018 https://bugs.kde.org/show_bug.cgi?id=485134
control: found 993018 1:3.20.0-2.1
Hello,
I got recently remembered about this bug and patch.
So I try to find out what upstream thinks about this.
It can still be observed with current version in Trixie/testing.
Kind
Hello,
I tried to reproduce this inside a minimal stable/bookworm VM
and received a qmlcachegen crash.
See attached file for details.
The resulting backtrace is quite similar to that found in:
https://bugreports.qt.io/browse/QTBUG-117361
Might avoid the crash, but cannot say if this would
On Wed, 24 Jan 2024 15:07:46 +0100 wouldsmina wrote:
2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747] slapd[13335]:
segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
ends on uninitialised value(s)".
Maybe those are responsible for the malloc abort.
Attached file fixes most of the issues shown by valgrind entering the
main menu.
Kind regards,
BernhardDescription: Fix a few delete and uninitilised values shown by valgrind
Author: Bernhard Übelacker
Last
Hello,
this issue is still present with current testing.
For some weird reason this loop in line 195 is never left.
Putting a printf into this loop confirms that n counts correctly,
but the loop is not left when it reaches 13 (NB_BUILDING).
Strangely a similar loop with the same condition in
On Mon, 20 Mar 2023 11:34:43 +0100 Christophe Lohr
wrote:
Package: libgl1-mesa-dri
Version: 22.3.3-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net
Dear Maintainer,
Xorg is carshing with a segfault:
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139)
Hello,
On Wed, 08 Nov 2023 20:17:49 +0100 =?utf-8?q?Andr=C3=A9_Offringa?=
wrote:
$ gmemusage
realloc(): invalid next size
Aborted
Looks like caused by having not enough space
for process names longer than 13 characters.
A package built with the modification below
shows no longer this
Hell Mulas,
I tried to get to the source line of you dmesg output:
[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp
7fff0ca38e10 error 4 in
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2,
socket 0)
[254868.778109] Code: 18 64
Hello,
just tried to get some more information where this stack smashing happens.
The stack canary gets at least overwritten here:
165 memmove(detect + n + 1, detect + n,
166 (j - n) * sizeof(int));
The variable detect has a size
Hello,
below is the top of a valgrind run
with dbgsym package installed.
Kind regards,
Bernhard
benutzer@debian:~$ valgrind bash
==1114== Memcheck, a memory error detector
==1114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1114== Using Valgrind-3.19.0 and LibVEX; rerun
Hello,
upstream uses now macro-prefix-map, therefore e.g.
source files using __FILE__ should no longer
contain absolute paths.
So there are still the *.S files embedding their absolute paths.
In the long run maybe dpkg-buildflags might help there [1], [2].
But there is also mentioned to "just"
Why isn't there a symbol package, just for some ports?
Hello Patrick,
there are symbol packages for nearly all Debian packages nowadays.
You can add the debug component [1] to be able to install the dbgsym packages,
or if you like you can just use the DEBUGINFOD_URLS environment variable [2].
Dear Maintainer,
it looks like the searched file ends up here in the current package:
/usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py
But by inspecting the strace output it should probably be in this directory:
/usr/lib/llvm-15/lib/python3/dist-packages/lldb
For a
Dear Maintainer,
I tried to find out where exactly the stack smashing takes place.
And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
allocated in variable old_p, by that overwriting the stack canary.
Kind regards,
Bernhard
(gdb)
0x5557589f 62 {
1: x/i $pc
=>
Am 23.03.23 um 17:38 schrieb Tim McConnell:
Bernhard,
Just cause I said it was fixed this happens to show up in journalctl:
systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core.
On Mon, 06 Mar 2023 14:40:12 + Reuben Thomas wrote:
If I select Help→About XSane, the application pauses for a couple of seconds
then crashes. (The changes in Ubuntu’s version are just to depend on a
different JPEG library, so I think it’s reasonable to file a bug here.)
Dear
On Wed, 08 Mar 2023 10:47:25 +0100 Laurent Bigonville wrote:
$ pkcon what-provides application/x-keepass2
Getting provides[=]
Loading cache [=]
Querying
control: tags -1 +patch
Hello Tim,
nice to hear it helps. Therefore adding the patch tag.
Kind regards,
Bernhard
Am 21.03.23 um 17:53 schrieb Tim McConnell:
Hi Bernhard,
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch.
Thanks so
Dear Maintainer,
I tried to reproduce this issue and found a difference between
a minimal Bookworm VM with just running jwm window manager and my
regular Plasma desktop.
In the minimal VM a `kstart5 kcalc` returns immediately,
while at my regular Plasma desktop it blocks until the started
Dear Maintainer,
I tried to add source line information to the Xorg backtrace:
fdd in inl at /usr/include/x86_64-linux-gnu/sys/io.h:83
(pci_device_linux_sysfs_read32+93)
f1a in x86emuOp_in_word_AX_DX at
../../../../../../hw/xfree86/int10/../x86emu/ops.c:10364
024 in X86EMU_exec at
Am 26.02.23 um 16:47 schrieb Tim McConnell:
Hi Bernhard,
The delay is fine, I'm sure it takes a minute to figure it out ;-) and
no I didn't have anything other than defaults for GDB set. I'm not a
programmer so I don't know all the tricks to GDB or when is best to
use them. With that said,
Dear Maintainer,
with the help of the core saved in the artifacts I found that
the crash happens when fontforge tries to print some logging.
It just started to crash if I run the command with LANG=C.
It seems to be caused by the call to function iconv returns
with errno==EILSEQ (Illegal byte
Stack trace of thread 67345:
#0 0x7f8daa6a9ccc n/a (libc.so.6 + 0x8accc)
#1 0x7f8daa65aef2 raise (libc.so.6 + 0x3bef2)
#2 0x7f8dabf4c83d _ZN6KCrash19defaultCrashHandlerEi
(libKF5Crash.so.5 + 0x583d)
#3
On Sun, 19 Feb 2023 21:38:22 +0100 =?utf-8?q?Linus_L=C3=BCssing?=
wrote:
... They sound like build options to me ...
Hello Linus,
I tried to have a look how Lutris detects fsync support.
It looks like Lutris extracts the version
from the path the wine executable was found.
(see the
Dear Maintainer,
I tried to add line information using the dbgsym packages.
That led me to libc trying to print the
message "double free or corruption (out)".
Kind regards,
Bernhard
https://sources.debian.org/src/glibc/2.36-8/malloc/malloc.c/
4584malloc_printerr ("double free or corruption
Am 08.02.23 um 19:31 schrieb Tim McConnell:
Opppss I thought I had, here it is.
bt full
Hello Tim,
sorry for the delay. For some reason the debug information
for libpcap.so.0.8 was missing in your backtrace (was the
DEBUGINFOD_URLS variable set in that console?).
But I guess I could fill in
On Sun, 12 Feb 2023 18:53:01 +0900 Junichi Uekawa wrote:
/usr/bin/wine64-stable fails because of missing files.
Should /usr/bin/wine64-stable be there at all?
I guess having just package wine64 without package wine
installed should also work?
Then /usr/bin/wine64-stable would be needed.
Package: approx
Version: 5.11-1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
approx got sensitive to lines in /etc/approx/approx.conf
which are empty except of spaces.
This did not harm previous approx versions.
Unfortunately there is no error message in journal:
Am 08.02.23 um 18:42 schrieb Tim McConnell:
Hi Bernhard,
Okay I did that. Let me know if that was of any use.
Hello Tim,
could you send the actual output below the `bt full`?
Kind regards,
Bernhard
Hello Tim,
thanks, that is good helpful information, but as long the core file
might be in the system, could you execute following commands:
export DEBUGINFOD_URLS="https://debuginfod.debian.net;
coredumpctl gdb 1546
(gdb) bt full
This will enable gdb to download needed debug symbol
Out of curiosity I investigated a little more.
With the below steps I could reproduce it in a minimal
Bookworm/testing amd64 qemu VM.
There the build stopped at this line:
dpkg-buildpackage: info: binary-only upload ...
And killing from outside this php process made the build
Dear Maintainer,
might this be caused by a process left running?
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
benutzer 743 0.0 0.4 217032 30284 pts/0S14:55 0:00 php -S
127.0.0.1:10002 tests/Integration/server.php
If that is really the case, would
Dear Maintainer,
if one creates this wine64-stable just as a link to wine64,
then `wine64-stable wineboot` would start to work.
# ln -s wine64 /usr/lib/wine/wine64-stable
Kind regards,
Bernhard
(rr)
692 execv( argv[1], argv + 1 );
(rr) print argv[1]
$2 = 0x7e848400
Am 04.02.23 um 16:26 schrieb Andreas Rönnquist:
Thanks - it does indeed sound reasonable to recommend on evince - If
you have evince installed, does printing work as you expect it then?
-- Andreas Rönnquist
gus...@debian.org
Sorry, I am not using geeqie regularly, I was just looking through
$ vflbanner -f /usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf
free(): invalid pointer
Aborted
Hello,
this seems to be call to hbf_release done twice [1].
If I see it right, if hbf_load_hbf_file is left via
the "Unexpected_Error" label, the hbf_release is still
called in
Source: vflib3
Version: 3.7.2+dfsg-0.1
Severity: wishlist
X-Debbugs-Cc: t...@test.de
Dear Maintainer,
I was looking at the crash in #1028311 when I found
the dbgsym packages did just help to get function names.
But getting also source line numbers would be desirable.
As far as I see these are
On Wed, 11 Jan 2023 22:48:42 +0100 waxhead wrote:
Tried to print a jpg picture
Restarted the machine, restarted printer, tried updating, looked at print queue
(nothing), tried preview print (nothing)
Tried to print from GIMP (success)
Hello,
I tried to reach the print preview window
On Wed, 18 Jan 2023 11:26:42 +0100 xevilstar wrote:
I am getting the following message in dmesg at boot
[Wed Jan 18 07:40:37 2023] gnome-control-c[14186]: segfault at 55a65c093a45 ip
7f206782b8f3 sp 7ffe36eef7d0 error 4 in
libgobject-2.0.so.0.7500.0[7f2067801000+32000] likely on CPU
On Tue, 31 Jan 2023 12:17:14 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=
wrote:
On 2023-01-31 05 h 02, Bernhard Übelacker wrote:
> could that be a dependency to "notification-daemon"?
No, this package is also installed on my system:
So I assume this daemon is not ru
#5 export_troff (bytes=0xd438, cv=0x56564ae0) at codec/export.c:1056
Dear Maintainer,
this crash happens because the array ansi2troff has
just 16 values, but gets accessed at value 32.
This value 32 originates from the constant CACA_TRANSPARENT.
With the below patch the crash could be
On Wed, 11 Jan 2023 15:20:22 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=
wrote:
On 2023-01-11 01 h 26, Birger Schacht wrote:
> The crash message ("Failed to show notification") sounds to me as if
> there is maybe no notification daemon running?
Here are the packages reportbug lists.
Dear Maintainer,
this can be reproduced in current Bookworm/testing too.
The backtrace below shows PyBytes_FromString received for
parameter str a NULL, which documentation states must not be NULL [1].
Unfortunately could not find an issue or update in upstream page [2].
Kind regards,
Bernhard
at <0x>
at (wrapper managed-to-native) GLib.SList.g_free (intptr) <0x0005f>
at GLib.ListBase.Empty () <0x0013c>
at GLib.ListBase.Dispose (bool) <0xf>
at GLib.ListBase.Finalize () <0x0001d>
at (wrapper runtime-invoke)
Control: reassign 1028220 libglib2.0-cil 2.12.40-3.1
Control: affects 1028220 cowbell
=
Managed Stacktrace:
=
at <0x>
at
Am 24.01.23 um 00:30 schrieb piorunz:
On 23/01/2023 22:46, Bernhard Übelacker wrote:
https://bugs.debian.org/1028197
On Mon, 23 Jan 2023 21:48:23 + piorunz wrote:
On 23/01/2023 13:35, Bernhard Übelacker wrote:
journalctl --user --since="2023-01-08 12:10" --until="20
https://bugs.debian.org/1028197
On Mon, 23 Jan 2023 21:48:23 + piorunz wrote:
On 23/01/2023 13:35, Bernhard Übelacker wrote:
journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12"
-- No entries --
Then please try something like this:
journalctl
Am 23.01.23 um 23:07 schrieb piorunz:
On 23/01/2023 21:59, Bernhard Übelacker wrote:
Hello Piotr,
if it is not clear it would be possible to take
the bug number from the email addresses and open
the bug page e.g. https://bugs.debian.org/1028208.
This was just about the plasma-discover crash
Am 23.01.23 um 22:48 schrieb piorunz:
On 23/01/2023 13:35, Bernhard Übelacker wrote:
(gdb) bt
#0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int
On Thu, 12 Jan 2023 18:31:37 + =?UTF-8?Q?Julian_Gro=c3=9f?=
wrote:
My computer just froze on Kernel version 5.19.11-1. Though nothing got
logged.
Now I don't know if this is the same issue and newer kernels just behave
better in terms of logging, or if this is a different issue..
I
Package: gdb
Version: 12.1-4+b1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I tried to debug a mono application in another Debian bug.
There I received the assertion below, with just trying to run
the application inside gdb.
I found this gdb upstream bug report:
(gdb) bt
...
#4
#5 0x7f54b82563fb in QQuickItem::~QQuickItem() () from
/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6 0x7f54b83d0045 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5
#7 0x7f54b66dd53f in QObject::event(QEvent*) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#8
(gdb) bt
#0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from
/lib/x86_64-linux-gnu/libKF5Crash.so.5
#3
#4 0x7fbffc2a9ccc in ?? ()
On Sat, 14 Jan 2023 18:07:08 + Stephan =?ISO-8859-1?Q?Verb=FCcheln?=
wrote:
This bug appears back some time ago. For some months, video thumbnails
failed to generate on multiple of my machines. Since then, I was trying
to figure out the cause.
It only seemed to affect h264, but not all
Am 22.01.23 um 14:19 schrieb Gregor Riepl:
FYI: My kded core dumps also contained something about a closed DBus
connection in a different thread's stack trace. Perhaps this is related?
I am not able to exclude it to be related, maybe it is the start of the
row of events. When debugging
On Fri, 06 Jan 2023 15:08:11 +0100 Lucio Crusca wrote:
$ time ccd2iso e.i.vol.16.img e.i.vol.16.iso
Unrecognized sector mode (0) at sector 0!
real0m0,110s
user0m0,003s
sys 0m0,005s
$ ls -lh *.iso
Dear Maintainer,
this seems to be an upstream issue.
The ccd2iso author states
On Fri, 06 Jan 2023 16:50:02 +0100 Gregor Riepl wrote:
...
#14 0x7f9c8c26f6ed in QObject::connect<...> (...) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268
#15 TransactionJob::TransactionJob (...) at ./apperd/TransactionJob.cpp:47
#16 0x7f9c8c271648 in
On Fri, 30 Dec 2022 09:46:49 -0300 craudio wrote:
#8 0x7f2ba43e5b99 n/a (kded_apperd.so + 0xeb99)
#9 0x7f2becae8fcf n/a (libQt5Core.so.5 + 0x2e8fcf)
#10 0x7f2ba4323095
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList
(libpackagekitqt5.so.1 + 0xe095)
Hello,
this
Dear Maintainer,
I tried to reproduce this segfault.
Unfortunately this did not work as expected.
The segfault in multi-thread did not show up.
But I received one in multi-dict (in e.g. 3 of 6 runs).
This was done in a up-to-date unstable amd64 VM,
running at a AMD cpu, 16 threads given to the
On Wed, 14 Dec 2022 10:07:27 +0100 martin f krafft
wrote:
Package: scrcpy
Version: 1.24-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Running `apt build-dep scrcpy` and `fakeroot debian/rules binary`
results in plenty of
On Mon, 5 Dec 2022 21:33:03 +0100 martin f krafft wrote:
Package: scrcpy
Version: 1.24-1
Severity: grave
The package depends on libavdevice59, but it's apparently built
against libavdevice58:
lotus:~% ldd =scrcpy | grep libavdevice
libavdevice.so.58 => not found
Hello Martin,
can you
On Tue, 27 Dec 2022 00:11:12 +0100 Tobias Frost wrote:
On Mon, 26 Dec 2022 16:53:27 +0200 Kostadin Shishmanov
wrote:
> I think it happens because libllvm15:i386 is at version 15.0.6-3+b1, while
libllvm15:amd64 is at version 15.0.6-3
This is due to #1025530: on i386, the binNMU built and
Forwarding, as the email from TJ possibly did not reach Felix.
On Fri, 21 Oct 2022 11:43:07 +0100 TJ wrote:
On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach wrote:
> I noticed that vgamem_mb was still low (32 MB).
> So I changed to this (slightly wasteful) command-line and am now running
After enabling "With a dragged window" in xfwm4-settings
which switches off the tile_on_move setting,
the user can re-enable this setting by
"Automatically tile windows when moving towards the screen edge"
in xfwm4-tweaks-settings.
(If both settings applications are opened side by side,
one can
The patch at the bottom would set tile_on_move to true,
if the "With a dragged window" gets switched off.
Now after some sleep I found that this might really be the
way upstream wants this to handle, so the patch is wrong.
After enabling "With a dragged window" in xfwm4-settings
which
"With a dragged window" - default as far as I see is on.
I confirm that either with those 4 defaults, or with "with a dragged
window" off (as you suggested that would fix it), I still have it bugged.
If you still don't get a dragged window filling half of the screen,
then I can't
And indeed, when unchecking following in Window Manager
settings it seems to "snap" again:
Wrap workspaces when reaching the screen edge / With a dragged window
I had that one disabled (but I didn't do that; I guess it was like
that by default). My windows don't move to other
When I upgraded my Sid system yesterday (I do it every week or so),
windows cannot be moved to the edge of the screen to have them use half
screen. It simply moves there without readjusting.
Dear Maintainer, hello Alejandro,
this looks like it appeared in unstable with the
appearance of
Short addition:
I tried to bring this to the attention of packagekit-qt
developers in this bug report:
https://github.com/PackageKit/PackageKit-Qt/issues/42
Kind regards,
Bernhard
Dear Maintainer,
I was able to reproduce this issue inside a minimal
amd64 qemu VM running Bookworm/testing.
By editing the kded service unit [1] I could get valgrind have a look
at this issue and it produced a matching use-after-free [2].
By further editing the service unit I was also able to
Dear Maintainer,
I retested this inside a minimal Bookworm/testing VM now because
the last plasma package updates seem to have settled a bit.
Unfortunately the black background
and the 30 seconds splash are still visible.
At least in this bug report at least the black
default wallpaper gets
Am 01.01.23 um 16:55 schrieb Uecker, Martin:
This is likely a numerical error caused by reordering a
floating point sum by parallelization. It is not worth
spending time on it.
I can apply the patch, but I do not have much time now.
Is there some urgency?
Not from my side, I just tried to
Hello,
thanks for your immediate responses.
Am 01.01.23 um 15:55 schrieb Uecker, Martin:
One could just relax (or simply remove) the test from bullseye
or packport the version bookworm.
I guess that would be applying 0003-relax-failing-unit-test.patch
to the Bullseye version.
The wine
Dear Maintainer,
I could reproduce this failure in a bullseye VM.
There the "test_nufft_adjoint" fails in about 1.2 % of the runs.
Attached diff helps to make it more visible.
It looks like the float comparison fails because the
limit of "1.E-6f" is slightly not enough.
If interpret following
Dear Maintainer,
I could reproduce this issue by these steps:
- installed a minimal test VM with `apt install systemd-coredump mc xdm
xserver-xorg jwm xterm atril latexmk texlive-latex-extra gdb
libatrilview3-dbgsym libgtk-3-0-dbgsym libglib2.0-0-dbgsym atril-dbgsym`
- created the PDF by
Dear Maintainer,
this backtrace looks similar to the ones shown in these upstream bugs:
https://gitlab.gnome.org/GNOME/gimp/-/issues/1891 (open)
https://gitlab.gnome.org/GNOME/gimp/-/issues/3103 (closed)
https://gitlab.gnome.org/GNOME/gimp/-/issues/6457 (closed)
With the instructions in
I upgraded from 2.04-20 to 2.06-7, and after rebooting I discovered
that I could no longer boot my Windows partition.
Downgrading back to 2.04-20 solved this, so only the grub packages
are causing this.
The whole os-prober section is omitted with 2.06-7. This is what
should be there (diff
On Tue, 13 Dec 2022 01:28:39 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
wrote:
Dear Maintainer,
I experienced since about a month ago sometimes crashes in applications
running in fullscreen, when doing display configuration changes
or lately when waking up the screen from power saving.
(See
Package: plasma-workspace
Version: 4:5.26.4.1-1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I noticed since a week or so a change in behaviour of a plasma desktop.
If i install in a minimal VM the package task-kde-desktop after logging
into the desktop no wallpaper is
1 - 100 of 1269 matches
Mail list logo
