Bug#542276: liferea blocks while running a feed update command
On Wed, Mar 28, 2012 at 2:00 PM, Moray Allan mo...@sermisy.org wrote: As of version 1.8.3, liferea is much less prone to locking up again. Please check whether you still see lockups with the script that caused them before, perhaps we can close this bug now. I don't use liferea any more, so I can't check this - sorry. -- Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631740: O: dejagnu -- framework for running test suites on software tools
Package: wnpp Severity: normal I intend to orphan the dejagnu package. The package description is: DejaGnu is a framework for testing other programs. Its purpose is to provide a single front end for all tests. . DejaGnu provides a layer of abstraction which allows you to write tests that are portable to any host or target where a program must be tested. All tests have the same output format. . DejaGnu is written in `expect', which in turn uses Tcl--Tool command language. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631741: O: amd64-libs
Package: wnpp Severity: normal I am orphaning amd64-libs. This package is less used now, and very stale. It's possible that it should be removed instead of adopted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631742: O: gdb-doc -- The GNU Debugger Documentation
Package: wnpp Severity: normal I intend to orphan the gdb-doc package. I suggest that the same person adopt this as adopts gdb. Instructions and tools for creating the source package are in debian/README.source (in the GDB source package, not this one). The package description is: GDB is a source-level debugger, capable of breaking programs at any specific line, displaying variable values, and determining where errors occurred. Currently, it works for C, C++, Fortran, Modula 2 and Java programs. A must-have for any serious programmer. . This package contains the GDB and GDB Internals manuals. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631743: O: gdb -- The GNU Debugger
Package: wnpp Severity: normal I intend to orphan the gdb package. I will continue to intermittently follow upstream development, and upstream is pretty active; not a lot of Debian-local work is needed. There's a couple of local patches (bad Dan!) which could be submitted. Or possibly dropped with the latest upstream. Please, if you adopt this, also take gdb-doc; a script in the GDB source package produces DFSG sanitized source packages for both packages from the FSF release tarball. The package description is: GDB is a source-level debugger, capable of breaking programs at any specific line, displaying variable values, and determining where errors occurred. Currently, it works for C, C++, Fortran, Modula 2 and Java programs. A must-have for any serious programmer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611004: gdb: default debug-file-directory is wrong
On Mon, Jan 24, 2011 at 05:41:34PM +, Diego Nieto Cid wrote: Debug packages install symbols under /usr/lib/debug but gdb's default symbol directory is located in /usr/local. This is fine on x86_64-linux. Is it specific to the Hurd, or specific to the 7.2-1+b1 rebuild? $ gdb --batch -ex show debug-file-directory The directory where separate debug symbols are searched for is /usr/local/lib/debug. drow@caradoc:~% gdb --batch -ex show debug-file-directory The directory where separate debug symbols are searched for is /usr/lib/debug. drow@caradoc:~% gdb --version GNU gdb (GDB) 7.2-debian -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#346409: gdb: PIE support still not available in squeeze
On Sun, Dec 12, 2010 at 06:57:43PM -0500, root wrote: Package: gdb Version: 7.0.1-2+b1 Severity: normal GDB isn't compiled with PIE support in squeeze, but Apache is compiled with PIE. This makes debugging apache impossible. Apache's justification is that GDB does support PIE, see: http://packages.debian.org/changelogs/pool/main/a/apache2/apache2_2.2.16-4/changelog apache2 (2.2.15-6) unstable; urgency=low [...] * Build as PIE, since gdb in squeeze now supports it. [...] -- Stefan Fritsch s...@debian.org Sat, 24 Jul 2010 22:18:43 +0200 This inconsistency should either be a bug against apache, or a bug against gdb. I've chosen you, because the way forward is fixing it :) PIE support is in GDB 7.1 and GDB 7.2; 7.2 is in sid. It seems to be too late to get an update into squeeze. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605060: dnsmasq preserves cache across interface changes
Package: dnsmasq Version: 2.55-2 Severity: normal I am using resolvconf and dnsmasq to handle internal DNS servers for our VPN. When openconnect creates the tun0 interface, it adds the internal nameservers using resolvconf. resolvconf modifies dnsmasq's configuration file, and dnsmasq rereads it. But my IRC client fails to reconnect to the internal server at this point, because the negative lookup has been cached - the IRC server's hostname is only valid inside the VPN. I don't see any option to make dnsmasq clear its cache when the VPN comes up other than restarting dnsmasq entirely. It'd be nice if I could make this happen automatically when dnsmasq rereads the resolv.conf file. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dnsmasq depends on: ii adduser 3.112+nmu1 add and remove users and groups ii dnsmasq-base 2.55-2 A small caching DNS proxy and DHCP ii netbase 4.43 Basic TCP/IP networking system dnsmasq recommends no packages. Versions of packages dnsmasq suggests: ii resolvconf1.46 name server information handler -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596953: gdb: Please add preliminary support for armhf
tags 596953 + pending thanks On Wed, Sep 15, 2010 at 01:37:44PM +0300, Konstantinos Margaritis wrote: Package: gdb Version: 7.2-1 Severity: wishlist Please add preliminary support for armhf port (now on debian-ports.org) The attached patch is enough to fix compilation. Thanks, will be in the next upload. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594740: gdb: wrong eval of strlen function when program is linked to eglibc
On Sat, Aug 28, 2010 at 11:55:01PM +0200, Alain Greppin wrote: Package: gdb Version: 6.8-3 Severity: important sample output of gdb: Breakpoint 2, var_subst ( s=0x7fffd73f /home/agreppin/src/tools/amake/amake, target=0x0, req1=0x0) at var.c:154 154 *a = '\0'; (gdb) p n $1 = 36 (gdb) p strlen(s) $2 = 1976916864 This bug is specific to STT_GNU_IFUNC. What GDB is printing is actually the return value of the indirect function, i.e. the address of the actual strlen. I believe some patches were posted for this upstream, but never in an acceptable state. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591889: gdb usage message misleading
On Fri, Aug 06, 2010 at 10:18:01AM +0200, Michal Suchanek wrote: The usage message suggests that when attaching to a process an executable image should be specified. This is useless and actually harmful, gdb can only load symbols if an executable is *not* specified. The usage message is correct. GDB can be run with or without an executable file when attaching. IPX7A-ION:/home/hramrach# gdb /usr/lib/debug/usr/bin/Xorg 2921 That's the wrong file. Use the program that was actually run; the files in /usr/lib/debug are special, and GDB will load them automatically. If you use gdb /usr/bin/Xorg does it work better? Attaching to process 2921 Reading symbols from /usr/bin/Xorg...Reading symbols from /usr/lib/debug/usr/bin/Xorg...done. As you can see here, GDB loads /usr/bin/Xorg first when told to find the file. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581707: gdb: refuses to print errno on amd64
On Sat, May 15, 2010 at 05:18:22AM +, brian m. carlson wrote: gdb refuses to print errno on amd64, regardless of whether the program in question is 32-bit or 64-bit. libc6-dbg is installed. Does linking with -lpthread help? It will, if I remember the problem correctly. This may be fixed upstream; I think Jan K. posted a patch for it at some point. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579021: gdb fails only when not linked to libpthreads
On Tue, May 04, 2010 at 08:56:09PM +1000, Craig Small wrote: On Mon, May 03, 2010 at 08:33:10AM -0400, Daniel Jacobowitz wrote: Does libdbi load libpthread dynamically? Indirectly it does. libdbi uses database-specific backends. So, for example, libdbd-mysql.so is dlopen()ed by libdbi and that mysql specific library is dynamically linked to libpthread. OK, thanks. That's going to be the issue then; I'm surprised to see it resurface, but GDB has historically had trouble in this situation. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579021: gdb fails only when not linked to libpthreads
On Mon, Apr 26, 2010 at 11:19:26AM +1000, Craig Small wrote: Hello, I had a closer look at programs using libdbi. Most of them seem to link to libpthread. Programs such as rrdtool and syslog-ng use it. So I changed my command line to build my simple test program I sent in my initial report from: gcc -o test -ldbi -ggdb test.c to: gcc -o test -ldbi -lpthread -ggdb test.c Does libdbi load libpthread dynamically? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576720: [ia64] gdb FTBFS and freezes / reboots the machine
On Tue, Apr 06, 2010 at 08:44:13PM +0200, Andreas Barth wrote: Package: gdb Version: 7.1-1 Severity: serious Hi, on trying to build gdb, the buildd freezes (mundy) or gets rebooted (alkman). This package was tried 3 times on mundy and 1 time on alkman. The log files ends with (please note that this may not be the last real line - the machine gets rebooted): Do you think this is a bug in GDB? It sounds like the kernel is broken. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570049: gdb/breakpoint.c:5989: internal-error: expand_line_sal_maybe: Assertion `found' failed.
On Mon, Feb 15, 2010 at 10:07:31PM -0600, Raphael Geissert wrote: Package: gdb Version: 7.0.1-2 Hi, Right after running gdb, when trying to add a breakpoint it displays the following error message: gdb/breakpoint.c:5989: internal-error: expand_line_sal_maybe: Assertion `found' failed. You can find the core dump of gdb itself at merulo.debian.org:~geissert/gdb.core (yes, this is on ia64) Do you still have instructions to reproduce this? I wonder if it's the same as the patch Ulrich posted today: http://sourceware.org/ml/gdb-patches/2010-03/msg00731.html -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569551: internal-error: get_frame_pc: Assertion `frame-next != NULL' failed.
On Fri, Feb 12, 2010 at 11:30:01AM +0100, Sascha Silbe wrote: Package: gdb Version: 7.0-1 Severity: normal While stepping through dl_open_worker() (eglibc-2.10.2, elf/dl-open.c) in order to debug a memory alignment issue on armel, I encountered the following error: /build/buildd-gdb_7.0-1-armel-GziZIf/gdb-7.0/gdb/frame.c:1742: internal-error: get_frame_pc: Assertion `frame-next != NULL' failed. Thanks, I can reproduce this on x86 too. It's confused by stepping over _dl_debug_state. I'll file this upstream. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569551: internal-error: get_frame_pc: Assertion `frame-next != NULL' failed.
Actually, even better: this is fixed in GDB 7.1, uploading shortly. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570233: [patches] please add timepps.h
On Wed, Feb 24, 2010 at 05:01:33PM +0300, Alexander Gordeev wrote: Hi! Can you please add timepps.h to eglibc? This header provides a standardized PPSAPI interface (RFC-2783) on top of custom Linux recently merged PPS implementation so libc should be the right place for this file. It can be then directly used by ntp and chrony time synchronization daemons after recompilation. Their respective configure scripts should find and use it automatically. I don't think glibc/eglibc is the right place for this file. GLIBC is principally an implementation of the library requirements of the C and POSIX / Single Unix standards; this is not part of those standards. Why can't it be a separate package? Debian, for instance, could easily have the ntp daemon build-depend on PPS support. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571132: split out gdbserver package doesn't save any space
On Tue, Feb 23, 2010 at 07:27:41PM +0100, Matthias Klose wrote: gdbserver was split out, but has it's own copy of the doc directory. Now having both packages installed uses more space than the former gdb package alone. Please consider symlinking the doc directory for gdbserver, gdb64 and libgdb-dev. gdbserver does not depend on gdb. gdb really shouldn't depend on gdbserver either; it only does for transition. gdbserver also has fewer docs installed. The changelog.gz installed in both packages is useless. It's the top-level changelog. How about I drop that, and if re-adding some changelog leave it out of the gdbserver package? The README in gdbserver is also useless, I do not know how it got there. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561924: gdb: FTBFS on kfreebsd-amd64 with 8.x kernel headers
On Wed, Feb 03, 2010 at 09:20:23AM +0100, Petr Salinger wrote: They have been removed somehere during 8.0 development, it started with 80, the 8.0 release have 800107. I did'n know the exact version, so please change the check to #if (__FreeBSD_version 800075) (__FreeBSD_kernel_version 800075) So the issue is checking __FreeBSD_version and not __FreeBSD_kernel_version? Does normal FreeBSD define both? Please, do you have some hints how to teach gdb, that on GNU/kFreeBSD is thread handling the same as in linuxthreads (pre-NPTL) implementation (#550361). Sorry, I don't know how to do that. You'd need to bring in linux-thread-db.c and bits of linux-nat.c somehow. I doubt it's really the same at the level GDB sees it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561924: gdb: FTBFS on kfreebsd-amd64 with 8.x kernel headers
On Mon, Dec 21, 2009 at 01:12:35PM +0100, Petr Salinger wrote:
Hi,
the current version fails to build on GNU/kFreeBSD with 8.x kernel
headers.
The FreeBSD 8.0 kernel does not have segment registers in pcb anymore.
To solve current FTBFS please just use patch bellow.
Sorry for the inconvenience.
In GDB 7.0.1, where this bug was just re-reported, GDB says:
#if (__FreeBSD_version 800075)
regcache_raw_supply (regcache, AMD64_DS_REGNUM, pcb-pcb_ds);
regcache_raw_supply (regcache, AMD64_ES_REGNUM, pcb-pcb_es);
regcache_raw_supply (regcache, AMD64_FS_REGNUM, pcb-pcb_fs);
regcache_raw_supply (regcache, AMD64_GS_REGNUM, pcb-pcb_gs);
#endif
Is that the wrong version? The patch was:
2008-10-16 Steven G. Kargl ka...@gcc.gnu.org (tiny patch)
* amd64fbsd-nat.c (amd64fbsd_supply_pcb): Conditionally compile in
support for pcb-pcb_{fs,ds,es,gs} on FreeBSD older than 8.0.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566872: gdb: /bin/true fails with Program received signal SIGTRAP, Trace/breakpoint trap.
On Mon, Jan 25, 2010 at 07:57:53PM +0200, Timo Juhani Lindfors wrote: (gdb) r Starting program: /bin/true Program received signal SIGTRAP, Trace/breakpoint trap. 0x77df61a7 in access () from /lib64/ld-linux-x86-64.so.2 Works for me, kernel 2.6.30-1-amd64. My best guess is that this is a bug in 2.6.30-2-amd64. When did this appear? Is it still there with the current testing/unstable 2.6.32? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566872: gdb: /bin/true fails with Program received signal SIGTRAP, Trace/breakpoint trap.
On Wed, Jan 27, 2010 at 07:01:04PM +0200, Timo Juhani Lindfors wrote: Daniel Jacobowitz d...@false.org writes: Works for me, kernel 2.6.30-1-amd64. My best guess is that this is a bug in 2.6.30-2-amd64. When did this appear? Is it still there with the current testing/unstable 2.6.32? I was running 2.6.30 under xen. In that case this is almost certainly a problem with Xen or the xen kernel. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560786: gdb: Please make the python dependency optional
On Sun, Jan 10, 2010 at 07:06:05PM +1030, Ron wrote: You've already said you don't have the space for GDB+Python. So file a wishlist bug to split gdbserver out to its own package, and I'll do that for you happily. I haven't seen anyone object to that idea yet, so we seem to have a rough consensus that would be a good plan independently of any other issues here, yeah. I'm working on this. I'll see what the build time costs of a gdb-minimal are at the same time (it's still pretty large). I still find your arguments unconvincing, but I may as well measure the cost of the compromise. Then you don't need to put the detached debug info files on your target either. If you are putting them on your target, well, that explains why you can't fit GDB! If I didn't have all that data which was actually useful to me, then I'd have plenty of space for whole subsystems I will never need ;? That's probably not the most productive argument we could entertain :) You can make strawman arguments at me as long as you want to. I'm quite familiar with resource-constrained systems - I work in the embedded industry. There are several ways to avoid keeping debug info files on your target system, and still recover traces or conduct debug sessions. At work, we advise all our customers to use stripped target filesystems. Ok. If it's still needed, that's mostly what I was wondering. Surely we can also do the takes almost no additional buildd time trick with --without-python though, no? It looked like only a couple of files would get touched by that at all. Did I miss something there? No, you have to reconfigure GDB from scratch to disable it. It's probably possible to change this, but it'd be fragile; I don't think it's a good idea. The range of systems is however larger than what gdbserver is suitable for, by its own description. Yes, it's a useful tool, for some problems, but it's not a magic bullet, without any cost of its own. FYI, if you have any way to run GDB on your target, you have a way to run gdbserver. For instance, you can multiplex it over a single serial console. I agree there's complex setup involved. I have a vague sense of what you are remembering, but common sense should basically sum it up. Is there no way upstream would accept doing this as a runtime plugin, that only gets used if it's there? I have no idea. It would be a big pain to implement. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#346409: ping
On Wed, Jan 06, 2010 at 10:27:15AM -0800, Kees Cook wrote: It's been another year; would you reconsider carrying the PIE patches in Debian gdb again? AFAICT, RedHat, SUSE, and Ubuntu all use the patches. I've ported what I could from the RedHat patches[1] into Ubuntu[2] and it's mostly working (it's not perfect, of course). Jan is currently merging PIE support upstream, as in, he reposted some of the patches this morning. I have my fingers crossed for GDB 7.1, which I will package for Debian when it is released around mid-February. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562766: gdb does not support 'break exception'
On Mon, Dec 28, 2009 at 03:09:10PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reassign 562766 gdb Bug #562766 [gnat-4.4] gdb does not support 'break exception' Bug reassigned from package 'gnat-4.4' to 'gdb'. Bug No longer marked as found in versions gnat-4.4/4.4.2-4. I'm confused by this reassignment. Does catch throw work, as Ludovic wrote in the bug report? If so, is this a bug in the GNAT documentation rather than GDB? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490769: iceweasel: input field boxes vanish randomly
On Wed, Dec 23, 2009 at 04:11:32PM +0100, Mike Hommey wrote: Isn't that just a gtk theme (both color and style) issue ? This may have gone away for me after I changed GTK themes. I had an old theme setting (this is a long-upgraded system) and it was having a lot of trouble with e.g. the volume buttons showing gray-on-gray. I had to pick a new theme to get things to display properly; I suspect some sort of incompatible change in GTK (~ 1-2 yrs ago). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490769: iceweasel: input field boxes vanish randomly
On Tue, Dec 22, 2009 at 02:05:12PM +0100, Mike Hommey wrote: I have never experienced these :-/ Did it continue with more recent version ? (especially 3.0 in lenny currently and/or 3.5.x in squeeze) It went on for a long while; I think it still happened in lenny. But it doesn't happen with the latest packages in sid or from Mozilla. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#366129: Debian Firefox/Iceweasel bug triage - bug #366129
found 366129 3.5.5-1 thanks On Mon, Dec 21, 2009 at 01:23:18PM +0100, Mike Hommey wrote: Version: 3.0.1-1 On Fri, Oct 12, 2007 at 09:51:42AM -0400, Daniel Jacobowitz wrote: found 366129 2.0.0.7-2 thanks Behavior has not changed since the last time I updated the report, in July 2006. I'm pretty confident this was fixed before the version currently in Lenny. The version in squeeze or unstable may have a different behaviour, though, as we reverted to the upstream behaviour, in which case you need both -P and --no-remote. Using either 3.5.5-1 or unmodified upstream firefox 3.5.5, I get exactly the same behavior as I did in the original report in 2006; for instance there is no way to open a new window in an alternate profile. I don't know about the version in lenny. To be clear, I'm not sure which of the other behaviors are bugs, but I'm sure that the second -P hacking -a other or the -P hacking -a other -no-remote case is a bug; there is no way to click on a shortcut and have it open a second window in a second copy of firefox. I'm fine with wontfix now; I was using the second isolated profile so I didn't have to mess around with flash in my actual web browser. But both nspluginwrapper and the Adobe plugin are in such poor shape now that I use Chrome for flash instead. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560786: gdb: Please make the python dependency optional
Picking some arbitrary messages in this thread to respond to. On Sun, Dec 20, 2009 at 03:30:20AM +1030, Ron wrote: I do appreciate, and share, your concern for not bloating the archive needlessly, but my concern is balancing that against the needs of small Debian systems, where the extra deps this drags in are of themselves a quite substantial and needless extra bloat. They are considerably larger than gdb is itself, and needing to put extra flash on a board, just to install python, which the board itself will never use, hits a much harder limit than an extra 4MB package in the archive would. There is not just one GDB package in the archive. Many platforms have two, and the build logic is tricky enough to produce all the variants already... I really don't see the justification for another binary. You've already said you don't have the space for GDB+Python. So file a wishlist bug to split gdbserver out to its own package, and I'll do that for you happily. Then you don't need to put the detached debug info files on your target either. If you are putting them on your target, well, that explains why you can't fit GDB! Ideally this should really be some sort of runtime dependency, otherwise what happens when people also add perl, lua, ruby, etc. etc. bindings to do the same thing as this python dep does? It's not going to happen. We (the GDB developers) spent a long time picking one language under the firm plan that we wanted exactly one. We don't want to fragment available GDB scripts by language; that defeats the point of making it scriptable. - libgdb-dev appears to be unused, and itself recommends that it never should be. That's the size of 2 gdb .debs itself, so if you really want to remain archive neutral, we could trade it for a gdb-minimal package, and wind up using less archive space in the deal. It exists for the benefit of the Free Pascal IDE. Also, it takes almost no additional build daemon time. I've cc'd -devel, as others may have even better or simpler solutions, but I'd appreciate your guidance on the best way to move forward with solving this from here. I just don't see why a solution to this is necessary in the archive. Nothing you've said has changed that. Either we install gdbserver, or else you can just throw a GDB binary around from system to system. I don't think the range of systems which don't need and can't fit Python, but can fit a GDB executable (and its substantial RAM requirements, and the huge debuginfo files it needs to be useful) is very large. Remote debugging is easy, and this is exactly what it's for. On Sun, Dec 20, 2009 at 11:45:00AM +0100, Eduard Bloch wrote: And people who don't care shouldn't be forced against their will. I am not holding a gun to your head and making you install GDB. I don't think this is an appropriate description. Debian isn't in the business of providing every possible combination of configure options; there are some other distros with that philosophy. Didn't there used to be a statement in policy or the developer's reference that optional dependencies should generally be enabled, which had some special words about X11? I can't find it any more. Why don't we provide a gdb-tiny package, in the same fashion as vim-tiny? Or is the python support that much hardcoded into gdb source now that it can never separated? It can be separated. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560786: gdb: Please make the python dependency optional
tags 560786 + wontfix thanks On Sat, Dec 12, 2009 at 08:22:12PM +1030, Ron wrote: Not all machines that it's useful to be able to run gdb on also need or want python installed. Can we please make this extra dependency optional? No, we can't. You build GDB either with or without linking to Python. I don't see a reason to split the GDB package into two and double its archive size for this. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550710: gdb: record error in memset: Process record doesn't support instruction 0xf6e
On Mon, Nov 23, 2009 at 11:38:46PM +0100, Bill Allombert wrote: Well, cannot gdb simply stop recording just before such unsupported instruction instead of sending a SIGTRAP ? I don't think it should. Would you like to come back to a long record session and find your recording shut off an hour ago? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555890: gdb: Please consider enabling Fortran90 support by merging archer-jankratochvil-vla
On Thu, Nov 12, 2009 at 11:51:17AM +0100, Florian wrote: The archer-jankratochvil-vla branch enables Fortran90/95 support (allocatable/assumed-shape arrays,...), see e.g. http://sourceware.org/bugzilla/show_bug.cgi?id=9395 I currently only plan to include this after Jan gets it merged into mainline. I expect it will change quite a bit on the way. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551362: BitchX: Long channel names being truncated
On Sat, Oct 17, 2009 at 07:35:41PM +0200, Benoit Panizzon wrote: Package: BitchX Version: 1:1.1-5 Severity: normal I don't even know where this package came from... bitchx has not been in Debian for two releases. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550999: Misleading comments in python.supp
Package: python Version: 2.5.4-2 Severity: normal The python package installs a file in /usr/lib/valgrind/python.supp that says: # Debian note: # The file Misc/valgrind-python.supp is placed in an modified form into the # directory /usr/lib/valgrind as python.supp. There's no need to to add it # with the --suppressions option. But that's not true. Valgrind doesn't load suppressions from this file by default. Instead a copy of these suppressions in default.supp, built from debian.supp, is used. If you want this copy, you have to specify it. Also, I get a number of errors on reads of size 8; the file only suppresses errors for reads of size 4, but these look like the same allocator issue. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages python depends on: ii python-minimal2.5.4-2A minimal subset of the Python lan ii python2.5 2.5.4-2An interactive high-level object-o python recommends no packages. Versions of packages python suggests: pn python-docnone (no description available) ii python-profiler 2.5.2-1deterministic profiling of any Pyt ii python-tk 2.5.2-1.1 Tkinter - Writing Tk applications -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550710: gdb: record error in memset: Process record doesn't support instruction 0xf6e
On Mon, Oct 12, 2009 at 02:51:10PM +0300, Török Edwin wrote: If I compile the program with -m32, then memset works, so it looks like something wrong with handling of SSE instructions. More precisely there isn't any such support: /* MMX/SSE/SSE2/PNI support */ /* XXX */ -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519522: gdb: setting breakpoint in constructor fails
On Fri, Mar 13, 2009 at 11:16:50AM +0100, Thomas Richter wrote: Compile with g++ -O0 -ggdb3 test.cpp and start debugging with gdb a.out. Now enter the command break A::A and start the program with run. Even though the breakpoint is reported to be set, the program does not stop in the constructor. This problem is still present in GDB 7.0: (gdb) break A::A (gdb) info break No breakpoints or watchpoints. That's a bizarre result. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519525: gdb: TAB expansion for class members does not work
On Fri, Mar 13, 2009 at 11:20:38AM +0100, Thomas Richter wrote: Package: gdb Version: 6.8-3 Severity: normal gdb does not provide any useful TAB expansion for class members. That is, if you define a name space like A::, pressing on TAB presents all useless symbols that are not even members of the class. To reproduce, enter the following program: This is improved in GDB 7.0, but still not great. (gdb) complete break A:: break A::A(int) break A::getX() const break A::~A() (gdb) complete break A::A break A::A(int) (gdb) break A::A(int) Breakpoint 1 at 0x4006eb: file 519525.cc, line 12. (2 locations) Good so far. But: (gdb) break A::getX() const Function A::getX() not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break A::getX() Function A::getX() not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break 'A::getX() const' Breakpoint 2 at 0x4006a4: file 519525.cc, line 24. If the quotes are necessary, GDB should insert them for you; ideally they shouldn't be necessary. And: (gdb) complete break A::~ break A::~anonymous struct break A::~anonymous struct::anonymous union break A::~A break A::~A::A(int) break A::~A::getX() const break A::~A::~A() break A::~FILE ... Completion is not recognizing ~ as valid in the middle of a symbol. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#346409: gdb: fails to function at all on stuff linked with -pie
Some minimal progress upstream: warning: The current binary is a PIE (Position Independent Executable), which GDB does NOT currently support. Most debugger features will fail if used in this session. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550361: gdb: Cannot access memory at address 0x5
On Fri, Oct 09, 2009 at 05:51:48PM +0200, Witold Baryluk wrote: This GDB was configured as i486-kfreebsd-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... (no debugging symbols found) (gdb) run a Starting program: /bin/echo a Cannot access memory at address 0x5 (gdb) bt #0 0x280ef7b0 in ?? () (gdb) c Continuing. a Program exited normally. (gdb) q Debuging more complicated programs (like epiphany-browser) is impossible. (gdb) r Starting program: /usr/bin/epiphany-browser Cannot access memory at address 0x5 (gdb) c Continuing. Program received signal ?, Unknown signal. 0x298a10a7 in ?? () (gdb) c Continuing. warning: Signal ? does not exist on this system. Thanks for the report. Unfortunately, I don't know anything about kfreebsd... this will need a porter's attention. Can anyone help? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544348: gdb fails attaching /usr/bin/Xorg: internal-error: linux_nat_attach: [...] failed
On Sun, Aug 30, 2009 at 08:29:50PM +, kar...@brueckenschlaeger.de wrote: /build/buildd/gdb-6.8/gdb/linux-nat.c:988: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) WIFSTOPPED (status) WSTOPSIG (status) == SIGSTOP' failed. Can you try the GDB in testing / unstable? This should be fixed already. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542276: liferea blocks while running a feed update command
Package: liferea Version: 1.6.0-1 Severity: normal I have a perl script which generates an RSS feed. It takes quite a while to run (30 seconds or so). Liferea becomes unresponsive whenever it is updating that feed; the UI does not even redraw if the window is covered and uncovered. The feed runs a command (the perl script), and then pipes it to a filter (iconv -f iso-8859-1 -t utf-8) to accomodate dubious input RSS feeds. I don't know if it's the command or the filter causing the problem. This worked fine a couple releases of liferea ago. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liferea depends on: ii gconf2 2.26.2-3 GNOME configuration database syste ii libatk1.0-0 1.26.0-1 The ATK accessibility toolkit ii libc6 2.9-23 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.16-2 simple interprocess messaging syst ii libdbus-glib-1-20.82-1 simple interprocess messaging syst ii libgconf2-4 2.26.2-3 GNOME configuration database syste ii libglade2-0 1:2.6.4-1library to load .glade files at ru ii libglib2.0-02.20.4-1 The GLib library of C routines ii libgtk2.0-0 2.16.5-1 The GTK+ graphical user interface ii libice6 2:1.0.5-1X11 Inter-Client Exchange library ii liblua5.1-0 5.1.4-3 Simple, extensible, embeddable pro ii libnm-glib0 0.7.1-1 network management framework (GLib ii libnotify1 [libnotify1-gtk2 0.4.5-1 sends desktop notifications to a n ii libpango1.0-0 1.24.5-1 Layout and rendering of internatio ii libsm6 2:1.1.0-2X11 Session Management library ii libsoup2.4-12.27.4-1 an HTTP library implementation in ii libsqlite3-03.6.16-1 SQLite 3 shared library ii libwebkit-1.0-2 1.1.12-1 Web content engine library for Gtk ii libx11-62:1.2.2-1X11 client-side library ii libxml2 2.7.3.dfsg-2 GNOME XML library ii libxslt1.1 1.1.24-2 XSLT processing library - runtime ii liferea-data1.6.0-1 architecture independent data for Versions of packages liferea recommends: ii curl 7.19.5-1 Get a file from an HTTP, HTTPS or ii dbus 1.2.16-2 simple interprocess messaging syst ii dbus-x11 1.2.16-2 simple interprocess messaging syst ii wget 1.11.4-4 retrieves files from the web Versions of packages liferea suggests: pn network-manager none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539351: Tiny patch to restore GDB functionality on GNU/Hurd
tags 539351 + pending thanks On Fri, Jul 31, 2009 at 12:37:48AM +0200, Thomas Schwinge wrote: Please apply the tiny patch from the attached email to the next Debian gdb package upload, so that we get a functional GDB again for GNU/Hurd. This patch is in GDB CVS HEAD already. This will be fixed in the next upload, thanks! -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537795: Addition of sources.redhat.com/gdb/onlinedocs/ in README.Debian
On Tue, Jul 21, 2009 at 12:06:26AM +, sobtwmxt wrote: Package: gdb Version: 6.8-3 Severity: wishlist I think that http://sources.redhat.com/gdb/onlinedocs/gdb.html#SEC_Top is great to get someone quickly into gdb. I wish it would be specifically mentioned in /usr/share/doc/gdb/README.Debian . The documentation is already in the gdb-doc package, but I'll add a pointer in the next upload. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536756: [Pkg-ia32-libs-maintainers] Bug#536756: It really would be nice to still have ia32-libs
On Mon, Jul 20, 2009 at 08:47:00AM +0200, Goswin von Brederlow wrote: If you can think of a way let me know but I think it just isn't possible for ia32-apt-get to provide ia32-libs/ia32-libs-gtk dummy packages. Only solution I can think of is to not only mangle the binary-i386/Packages file but also the binary-amd64/Packages file and replace any dependcy on ia32-libs or ia32-libs-gtk. The version in unstable will have some version number; coordinate with Mark to know what it will be. Conflict/Replace ia32-libs with the same epoch and synthesize one with a later epoch. Does that work? Sure, it's not 100% robust against future packages, but I think it covers the highlights. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537743: locales-all postinst uses too much RAM
On Mon, Jul 20, 2009 at 07:11:52PM +0200, Aurelien Jarno wrote: That's an option, but it means someone has to work on patching locales generation tools, as it is currently not possible to create /usr/lib/locale/locale-archive during the build. Some of the required work is in the EGLIBC localedef component. I've never made it generate an archive instead of separately compiled files, but I keep meaning to... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536756: It really would be nice to still have ia32-libs
reopen 536756 thanks Hi Goswin, I think you've answered a different suggestion than the submitter actually made. A lot of people want ia32-libs back in unstable, for those who aren't using ia32-apt-get. But the other useful thing would be to let those using ia32-apt-get have packages named ia32-libs and ia32-libs-gtk installed. I can't even make dummy packages because everything the latest ia32-apt-get generates has Conflicts/Replaces. There are external packages that depend on these; there will be for a while, and indefinitely if the packages re-enter unstable. So could you add ia32-apt-get-generated packages to fulfill those dependencies? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492846: same manpage file in gdb and gdb-arm-linux-gnueabi
On Sat, Jul 18, 2009 at 02:15:50PM +0200, Reine Johansson wrote: I have the same problem. My gdb-arm-linux-gnueabi 6.8-3 is precompiled from the repository at http://www.emdebian.org/debian/ This is fixed in unstable; I just closed the bug. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536992: gdb: FTBFS: make[3]: *** No rule to make target `install'. Stop.
On Tue, Jul 14, 2009 at 09:00:51AM -0400, Lucas Nussbaum wrote: Relevant part: make[2]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir' /bin/sh /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/mkinstalldirs /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr mkdir -p -- /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr make[3]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[3]: *** No rule to make target `install'. Stop. make[3]: Leaving directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[2]: *** [install-bfd] Error 2 This doesn't make sense. There's an install target in that Makefile.in, but no install-bfd target. There's no sign in the build log of rerunning automake, either. Is this reproducible in some way that the build directory survives? FWIW, I built the packages on amd64, in a pbuilder chroot. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536992: gdb: FTBFS: make[3]: *** No rule to make target `install'. Stop.
On Tue, Jul 14, 2009 at 11:50:47AM -0400, Lucas Nussbaum wrote: On 14/07/09 at 10:47 -0400, Daniel Jacobowitz wrote: On Tue, Jul 14, 2009 at 09:00:51AM -0400, Lucas Nussbaum wrote: Relevant part: make[2]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir' /bin/sh /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/mkinstalldirs /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr mkdir -p -- /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr make[3]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[3]: *** No rule to make target `install'. Stop. make[3]: Leaving directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[2]: *** [install-bfd] Error 2 This doesn't make sense. There's an install target in that Makefile.in, but no install-bfd target. There's no sign in the build log of rerunning automake, either. Is this reproducible in some way that the build directory survives? Yes, I've just reproduced it in a clean chroot with dpkg-buildpackage. I've tar'ed the build dir, but it's quite big (101 MB). Do you want me to upload it somewhere for you? Sure - do you have somewhere you could put it? people.d.o? FWIW, I built the packages on amd64, in a pbuilder chroot. Have you tried again today? I built and uploaded -3 last night, using a freshly updated pbuilder chroot, and using the same source tarball. I can try it again today. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495607: dejagnu: Another typo
On Sun, Dec 21, 2008 at 01:29:33AM +, Reuben Thomas wrote: Package: dejagnu Version: 1.4.4.git20080407-1 Followup-For: Bug #495607 it's one test state output - its one test state output Thanks, I've reported these upstream and I'll keep a note on them in case another upload is needed before the next version. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536992: gdb: FTBFS: make[3]: *** No rule to make target `install'. Stop.
On Tue, Jul 14, 2009 at 07:27:47PM +0200, Stéphane Glondu wrote: Same problem as #537011: gdb builds successfully after downgrading cdbs to 0.4.56. FWIW, I'm pretty sure the build I did this morning used CDBS 0.4.57... I'm not sure, though, I wish it was easier to save trees after pdebuild. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536024: gdb gets wrong address for glibc optind variable
On Tue, Jul 07, 2009 at 11:38:24AM +0200, John Hughes wrote: I don't get the static version with gcc 4.3 and gdb 6.8 on lenny (x86-64): (gdb) info var optind All variables matching regular expression optind: File /usr/include/getopt.h: int optind; Non-debugging symbols: 0x00600a00 optind@@GLIBC_2.2.5 Maybe this means you don't have libc6-dbg installed? I would have expected GDB to work in this case, preferring the copy in the executable. Go figure. Unfortunately, this bug is quite hard to fix. It applies to any variable defined in a shared library and used in the executable. Eew. How horrid. Here's another reference (the problem has been around for a while): http://sourceware.org/ml/gdb/2003-12/msg00165.html -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536024: gdb gets wrong address for glibc optind variable
On Tue, Jul 07, 2009 at 04:17:21PM +0200, John Hughes wrote: I'm a bit confused - the program itself prints optind as 0x600a00, which is what the non-debugging symbol optind@@GLIBC_2.2.5 is shown as. Which copy is the good one? What happens is that the variable is defined in libc.so.6. But at program startup, any initial value is copied from that version to the one in the executable. Then all future references go to the executable. For reference this is gdb bugzilla bug 8588, opened 2003-12-12 15:08, previously Gnats 1483 http://sourceware.org/bugzilla/show_bug.cgi?id=8588 Thanks! Let me see if I can make bts-link work... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536024: gdb gets wrong address for glibc optind variable
On Mon, Jul 06, 2009 at 10:59:56PM +0200, John Hughes wrote: debugging a program that uses the glibc getopt function shows the wrong address and value for the optind variable. (gdb) info var optind All variables matching regular expression optind: File /usr/include/getopt.h: static int optind; File getopt.c: int optind; Non-debugging symbols: 0x00600a00 optind@@GLIBC_2.2.5 GDB thinks there are two copies. One is in getopt.c in libc.so. That's the one that GDB is printing. The other is in the executable, target of an R_arch_COPY relocation. GDB prints the one that has debug info. (I do not know why there is also a static copy attributed to getopt.h; I can not find it in GDB's symbol dumps...) Unfortunately, this bug is quite hard to fix. It applies to any variable defined in a shared library and used in the executable. Here's a little more about the issue: http://sourceware.org/ml/gdb/2005-08/msg00031.html -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535237: binutils: Please enable --build-id in ld by default
On Tue, Jul 07, 2009 at 01:43:51AM +0200, Emilio Pozuelo Monfort wrote: Can you give me your opinion on the (little) patch, and what you think I should do with respect to the test suite regressions? Do you need a binutils patch at all? Why not do it in GCC like Fedora did? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535863: aptitude: Reports Hash Sum mismatch on valid packages
Package: aptitude Version: 0.4.11.11-1+b1 Severity: normal I've been trying to build gdb using pbuilder for a couple of days. Every time, I get this: Fetched 99.8MB in 9s (10.9MB/s) E: Failed to fetch http://http.us.debian.org/debian/pool/main/libx/libxau/libxau6_1.0.4-2_amd64.deb: Hash Sum mismatch E: Unable to correct for unavailable packages I can reproduce this by hand, by: * Unpacking base.tar.gz from pbuilder * Setting http_proxy to point to my apt-cacher instance, which has a valid copy of libxau6 and does not cache packages lists. * Installing the dummy build-deps .deb produced by pbuilder. * Running: aptitude -y --without-recommends -o APT::Install-Recommends=false \ -o Aptitude::CmdLine::Ignore-Trust-Violations=true \ -o Aptitude::ProblemResolver::StepScore=100 install \ pbuilder-satisfydepends-dummy It downloads 147 packages and then reports an error on libxau6. Every other combination I've tried works, for instance I can install libxau6 directly. It would help if aptitude printed out the expected and observed checksums; it's possible this is apt-cacher's fault instead. I've saved the .deb and base.tar.gz I used to reproduce this, let me know if you want them. -- Package-specific info: aptitude 0.4.11.11 compiled at Apr 16 2009 23:38:07 Compiler: g++ 4.3.3 Compiled against: apt version 4.6.0 NCurses version 5.7 libsigc++ version: 2.0.18 Ept support enabled. Current library versions: NCurses version: ncurses 5.7.20090530 cwidget version: 0.5.12 Apt version: 4.6.0 not a dynamic executable Terminal: screen $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: squeeze/sid APT prefers transitional APT policy: (500, 'transitional'), (500, 'unstable'), (500, 'stable'), (400, 'unstable-i386'), (400, 'stable-i386') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.7.21Advanced front-end for dpkg ii libc6 2.9-18GNU C Library: Shared libraries ii libcwidget30.5.12-4 high-level terminal interface libr ii libept00.5.26+b1 High-level library for managing De ii libgcc11:4.4.0-10GCC support library ii libncursesw5 5.7+20090530-1shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libstdc++6 4.4.0-10 The GNU Standard C++ Library v3 ii libxapian151.0.13-3 Search engine library ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-do 0.4.11.11-1 English manual for aptitude, a ter ii libparse-debianchangelog-per 1.1.1-2 parse Debian changelogs and output Versions of packages aptitude suggests: ii debtags 1.7.9+b1 Enables support for package tags ii tasksel 2.79 Tool for selecting tasks for insta -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Re: [libgdb-dev] Undefined symbols in libgdb.a
On Thu, Jun 11, 2009 at 11:33:01PM +0200, Mazen NEIFER wrote: Any news about this bug? Could you please provide an estimation about when it could get solved? I'm trying to find time to work on it. I'll do it as soon as I can, or anyone is welcome to submit a patch. I believe the planned fix is already described in the bug log. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532238: [Pkg-fglrx-devel] Bug#532238: fglrx-atieventsd: authatieventsd.sh retried forever
On Mon, Jun 08, 2009 at 01:54:22PM +0200, Patrick Matthäi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Jacobowitz schrieb: Package: fglrx-atieventsd Severity: normal I installed fglrx-atieventsd along with the rest of the fglrx packages today, and my hard disk immediately started spinning. I discovered it was logging to auth.log every few seconds by running 'su', from authatieventsd.sh. The command was presumably failing and then being retried forever. After a reboot into the fglrx driver and a reconfigured X server, I can no longer reproduce this; but is there any way to stop the script from being constantly re-run? Hmm what was exactly failing? For the start thing.. I think I will add a default file for it the next time. I'm not sure :-( Here's the only log got: Jun 7 09:27:31 caradoc su[8778]: Successful su for drow by root Jun 7 09:27:31 caradoc su[8778]: + ??? root:drow Jun 7 09:27:31 caradoc su[8778]: pam_unix(su:session): session opened for user drow by (uid=0) Jun 7 09:27:31 caradoc su[8778]: pam_unix(su:session): session closed for user drow Jun 7 09:27:32 caradoc su[9350]: Successful su for drow by root Jun 7 09:27:32 caradoc su[9350]: + ??? root:drow Jun 7 09:27:32 caradoc su[9350]: pam_unix(su:session): session opened for user drow by (uid=0) Jun 7 09:27:32 caradoc su[9350]: pam_unix(su:session): session closed for user drow Jun 7 09:27:32 caradoc su[9407]: Successful su for drow by root Jun 7 09:27:32 caradoc su[9407]: + ??? root:drow Jun 7 09:27:32 caradoc su[9407]: pam_unix(su:session): session opened for user drow by (uid=0) Jun 7 09:27:32 caradoc su[9407]: pam_unix(su:session): session closed for user drow Jun 7 09:27:33 caradoc su[10006]: Successful su for drow by root Jun 7 09:27:33 caradoc su[10006]: + ??? root:drow Jun 7 09:27:33 caradoc su[10006]: pam_unix(su:session): session opened for user drow by (uid=0) Jun 7 09:27:33 caradoc su[10006]: pam_unix(su:session): session closed for user drow Jun 7 09:27:33 caradoc su[10064]: Successful su for drow by root Jun 7 09:27:33 caradoc su[10064]: + ??? root:drow Jun 7 09:27:33 caradoc su[10064]: pam_unix(su:session): session opened for user drow by (uid=0) Jun 7 09:27:33 caradoc su[10064]: pam_unix(su:session): session closed for user drow And so on, until I figured out what was running. There was also this error, but fixing it by installing acpid didn't help with the su logs: Jun 7 09:49:50 caradoc atieventsd[21315]: ATI External Events Daemon started... Jun 7 09:49:50 caradoc atieventsd[21315]: Configuration file: /etc/ati/atieventsd.conf Jun 7 09:49:50 caradoc atieventsd[21315]: Control socket: /var/run/atieventsd.socket Jun 7 09:49:50 caradoc atieventsd[21315]: ACPI daemon socket: /var/run/acpid.socket Jun 7 09:49:50 caradoc atieventsd[21315]: X auth script file: /etc/ati/authatieventsd.sh Jun 7 09:49:50 caradoc atieventsd[21315]: Internal event queue size: 16 Jun 7 09:49:50 caradoc atieventsd[21315]: Control socket connection created with handle: 4 Jun 7 09:49:50 caradoc atieventsd[21315]: Event daemon control socket created Jun 7 09:49:50 caradoc atieventsd[21315]: Socket for acpid connection created with handle: 5 Jun 7 09:49:50 caradoc atieventsd[21315]: Unable to connect to acpid Jun 7 09:49:51 caradoc atieventsd[21315]: Socket for acpid connection created with handle: 5 Jun 7 09:49:51 caradoc atieventsd[21315]: Unable to connect to acpid I wonder if I could reproduce it by starting X with the Radeon driver instead of fglrx again. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532238: fglrx-atieventsd: authatieventsd.sh retried forever
Package: fglrx-atieventsd Severity: normal I installed fglrx-atieventsd along with the rest of the fglrx packages today, and my hard disk immediately started spinning. I discovered it was logging to auth.log every few seconds by running 'su', from authatieventsd.sh. The command was presumably failing and then being retried forever. After a reboot into the fglrx driver and a reconfigured X server, I can no longer reproduce this; but is there any way to stop the script from being constantly re-run? -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages fglrx-atieventsd depends on: ii fglrx-glx 1:9-5-1proprietary libGL for the non-free ii libc6 2.9-13 GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1] 7.4.1-1A free implementation of the OpenG ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxrandr22:1.3.0-2 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii xserver-xorg 1:7.4+1the X.Org X server Versions of packages fglrx-atieventsd recommends: ii fglrx-driver 1:9-5-1non-free AMD/ATI r6xx - r7xx displ fglrx-atieventsd suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531849: hddtemp: Default settings check sg?, spin up drives
Package: hddtemp Version: 0.3-beta15-45 Severity: normal The default init script for hddtemp checks both sg? and sd?. When sda (which is the same disk as sg0 on my system) is sleeping, hddtemp /dev/sda reports that the disk is sleeping; but hddtemp /dev/sg0 spins up the disk. So this default configuration causes all drives to spin up whenever sensors-applet connects to the daemon. Solutions I can think of: spun-down detection for generic drives (is this even possible?); identify which non-generic devices /dev/sg? correspond to; or do not check generic devices by default. This took me a day to figure out; I've changed /etc/default/hddtemp to say: # Skip /dev/sg?. DISKS=/dev/hd? /dev/sr? /dev/sd? And now my unused drive stays spun down. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-rc7 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hddtemp depends on: ii cdebconf [debconf-2.0]0.141 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii libc6 2.9-13 GNU C Library: Shared libraries ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip hddtemp recommends no packages. Versions of packages hddtemp suggests: pn ksensors none (no description available) -- debconf information: * hddtemp/SUID_bit: false * hddtemp/interface: 127.0.0.1 * hddtemp/syslog: 0 * hddtemp/daemon: true * hddtemp/port: 7634 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524424: closed by Daniel Jacobowitz d...@false.org (Re: Bug#524424: gdb: asin produces wrong values)
reopen 524424 reassign 524424 gcc-4.3 thanks On Thu, Apr 16, 2009 at 08:41:05PM -0700, Jacob Mandelson wrote: Should I file this against gcc or libc then? In concert, this behavior is clearly erroneous. I'll reassign this to GCC - I think that at least the option to output the declarations would be useful. The libc behavior is an implementation detail. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522093: info: New regex isearch beeps/flashes
Package: info Version: 4.13a.dfsg.1-1 Severity: normal I use the standalone info viewer, inside screen. Typing C-s * now causes the screen to flash about a dozen times. I believe it's trying to beep once per character of some error message. Even more annoying is that this happens for C-s \ (backslash). You can't search for anything that requires an escape sequence without at some point having an invalid regular expression in the buffer. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages info depends on: ii libc6 2.9-6 GNU C Library: Shared libraries ii libncurses5 5.7+20090314-1 shared libraries for terminal hand info recommends no packages. Versions of packages info suggests: pn texinfo-doc-nonfree none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520651: GDB crashes on watchpoints with illegal addresses
On Sat, Mar 21, 2009 at 04:59:34PM +0100, Claus Fischer wrote: With the latest gdb, a watchpoint which points into allocated memory that is not available at process start, will not only cause the program but also gdb to crash and abort. Can you show me an example debug session where this happens? I've used this feature as recently as yesterday. It worked fine, and in fact I was very happy with it - you used to get GDB errors on startup but now it will detect the first write even if memory was previosuly unmapped. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520651: GDB crashes on watchpoints with illegal addresses
On Sun, Mar 22, 2009 at 03:04:23PM +0100, Claus Fischer wrote: r# gives the following output - Starting program: /home/cfischer/tmp/tt Error in re-setting breakpoint 3: Cannot access memory at address 0x777e2f90 Error in re-setting breakpoint 3: Cannot access memory at address 0x777e2f90 Error in re-setting breakpoint 3: Cannot access memory at address 0x777e2f90 Cannot access memory at address 0x777e2f90 (gdb) Debugger aborted - r post-prompt Starting program: /home/drow/gdbtest starting breakpoint 1 Breakpoint 1, frame-begin 0 0x40052b main (argc=1, argv=0x7fffe068) at gdbtest.c:7 source /home/drow/gdbtest.c:7:95:beg:0x40052b stopped pre-prompt (gdb) prompt My mistake: I have the GDB from experimental installed. It works there. I need to update unstable. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518452: All programs segfault when running under gdb
On Fri, Mar 06, 2009 at 03:38:44AM -0500, Bryan Donlan wrote: (gdb) run Starting program: /bin/true (no debugging symbols found) (no debugging symbols found) Program received signal SIGTRAP, Trace/breakpoint trap. 0xf7f8bba8 in ?? () (gdb) cont Continuing. There is no plausible way that this is a GDB bug. It's going to be a problem with your kernel. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518134: gdb: please don't read the whole file when using split symbols
On Wed, Mar 04, 2009 at 11:49:48AM +0100, Josselin Mouette wrote: Therefore, it would be very nice to think of a way to not make this reading happen. I don’t think it is necessary to check the whole file’s CRC32; other mechanisms (like dependencies) should prevent the files from having discrepancies. Just to be safe, you could store a generated UUID in both file headers, and that would not require reading the whole files. This is possible using build-id notes. However, I don't know what changes across the distribution would be required for that. We'd have to generate them for all binaries and libraries if we aren't already. After that, if GDB locates a debug file by using build ID it won't check the crc. I think it will still check CRC's if it searches /usr/lib/debug, but that could be fixed in a very straightforward manner. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518134: gdb: please don't read the whole file when using split symbols
On Wed, Mar 04, 2009 at 04:35:29PM +0100, Josselin Mouette wrote: I guess it means changing the default for ld, which is currently set to not generating them by default, AFAICT. Should I report another bug against binutils, then? IMO yes. This would be nice. Also, looking at the documentation, it would be a very elegant way to store the debugging symbols for many versions in a single online directory structure. There wouldn’t be a need to create a virtual filesystem layout pointing to the correct debugging symbols since the build IDs are unique. If you're interested in this subject, you may want to see what Fedora has done with them. They have some mechanism for making GDB report which debuginfo RPMs you ought to install. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516516: Provide all debug symbols
On Sun, Feb 22, 2009 at 10:21:44AM +0100, Jörg Sommer wrote: Gdb can look in different directories for debugging informations. Can you provide two versions: the current and a full (fat) version? Then I could “set debug-file-directory /usr/lib/debug/fat” and get a slow and verbose gdb output. Is this possible? Do you think it's useful? Note that, unfortunately, it can not search two in the same session. This would break all other libraries with debug symbols. If not for that, yes, I think this would be useful. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516571: gdb on SPARC fails with regcache.c:175: internal-error: register_size: assertion failure
On Sun, Feb 22, 2009 at 01:14:12PM +0100, Henrik Stoerner wrote: Package: gdb Version: 6.4.90.dfsg-1 Severity: normal While trying to debug a program on Debian/SPARC I loaded the binary and a core-dump into gdb. A simple bt then caused the following error (after displaying part of the backtrace, but not all of it): I believe this is fixed in lenny already. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513816: gdb sometimes doesn't find line numbers (on very large executables?)
tag 513816 + experimental fixed-upstream thanks On Sun, Feb 01, 2009 at 03:26:18PM +0100, John Hughes wrote: Trying to use gdb to debug a linux kernel running under qemu many functions don't seem to have line numbers. (Kernel built with CONFIG_DEBUG_INFO). I've just committed a fix for this upstream: http://sourceware.org/ml/gdb-patches/2009-02/msg00182.html The next time that HEAD is merged to the Python branch, and I update the Debian packaging, this fix will come into Debian. Thanks for the test case! That made this much easier to solve. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513678: Acknowledgement (gdb segfaults if set hardware watchpoints when target remote)
tag 513678 + fixed-in-experimental thanks On Sat, Jan 31, 2009 at 06:02:48PM +0100, John Hughes wrote: Yup, that seems to fix it. Boy, it's mighty chilly out here. Are we frozen or what? Yup, we are. I'll be updating the GDB in unstable at some point, but this has missed lenny. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513341: doesn't contain debugging symbols
On Mon, Feb 02, 2009 at 10:12:37PM +0100, Jörg Sommer wrote: But this doesn't work for core dumps. I would like to get more informations, like local variables from core dumps. How can I get such informations with the debugging library in /usr/lib/debug? Sorry, there's no way to do this with the current packages. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Re : Use libiberty.a and libexpat.a
On Wed, Feb 04, 2009 at 05:26:00PM +, marcos.mar...@sonae.com wrote: Hi there, Any updates on this issue? Not yet, sorry. I think the best solution would be to add the contents of libiberty.a to libgdb.a at the end of the GDB build. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513816: Some clues?
On Mon, Feb 02, 2009 at 01:17:26PM +0100, John Hughes wrote: With 6.8.50.20090106-cvs: $ gdb vmlinux Could you put the binary affected by this problem somewhere for me to look at? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513816: Some clues?
On Mon, Feb 02, 2009 at 01:17:26PM +0100, John Hughes wrote: It looks like 6.8.50 is loading the symtab for init/main.c automatically and somehow refusing to look at other stuff on the list. Right. I can reproduce the error with your binary; this is probably caused by DW_AT_ranges support. The Linux kernel very frequently triggers this sort of error, because of the use of .init.text; any one file is likely to have code at two widely separated addresses and GDB can get confused about things in the middle. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513678: Acknowledgement (gdb segfaults if set hardware watchpoints when target remote)
On Sat, Jan 31, 2009 at 01:34:08PM +0100, John Hughes wrote: Here's a patch that fixes it for me (obviously it needs generalising for os's/cpu configurations other than Linux/i386). Thanks, but could you first try the GDB package in experimental? That one should work OK; I believe this was fixed last year. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#346409: merged patch for PIE
On Thu, Dec 18, 2008 at 04:56:58PM -0800, Kees Cook wrote: Hello, here is an updated PIE patch, which is used in Ubuntu and works well enough. FYI I just saw a bug report in the GDB bugzilla which looks to be caused by this patch. I'm not planning to apply it for Debian until it is merged upstream. I know Jan was planning to do so at some point. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Re : Use libiberty.a and libexpat.a
On Tue, Dec 30, 2008 at 12:25:45AM +0100, Mazen NEIFER wrote: Package: libgdb-dev Version: 6.8-3 --- Please enter the report below this line. --- /usr/lib/libgdb.a(exec.o): In function `generic_skip_trampoline_code': (.text+0x0): multiple definition of `generic_skip_trampoline_code' /usr/lib/libgdb.a(arch-utils.o):(.text+0x0): first defined here How are you linking the library to cause this error? --whole-archive? I'm using FPC which produces the attached linker script. Oh right, this was fixed upstream but the fix may not be in Debian yet. #include foo.c instead of foo.h. /usr/lib/libgdb.a(gdbtypes.o):(.data+0x50): undefined reference to `floatformat_ibm_long_double' You need -liberty. I could not find this function in libiberty.a Version skew - that libiberty.a is from an older version of binutils than this version of GDB. The function is in GDB's version of libiberty. I have no idea what to do about that. I don't want to have multiple versions of libiberty installed... I will think about it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Unresolved symbols
On Sat, Dec 27, 2008 at 12:18:50PM +0100, Mazen NEIFER wrote: After installing binutils-dev package the following error is got : It is a static library; it has no way to indicate its dependencies. /usr/lib/libgdb.a(exec.o): In function `generic_skip_trampoline_code': (.text+0x0): multiple definition of `generic_skip_trampoline_code' /usr/lib/libgdb.a(arch-utils.o):(.text+0x0): first defined here How are you linking the library to cause this error? --whole-archive? /usr/local/src/fpcbuild-2.2.3/build/fpc-2.2.3/fpcsrc/packages/gdbint/units/i386-linux/gdbint.o: In function `GDBINT_INITLIBGDB': gdbint.pp:(.text+0x1666): undefined reference to `error_init' This is not related to libgdb. /usr/lib/libgdb.a(gdbtypes.o):(.data+0x50): undefined reference to `floatformat_ibm_long_double' You need -liberty. (.text+0x69e): undefined reference to `XML_SetParamEntityParsing' Also -lexpat. Soon you'll need Python, too. I'll update the dependencies if I can find where to pull libiberty from. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509920: binutils-dev: the file /usr/lib/libbfd.a is absent
On Sat, Dec 27, 2008 at 12:23:35PM -0600, Oleg SHALAEV wrote: Package: binutils-dev Version: 2.18.1~cvs20080103-7 Severity: normal According to the output of the command apt-file show binutils-dev the package binutils-dev contains the file /usr/lib/libbfd.a However in reality it doesn't. It looks like binutils-multiarch has funny diversions... there is a libbfd.a in binutils-dev, though. If you have binutils-multiarch installed it is diverted to libbfd-single.a. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509173: gdb: no locals in C++ constructors
reassign 509173 gcc-4.3 thanks On Fri, Dec 19, 2008 at 09:14:02AM +0200, Eugene V. Lyubimkin wrote: Package: gdb Version: 6.8-3, 6.8.50.20081210.python-1 Severity: normal It is very hard to debug something in C++ constructors because GDB failes to see any local variables in it. Consider this tiny example: This is a GCC bug, recently fixed in mainline. There's no debug info for the locals. PRs include 27574 and 33044. 33044 mentions a GDB bug but that's only for static local variables. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475839: libc6-dev: pthread_mutex_t definition contains a nameless union
On Sun, Dec 14, 2008 at 11:43:24PM +0100, Francois Gouget wrote: I would like this bug to be reopened because I think it was closed for the wrong reasons: 1) gcc-2.95 is still present in Lenny. If you are not seeing it in aptitude, it's because you are using the 64bit build. For the record, it isn't. You may still have it installed, or you may have Etch also in your sources.list; etch did include gcc-2.95 on some platforms. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506119: gdb: please consider integrating python support
On Tue, Nov 18, 2008 at 03:00:02PM +0100, Josselin Mouette wrote: as you probably already know, some work is underway to be able to script gdb in python: http://sourceware.org/gdb/wiki/PythonGdb There are already some Python scripts out there that help a lot debugging GObject-based programs, and it would be very nice if we could benefit of it. I guess this is only the beginning and that we will see a lot of things to improve debugging experience. Please consider shipping these changes in Debian packages; maybe in experimental at first if you feel this is not stable enough. I don't want to put this in unstable yet, since it's not available on trunk - it's on a branch in the archer git repository. Experimental is not a bad idea though. It will be merging to trunk over the next six months. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490769: Disappearing input boxes in iceweasel
I've been having this problem too (since the first 3.0 beta that had a Debian package). Virtually all text boxes are affected for me. If I go to google.com, the black outline of the input box appears; but the moment my mouse cursor goes over it, the line vanishes. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499463: linux-image-2.6.26-1-versatile: Please enable CONFIG_VFP
Package: linux-image-2.6.26-1-versatile Version: 2.6.26-5 Severity: normal Both some versatile boards, and qemu, have VFP support. The Debian kernel leaves CONFIG_VFP off, so any program using VFP will fail. I checked here: http://svn.debian.org/viewsvn/kernel/dists/trunk/linux-2.6/debian/config/arm/config.versatile?rev=11915view=log -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498390: gdb refuses to load freshly built vlc binary on mips
On Tue, Sep 09, 2008 at 06:52:39PM +0100, peter green wrote: I tried to use gdb to get a backtrace of the problem. Unfortunately gdb refuses to load the freshly built vlc binary. The binary does appear to be a valid executable as I get some output from it before it segfaults. What does 'file' say? Is it a libtool-generated script, for instance? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498290: wrong primitive type sizeof in gdb amd64
On Mon, Sep 08, 2008 at 08:34:32PM +0200, Matthias Klose wrote: Package: gdb Version: 6.8-3 gdb reports incorrect sizeof: $ gdb GNU gdb 6.8-debian Copyright (C) 2008 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. (gdb) p sizeof(int) $1 = 4 (gdb) p sizeof(long) $2 = 4 (gdb) p sizeof(void *) $3 = 4 (gdb) quit This is just how a biarch capable GDB works: (gdb) show architecture The target architecture is set automatically (currently i386) There's no way to specify which variant ends up as the default. Is it causing a problem? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498030: gdb: make gdb print %ebp based backtraces
On Sat, Sep 06, 2008 at 02:46:26PM +0200, Martin Pitt wrote: I monkey-patched it to cover x86_64 as well, and it works well for me: Do you have an example where it makes a difference on x86_64? It shouldn't; GCC defaults to -fasynchronous-unwind-tables on x86_64 (it's an ABI requirement), and that's much better than this. The patch needs to be posted upstream. If gnats is broken (we're in the process of ditching it), I suggest just posting it to gdb-patches. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432461: more info
On Fri, Aug 08, 2008 at 04:07:28PM -0300, Wouter Verhelst wrote: However, once you start stepping into a library (because, say, you're actually developing a library), the distinction between 'application functions' and 'library functions' that gdb uses to distinguish whether or not to step in or over a library call disappears (because every call is a library call, I presume), and the bug reappears. GDB doesn't differentiate between library and application functions; I assume this is some difference in the PLT sequence between applications and shared libraries that GDB is not prepared for. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493651: Failure building d-i images, bintutils fails - sid/experimental amd64
On Sun, Aug 03, 2008 at 11:37:02PM +0100, Miguel Figueiredo wrote: BFD: BFD (GNU Binutils for Debian) 2.18.50.20080507 internal error, aborting at../../bfd/elf.c line 4612 in assign_file_positions_for_non_load_sections BFD: Please report this bug. Command failed with status 1 : objcopy --strip-unneeded -R .note -R .comment /lib//libpthread.so.0 ./tmp/netboot/tree/lib/libpthread.so.0-so-stripped Can you reproduce by running this command by hand? What version of libc6 is installed? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489252: libc6-dbg: doesn't contain debug symbols for /lib/i686/cmov/libc.so.6
On Tue, Jul 22, 2008 at 10:17:12PM +0800, Paul Wise wrote: I guess this is a gdb issue then, since it doesn't seem to be able to find symbols for libc. Hmmm, it can't even find the libc.so.6 symbols when I purge libc6-i686 and copy /usr/lib/debug/lib/libc-2.7.so to /usr/lib/debug/lib/libc.so.6. Same happens when I make a symlink to libc-2.7.so. Reinstalling libc6-i686 and libc6-dbg doesn't seem to help either. Sorry, there's no concrete information in this bug report. What exactly happens that you believe is a bug? I believe symbols for libc are deliberately not shipped, just enough to backtrace. So GDB is likely behaving as expected. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485375: gdb: error cannot read floating-point and SSE registers
reassign 485375 linux-2.6 thanks On Sat, Jun 21, 2008 at 10:00:31AM +1000, Kevin Ryde wrote: Perhaps not surprisingly this is something kernel related, as 2.6.15 is ok. But what it means is a mystery. This has been identified as a kernel bug. The fixing commit is 11dbc963a8f6128595d0f6ecf138dc369e144997. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Sun, Jun 22, 2008 at 07:30:59PM -0400, James Y Knight wrote: Could this be the same bug as: https://bugzilla.novell.com/show_bug.cgi?id=390722 and https://bugs.launchpad.net/ubuntu/hardy/+source/gdb/+bug/111869 ? (with patch available) No, it's not related. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:19:35PM +0200, Pierre Habouzit wrote: Is a shared library involved? No, the symbol is local, visibility hidden. Normally, when this happens, there is a symbol in the ELF symbol table (.symtab) for the hidden symbol. That symbol is missing in your case. I don't know why it worked pre-6.7, but this is not a well-supported case in GDB. It expects there to be ELF symbols for all functions. Fortunately, an optimized code improvement added to GDB HEAD after 6.8 fixes your testcase again. In the mean time, I suggest you use 6.7, use HEAD, or arrange not to strip a subset of ELF symbols. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
severity 485955 normal thanks On Thu, Jun 12, 2008 at 05:41:02PM +0200, Pierre Habouzit wrote: Since the 6.8 releases, gdb totally fails to detect stack frames correctly, whereas the lenny version (6.7.1-2 atm) works fine. My architecture is amd64, but I've seen the same issues on i386 FWIW. I've seen no evidence this bug affects anyone else and the package is clearly not unusable. Downgrading. The code is C, with quite a few inlines, changing the gcc debug levels (-g/-g3/-ggdb3) or even building with -O0 -fno-inline doesn't change a damn thing. This renders gdb mostly unusable because it's totally unable to dump useful backtraces (with source files and files lineno's) on segfaults. Can you provide a test case? Or even an example session? I can't read your mind... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:11:28PM +0200, Pierre Habouzit wrote: #0 sms_emi_ack_5X (out=0x1b1dc88, msg=0x7fff637d97e0) at lib-inet/sms-emi.c:230 #1 0x00404973 in ?? () With gdb from etch: (gdb) bt #0 sms_emi_ack_5X (out=0x110dc88, msg=0x7fff73230240) at lib-inet/sms-emi.c:230 #1 0x00404973 in smsc_emi_on_query (we=0x110dbe0, msg=0x7fff73230240) at simulator/smsc/emi_smsc.c:232 Note, same address. Is a shared library involved? Does list smsc_emi_on_query do anything? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:19:35PM +0200, Pierre Habouzit wrote: sid: (gdb) list smsc_emi_on_query No line number known for smsc_emi_on_query. (gdb) b smsc_emi_on_query Breakpoint 1 at 0x404520 The debug readers were not able to parse this function's debug info. Is there any chance you can reproduce this with a smaller piece of code that you can share? I don't need source, just linked executable. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:47:03PM +0200, Pierre Habouzit wrote: (gdb) b smsc_emi_on_query During symbol reading, DW_AT_name missing from DW_TAG_base_type. During symbol reading, unsupported tag: 'DW_TAG_const_type'. Breakpoint 1 at 0x404520 These complaints are not relevant to your error. Also, the testsuite is still running but I already saw those failures: See the log in /usr/share/doc/gdb for typical failures. Does readelf -wi complain about the file containing one of your 'invisible' functions? What does the DW_TAG_subprogram look like for smsc_emi_on_query? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
