Bug#868654: Combining Unicode Mark-Nonspacing are classified as [:punct:]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=31149 I've just reported the bug upstream, as nothing has been done since more than 6 years! -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work:

Bug#1054487: manpages-dev: mtrace(3): LD_PRELOAD=libc_malloc_debug.so is needed

Control: reassign -1 manpages-dev 6.03-2 Control: retitle -1 manpages-dev: mtrace(3): LD_PRELOAD=libc_malloc_debug.so is needed Control: tags -1 upstream I can also reproduce the issue on a Red Hat machine with glibc 2.34, but this is actually an error in the man page: one now needs to preload

Bug#1054487: libc6: mtrace doesn't produce any result

Control: retitle -1 libc6: mtrace doesn't produce any result Control: found -1 2.36-9+deb12u3 On 2023-10-24 14:07:10 +0200, Vincent Lefevre wrote: > Even when MALLOC_TRACE is set, mtrace() doesn't produce any result. > > I've tested the example given in the mtrace(3) man page, and the

Bug#1054487: libc6:amd64: mtrace doesn't produce any result

Package: libc6 Version: 2.37-12 Severity: normal Even when MALLOC_TRACE is set, mtrace() doesn't produce any result. I've tested the example given in the mtrace(3) man page, and the /tmp/t file is not created. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

Cc'ing Axel Beckert, who maintains screen. On 2023-01-03 02:28:14 +0100, Vincent Lefevre wrote: > On 2023-01-02 23:08:39 +0100, Aurelien Jarno wrote: > > This U+1FAF6 character is new in Unicode 14, which is supported starting > > with glibc 2.35. Older glibc does not know about

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

On 2023-01-02 23:08:39 +0100, Aurelien Jarno wrote: > This U+1FAF6 character is new in Unicode 14, which is supported starting > with glibc 2.35. Older glibc does not know about this character, causing > mutt to display it with '?'. With newer glibc mutt displays the > character. > > Now I am not

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

On 2023-01-02 19:27:28 +0100, Vincent Lefevre wrote: > Hmm... This also depends on the terminal. > > This problem (both step 2 and step 3) is reproducible with xterm, > rxvt and GNOME Terminal, but not mlterm. > > This might also be a terminal bug, but several terminals w

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

On 2023-01-02 19:08:17 +0100, Vincent Lefevre wrote: > > > Example to reproduce the issue with the U+1FAF6 HEART HANDS character > > > under Debian/unstable: > > > > > > 1. Run "screen" in a 80-column terminal. > > > > > >

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

On 2023-01-02 18:07:52 +0100, Sven Joachim wrote: > On 2023-01-02 16:34 +0100, Vincent Lefevre wrote: > > There is no such issue under bullseye (Debian 11.6), which also has > > GNU Screen 4.09.00, so the breakage appears to be due to libc6. > > Without having looked at the

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

Package: libc6 Version: 2.36-7 Severity: serious The new libc6 appears to have some change related to Unicode that yields display issues in screen 4.9.0-3, such as horizontal and/or vertical text shifting. A consequence of this text shifting is that in Mutt (in particular with arrow_cursor), one

Bug#884075: [Bug regex/11053] Wrong results with backreferences

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=29560 On 2022-09-05 19:37:18 -0500, Paul Eggert wrote: > It looks like my comment > was incorrect, > in that the two bugs are different bugs. glibc bug 11053 is

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

On 2022-08-04 10:23:42 +0200, Aurelien Jarno wrote: > On 2022-08-04 00:33, Vincent Lefevre wrote: > > On 2014-05-19 00:33:00 +0200, Aurelien Jarno wrote: > > > Until the C.UTF-8 locale is integrated directly into glibc instead of > > > being provide like a stan

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

On 2014-05-19 00:33:00 +0200, Aurelien Jarno wrote: > Until the C.UTF-8 locale is integrated directly into glibc instead of > being provide like a standard locale, it's not going to be something > easy to do. Well, on the upstream side, the C.UTF-8 locale is now provided, but the bug still

Bug#719590: libc6:amd64: C.UTF-8 locales should be regarded like C w.r.t. $LANGUAGE precedence

as they were in 2014 (this was the original bug report), + found in 2.33-8. On 2014-02-21 13:55:37 +0100, Vincent Lefevre wrote: > Control: tags -1 upstream > Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16621 > Control: found -1 2.18-1 > > Reported upstr

Bug#1006764: libc6: i18n causes deadlocks with malloc interposers like libasan (AddressSanitizer)

Package: libc6 Version: 2.33-7 Severity: normal Tags: upstream Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=27653 Affects: libasan6 This has been reported upstream, but let's give it more visibility (this could save hours of debugging...). In short, using

Bug#992568: glibc: inconsistency in NEWS.Debian.gz file for locales and locales-all

Source: glibc Version: 2.31-16 Severity: minor The NEWS.Debian.gz file for locales and locales-all packages contain: Please note that iconv still supports conversion to and from non UTF-8 charsets. For instance reading a file using an ISO-8859-15 charset can be done with: iconv

Bug#992500: locales: obsolete /etc/locale.alias settings after drop of non-UTF8 locales

On 2021-08-20 09:52:59 +0200, Aurelien Jarno wrote: > On 2021-08-19 14:22, Vincent Lefevre wrote: > > The /etc/locale.alias contains aliases to dropped locales, such as > > > > french fr_FR.ISO-8859-1 > > At this stage those locales haven't been dropped

Bug#992500: locales: obsolete /etc/locale.alias settings after drop of non-UTF8 locales

Package: locales Version: 2.31-16 Severity: normal The /etc/locale.alias contains aliases to dropped locales, such as french fr_FR.ISO-8859-1 Such lines should be removed, or maybe better, replaced to use the UTF-8 locales (such as fr_FR.utf8). -- System Information: Debian Release:

Bug#973647: libc-bin: iconv does not support C.UTF-8

On 2020-11-02 20:41:02 +0100, Vincent Lefevre wrote: > With en_US.utf8, no issues: > > $ export LC_ALL=en_US.utf8 > $ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT > a-b > > But with C.UTF-8, the character "─" is regarded as invalid: > > $ export LC_ALL=C.U

Bug#973647: libc-bin: iconv does not support C.UTF-8

Package: libc-bin Version: 2.31-4 Severity: normal With en_US.utf8, no issues: $ export LC_ALL=en_US.utf8 $ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT a-b But with C.UTF-8, the character "─" is regarded as invalid: $ export LC_ALL=C.UTF-8 $ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT

Bug#968260: libc6: breaks translations when changing the charset to ...//TRANSLIT

On 2020-08-13 15:13:18 +0200, Aurelien Jarno wrote: > On 2020-08-12 05:13, Vincent Lefevre wrote: > > Since the upgrade to 2.31-3, the translations are no longer working > > in Mutt. > > > > In my config, the charset gets automatically set to UTF-8//TRANSLIT > &

Bug#968260: libc6: breaks translations when changing the charset to ...//TRANSLIT

Package: libc6 Version: 2.31-3 Severity: important Since the upgrade to 2.31-3, the translations are no longer working in Mutt. In my config, the charset gets automatically set to UTF-8//TRANSLIT (possibly with something else instead of UTF-8). There is the same issue with ISO-8859-1//TRANSLIT,

Bug#960737: libc6: on the Unicode character U+1F928 and above, iswctype returns false for all properties

Package: libc6 Version: 2.30-8 Severity: normal On the Unicode character U+1F928 and above, iswctype returns false for all properties. It should have the graph, print and punct properties. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500,

Bug#959874: locales: default date format for en_DK and other en_* should be improved

On 2020-05-06 16:12:58 +0200, Aurelien Jarno wrote: > On 2020-05-06 13:52, Vincent Lefevre wrote: > > Package: locales > > Version: 2.30-5 > > Severity: wishlist > > > > I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when > > written with di

Bug#959874: locales: default date format for en_DK and other en_* should be improved

Package: locales Version: 2.30-5 Severity: wishlist I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when written with digits. But the default date format seems to be the same one as LC_TIME=C and should be improved. This has currently been done only for US: $ for i in $(locale -a |

Bug#905939: tzdata files can get corrupted via write to /etc/localtime

On 2018-08-13 00:57:47 +0200, Vincent Lefevre wrote: > > In summary I don't believe there is a bug in tzdata. The bug should be > > reassigned to the package wrongly changing /etc/localtime. > > I'll try to get information from the administrator of the machine > about

Bug#905939: tzdata files can get corrupted via write to /etc/localtime

On 2018-08-12 22:05:00 +0200, Aurelien Jarno wrote: > The switch to a symlink has been done so that systemd (#803144), and > recent desktop environments can work on Debian. On other distributions > /etc/timezone does not exist and the timezone configuration can be > checked by looking where the

Bug#905939: tzdata files can get corrupted via write to /etc/localtime

Package: tzdata Version: 2018e-0+deb9u1 Severity: important On a Debian 9 machine: patate:~> TZ=UTC date; TZ=UTC0 date Sun Aug 12 03:02:35 CEST 2018 Sun Aug 12 01:02:35 UTC 2018 The first line is based on the /usr/share/zoneinfo/UTC file according to strace, but this is wrong as CEST is not

Bug#903964: locales: buggy regexp in locales.postinst yields useless locales regeneration when locales-all is installed

On 2018-07-17 14:06:58 +0200, Vincent Lefevre wrote: > According to the dpkg-query(1) man page: > > Desired action: > u = Unknown > i = Install > h = Hold > r = Remove >

Bug#903964: locales: buggy regexp in locales.postinst yields useless locales regeneration when locales-all is installed

Package: locales Version: 2.27-5 Severity: normal When upgrading, I got the following: [...] Setting up locales (2.27-5) ... Generating locales (this might take a while)... aa_DJ.UTF-8... done aa_DJ.ISO-8859-1... done aa_ER.UTF-8... done [...] zu_ZA.UTF-8... done zu_ZA.ISO-8859-1...

Bug#499801: sprof doesn't work at all in lenny

Control: reassign -1 libc-dev-bin Control: found -1 2.27-3 Control: retitle -1 sprof doesn't work at all: _dl_open assertion failed (This bug is old, and libc6-dev was split in the mean time, with sprof now being in libc-dev-bin.) On 2009-07-26 15:54:31 -0400, James Y Knight wrote: > Also

libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer

Control: reassign -1 libc6 2.27-1 Control: retitle -1 libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer Control: severity -1 serious On 2018-03-05 14:10:56 +0100, Vincent Lefevre wrote: > cventin:~> cat tst.c > int main (void) > { > return 0; > } > cv

Bug#865429: libc6-dev-i386: gcc-multilib should not be recommended

On 2017-08-13 19:38:11 +0200, Aurelien Jarno wrote: > This is actually not correct. gcc-multilib is required even for > compiling with another gcc-X-mutilib compiler as it provides the > /usr/include/linux/asm symlink. I suppose you meant /usr/include/asm. > I'll therefore revert the change in

Bug#865429: libc6-dev-i386: gcc-multilib should not be recommended

Package: libc6-dev-i386 Version: 2.24-12 Severity: normal The libc6-dev-i386 package has: Recommends: gcc-multilib But recommended packages are installed by default, and the above "Recommends:" is too strong as gcc-multilib is not the only way to use libc6-dev-i386. The issue is that

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

On 2016-08-13 16:46:46 +0200, Aurelien Jarno wrote: > On 2016-08-13 04:23, Vincent Lefevre wrote: > > I was not suggesting not to return all addresses. But in case of error > > (which could just be a temporary network error, not necessarily due to > > a bug in the nameserver

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

On 2016-08-12 23:24:29 +0200, Aurelien Jarno wrote: > On 2016-08-12 12:15, Vincent Lefevre wrote: > > According to tcpdump output below, there is no truncation: the number > > of A's and 's (10 for each) match what "host keys.gnupg.net" > > gives. BTW,

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

On 2016-08-12 09:26:10 +0200, Aurelien Jarno wrote: > The libc does a first connection to the configured name server > (192.168.0.1) using UDP. Note the size of the packet, very close to > the 512 bytes limit without EDNS0 support. This very likely mean the > answer is marked as truncated (look at

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

On 2016-08-11 23:33:30 +0200, Vincent Lefevre wrote: [...] > I wondered whether this was a bug from gnupg, until I tried: > > zira:~> ping keys.gnupg.net > ping: keys.gnupg.net: Temporary failure in name resolution > zsh: exit 2 ping keys.gnupg.net > > which I alway

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

Package: libc6 Version: 2.23-4 Severity: normal I always get the folloing error on this machine: zira:~> gpg --keyserver-options verbose,debug --keyserver hkp://keys.gnupg.net --recv-key gpg: requesting key from hkp server keys.gnupg.net gpgkeys: curl version = GnuPG curl-shim

Re: segmentation fault on any code compiled by tcc with libc6 2.21-4

Control: retitle -1 tcc: segmentation fault on any code due to new binutils relocations Control: tags -1 upstream On 2015-12-15 17:14:54 +0100, Aurelien Jarno wrote: > Control: retitle -1: segmentation fault on any code due to new binutils > relocations There shouldn't be a ":" after -1. > I

segmentation fault on any code compiled by tcc with libc6 2.21-4

Control: retitle -1 segmentation fault on any code compiled by tcc with libc6 2.21-4 Cc to the glibc maintainers because the cause of the bug is due to some change in glibc. On 2015-12-15 09:35:04 +0100, Vincent Lefevre wrote: > Code compiled by tcc segfaults: > > ypig% cat conftest

Bug#799856: libc6: strftime doesn't honor the charmap

On 2015-10-01 22:37:43 +0200, Vincent Danjean wrote: > Le 23/09/2015 12:17, Vincent Lefevre a écrit : > > Package: libc6 > > Version: 2.19-22 > > Severity: normal > > > > strftime doesn't honor the charmap. The following shows that strftime > > yields

Bug#799856: libc6: strftime doesn't honor the charmap

Package: libc6 Version: 2.19-22 Severity: normal strftime doesn't honor the charmap. The following shows that strftime yields ISO-8859-1 characters while the charmap is UTF-8. $ locale LANG=POSIX LANGUAGE= LC_CTYPE=en_US.UTF-8 LC_NUMERIC="POSIX" LC_TIME=fr_FR LC_COLLATE=POSIX LC_MONETARY="POSIX"

Bug#724456: locales: regeneration of locales by locale-gen breaks programs; should be done in a temporary file

Control: found -1 2.13-38+deb7u7 On 2013-09-24 02:07:39 +0200, Vincent Lefevre wrote: The regeneration of all the locales by /usr/sbin/locale-gen is slow, so that it sometimes breaks programs. It currently removes the /usr/lib/locale/locale-archive file to rebuild it, and until the used

Bug#719590: libc6:amd64: C.UTF-8 locales should be regarded like C w.r.t. $LANGUAGE precedence

Control: tags -1 upstream Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16621 Control: found -1 2.18-1 Reported upstream at it still applies to 2.18. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog:

Bug#724456: locales: regeneration of locales by locale-gen breaks programs; should be done in a temporary file

Package: locales Version: 2.17-93 Severity: normal The regeneration of all the locales by /usr/sbin/locale-gen is slow, so that it sometimes breaks programs. It currently removes the /usr/lib/locale/locale-archive file to rebuild it, and until the used locales are available, various programs

Bug#720777: libc6-x32: /usr/local/libx32 (required by FHS) doesn't exist

Package: libc6-x32 Version: 2.17-92 Severity: normal The libc6-x32 package provides the /libx32 and /usr/libx32 directories, but the /usr/local/libx32 doesn't exist. The FHS[*] says: If directories /libqual or /usr/libqual exist, the equivalent directories must also exist in /usr/local.

Bug#720778: libc6-i386: /usr/local/lib32 (required by FHS) doesn't exist

Package: libc6-i386 Version: 2.17-92 Severity: normal The libc6-i386 package provides the /lib32 and /usr/lib32 directories, but the /usr/local/lib32 directory doesn't exist. The FHS[*] says: If directories /libqual or /usr/libqual exist, the equivalent directories must also exist in

Bug#720780: libc6:amd64: /usr/local/lib64 (required by FHS) doesn't exist

Package: libc6 Version: 2.17-92 Severity: normal The libc6:amd64 package provides the /lib64 directory, but the /usr/local/lib64 directory doesn't exist. The FHS[*] says: If directories /libqual or /usr/libqual exist, the equivalent directories must also exist in /usr/local.

Bug#719590: libc6:amd64: C.UTF-8 locales should be regarded like C w.r.t. $LANGUAGE precedence

Package: libc6 Version: 2.17-92 Severity: normal Scripts tend to use LC_ALL=C.UTF-8 instead of LC_ALL=C for UTF-8 support and to behave in a locale-independent manner. However $LANGUAGE is still taken into account by glibc: xvii% LANGUAGE=fr_FR LC_ALL=C.UTF-8 cp cp: opérande de fichier manquant

Bug#716775: Processed: Re: libc6:amd64: mismatch between strcasecmp and toupper/tolower in tr_TR.iso88599 locale

Control: severity 716775 normal On 2013-07-15 06:42:06 +, Debian Bug Tracking System wrote: # unstandardized, correct behavior unclear severity 716775 wishlist This is not true. It is partially standardized, and the glibc does not behave correctly on at least one case of specified

Bug#716775: libc6:amd64: mismatch between strcasecmp and toupper/tolower in tr_TR.iso88599 locale

Package: libc6 Version: 2.17-7 Severity: normal There is a mismatch between strcasecmp and toupper/tolower in the tr_TR.iso88599 locale: #include stdio.h #include stdlib.h #include locale.h #include ctype.h #include strings.h int main (void) { int i, j, k; char *infs[] = { INF, inf }; if

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

On 2013-03-05 17:36:20 -0800, Jonathan Nieder wrote: Does apt-get source libc6/unstable work? If it doesn't, then dget http://http.debian.net/debian/pool/main/e/eglibc/eglibc_2.13-38.dsc should do the trick. Yes, apt-get source libc6/unstable works. The problem is mentioned here:

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

On 2013-03-03 23:49:26 -0800, Jonathan Nieder wrote: Jonathan Nieder wrote: debdiff attached. Better debdiff attached. OK, but I don't know how to download the eglibc source: both apt-get source eglibc/unstable and apt-get source -t unstable eglibc download the experimental version. This

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

On 2013-03-03 16:33:45 -0800, Jonathan Nieder wrote: If someone prepares a backport of the fix for 2.13.y, would you like to test it? Yes, if this doesn't introduce dependency problems on unstable. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated

Bug#399904: gnupg: --list-keys hangs at ctrl-C

found 399904 2.13-37 thanks On 2006-11-23 09:39:23 +0100, Werner Koch wrote: I was able to duplicate this after some tries. strace shows that it hangs in futex(0xb7ea9880, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call) I can also reproduce this bug, with the same example. The

Bug#687545: libc6: Incorrect decimal printf output of tiny long double values on PowerPC

Package: libc6 Version: 2.13-35 Severity: normal The minimum positive long double value is not output correctly by printf with the decimal conversion specifiers (e, f, g) on PowerPC (where long double is implemented with a double-double arithmetic). See the testcase below. There may be the same

Bug#372544: fixed in eglibc 2.13-1

On 2011-12-09 22:34:30 +0100, Aurelien Jarno wrote: I'll try to write my own test suite (based on difficult cases and with the 4 rounding modes). Please open a new bug when it's done and if you find some more bugs. In the meanwhile, I guess it's better to trust upstream and consider this

Bug#372544: fixed in eglibc 2.13-1

On 2011-10-18 07:15:31 +0200, Aurelien Jarno wrote: I have reopened the bug, but tagged it moreinfo + unreproducible given fma() has been implemented in eglibc 2.13, and that the testcases you provided now pass correctly on at least i386 and amd64. Please provide some more details or

Bug#632798: libc6: broken LANGUAGE design

On 2011-07-07 18:46:38 -0500, Jonathan Nieder wrote: Vincent Lefevre wrote: Now, if LANGUAGE is set in /etc/default/locale, this change may not solve the problem due to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313317 Wow. The upstream discussion went nowhere fast. Have you

Bug#632798: libc6: broken LANGUAGE design

On 2011-07-07 19:30:38 -0500, Jonathan Nieder wrote: My settings come from the installation. /etc/default/locale was: # File generated by update-locale #LANG=en_US.UTF-8 LANGUAGE=en_US:en (I only added a LC_TIME=en_DK since, hoping it would be taken into account for the time

Bug#632798: libc6: broken LANGUAGE design

Hi Jonathan, On 2011-07-05 22:22:51 -0500, Jonathan Nieder wrote: 1. On my local machine, I could not reproduce the same effect. That's probably because no default locale is configured here. After making the default locale de_DE.UTF-8 using dpkg-reconfigure -plow locales,

Bug#632795: glibc-doc-reference: Information about LANGUAGE is incorrect

Package: glibc-doc-reference Version: 2.13-1 Severity: normal The libc manual (libc.info.gz) says: 8.2.1.6 User influence on `gettext' [...] The LOCALE component is computed based on the category used. Just like for the `setlocale' function here comes the user selection into the

Bug#632798: libc6: broken LANGUAGE design

Package: libc6 Version: 2.13-10 Severity: normal The current LANGUAGE design is broken. Here an example: ypig% locale LANG=POSIX LANGUAGE= LC_CTYPE=en_US.ISO8859-1 LC_NUMERIC=POSIX LC_TIME=en_DK LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=fr_FR LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX

Bug#591334: Processed: [bts-link] source package eglibc

On 2011-05-23 18:12:28 +, Debian Bug Tracking System wrote: tags 591334 + upstream wontfix Bug #591334 [libc6] libc6: LANGUAGE not taken into account unless LC_MESSAGES is set Added tag(s) wontfix. [...] I agree with the reason given by upstream, but this is not the behavior described

Bug#612000: libc6: please postinst symlink /usr/local/lib64 - /usr/local/lib for consistency with /, and /usr ones

On 2011-02-04 10:09:51 -0500, Yaroslav Halchenko wrote: Without /usr/local/lib64 symlink to /usr/local/lib many local installations of upstream projects (not that I am encouraging such cruel activity) would install into /usr/local/lib64 on amd64 systems. Since symlink is not available, install

Bug#591334: libc6: LANGUAGE not taken into account unless LC_MESSAGES is set

On 2010-09-14 15:42:15 +0200, Aurelien Jarno wrote: It's most probably a documentation issue, given this behaviour is actually wanted, according to this changelog entry: | 2001-01-02 Ulrich Drepper drep...@redhat.com | | * intl/dcigettext.c (guess_category_value): Rewrite so that

Bug#591334: libc6: LANGUAGE not taken into account unless LC_MESSAGES is set

On 2010-09-14 17:31:49 +0200, Aurelien Jarno wrote: From what I understand both LC_CTYPE and LC_MESSAGES should not be set to the C locale (or POSIX one). It seems the goal is to make sure the translated messages could be displayed correctly, which would not be the case otherwise. I don't

Bug#593361: glibc-doc-reference: The manual is obsolete (for version 2.8 whereas Debian has libc 2.11)

Package: glibc-doc-reference Version: 2.11.1-1 Severity: normal The manual is obsolete. It is said: This is Edition 0.12, last updated 2007-10-27, of `The GNU C Library Reference Manual', for Version 2.8 of the GNU C Library. But the current libc version in Debian is 2.11. For instance,

Bug#593361: glibc-doc-reference: The manual is obsolete (for version 2.8 whereas Debian has libc 2.11)

On 2010-08-17 19:20:30 +0200, Aurelien Jarno wrote: This is the upstream manual from glibc 2.11, even if it said the contrary. Marking the bug as wontfix. OK, it's quite surprising that the developers don't update the manual at the same time they change the API! -- Vincent Lefèvre

Bug#591334: libc6: LANGUAGE not taken into account unless LC_MESSAGES is set

Package: libc6 Version: 2.11.2-2 Severity: normal The LANGUAGE environment variable isn't taken into account for translations, unless LC_MESSAGES is set. Here's an example: ypig% unset LC_MESSAGES ypig% LANGUAGE=fr_FR:fr cp cp: missing file operand Try `cp --help' for more information. ypig%

Bug#591334: libc6: LANGUAGE not taken into account unless LC_MESSAGES is set

tags 591334 upstream forwarded 591334 http://sourceware.org/bugzilla/show_bug.cgi?id=11869 thanks -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project

Bug#591334: libc6: LANGUAGE not taken into account unless LC_MESSAGES is set

It could be a documentation bug[*], but I'm not sure since Debian scripts assume that LANGUAGE can be used alone. For instance, the /etc/default/locale file generated by Debian contains: # File generated by update-locale #LANG=en_US.UTF-8 LANGUAGE=en_US:en [*]

Bug#586883: libc6: printf doesn't return a negative value in case of output error

Package: libc6 Version: 2.11.2-1 Severity: normal For fprintf (thus printf), the C standard says: The fprintf function returns the number of characters transmitted, or a negative value if an output or encoding error occurred. But in glibc, printf doesn't return a negative value in case of

Bug#586883: libc6: printf doesn't return a negative value in case of output error

forwarded 586883 http://sourceware.org/bugzilla/show_bug.cgi?id=11741 thanks -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To

Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported

Package: libc6-dev Version: 2.10.2-8 Severity: minor The INTMAX_MAX definition in /usr/include/stdint.h yields build failure in 32-bit C90 mode (x86_64 machines with the -m32 gcc switch and x86 machines). $ cat intmax-test.c #include stdint.h int main (void) { intmax_t x; x = INTMAX_MAX;

Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported

On 2010-05-22 21:36:14 +, Clint Adams wrote: Is this patch what you want? No, that would be incorrect, as when __WORDSIZE isn't 64, /usr/include/stdint.h defines: __extension__ typedef long long int intmax_t; __extension__ typedef unsigned long long int uintmax_t; i.e. intmax_t

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-21 16:14:49 +0100, Aurelien Jarno wrote: On Wed, Mar 17, 2010 at 11:29:00AM +0100, Vincent Lefevre wrote: It may be optimized, but completely buggy. For instance, on 1e22, sincos returns 0.46261304076460174617 for the sine instead of -0.85220084976718879499 (correctly rounded

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-21 20:55:01 +0100, Aurelien Jarno wrote: On Sun, Mar 21, 2010 at 04:30:36PM +0100, Vincent Lefevre wrote: Actually the sincos() function uses the x87 FPU (fsincos instruction), so that's not surprising that you get the same result. That just means that the precision

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote: On amd64, only sincos has an optimized version, It may be optimized, but completely buggy. For instance, on 1e22, sincos returns 0.46261304076460174617 for the sine instead of -0.85220084976718879499 (correctly rounded value). Even the sign is

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-06 11:42:51 +0100, Jerome Vizcaino wrote: After many tests and research I've come to the conclusion that the float variants of sin/cos (and maybe others) are anormaly slow Debian amd64. Note that on amd64, sin and cos may be slow, but at least they are mostly correct (in rounding to

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-17 13:41:04 +0100, Giacomo A. Catenazzi wrote: On 17.03.2010 11:29, Vincent Lefevre wrote: On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote: On amd64, only sincos has an optimized version, It may be optimized, but completely buggy. For instance, on 1e22, sincos returns

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-17 17:14:37 +0100, Giacomo A. Catenazzi wrote: From C standard (not really the standard, but the draft n1256: 5.2.4.2.2, point 5): : The accuracy of the floating-point operations (+, -, *, /) and of : the library functions in math.h and complex.h that return : floating-point

Bug#572746: libm: sinf/cosf performance is awful on amd64

On 2010-03-17 19:31:16 +0100, Jerome Vizcaino wrote: I do not complain about the sin/cos performance but only on the float variants. OK. I haven't looked at the code, but if sinf() simply calls sin(), this is suboptimal and there would be room for performance boost without sacrifying accuracy.

Bug#493231: locale names are not in alphabetical order in locales.postinst

Package: locales Version: 2.7-13 Severity: minor It seems that the locale name are normally in alphabetical order, but this is not the case for the following one. From the locales.postinst file: ar_YE.UTF-8 UTF-8 ar_YE ISO-8859-6 az_AZ.UTF-8 UTF-8 as_IN.UTF-8 UTF-8 ast_ES.UTF-8 UTF-8 ast_ES

Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

On 2007-12-25 21:38:48 +, Colin Watson wrote: I was under the impression that it was conventional even if not required to reserve host zero in a given subnet to identify the network itself, to avoid confusion of networks with hosts. I thought for this reason 1.0.0.0 could be detected as

Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

On 2007-12-24 21:48:18 +, Colin Watson wrote: On Mon, Dec 24, 2007 at 05:01:28PM +0100, Pierre Habouzit wrote: On Mon, Dec 24, 2007 at 03:37:39PM +, Colin Watson wrote: Have you considered asking your router vendor for a firmware upgrade? It sounds like a straightforward bug in

Bug#448723: libc6: strtod(-0, 0) returns +0.0 instead of -0.0

Package: libc6 Version: 2.6.1-6 Severity: normal In new versions of libc6, strtod(-0, 0) returns +0.0 instead of -0.0 (this bug isn't present in etch). Discussion: https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tplsource=Llistname=austin-group-lid=11150

Bug#438191: tzdata: /etc/timezone changed from Europe/Paris to User defined

Package: tzdata Version: 2007f-10 Severity: serious Justification: Policy 10.7.3 I've upgraded tzdata from 2007f-9 to 2007f-10, and the contents of /etc/timezone changed from Europe/Paris to User defined. This change is incorrect and can affect some software. For instance, /etc/init.d/cupsys

Bug#372544: libc6-dev: fma() is incorrect (inaccurate), not conform to C99

Note: this is upstream bug 3268: http://sourceware.org/bugzilla/show_bug.cgi?id=3268 -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Bug#372544: libc6-dev: fma() is incorrect (inaccurate), not conform to C99

On 2006-06-10 03:11:51 +0200, Vincent Lefevre wrote: The cause is that fma() is implemented on the x86 with (x * y) + z. The ISO C99 standard requires: The fma functions compute (x × y) + z, rounded as one ternary operation: they compute the value (as if) to infinite precision

Bug#415417: libc6: INF not accepted by strtod in Turkish locales (tr_TR.iso88599)

Package: libc6 Version: 2.3.6.ds1-13 Severity: normal The ISO C standard requires INF to be accepted by strtod: -- one of INF or INFINITY, ignoring case But in Turkish locales (LC_ALL=tr_TR.iso88599), where the lowercase 'I' is the dotless 'i', INF (or similar) is not recognized as the

Bug#404433: libc6: The locale -a command should output data in the current charmap/codeset

Package: libc6 Version: 2.3.6.ds1-9 Severity: normal On this machine, there's a locale called français, but in a UTF-8 environment, locale -a doesn't output the non-ASCII character in UTF-8: vin:~ locale charmap UTF-8 vin:~ locale -a | grep fran | od -Ax -txC -v 00 66 72 61 6e e7 61 69 73

Bug#395177: libc6: default library search path is inconsistent with gcc

On 2006-10-27 10:33:53 +0200, Gabor Gombas wrote: On Wed, Oct 25, 2006 at 02:37:04PM +0200, Vincent Lefevre wrote: 5. Run it. You should get: GMP . Library: 4.2.1 - Header: 4.2.17 This means the soname of gmp 4.2.1 and 4.2.17 is the same (or you'd have got an error while

Bug#395177: libc6: default library search path is inconsistent with gcc

On 2006-10-27 14:09:59 +0200, Gabor Gombas wrote: On Fri, Oct 27, 2006 at 11:25:51AM +0200, Vincent Lefevre wrote: Not necessarily. The soname isn't defined in the header file, is it? (At compile time, it seems that the library was also 4.2.1, because I get the same problem when using

Bug#395177: libc6: default library search path is inconsistent with gcc

Package: libc6 Version: 2.3.6.ds1-7 Severity: normal (Not sure if this is a bug in libc6 or binutils or another package; I first thought it was a bug in gcc, but a gcc developer said no: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29588.) gcc has /usr/local/include in its default search path,

Bug#295680: closed by Bastian Blank [EMAIL PROTECTED] (Bug#295680: fixed in linux-2.6 2.6.17-3)

On 2006-07-13 07:49:05 -0700, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #295680: libc6: getgrname returns a result that doesn't belong to /etc/group, which was filed against the libc6 package. It has been closed by Bastian Blank [EMAIL

Bug#372544: libc6-dev: fma() is incorrect (inaccurate), not conform to C99

Package: libc6-dev Version: 2.3.6-15 Severity: normal The fma() function is incorrect. For instance (this example is based on one given in the ieee754r mailing-list): #include stdio.h #include stdlib.h #include float.h #include math.h int main (void) { double eps, e2, f, x, z; eps =

Bug#324075: libc6: putwchar() returns WEOF without setting errno to EILSEQ

Package: libc6 Version: 2.3.5-4 Severity: normal The following program shows that putwchar() can return WEOF with errno = 0, though it should have set it to EILSEQ (see the ISO C standard, and it is explicitly say in the putwchar(3) man page). It should be run with LC_CTYPE=tr_TR.UTF-8; in this

Bug#321580: locales: installation fails because of [EMAIL PROTECTED]

On 2005-08-08 22:00:56 +0200, Denis Barbier wrote: So the problem here is that a locale listed in /etc/locale.gen is not valid. There are several possible causes: a. This locale was previously listed in /usr/share/i18n/SUPPORTED, but has been dropped. b. Admin made a typo when

  1   2   >