On Fri, 2016-08-05 at 17:15 +0200, Johannes Schauer wrote:
> Control: tag -1 + patch
>
> On Fri, 05 Aug 2016 13:55:14 +0100 Brian Drummond <bri...@shapes.demo
> n.co.uk> wrote:
> >
> > *** Reporter, please consider answering these questions, where
> >
Package: debootstrap
Version: 1.0.81
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
0) Okay, this will be embarrassing...
1) Occasional need to work on i386 software on an x86-64 machine.
2)
By running the following script I have found who owns the errant pool
process, and it is gvfsd-dav.
Script (crude but it works!):
#!/bin/bash
while true; do
pstree -p | grep pool -B 5 pool.log
sleep 0.5
done
Backtrace from the relevant thread in gvfsd-dav...
I hope this is helpful. If any further info is required I will endeavour
to provide it, given adequate instructions. (In particular, how would I
make gdb display the optimized out bits?
- Brian
On Tue, 2014-11-18 at 15:21 +, Simon McVittie wrote:
Control: reassign 766732 gvfs-backends
On 18/11/14 14:49, Brian Drummond wrote:
Backtrace from the relevant thread in gvfsd-dav...
Reassigning to the package that owns gvfsd-dav.
OK.
ua = 0x0
ub
On Tue, 2014-11-18 at 15:21 +, Simon McVittie wrote:
Control: reassign 766732 gvfs-backends
So there are probably two bugs here:
* whatever software you are using to serve your music over DAV (what is
it?) is encoding paths incorrectly; and
* gvfs isn't coping gracefully with that.
On Wed, 2014-10-29 at 20:56 +0100, intrigeri wrote:
Control: severity -1 important
Hi,
Brian Drummond wrote (25 Oct 2014 12:32:42 GMT) :
The non serious data loss may be a misnomer. It is my assessment
because, if one assumes that a copy finished correctly when it actually
terminated
On Mon, 2014-10-27 at 14:12 +, Simon McVittie wrote:
On 26/10/14 15:18, Brian Drummond wrote:
BFD:
/usr/lib/debug/.build-id/f4/bb3ff29b5a72f4c60cc4f76854a1bb47a3bc78.debug:
unable to initialize decompress status for section .zdebug_aranges
That's a bug in either libglib2.0-0-dbg
On Mon, 2014-10-27 at 14:10 +, Simon McVittie wrote:
On 26/10/14 14:59, Brian Drummond wrote:
gdb nautilus allows me to reproduce the segfault, but doesn't return
control to the debugger. So the pool (is it a process? I can't see it
in ps ax) containing the error must be elsewhere
On Mon, 2014-10-27 at 14:10 +, Simon McVittie wrote:
On 26/10/14 14:59, Brian Drummond wrote:
gdb nautilus allows me to reproduce the segfault, but doesn't return
control to the debugger. So the pool (is it a process? I can't see it
in ps ax) containing the error must be elsewhere
On Sun, 2014-10-26 at 12:00 +0100, Aurelien Jarno wrote:
control: tag -1 + moreinfo
dmesg on the Client machine reports:
[ 699.677988] pool[1873]: segfault at 0 ip 7f5d88066a3a sp
7f5d7d974cb8 error 4 in libc-2.19.so[7f5d87fe5000+19f000]
The crash happens because a NULL pointer
gdb nautilus allows me to reproduce the segfault, but doesn't return
control to the debugger. So the pool (is it a process? I can't see it
in ps ax) containing the error must be elsewhere in the system.
Any suggestions how to move forward?
- Brian
--
To UNSUBSCRIBE, email to
Backtrace revealed missing debug info in glib, viz...
Thread 5 (Thread 0x7fffe5d4e700 (LWP 3843)):
#0 0x73c760ed in poll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x74c52ee4 in ?? ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info
The non serious data loss may be a misnomer. It is my assessment
because, if one assumes that a copy finished correctly when it actually
terminated, the client machine is left with an incomplete data set.
Non-serious because the files are still there on the server, and it is
possible (tedious!)
Quoting from upstream discussion :
ghdl is correct here.
If i_a is converted to unsigned, you should simply declare i_a as a
natural signal.
Note that there is no uninitialised values in VHDL, that's almost
doesn't exist.
i_s
This issue is now fixed in upstream ghdl, as of commit 55ee46 :
https://sourceforge.net/p/ghdl-updates/code/ci/55ee4649440bf1c336a26aaf79edaea6d008be95/
Once that commit or newer is incorporated into Debian ghdl, this bug can
be closed.
- Brian
--
To UNSUBSCRIBE, email to
This issue is now fixed in upstream ghdl, as of commit 55ee46 :
https://sourceforge.net/p/ghdl-updates/code/ci/55ee4649440bf1c336a26aaf79edaea6d008be95/
Once that commit or newer is incorporated into Debian ghdl, this bug can
be closed.
- Brian
--
To UNSUBSCRIBE, email to
This bug appears to be a duplicate of upstream bug
https://gna.org/bugs/index.php?16128
The patch has been applied to the development snapshot at
https://sourceforge.net/projects/ghdl-updates/
currently known as 0.31dev, built with gcc4.8.2.
- Brian
--
To UNSUBSCRIBE, email to
The patch has been applied to the upstream development snapshot at
https://sourceforge.net/projects/ghdl-updates/
currently known as 0.31dev, built with gcc4.8.2.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
This bug appears to be a duplicate of upstream bug
https://gna.org/bugs/index.php?15702
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I have reported this bug upstream to ghdl_updates.
https://sourceforge.net/p/ghdl-updates/tickets/2/
- Brian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I have reported this bug upstream to ghdl_updates.
https://sourceforge.net/p/ghdl-updates/tickets/1/
- Brian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I have reported this bug upstream to ghdl_updates.
https://sourceforge.net/p/ghdl-updates/tickets/3/
- Brian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
As of today, and pending some further testing, a development version of
upstream GHDL builds against gcc4.8.2+gnat4.8.2. This includes the OSVVM
patches.
Message inc. instructions and patch has been posted to
https://mail.gna.org/public/ghdl-discuss/2013-11/index.html
but hasn't appeared there
Package: libgtkada-doc
Version: 2.24.1-7
Severity: serious
Justification: fails to build from source
Source package libgtkada is also affected.
My first experience of GTKADa programming is to compile the TestGTK example.
Unpack the archive provided at
My apologies if I selected the wrong severity level; this is my first
time submitting a report to Debian.
For the record I also tried building libgtkada from source using my own
GCC 4.7.0 build, and it failed in the same way as the example - having
built the tools, it tried to build the TestGTK
26 matches
Mail list logo
