Hello Johannes,
On Mon, 07 Jan 2019 21:06:28 +0100 Johannes Zarl-Zierl wrote:
> Hello Bernhard,
>
> Am Montag, 7. Jänner 2019, 01:00:13 CET schrieb Bernhard Übelacker:
> > Can you repeat that gdb command with following additional
> > dbgsym packages installed, to co
Package: dizzy
Version: 0.3-3
Severity: normal
Dear Maintainer,
this is the output of dizzy when started
on a desktop PC with amd graphics
or a qemu amd64 VM, both running current buster:
$ dizzy
GPU features: [x] GLSL [x] FBOs
Your vendor has not defined OpenGL macro
Dear Maintainer,
I tried to have a look at this segfault.
It seems this is a case of pointer truncation.
In following location [1] a pointer gets casted to int (pogl_glut.xs:1021)
and stored in freeglut_callbacks.c:115 into field ID of a SFG_Timer struct.
This leads later [2] to the crash when
Hello Johannes,
thanks for your fast respone.
Can you repeat that gdb command with following additional
dbgsym packages installed, to complete the backtraces:
libxcb1-dbgsym libqt5gui5-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym
libqt5dbus5-dbgsym libqt5core5a-dbgsym libglib2.0-0-dbgsym
Control: reassign 918370 krita 1:4.1.7+dfsg-1
Control: tags 918370 + upstream fixed-upstream patch
Hello Johnny, dear Maintainer
I tried to get some more information, but I think it is not
reproducable without that tablet hardware.
For future bug reports it would be very helpful if debug symbols
Hello Dominik Röttsches,
the missing debug symbols for libmariadbclient.so.18
might hide in libmariadb3-dbgsym.
You may also want to install these packages too:
dovecot-core-dbgsym dovecot-mysql-dbgsym
They should be available in a different debug symbol
repository described in [1].
I had a
Hello Michael Tokarev, hello Theo
I have now another machine at hand where I currently have
buster installed, where today qemu-user-static in
version 3.1 appeared.
So I did some tests.
It still shows the issue reported by Theo:
root@qnap-119p-ii:~# chroot /tmp/buster-chroot-i386 /bin/bash
Hello Michael Tokarev,
I am sorry, I have missed your mail from december.
Thanks for the information, I will report back
when I have tested it. (Forwarding to the submitter too.)
Kind regards,
Bernhard
Am 03.01.19 um 21:02 schrieb Michael Tokarev:
> Control: tag -1 + moreinfo
>
> Adding a bit
Hello Adam Knapp,
you might run octave inside gdb to retrieve a backtrace of the crash.
Run below command inside a terminal application and you should
receive a file gdb-octave*.log that you might forward to this bug.
gdb -q -batch -ex 'set pagination off' -ex 'set width 0' -ex run -ex 'bt
Control: reassign 892871 libasan4 7.3.0-5
Control: found 892871 7.3.0-12
Control: fixed 892871 7.3.0-13
Dear Maintainer,
did some tests with snapshot.debian.org and found
that crash does not happen anymore since libasan4:i386 (7.3.0-13).
Kind regards,
Bernhard
Hello Ian, hello Ted,
yesterday I tried to reinstall that device with the latest
buster installer - but unfortunately I was already too late,
the archive moved already too far away:
No kernel modules were found.
Therefore I did the reinstall with the stretch installer
and upgraded to buster,
Dear Maintainer, hello Philipp Marek
tried to have a look at this backtrace.
Unfortunately I could not reproduce a crash with a random test file.
See the same backtrace with all needed debug symbols below.
It points to following line 147:
(gdb) list
144 /* If this edge of the
Dear maintainer,
is this bug currently causing not being able to install gkrellm in a
current buster system where some packages depending on libsensors5 are
already installed?
I guess this is an unfortunate situation if it stays until the buster
release, as following is currently not possible in
Dear Maintainer, hello Mark Buranyi,
tried to reproduce inside a Stretch amd64 qemu VM.
I assume the first is calling the
SIGTERM handler [frame #9].
Unfortunately it looks like the module containing sig_term was already
unloaded at that time (mod_mpm_event.so).
Therefore executing that now
Hello Christian Schrötter,
not being involded in dovecot packaging I looked at this crash.
That address in event_unref seems to point here:
(gdb) disassemble /m event_unref,event_unref+370
Dump of assembler code from 0x77f33d70 to 0x77f33ee2:
...
210
211 void
Dear Maintainer,
as far as I found is the problem related to:
debian/patches/generate/icons.patch
That strips away the ico files from being included in the
resources in regedit. But the treeview seems just to be shown when
programs/regedit/treeview.c:InitTreeViewImageLists was able to
load the
Hello all,
that bug sounds like a duplicate of #917167.
Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917167
Dear Maintainer, hello Martin Gummi,
at least the crash seems to be exact the same as seen in #917269.
Kind regards,
Bernhard
#917269 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917269
Control: forwarded 917269 https://bugs.kde.org/show_bug.cgi?id=400638
Control: tags 917269 + fixed-upstream
Dear Maintainer, hello Braun Gábor,
I did a quick query in the upstream bugtracker and received
this result [1], where the user seems to even use debian
testing also, because the function
Control: reassign 917269 ffmpegthumbs 4:17.08.3-1
Dear Maintainer, hello Braun Gábor,
some informations on where and how to retrieve the debug symbol packages
is described in [1]. Maybe with them you can confirm my findings which
are just based on the offsets of the function addresses.
To
Sorry, missed the file.
# buster amd64 qemu VM
apt update
apt dist-upgrade
apt install systemd-coredump fakeroot mc gdb htop dpkg-dev devscripts quilt
apt build-dep libbio-tools-run-alignment-tcoffee-perl
apt build-dep t-coffee
wget
Dear Maintainer,
just tried to get some more information out of the crash.
It was not showing up with t-coffee 12 compiled in testing.
Just with switching to unstable and recompiling t-coffee
the crash manifested when
building libbio-tools-run-alignment-tcoffee-perl-1.7.4.
Unfortunately the
Control: fixed 917018 wget/1.19.1-1
Control: tags 917018 + upstream
Dear Maintainer, hello RW Penney,
I had a look and think I found something.
You have by any chance made something like 'chmod 000 ~/.wget-hsts' ?
Because in that case we end up in a backtrace like below.
(And stretch systems
Hello rwpenney,
just tried to reproduce and collect some information for the maintainer
on a minimal buster amd64 qemu VM.
Unfortunately I could not reproduce the crash
and after 700 files I stopped my test.
Maybe you could run the wget command like that:
gdb -q -ex 'set pagination off' -ex
Hello Alain,
just saw your report and though it sounds similar to another one [1].
Do you have linux-image in version 4.9.130-2 installed?
Were older kernels working like expected?
If possible you might want also check if reverting back
to 4.9.110-3+deb9u6 gives you a not hanging system on eject.
Hello Brian Potkin,
you might have a look at following commands to build a
complete local cups-browsed package with the upstream
patch included.
That may work better, as a plain make built shared lib
might be not enough compatible with the executable from
the debian package.
Just if you do not
Hello bitfreak25,
trying to get more details out of it I recognised that my physical PC
is also using radeonsi. "Unfortunately" my vlc closes correctly.
I tried to watch how on my system vlc is running through
vout_display_opengl_Delete
and found that on mine it diverts into
Hello Brian Potkin,
> You got exactly what I was shown.
You are right, and I just wanted to make a point how someone
who want to help can start right away with all the needed information.
> Do you really think reportbug would have added an imortant clue? It
> was clear that my original report
Control: found cups-browsed 1.11.6-3
And probably I was not clear in my message #36:
- I may have found something that could lead to your sitation,
and attached a change that might avoid it.
- I could not reproduce the crash because I do not have such printers.
- Maintainer or Upstream are
Hello Brian Potkin,
> Does the efficient and correct operation of a program depend on whether
> the system is amd64 or i386? Most of my machines are i386 only and, to
> my knowledge, Debian has not abandoned this architecture.
>
> I was probably incorrect in thinking I had tested the offending
Dear Maintainer, hello Brian Potkin,
> Thanks. All this is very new to me. I hope it is what is needed and
>
> someone can interpret it!
Thanks for the information, in my first attempts I was under the impression
you are on a amd64 system
Hello Brian Potkin,
I tried to have a look in a unstable VM, but unfortunately
I get different offsets ...
You might add the output of this command:
dpkg -l | grep -E "cups-browsed|libc6|libglib|libavahi|libdbus" | sort
And what output did you receive from this command
coredumpctl list
and
Hello,
probably you can also add following debug symbol packages:
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so ->
libgl1-mesa-dri-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 ->
libqt5dbus5-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
Hello Cristian Ionescu-Idbohrn,
following is what I get from a buster amd64 qemu VM,
with explicitly downgraded systemd packages to 239-13:
It has quite a similarity to upstream bug [1].
And upstream received a fix for that just a few days ago,
and is therefore not yet contained in an upstream
Hello Cristian Ionescu-Idbohrn,
Am 18.12.2018 um 09:35 schrieb Cristian Ionescu-Idbohrn:
> On Mon, 17 Dec 2018, Bernhard Übelacker wrote:
>>
>> Hello Cristian Ionescu-Idbohrn,
>> following is what I get from a buster amd64 qemu VM,
>> with explicitly downgraded
Hello Brian Potkin,
you might want to install a core dump collector like systemd-coredump.
With that in place you might get a more verbose message in journalctl.
Also a later inspection of the coredump might be possible:
coredumpctl list
coredumpctl gdb [PID]
bt
quit
And even better when
Hello
when you find such a failing to close vlc, you might
consider to run following line.
That should give you a vlc_*.txt file which contains
all threads current backtrace and might point to where
the vlc process is waiting.
for pid in `pgrep vlc`; do gdb -q --pid $pid -ex "set pagination off"
Hello Anton,
> (gdb) print/x $rax
> $7 = 0x0
> (gdb) print stmt->mysql
> $8 = (MYSQL *) 0x0
> (gdb) print *stmt->mysql
> Cannot access memory at address 0x0
>> (gdb) list libmysql.c:4134
>> 4134 if (stmt->mysql->options.report_data_truncation)
That null pointer seems to be the problem
Hello Vincas Dargis,
I just wanted to find out where in thread 4 this call to qTerminate
originates, without having deeper knowledge of akonadi ...
Unfortunately it looks like this backtrace just shows where we are in
the exception handler - effectively hiding where the exception really
happened
Hello Nils Jarle Haugen,
these instructions are great to reproduce the crash.
Below is the backtrace with debug symbols installed.
It looks like the vector m_boardLed->m_pin contains invalid
data, and therefore we crash when calling methods on an
element retrieved from it.
Valgrind shows the
Control: fixed 916200 1:2.30.2-0.3
Control: found 916200 1:2.31.1-0.1
Dear Maintainer,
I noticed this behaviour too and found last version that
normally exits is 2.30.2.
I did a git bisect that points to the upstream commit [1] below.
Kind regards,
Bernhard
[1]
Hello Anton,
On Fri, 14 Dec 2018 16:34:23 -0500 Anton Avramov wrote:
> Hello Bernhard,
>
> Well no. I've actually installed. apt install
> libmariadbclient18=10.1.26-0+deb9u1 libmariadbclient18-dbgsym
>
> (gdb) display/i $pc
> 2: x/i $pc
> => 0x7479eccc : movzbl 0x451(%rax),%eax
At
Hello Anton,
sorry, did completely miss the option that upstream could
also provide dbgsym packages ...
Just to be sure, the last backtrace was retrieved with upstream
binaries of version 10.2.19+maria~stretch?
And debug symbols are contained in libmariadb3-dbgsym?
Because your last backtrace
Hello Anton Avramov,
not involved in packaging of isc-kea I just read
your report and may have some points.
Why do you use the upstream binary of libmariadbclient.so.18.
Is the stretch packaged version 10.1.37-0+deb9u1 too old? [1]
And it looks like you installed the debug symbol package
Hello Marc Lehmann,
are you able to reproduce this hang on a installation
with just stretch package versions, too.
(Or maybe on a buster installation)
I ask because at least following packages are more current as
the plain stretch versions:
| versions reported | currently in
Dear Maintainer,
tried just to reproduce and found that this issue should be
solved upstream with commit [1].
Upstream has also an entry in their bug tracker [2].
This commit is not yet included in an upstream released version.
[1]
Hello Mindaugas Celiesius,
I just tried to reproduce the crash.
Unfortunately it did not crash in my test.
Therefore I assume the information you provided is not
sufficient for the Maintainer to correct the program.
Maybe you could install a core dump collector like systemd-coredump.
When
Control: reassign 909015 libcogl20 1.22.2-2
Control: affects 909015 abiword
Dear Maintainer,
this crash seems to be caused by a broken opengl configuration.
It could still be seen with buster when e.g. someone has the
nvidia-driver-libs-nonglvnd installed without the kernel module loaded.
Hello Jörg Frings-Fürst,
I am not maintaining roger-router, but just saw this report.
Do you still receive this segmentation fault?
If yes you might run roger like the following:
(That should print the backtrace when the segmentation fault happens.)
gdb -q -ex run -ex bt -ex detach -ex quit
Hello Marc Lehmann,
in that situation an strace is probably not that helpful.
Maybe you can provide a backtrace while the program is frozen.
You might use following in a different terminal:
(Basically attaches a debugger every 30 seconds, prints the backtrace and
detaches.)
while true; do echo
Control: notfixed 914616 20181001.4.a99aaec~ds6-2+b1
Hello Petter Reinholdtsen,
in another bug I got told that BTS is not handling
binNMU versions, therefore ending up with fixed+found
versions being the same (915364).
Maybe that is also the case here why the autoremoval stays.
Let's try to just
While looking into #915642 I found that this bug might just
be another case of bug #904808.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904808
Kind regards,
Bernhard
Dear Maintainer,
I just tried to reproduce and found it crash on service startup when
using the given /etc/apache2/sites-enabled/default.conf.
It looks like here the apache2 process wants to fork and calls the
fork_handlers. Unfortunately one of them belongs to an unloaded module.
Therefore we
Dear Maintainer,
I just tried to reproduce and collect some more information,
used a minimal buster amd64 qemu VM.
This issue seems to be more located in libt4k-common0.
It uses "rsvg_handle_get_desc(file_handle)" to retrieve
a char pointer to the description and tries to convert that
into an
Dear Maintainer,
tried to reproduce this issue and attached backtrace is created by
- using a minimal buster amd64 qemu VM
- installing a minimal plasma desktop
- logging into graphical session
- via ssh: running "prelink -mR /usr/bin/plasmashell"
- via ssh: running "DISPLAY=:0
Control: found -1 dovecot/1:2.3.4-2
Dear Maintainer,
I could reproduce this crash in a minimal stretch amd64 VM
with just dovecot-core installed and default configuration.
That command crashes also in a similar VM with current
buster/testing version.
Kind regards,
Bernhard
(gdb) bt
#0
Dear Maintainer,
this issue seems to be caused by wxGLCanvas not being yet ready
for wayland. At least in version current version in testing.
There are already bugs [1] and [2], the first one also for slic3r.
Both are forwarded to [3].
And all describing as workaround using something like
Dear Maintainer,
sorry, tried to mark it as fixed in the rebuild 1.1.9-1+b1.
But cont...@bugs.debian.org processed just version 1.1.9-1.
Kind regards,
Bernhard
Hello Martin Haase,
> ii libtorrent-rasterbar9 1.1.9-1
You probably have also to update your libtorrent-rasterbar9
package to version 1.1.9-1+b1.
libtorrent-rasterbar (1.1.9-1+b1) sid; urgency=low, binary-only=yes
* Binary-only non-maintainer upload for amd64; no source changes.
*
Hello Wojciech Muła,
I am just trying to reproduce the crash inside a minimal
buster amd64 qemu VM.
Unfortunately I was not able to reproduce and found most of
the listed versions are already outdated in testing.
Is there a reason, why your debian unstable installation
is not receiving updates?
Hello Dino,
I tried to have another look at this issue.
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (500, 'testing')
I found your report claims you are running testing, but
php7.3-intl 7.3.0~rc5-2 is currently just in unstable.
Are there more packages installed from
On Fri, 23 Nov 2018 00:26:28 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
wrote:
> but I cannot make a clue out of the
> armel "Not-For-Us" [1] for the build dependeny guile-2.2.
> What does that mean?
Hello Dimitry, hello Chris,
I just stepped over the answer to "Not-For-Us"
in [1] and [2] for the
Hello Dino,
if possible you might want to install the package php7.3-intl-dbgsym
matching to your php7.3-intl. That is in a separate repository [1].
Then that last frame should show up in the debugger with a
function name and line of source code.
Kind regards,
Bernhard
[1]
notfound 807179 2.10.09-1
found 807179 2.11.05-1
found 807179 2.11.06-1really2.11.05-1
found 807179 2.11.06-1
fixed 807179 2.11.08-1
tags 807179 + upstream fixed
forwarded 807179 https://bugzilla.nasm.us/show_bug.cgi?id=3392289
bye
Dear Maintainer,
tried to some more details out of that report.
Dear Maintainer,
tried to find out the actual location that the backtrace points to.
Unfortunately I could not make any clue out of the line
containing /usr/sbin/apache2(+0x29e450).
But at least, I think, the line containing mod_mpm_prefork.so(+0x4c08)
translates to function prefork_run in
Hello Francesco,
can you still observe the crash, or got it fixed by updates
in mid October? (Like mentioned in #910581)
If it is fixed that bug might be closed.
Kind regards,
Bernhard
Dear Maintainer,
I tried to find out where this given backtrace points to.
I think that following would be the location
where the invalid pointer was tried to be freed.
Attached file contains some details on how it was retrieved.
Upstream removed/replaced function teardown_ag_bmap in [1],
Dear Maintainer, hello Gonçalo,
I tried to have a look at this issue, and could
reproduce it in a jessie and buster amd64 qemu VM.
As far as I see xcircuit tries to draw all files into one big pixmap.
(gdb) list filelist.c:480
477 pixheight = flfiles * FILECHARHEIGHT + 25;
Dear Maintainer, hello Klaus Ethgen,
I just tried to get some more information out of this bug.
I could not reproduce it with a stretch testing or unstable
as of date 2016-07-20 inside a i386 qemu VM.
As far as I see is the problematic function in WDM:
(gdb) list ManageSession#
Hello Michael Ott,
I just tried to reproduce this crash.
You were really using the gtk+3.0 packages from experimental at that time?
> Aug 14 13:49:22 king-coder13 kernel: [16027.866859] gnucash[22985]:
> segfault at f0 ip 7f76d6ba7952 sp 7ffcb1fd9198
> error 4 in
Dear Maintainer, hello Kinky Nekoboi,
just tried to reproduce this issue and there is really a crash.
In a minimal buster amd64 qemu VM,
with installed cantor and cantor-backend-sage packages.
Then follow these steps:
- start cantor
- select Sage backend
- enter in the field below the "Session
Hello Maximilian,
Am 23.11.2018 um 16:58 schrieb Maximilian Stein:
> Maybe the connection object ptr c
> was free'd or NULL?
Yes, I think c was NULL at the time of the crash.
Kind regards,
Bernhard
Dear Maintainer, hello Felipe Sateler,
that output would match that output in bug #913859 from
the unmodified package iwd 0.10-1.
In your backtrace the paramter method_call=0x0.
Therefore I would suspect it belongs to line 366, where method_call
gets unconditionally dereferenced.
(gdb) list
Dear Maintainer, hello Laura Arjona Reina,
I just tried to have a look at this crash.
Unfortunately given information point to no exact location.
In that case the line from dmesg would already be helpful:
[ 609.690904] kamoso[28487]: segfault at 0 ip 55bc679e7fd5 sp
7ffc474fd950
Package: kamoso
Version: 18.04.0-3
Severity: normal
Dear Maintainer,
on a minimal installation of kamosos following is written to the console:
benutzer@debian:~$ kamoso
No device found
QQmlApplicationEngine failed to load component
qrc:/qml/Main.qml:7 module "org.kde.kirigami" is
Am 22.11.2018 um 23:15 schrieb Dmitry Smirnov:
> On Thursday, 22 November 2018 9:50:02 AM AEDT Chris Lamb wrote:
>> grep-excuses claims:
>>
>> missing build on armel: gnucash, python-gnucash (from 1:2.6.19-1)
>> missing build on mips: gnucash, python-gnucash (from 1:2.6.19-1)
>>
>> Is
Hello Maximilian Stein,
maybe the package maintainer can get some information out of that
kernel line, but maybe you can install a core dump collector
like e.g. systemd-coredump.
When the next crash happens you can examine the core by:
coredumpctl list
coredumpctl gdb
Even better if debug
Hello,
On Tue, 30 Oct 2018 18:47:41 -0700 Don Armstrong wrote:
> On Mon, 29 Oct 2018, Peter Palfrader wrote:
> > debbugs tries to wrap messages such as
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912215#10
> > in its web interface.
> >
> > This makes the message entirely unreadable.
Package: gdb
Version: 8.1-4+b1
Severity: normal
Tags: upstream
Dear Maintainer,
while trying to debug #914300 I wanted to use the record feature of gdb.
Unfortunately that stopped on me with an assertion failed.
See at the bottom of this mail for an example run.
I was able to find the issue
Dear Maintainer,
I tried to have a look at this issue.
This is the stack with debug symbols:
(gdb) bt
#0 QByteArray::QByteArray (a=..., this=0x7fffd4e8) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbytearray.h:492
#1 QList::takeLast (this=0x7fffd4e0) at
Dear Maintainer,
just tried to reconstruct a better readable stack with
function names, that would probably look like this:
0x...e27 | 0x779c9e27: 0x779c9e22 :
callq 0x779bf150
0x...4a0 | 0x556274a0: 0x5562749b : callq
0x55621790
0x...8d8 |
Dear Maintainer,
this crash on key generation when running adb for the first time seems
now fixed in current buster/testing, version 1:8.1.0+r23-3.
The patches adb_libssl_*.diff seem to have been dropped.
This issue is still visible in current stretch version 1:7.0.0+r33-1.
The duplicate
Dear Maintainer,
just tried to reproduce the crash and succeeded:
The backtrace looks like this with debug symbols installed:
(gdb) bt
#0 fm_file_info_get_path (fi=0x0) at base/fm-file-info.c:1028
#1 0x7f4397419b7b in on_file_info_job_finished (job=0x558b83a39960,
folder=0x558b83a2c230)
Hello Nils Jarle Haugen,
I just tried to reproduce the issue.
Unfortunately without having deeper knowledge about
simulide and not knowing which elements you are using,
I did not receive a crash.
Running with valgrind led just to an unintialized variable
m_deltaV that might be more related to
Dear Maintainer,
this looks like a matching upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=18035
Kind regards,
Bernhard
Hello,
just for completeness, the backtrace above points to these functions:
backtrace
#0 0x7efd7c3dbfc0 in /lib/x86_64-linux-gnu/libc.so.6|
#1 0x556a4c101217 in /usr/sbin/connmand |
Dear Maintainer,
while having a proper core dump would be desirable,
I tried to get some more information out this actual crash.
I assume the crash happens in the following functions,
while there might be a problem with a variable argument list.
Aborting (signal 11) [/usr/libexec/iwd]
Dear Maintainer,
I could reproduce this issue with a stretch amd64 VM,
forwarding an USB webcam into it.
This seems to be upstream bug [1] and is fixed in upstream git in [2].
A local build cheese package containing the commit [2] does
not crash that way.
Upstream version 3.26 and above should
Dear Maintainer, hello Luc,
I just tried to reproduce this issue.
I started with a minimal buster amd64 qemu VM.
Then following steps led me to that or at least a similar error:
- installed minimal desktop environment, virtualbox and rdesktop
- started virtualbox and created a test VM
- activated
Dear Maintainer,
I just tried to reproduce the issue.
This segfault in GL_shadow happens here:
Thread 1 "gl_shadow" received signal SIGSEGV, Segmentation fault.
0x79f6 in LoadTexture (tex_name=0x7fffe120 "tex.png") at
src/benchmarks/GL_shadow/object.c:196
196
Now really with the mentioned file.
# snapshot
deb [check-valid-until=no]
http://192.168.178.25:/debian-10-buster-snapshot.debian.org/ buster main
deb-src [check-valid-until=no]
http://192.168.178.25:/debian-10-buster-snapshot.debian.org/ buster main
deb [check-valid-until=no]
Dear Maintainer, hello Anthony DeRobertis,
I just tried to reproduce this issue in a buster amd64
qemu VM with a uptodate buster at 2018-09-27.
On Wed, 26 Sep 2018 13:42:01 -0400 Anthony DeRobertis
wrote:
> Package: clementine
> Version: 1.3.1+git565-gd20c2244a+dfsg-1
> Severity: normal
>
>
Dear Maintainer,
just tried to reproduce this issue.
I suspected this is caused by some changes in the linux kernel,
as a up to date buster amd64 userland inside a qemu VM with following
kernel shows no problem:
Linux debian 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64
Hello Jade McCormick,
I just tried to reproduce this issue too.
I started inside an testing amd64 qemu VM and applied
the instructions from [1] to enable selinux,
and set it by "setenforce 1" from permissive mode to
enforcing mode.
Then I did not find a "yarn" command related to nodejs,
Hello all,
tried to reproduce and still receive the crash triggered by either SVG
import or the manual action in the python console.
The parameter --enable-system-expat seems to just defines HAVE_SYSTEM_EXPAT,
which seems not used later.
Attached patch makes coin3 not to build the subdirectory
Hello Matt Zagrabelny,
this might be the the same issue as already discussed in #912087.
Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
Dear Maintainer,
I just tried to have a look at this crash.
The following is the part of valgrind output relevant for this bug (I think):
==23786== Invalid read of size 8
==23786==at 0x2338D2: load (atomic_base.h:396)
==23786==by 0x2338D2: load (qatomic_cxx11.h:227)
==23786==by
Am 28.10.2018 um 19:23 schrieb Colin Watson:
>
> Thanks for the investigation. (Note also that the OpenSSH version in
> question is the one that switched from OpenSSL 1.0 to 1.1, which was a
> big change.)
>
> There were some significant changes in this area in OpenSSL 1.1.1.
> Would it be
Dear Maintainer,
just some more information, because I think I see this
difference in my qemu buster amd64 VM too.
Before I could ssh into that machine just after some seconds.
Now it takes some time until that line "random: crng init done"
appears in dmesg.
With logging in in the qemu window
Package: buildd.debian.org
Severity: normal
Hello,
when opening [1] the drop-down list contains a "jessie-security",
but misses a "stretch-security" - should that be available?
[1] https://buildd.debian.org/status/package.php
Kind regards,
Bernhard
901 - 1000 of 1271 matches
Mail list logo
