Control: retitle 927940 [Windows Subsystem for Linux] Applications cannot find
libQt5Core.so.5
Hello Ryo,
> I encountered this problem with my WSL environment.Not quite the usual kernel
> ... ;-)
A google search leads to this information [1]
and this bug [2].
There a workaround is provided b
Hello Osama Nasr,
I tried to reproduce this issue in a minimal Unstable VM
with plasma-desktop and konqueror installed.
But could not reproduce it.
Could you try to start it from a konsole and forward
the output you get there after you hit this bug?
And have you configured something non-default i
Hello Ryo IGARASHI,
I just trying to triage this bug, and have in a minimal
Buster amd64 VM installed just paraview installed and
could not reproduce the issue.
Could you please check the output in your system for any
differences to the outputs below:
dpkg -l | grep -E "paraview|libqt5core5a"
Control: tags 924445 + moreinfo
Hello Joshua,
the given information seems not sufficient to start investigation.
Therefore, if you still can observe this crash, you might install
the packge systemd-coredump, trigger the crash, then retrieve
the output of following command and forward it to this b
Dear Maintainer,
I just tried to find some more information.
I could reproduce the issue in a unstable amd64 VM
on the second attempt.
It looks like in a garbage collector run a
division by zero is triggered because we
get there with sector_size==0.
If wanted I can forward the core file.
Kind r
Hello gpe,
this stack trace looks really like that one
submitted in https://bugs.debian.org/927728 .
Possibly you can install just libgeocode-glib0 3.26.1-1
from unstable?
>From my findings in https://bugs.debian.org/927728
I would expect that this crash should then be gone.
Kind regards,
Bernha
Hello gpe92,
maybe you could add some more information for the maintainer
by following steps, if possible:
- install the package "systemd-coredump"
- try to start gnome-maps again
- forward the output of following command to this bug:
journalctl | sed -n '/dumped core/,/systemd-coredump@/p'
I
Hello Daniel Kahn Gillmor,
the backtrace looks similar to that from this bug:
https://bugs.debian.org/924029
Kind regards,
Bernhard
Hello Paul Wise,
might this be related to #925539 ?
Can you still reproduce it when you install
libgeocode-glib0 3.26.1-1 from unstable?
Kind regards,
Bernhard
https://bugs.debian.org/925539
Hello Dave Kitchen,
I am not involved in packaging kate, just trying to collect
some more information.
You wrote you open via nautilus - so you are running a
Gnome/Wayland desktop session?
I tried to reproduce the issue in a Gnome/Wayland session
but could not find a problem. In kate the native G
Hello Pere Nubiola Radigales,
I just saw this report without being involved in packaging freecad.
And tried to reproduce the issue but failed.
Is it possible to save it into a file just before it crashes?
Can the crash be reproduced by starting from that file?
Otherwise you could install the pack
Control: tags 922943 + upstream fixed-upstream patch
Control: tags 319221 + upstream fixed-upstream
Dear Maintainer,
this bug seems to be a duplicate of #319221,
which got forwarded and fixed upstream.
Attached is a targetted patch, slightly changed from
upstream [1] to apply, just resolving thi
Dear Maintainer,
one short addition, I tried to install to a current buster system
some versions from snapshot.debian.org.
Some versions around Stretch release allow a connection and
interacting with the desktop is possible.
Just on disconnect Xtigervnc crashes but cannot
say if that is related.
Control: found 922323 0.9.20180101-1+b1
Control: tags 922323 + upstream
Dear Maintainer,
I tried to have a look at this segfault, and guess I
have found something.
The problem seems to be, that the slirp library used
by Basilisk is using some 32 bit types for pointers.
Unfortunately this does no
Control: reassign 923962 libunwind8 1.2.1-9
Control: affects 923962 tigervnc
Dear Maintainer,
I guess this could be a problem in libunwind8 at aarch64.
Please find in message #15 some more details.
Kind regards,
Bernhard
#15 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923962#15
Dear Maintainer,
I just tried to collect some more info from this crash.
I got this by using "peek --backend=gnome-shell"
inside a gnome/wayland session.
Using some reverse debugging, I guess all happens below function
peek_post_processing_ffmpeg_post_processor_generate_animation_async_co,
that s
Hello Adam Borowski,
I am just looking through crashes of random packages and tried to
get some more information from that.
The line information from your backtrace and that in 268630
looks quite equal, so it might still be the same cause.
In this bug and in 268630 xbindkeys-config might crash
bec
Control: tags 268630 + upstream patch
Dear Maintainer,
I just tried to have a look at 926554, but I think
both are kind of the same.
The issue here is, as far as I see, that in function
middle_get_key a process "xbindkeys -k" gets started
and its output is tried to be parsed.
Unfortunately if t
Dear Maintainer,
from the segfault and also the code line this
may be a duplicate of #926212.
At least the crash points to the same source line:
src/shell-app.c, line 1485.
Kind regards,
Bernhard
#926212 https://bugs.debian.org/926212
# Buster amd64 qemu VM 2019-04-19
apt update
apt dist
Hello Marcus Lundblad,
I don't know if it is related - I own a Baytrail
device that contains also these axp devices.
Back in late 2017 I got some help from Hans de Goede,
who worked that time in that area.
There my battery information was also missing with
the stock debian kernel.
He suggested to
Hello Johan Mollevik,
I am maintaining neither python, gdal or matplotlib, was
just trying to reproduce the memory error.
Unfortunately it worked in my minimal test VMs without
crash or fault.
Comparing the versions of my tests led me to the question
if the system, where you experience this fault
Am 17.04.19 um 09:04 schrieb Bernhard Reiter:
> Am Dienstag 16 April 2019 22:32:30 schrieb Bernhard Übelacker:
>> - Signature Validation: Signature is Valid.
>> - Certificate Validation: Certificate has Expired
>
> Looks good, so it seems that libnss3 has a different c
On Tue, 16 Apr 2019 22:47:14 +0100 Simon McVittie wrote:
> How sure are you that the virtual memory area starting at 0x7fd4fa6a6000
> starts with .init and not .text?
Unfortunately I am not completely sure, but I caused a crash while
knowing the memory layout and found there also the dmesg line
c
Dear Maintainer,
tried to have another look with the original input file.
In my minimal test VM I came again across the segfault I
described in message #10, which is not the
problem Wesley hit and got sumitted in #926404 too.
So I had to start firefox once to have a profile
in the home directory.
Am 16.04.19 um 12:04 schrieb Bernhard Reiter:
>> there was neither /etc/pki/nssdb nor a firefox profile in the
>> home directory.
>
> Can you post the signature information?
> My guess from the code is that you saw the info,
> but no certification validation.
benutzer@debian:~$ /usr/bin/pdfsig Sa
Hello Kim-Alexander,
thank you for the fast response.
I loaded the core and found following backtrace.
(Information how to retrieve it attached.)
Kind regards,
Bernhard
(gdb) bt
#0 0x7f65d13e3dd9 in __bswap_32 (__bsx=) at
/usr/include/x86_64-linux-gnu/bits/byteswap.h:52
#1 sieve_bytecode_
Hello Bernhard,
> The indicateion is the difference in the messages in the original problems:
> #924050: Internal Error (0): Input couldn't be parsed as a CMS signature
> #926404: Internal Error (0): couldn't find default Firefox Folder
Yes, I fear I hit not the submitters problem in #924050 and
Hello Wesley Schwengle,
I am not sure anymore if the error I received is the same you got.
Therefore, if you can still reproduce this issue, can you please
run pdfsig inside a debugger like below and forward the output to
this bug? You would at least need to install the package 'gdb'.
gdb -q -
Control: tags 924050 + upstream fixed-upstream patch
Dear Maintainer,
> Program received signal SIGSEGV, Segmentation fault.
> 0x77321c84 in SECMOD_ReferenceModule () from
> /lib/x86_64-linux-gnu/libnss3.so
> #0 0x77321c84 in SECMOD_ReferenceModule () from
> /lib/x86_64-linux-
Hello Kim-Alexander Brodowski,
I just tried to get some more information from the segfault
lines, while not being involved in packaging.
It seems to point to function sieve_bytecode_version
in sieve/bc_eval.c:1809.
Unfortunately upstream seems to have removed/rewritten that
function completely [1]
Hello Juanjo Espí,
I just tried to reproduce this issue to get some
more informations for the Maintainer.
Unfortunately due to my limited docker
knowledge I was not successful.
Therefore you might supply some more information by installing
gdb, attaching it with following command and then start th
Control: tags 927027 + patch
Dear Maintainer,
I tried to have a look at this crash and I think it is related to
the large file support, which is defined in dcfldd.h, line 27 and 28.
Unfortunately this file gets not included first in split.c and
therefore off_t gets defined without large file sup
Hello Alf,
Am 12.04.19 um 22:10 schrieb Alf:
> I am prepared to test your patch as soon as I get a binary of the
> patched lib.
please find attached some commands to build the package
with the patches in question by yourself.
Maybe you want to do this on a different machine as it
installs quite
Dear Maintainer,
I tried to triage that issue and came to this try and catch block:
146 try {
147 PlainPasswd plainPassword(obfuscated);
148 password->replaceBuf(plainPassword.takeBuf());
149 PlainPasswd plainPasswordReadOnly(obfuscatedReadOnly);
1
Control: reassign 921266 libbellesip0 1.6.3-4
Control: affects 921266 linphone
Control: tags 921266 + upstream patch
Hello Alf,
> Hope this helps you to locate the root cause.
I had a quick look at this line and found that upstream has
changed these lines already in their repository,
these comm
Hello Alf,
thanks for the fast response.
You can query to which package a shared object belongs by:
dpkg -S /usr/lib/x86_64-linux-gnu/libbellesip.so.0
That should show 'libbellesip0' I guess.
So, if package libbellesip0-dbgsym gets installed, another
retry should have all needed debug inform
Hello Thorsten Glaser,
Am 24.03.19 um 14:25 schrieb Thorsten Glaser:
> Bernhard Übelacker dixit:
>
>> I see that the syscall number gets modified to become 0x4062.
>>
>> But the syscall modifies 144 bytes, more than just the size of
>> variable ru1 of 88 byte
Hello Alf,
maybe we can get more context of this crash
by doing one of the following:
- Install gdb and run linphone like this:
script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex
'bt' -ex 'bt full' -ex 'detach' -ex 'quit' --args linphonec -d 5 -l
linphone-debug" -a g
Control: tags 926658 + patch upstream fixed-upstream
Dear Maintainer,
I just tried to help triage this issue.
I think this is related to upstream bug [1] and
was already fixed in the 5.2 branch by commit [2].
A package built with this patch does just show the
'undefined variable' error, but not
Hello Adrian,
> I don't have any of those old GNOME applications installed, you mentioned.
Then these files should not be there I guess like e.g.:
/usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml
On a system where e.g. easytag is installed a 'dpkg -S' returns this:
$ dpkg -S /usr/sh
Control: tags 926408 + upstream patch
Control: tags 926408 - moreinfo unreproducible
Dear Maintainer, Hello Gudjon,
I forgot to mention that this little "save" button should be on the
developers information tab of DrKonqi. Then you should not need to
do something in gdb manually.
However, I over
Hello Guenter Grodotzki,
(I guess you wanted me to receive your last message, so you should
use "reply all", or it gets just attached to your bug report.)
I have left a note in this upstream report [1], lets see if they agree.
Kind regards,
Bernhard
[1] https://gitlab.gnome.org/GNOME/gnome-shel
Dear Maintainer,
just tried to help triaging this issue.
Seems this is "expected" behaviour with LC_ALL not
set to "C". In the end it leads to this upstream bug:
https://github.com/sirfz/tesserocr/issues/165
It contains some workarounds and more information.
Kind regards,
Bernhard
# Buster
Hello Guenter Grodotzki,
I just tried to help triage that issue.
For some reason you just added the segfault line.
I assume there was one line following starting with "Code:".
Please add that line too when submitting bugs.
As this information is still kind of small, you might consider
to install
Hello Jérémy,
sorry for the delay.
> So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,
> npm install electron-spellchecker@1.1.2
> no longer crashes.
>
> That doesn't prove there is no crash on a supported cpu, but that's a start.
> Comparing the flags and address sizes might
Hello Bernhard E. Reiter,
just tried to help triaging this bug.
It sounds quite similar to an already filed bug #924050 .
Is pdfsig on your system really not crashing if firefox is installed?
Maybe you could run following command in a terminal to get a backtrace
from a debugger when it crashes a
Control: tags 926408 + unreproducible moreinfo
Hello Gudjon I. Gudjonsson,
just tried to triage this report and could unfortunately not
reproduce the crash either in a VM or a regular desktop system.
You should received a crash message from "drkonqi".
(The bad smiley icon in the tray near the cl
Dear Maintainer,
tried to get some more information out of the
kernel segfault line, until a backtrace or core
gets delivered...
For the lines with "ip .90e" I guess
it could be related to these functions:
array_append_array_i
mailbox_uidset_change
mail_search_arg_init
It migh
Hello Jérémy,
Am 29.03.19 um 12:44 schrieb Jérémy Lal:
> This fails too:
> yarnpkg add electron-spellchecker@1.1.2
>
> Are you all doing this on qemu or on real hardware ?
> On i686 ?
> I'm asking because buster does not support i586, nor does nodejs,
> and it seems qemu defaults to something < i
Control: fixed 902893 0.9.13-6
Dear Maintainer,
just tried to make a more readable stack out of these
backtraces.
This one points to function snapshot_stack_list,
and this one saw also a fix some time ago.
Therefore marking as fixed.
Kind regards,
Bernhard
https://github.com/LibVNC/x11vnc/pu
Control: fixed 857498 0.9.13-6
Dear Maintainer,
just tried to make a more readable stack out of these
backtraces.
So that one points to function "record_CW" and a buffer
overflow in that function got fixed in [1],
like mentioned in last message.
Therefore marking as fixed.
Kind regards,
Bernha
Control: retitle 925553 audacity: with ssh X-forwarding:
PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed.
Hello Jeff Cliff,
I looked at this backtrace without deeper knowledge of
audacity and the problem might not be a segfault in
mentioned funciton, instead a SIGABRT f
Control: tags 925577 + upstream patch
Dear Maintainer,
I tried to have a look at this crash and
could reproduce the issue.
It seems a pointer to the name-parameter value is queried
from libconfig9 and some lines later this pointer gets freed.
Unfortunately libconfig9 tries to free the pointer l
Hello Jérémy Lal,
unfortunately yes, it still crashes.
Attached file shows a test starting with a minimal up-to-date
Buster i386 qemu VM, and as far as I see after the crash
/usr/local/lib/node_modules does not exist and following command
shows just these files in ~/node_modules, so I can assume
i
Hello Everyone,
I tried to track down when this crash got introduced into testing.
It still did not crash at 2019-01-31.
(While still not succeeding because of a linker error.)
The next day these packages transitioned into testing:
- apparmor iso-codes libapparmor1 libsqlite3-0 sysvinit-utils
Control: fixed 925539 3.26.1-1
Dear Maintainer,
unfortunately realised just now that there is
already a newer version 3.26.1-1 in unstable which
contains both patches - should therefore fix the issue.
Kind regards,
Bernhard
Hello Mattia,
Am 26.03.19 um 15:32 schrieb Mattia Rizzolo:
> On Tue, Mar 26, 2019 at 01:40:47AM +0100, Bernhard Übelacker wrote:
>> Therefore gdb may not show the line information I guess.
>>
>> Maybe you can please send the output of the disassemble
>> and x command
Hello David Bremner,
now the hint in the subject makes sense ;-)
I can perfectly reproduce the crash now.
I compared the arguments from the build log [1]
and reduced it until the crash happens and
the important part is the "-D BLISS_USE_GMP".
Therefore /usr/share/doc/bliss-doc/examples/Makefile c
Hello Mattia Rizzolo,
I am just looking at some random crashes, and
tried to detect at which exact instruction
in libgtkmm-2.4.so.1 we are in the given backtrace.
That function contains just two instructions.
But the backtrace from the core dump tells we crashed
at ...459, which is in the middle o
Hello David Bremner,
>> Maybe something got lost in the input file,
>> so you could attach it to the email?
> ok
Thanks for the file, but unfortunately that makes no
difference - works fine in my test VM.
>> Is the backtrace you copied all of the output or
>> did you remove the frame in functio
Hello Guenter Grodotzki,
I am not the maintainer for tilda, just got here and
tried to collect some more information.
For some reason your upstream report contains one
(interesting) lines more than made it into the debian report.
Just as a hint: the real important information has to be
queried fr
Hello David Bremner,
I just tried to reproduce this crash, while I am not
involved in packaging and without knowledge of bliss.
I always this output:
benutzer@debian:~$ bliss myciel3.col
Generator: (2,4)(3,5)(7,9)(8,10)
Generator: (1,2)(3,4)(6,7)(8,9)
Nodes: 6
Leaf no
Hello Dimitris, hello di dit,
I think the issue is that freefem++s configure activate
AVX instructions when the build CPU supports it.
I could reproduce the crash in a Buster amd64 qemu VM, that
unintentionally did not support AVX (while the VM host would).
That led to following backtrace:
Control: tags + 924496 unreproducible
Hello Fred,
Am 20.03.19 um 22:22 schrieb Fred Korz:
> I loathe Heisenbugs! Sorry for the time waste.
>
> I tried the same IPod on my home system which runs vanilla debian
> testing and has the same version (3.4.3-2) of rhythmbox. I could not
> reproduce t
Hello Thorsten,
Am 24.03.19 um 01:46 schrieb Thorsten Glaser:
> Bernhard Übelacker dixit:
>
>> Now I wonder if a x32 binary doing a syscall getrusage to a 64bit
>> kernel is supposed to supply memory like "long" would be 8 bytes?
>
> The x32 kernel is amd64,
Dear Maintainer,
I just tried to get some more information.
Following backtrace, little after the stack smashing happend, I could
reproduce with a amd64 qemu VM crossgraded from Buster amd64 to x32. :-)
That "struct rusage" has some elements of type "long" [1].
In gdb sizeof shows 4 bytes for suc
Forgot to attach the file with some more information.
# Buster amd64 qemu VM 2019-03-22
apt update
apt dist-upgrade
apt install dpkg-dev devscripts systemd-coredump xserver-xorg dbus-x11 lightdm
openbox evince gdb evince-dbgsym libglib2.0-0-dbgsym libevview3-3-dbgsym
libevdocument3-4-dbgsym l
Control: reassign 924029 libpoppler-glib8 0.71.0-3
Control: affects 924029 evince
Control: tags 924029 + patch upstream fixed-upstream
Dear Maintainer,
I just tried to reproduce the issue and received the crash below.
For some reason poppler_annot_get_modified returns a null pointer,
instead of
Control: tags 924050 + upstream fixed-upstream patch
Dear Maintainer,
I tried to reproduce this crash, and received one with
this example file [1].
But due to the lack of the submitters original
file, this crash might be different.
However, following crash got already fixed upstream [2][3]
and r
Dear Maintainer,
just tried to collect some more information.
I could reproduce the issue inside a qemu amd64 VM,
running current Buster.
Not every attempt resulted in a crash.
Indeed "file" seems to report just the first 80
character of the command line.
Like gdb does too when it opens a core fi
Dear Maintainer,
just trying to get some more information from the attached core.
It looks like the pointer stored in pPixmap->drawable.pScreen got
somehow overwritten and was then invalid, therefore received a SIGSEGV.
Kind regards,
Bernhard
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sys
Dear Maintainer,
so both issues have the same root and upstream commited this,
to open the dbus interface as soon as possible.
https://cgit.kde.org/plasma-workspace.git/commit/?id=9a4bb220c162f031b4d45ed04f9e156b6d0b852e
Kind regards,
Bernhard
Control: tags 924402 + upstream
Hello Dimitry,
thanks for your quick response.
> Can I ask you to submit your patch upstream to [1], either as a pull
> request or as a simple issue?
I just created this pull request:
https://github.com/annulen/webkit/pull/803
Kind regards,
Bernhard
Hello Everyone,
I think the same issue manifested in bug #924402.
To me it looks like the problem started when -fpermissive
got added to get the i386 build working again.
Without that a compiler error "invalid conversion" got hit,
because a derived class missed the attribute fastcall.
In bug #92
Control: tags 924402 + patch
Hello Everyone,
I continued to look into the "invalid conversion" and think
the problem is member JSImageConstructor::construct is
missing the __attribute__((fastcall)) aka JSC_HOST_CALL.
Attached patch to qtwebkit-opensource-src-5.212.0~alpha2
removes the -fpermissi
Hello Everyone,
might this report be the same issue as following?
https://bugs.debian.org/922608
Kind regards,
Bernhard
Control: merge 908549 924448
Hello Kingsley,
> It's OK with me if you merge my bug report, #924448, with it.
Ok, I am trying to do so.
> ... why
> 1.) Frederic MASSOT wrote
> "The fix is built-in for versions 2.10"
> at
> https://bugs.debian.org/cgi-bin/bu
Hello Fred Korz,
I just tried to get some more information out of backtrace,
without having an iPod or being involved on packaging rhythmbox...
But am I right this "Debian Release: rodete" is a version
of gLinux - Googles internal rebuild of Debian testing?
Can this be downloaded somewhere?
And a
Hello Kingsley G. Morse Jr.,
> My main concern?>> The normal way of eliciting a back trace from> within gdb
> didn't work.> > The non repeating lines were reported by defining> a function
> in gdb and logging output to a file.
You can start gimp that way to get a backtrace:
script -c "gdb
Hello Kingsley G. Morse Jr.,
the backtrace of the crash you reported seems to be quite
similar to another bug reported in #908549.
Can you confirm that you just forwarded the top 19 frames
and that they kind of repeat all the time?
Kind regards,
Bernhard
#908549: https://bugs.debian.org/cgi-bin
reassign 923720 libappstreamqt2 0.10.6-2
Control: reassign 923720 libappstreamqt2/0.10.6-2
Control: affects 923720 plasma-discover
Control: fixed 923720 libappstreamqt2/0.11.3-1
Control: fixed 923720 plasma-discover/5.10.5-1
Control: tags 923720 + upstream fixed-upstream patch
Hello Everyone,
tried to get some more information from the
Hello Andriy Grytsenko,
tried to reproduce but could not find the file "meteoCNS" anywhere on the net.
Instead found following file that triggers the same crash stacktrace:
openclipart-svg:
/usr/share/openclipart/svg/recreation/religion/christianity/coat_of_arms_of_anglica_01.svg
Navigating
Control: tags 908549 + fixed-upstream
Hello,
Just adding the fixed-upstream tag.
The patch might be small enough to be
cherry-picked to version 2.8 in buster?
https://gitlab.gnome.org/GNOME/gimp/commit/a2c20b15392d456b36afdc9074d1176f02403b29
Kind regards,
Bernhard
Control: tags 920139 + unreproducible moreinfo
Hello Adrian Immanuel,
I am sorry for the late reply.
First a question: Do you still observe this fault?
I took a look today inside the md5sums you supplied
and tried to reproduce this setup inside a VM.
Unfortunately I found following old packag
Package: plasma-workspace
Version: 4:5.14.5.1-1
Severity: normal
Tags: patch upstream
Dear Maintainer,
I found that the splash screen takes longer than some month ago and did
some investigations that led to following two upstream bugs I reported.
Bug 405444 - ksplashqml hits its hard timeout o
Hello Sandro,
Am 05.03.19 um 00:43 schrieb Sandro Knauß:
> Btw. please use the bugnumber-qu...@bugs.debian.org rarely, because than
> maintainers like me don't gets any mails, that's why I missed your
> conversation.
Sorry for using -quiet - Pino Toscano made me already
aware to avoid -quiet.
Control: reopen 921959
Control: reassign 921959 tftpd 0.17-22
Hello Everyone,
I hope it is ok to reopen and reassign this report to package tftpd,
which I assume Alison Chaiken has installed, based on the addresses
in the supplied backtrace.
I assume this is the result of some implicit "Object
Package: vlc-plugin-video-output
Version: 3.0.6-1
Severity: normal
Tags: upstream upstream-fixed patch
Dear Maintainer,
I received a "SIGFPE, Arithmetic exception." while the menu of a to
hard disk copied VIDEO_TS folder was playing and then pressing space.
For some reason I did not get that exc
Package: udisks2
Version: 2.8.1-3
Severity: normal
Dear Maintainer,
I received a crash of udevd by doing an unmount of a ntfs partition
of an usb stick via the plasma systray icon.
As far as I see in this case in function udisks_linux_drive_object_get_block
is a call to udisks_linux_block_object
Ok, so the package corekeeper would be an option?
Is gdb-minimal also already too much?
Kind regards,
Bernhard
PS.: please leave the bugs email as CC or To. ;-)
Hello Zac Morris,
you still may consider installed systemd-coredump and
when it happens again provide the complete lines reported
by journalctl related to the crash.
I, as I said not deeply involved in dnsmasq and just trying to
collect some information, tried to replicate your configuration,
but
Betreff:Re: Bug#921310: dnsmasq "segment fault" bug when total conf
files size is too large
Datum: Sat, 9 Feb 2019 15:31:52 -0500
Von:Zac Morris
An: Bernhard Übelacker
Yeah, I didn't know how to update the case. Is there a web front-end for
updating/tr
Hello Adrian,
maybe one of the installed source files lead
to a bad gschemas.compiled file?
Could you create a file with the md5sums of all
the xml files that seem to get combined into that
gschemas.compiled file.
md5sum /usr/share/glib-2.0/schemas/* >
~/usr-share-glib-2.0-schemas-md5sums.t
Hello Zac Morris,
I am not the maintainer and just trying to get some
more informations of the segfault.
Unfortunately I think you need to provide some more
details on your used configuration.
The line shown in dmesg about the segfault could
also be of help already.
Otherwise you could also inst
Hello Jiri Palecek,
I could reproduce this issue also on amd64.
It looks intentional and seems like a security consideration
to make no crash dumps and is caused by this line:
kdesu.cpp:83: prctl(PR_SET_DUMPABLE, 0);
However, you may temporarily add SUID to gdb, then gdb
will run as
Hello Thomas,
Am 05.02.19 um 20:50 schrieb Thomas Gaugler:
...
> I thought to use the momentum around secure boot within Debian [2] for
> supporting it within win32-loader as well.
>
> The basic idea is to replicate the following commands in win32-loader:
> $ # Copy /usr/lib/shim/shimx64.efi.sign
Am 04.02.19 um 13:42 schrieb Didier 'OdyX' Raboud:
> Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
>> If such a system is detected, maybe a warning could be added?
>
> Sure. I suggest this would be done very early, but have no clue how to dete
Control: tags 920139 + moreinfo
Hello Adrian,
Am 03.02.19 um 09:24 schrieb Adrian Immanuel Kiess:
> The bug is, like I see it, that the applications cannot find the
> gsettings schema directory.
>From my point of view it might be more the file gschemas.compiled
inside that directory. Does that
Hello Jean-Dominique Frattini,
I am not involved in packaging any of these packages,
but I noted that you opened the last three days nearly
the same issue against three different packages?
What are you trying to achive that way?
And you noted versions contained in current Buster,
but you claim it i
801 - 900 of 1319 matches
Mail list logo
