Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On Fri 2020-03-13 17:22:30 +0100, Aurelien Jarno wrote: > The reason is that all *-dbgsym packages need to go the debug archive, > not the main archive. Thanks, this is the piece of information that i was missing. Where is it documented that all *-dbgsym packages need to go to the debug archive? --dkg signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On Thu 2020-03-12 23:21:29 +0100, Aurelien Jarno wrote: > That would clearly work for your use case. Now I am not sure it won't > break other things. I'd like to know what it would break if it would break anything. > I asked on IRC and so far only get the confirmation that the package > shall not be renamed to libc6-dbgsym. Thanks for the reportback. Is there some policy about what kinds of package may be named *-dbgsym generally that renaming libc6-dbg would violate? comparing the file lists and (lack of) maintscripts between libc6-dbg and (as a random example) libglib2.0-0-dbgsym, they don't look that different (libglib2.0-0-dbgsym ships a file in /usr/lib/debug/.dwz while libc6-dbg does not, but i don't know that this is an important difference). Or is the reason that a rename would require updating the dependencies of other existing packages? For runtime deps, there aren't many: 0 dkg@alice:~$ apt rdepends libc6-dbg libc6-dbg Reverse Depends: Suggests: testdisk-dbg Suggests: libxapian30-dbg Depends: valgrind Suggests: testdisk-dbg Recommends: libntdb1-dbg |Recommends: libgcj17-dbg Suggests: ekiga-dbg Depends: valgrind Suggests: testdisk-dbg Depends: valgrind 0 dkg@alice:~$ I'm not sure the quickest way to get a list of build-deps, sorry! It does seem like a transitional package would be the standard way to solve this problem, and not a huge pain to do. We've handled much worse transitions. Or is it because it's always been this way, and there's documentation out there that might get out of date? The documentation would survive with a transitional package for one release of debian anyway, and at some point we need to prioritize consistency for new users over stability of unmaintained documentation. if someone is reading a 4-year-old unmaintained tutorial on debugging in debian they're probably not getting the most helpful information anyway. Or is there some other reason? I'm sorry to press on this, but "IRC says we shall not do this" sounds a lot like what people accuse debian of in its worst moments -- reflexive resistance to change, even when there's a well-motivated reason and a transition plan available for a concrete improvement, even a minor one like this. I'm really in the dark here. If there are other reasons, i'd like to know them. Thanks for all your work in maintaining such a critical part of debian! Regards, --dkg signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On Wed 2020-03-11 21:42:43 +0100, Aurelien Jarno wrote: >> Every other debug symbol package in debian is named $foo-dbgsym. libc6 >> seems to be the exception. > > Well libc6-dbg is not a standard dbgsym package: > - It is a dependency for other packages > - It is a build-dependency for other source packages > - It is not an automatic debug package (ie using debhelper) as we need > to strip libpthread.so and crt*.o differently. This means that the > resulting package do not have the same properties. Thanks for outlining these differences. I expected that it would indeed be different from others due to the unique position of libc, but i didn't know the details. >> Can we please rename this package (along with a transitional package to >> help folks upgrade from libc6-dbg) and set up an appropriate Provides: >> at least? > > With all the above said, I am not sure it's something we can do. However > I don't know who can actually answer that question. What about just adding a Provides: libc6-dbgsym to the package? That should make it findable at least, for people who are now used to the convention that foo's debug symbols are in foo-dbgsym. --dkg signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
Package: libc6-dbg Version: 2.29-10 Every other debug symbol package in debian is named $foo-dbgsym. libc6 seems to be the exception. Can we please rename this package (along with a transitional package to help folks upgrade from libc6-dbg) and set up an appropriate Provides: at least? This can be a stumbling block for people trying to get software development work done on debian, as evidenced by me screwing up over here: https://lists.debian.org/debian-powerpc/2020/03/msg00029.html --dkg signature.asc Description: PGP signature
Bug#844420: [fweimer at redhat dot com] [Bug network/20826] posix/tst-getaddrinfo5 fails on hosts without network access
Control: tags -1 patch Florian Weimer posted a patch to address network build problems for glibc upstream making it not-a-failure when building without network access: --- 2017-11-13 Florian Weimer [BZ #20826] Turn posix/tst-getaddrinfo5 into xtest due to Internet requirement. * posix/Makefile (tests): Remove tst-getaddrinfo5. (xtests): Add tst-getaddrinfo5. diff --git a/posix/Makefile b/posix/Makefile index 532f2c73c5..8b3632a3ba 100644 --- a/posix/Makefile +++ b/posix/Makefile @@ -91,7 +91,7 @@ tests := test-errno tstgetopt testfnm runtests runptests \ bug-getopt1 bug-getopt2 bug-getopt3 bug-getopt4 \ bug-getopt5 tst-getopt_long1 bug-regex34 bug-regex35 \ tst-pathconf tst-getaddrinfo4 tst-rxspencer-no-utf8 \ - tst-fnmatch3 bug-regex36 tst-getaddrinfo5 \ + tst-fnmatch3 bug-regex36 \ tst-posix_spawn-fd tst-posix_spawn-setsid \ tst-posix_fadvise tst-posix_fadvise64 \ tst-sysconf-empty-chroot tst-glob_symlinks tst-fexecve \ @@ -99,7 +99,7 @@ tests := test-errno tstgetopt testfnm runtests runptests \ tests-internal := bug-regex5 bug-regex20 bug-regex33 \ tst-rfc3484 tst-rfc3484-2 tst-rfc3484-3 \ tst-glob_lstat_compat -xtests := bug-ga2 +xtests := bug-ga2 tst-getaddrinfo5 ifeq (yes,$(build-shared)) test-srcs := globtest tests += wordexp-test tst-exec tst-spawn tst-spawn2 tst-spawn3 --- Begin Message --- https://sourceware.org/bugzilla/show_bug.cgi?id=20826 Florian Weimer changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-13 Assignee|unassigned at sourceware dot org |fweimer at redhat dot com Summary|Tests fail on hosts without |posix/tst-getaddrinfo5 |network access |fails on hosts without ||network access Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.--- End Message --- --- Begin Message --- https://sourceware.org/bugzilla/show_bug.cgi?id=20826 --- Comment #4 from Florian Weimer --- I posted a different patch: https://sourceware.org/ml/libc-alpha/2017-11/msg00395.html -- You are receiving this mail because: You are on the CC list for the bug.--- End Message ---
Bug#548842: libc6: alignment error in /lib/ld-linux.so.3 on armel
found 548842 2.10.1-0exp1 thanks On 09/28/2009 11:34 PM, Daniel Kahn Gillmor wrote: > Version: 2.9-25 I tried upgrading libc6 on the machine that was experiencing this, and it didn't improve. I'm still seeing the alignment error during the dynamic linking step when i launch alsaplayer using 2.10.1-0exp1 from experimental: Program received signal SIGBUS, Bus error. elf_machine_rel (scope=0x4001e1a0, reloc_mode=, consider_profiling=0) at ../ports/sysdeps/arm/dl-machine.h:429 429 ../ports/sysdeps/arm/dl-machine.h: No such file or directory. in ../ports/sysdeps/arm/dl-machine.h Current language: auto; currently c (gdb) bt #0 elf_machine_rel (scope=0x4001e1a0, reloc_mode=, consider_profiling=0) at ../ports/sysdeps/arm/dl-machine.h:429 #1 elf_dynamic_do_rel (scope=0x4001e1a0, reloc_mode=, consider_profiling=0) at do-rel.h:120 #2 _dl_relocate_object (scope=0x4001e1a0, reloc_mode=, consider_profiling=0) at dl-reloc.c:268 #3 0x40003a30 in dl_main (phdr=0x8034, phnum=8, user_entry=0xbed9057c) at rtld.c:2229 #4 0x40015418 in _dl_sysdep_start (start_argptr=, dl_main=0x40002248 ) at ../elf/dl-sysdep.c:243 #5 0x4ce8 in _dl_start_final (arg=0xbed90870, info=0xbed905f8) at rtld.c:333 #6 0x4f80 in _dl_start (arg=0xbed90870) at rtld.c:561 #7 0x47f0 in _start () from /lib/ld-linux.so.3 #8 0x47f0 in _start () from /lib/ld-linux.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) fwiw, here's the contents of /proc/cpuinfo on the host in question: Processor : XScale-IXP42x Family rev 1 (v5l) BogoMIPS: 266.24 Features: swp half thumb fastmult edsp CPU implementer : 0x69 CPU architecture: 5TE CPU variant : 0x0 CPU part: 0x41f CPU revision: 1 Hardware: Linksys NSLU2 Revision: Serial : hth, --dkg signature.asc Description: OpenPGP digital signature
Bug#548842: libc6: alignment error in /lib/ld-linux.so.3 on armel
Package: libc6 Version: 2.9-25 Severity: normal I'm running alsaplayer on an armel platform, using the -text frontend and the -alsa output. I've configured my armel machine to send a SIGBUS to any process which makes an alignment error by doing this: echo 5 > /proc/cpu/alignment when i launch the player (compiled with debug symbols), even before it gets to main() i get the SIGBUS. Here's the backtrace i see with libc6-dbg installed: (gdb) bt #0 elf_machine_rel (scope=0x4001e1a0, lazy=1, consider_profiling=0) at ../ports/sysdeps/arm/dl-machine.h:429 #1 elf_dynamic_do_rel (scope=0x4001e1a0, lazy=1, consider_profiling=0) at do-rel.h:120 #2 _dl_relocate_object (scope=0x4001e1a0, lazy=1, consider_profiling=0) at dl-reloc.c:266 #3 0x400039bc in dl_main (phdr=0x8034, phnum=8, user_entry=0xbe98257c) at rtld.c:2231 #4 0x40015110 in _dl_sysdep_start (start_argptr=, dl_main=0x400021d8 ) at ../elf/dl-sysdep.c:239 #5 0x4cd0 in _dl_start_final (arg=0xbe982870, info=0xbe9825f8) at rtld.c:332 #6 0x4f68 in _dl_start (arg=0xbe982870) at rtld.c:560 #7 0x47f0 in _start () from /lib/ld-linux.so.3 #8 0x47f0 in _start () from /lib/ld-linux.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) that last line is just: *reloc_addr += value but reloc_addr is optimized out. unfortunately, rebuilding packages (esp. large packages like libc6) takes a long time on machines like this (it's an NSLU2, 266Mhz with 32MB RAM), so i haven't had a chance to debug further. People interested in this bug might also be interested in discussion from http://bugs.debian.org/397616 . for examples of potential dangers of undetected memory alignment failures, see http://bugs.debian.org/548815 -- hopefully alignment failures in libc6 won't cause higher-level trouble the way they do with some media codecs. I also asked for discussion in general about alignment issues on armel: http://lists.debian.org/debian-arm/2009/09/msg00109.html Let me know if i can provide more debugging help on this. --dkg -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.30-1-ixp4xx Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.9-25 GNU C Library: Binaries ii libgcc1 1:4.4.1-1 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy pn glibc-doc (no description available) ii locales 2.9-25 GNU C Library: National Language ( -- debconf information: * glibc/restart-services: cron glibc/disable-screensaver: glibc/restart-failed: glibc/upgrade: true -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
