Bug#285368: mv segfaults
GOTO Masanori wrote: [UPGRADE] libc6 2.3.2.ds1-18 - 2.3.2.ds1-19 First of all mv segfaults. Well it did. System (possibly just X) hung-up, rebooted now mv seems OK. Not much information, I'm sorry. However I'm also getting this problem with rsync (which wasn't upgraded): /usr/bin/rsync: relocation error: /usr/bin/rsync: symbol ut, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Please show us your architecture. If your architecture is i386, it may be hardware problem. Yes, i386. AMD XP2000 512M K7S5A. Hardware? Interesting. I reverted back to libc6 2.3.2.ds1-18 and problem went away. Except now grep fails. So I'll work on the assumption it could be hardware. Appologies for consuming your bandwidth. Dick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284137: locale -a reports misleading values for UTF-8 locales
[EMAIL PROTECTED] (2004-12-13 at 1539.53 +0900): At Thu, 9 Dec 2004 00:03:09 +0100, Guillermo S. Romero [EMAIL PROTECTED] wrote: I think the problem is the system does not provide the function to answer en_GB.UTF-8 and en_GB.utf8 is the same locale. One way to check that two locales are same or not: [... script ...] (If you think it's worthwhile that glibc includes this shell script, please let me know) Well, it would help, but then the users have to be informed the tool exists, which is similar effort than inform the issue with locale -a output, or just which one is the prefered values (for example, man page pointing users to check /usr/share/i18n/SUPPORTED). Then, could you show us the best way to improve as you think? I think I and Denis already explained the difference between locale -a and X11 issue - now your turn. For example, locale man page having a FILES section where /usr/share/i18n/SUPPORTED is listed as best reference for variable values. Something like: FILES /usr/share/i18n/SUPPORTED List of supported values (and their associated encoding) for the LC_* environment variables in a Debian system. This representation is recommended over --all-locales one, due being the system wide supported values See attached patch, I hope it follows proper man page syntax. GSR --- locale.12004-12-13 16:47:56.0 +0100 +++ locale-patched.12004-12-13 17:02:46.0 +0100 @@ -242,6 +242,14 @@ .Vb 1 \The directory where locale data is stored. In default, /usr/lib/locale is used. .Ve +.SH FILES +.IX Header FILES +.TP +\fI/usr/share/i18n/SUPPORTED\fP +List of supported values (and their associated encoding) for the \fBLC_*\fR +environment variables in a Debian system. This representation is recommended +over \fB\-\-all\-locales\fR one, due being the system wide supported values +.PP .SH AUTHOR .IX Header AUTHOR \\fIlocale\fR was written by Ulrich Drepper for the \s-1GNU\s0 C Library.
Bug#284563: status of libunwind patches for ia64
Hi Matthias, On Sun, 12 Dec 2004 17:55:57 +0100, Matthias Klose [EMAIL PROTECTED] said: Matthias with the patch attached and an updated gcc-3.3 package, Matthias libunwind support for ia64 seems to work for me. I Matthias couldn't install any of the built packages. I'd like to Matthias ask people to install the test builds found at Matthias http://people.debian.org/~doko/glibc/ Matthias http://people.debian.org/~doko/gcc-3.3/ Matthias and stress test these packages. I wanted to try this but found that the gcc-3.3 has a libgcc1 package for hppa only. Is this intentional? I thought a new libgcc1 package for ia64 was needed so we pick up the libunwind built from the libunwind sources. Thanks, --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose [EMAIL PROTECTED] said: Matthias please get the libgcc1 package from the unstable Matthias distribution. I think I've got that one already (libgcc1 v3.4.3-2). Matthias It's currently built by the gcc-3.4 sources and includes Matthias the libunwind.so.7 shared library. The libunwind.so.7 in libgcc1 v3.4.3-2 appears to be built from the GCC sources. Is that what you had in mind? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
David Mosberger writes: I wanted to try this but found that the gcc-3.3 has a libgcc1 package for hppa only. Is this intentional? I thought a new libgcc1 package for ia64 was needed so we pick up the libunwind built from the libunwind sources. please get the libgcc1 package from the unstable distribution. It's currently built by the gcc-3.4 sources and includes the libunwind.so.7 shared library. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]