Bug#1078127: libc6: mcheck(NULL) fails even at the beginning of a program

Control: tags -1 upstream Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=32156 On 2024-09-09 11:42:43 +0200, Bernhard Übelacker wrote: [...] > In Bookworm and Trixie [3] the function mcheck always returns -1, > because "IS_IN (libc)" seems to be true at compile time. > > Re

Bug#1078128: libc6: mtrace() + malloc() do not generate data

Package: libc6 Version: 2.39-6 Severity: normal When testing the example given in the mtrace(3) man page, no data are generated: $ cat t_mtrace.c #include #include #include int main(void) { mtrace(); for (unsigned int j = 0; j < 2; j++) malloc(100);/* Never freed--a memor

Bug#1078127: libc6: mcheck(NULL) fails even at the beginning of a program

Package: libc6 Version: 2.39-6 Severity: normal The following program #include #include int main (void) { int r; r = mcheck (NULL); printf ("%d\n", r); return 0; } outputs -1, which is incorrect. It should have been 0. The glibc manual says It is too late to begin allocation chec

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: C

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 th

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) ma

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 p

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

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 woul

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 m

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 fixed

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 standard l

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 occurs.

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

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 LD_PRELOAD=/usr/lib/x86_64-

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 --from

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: 11

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 aiconv:

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, b

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, 'unstab

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

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 | gre

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 &

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 sym

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 UTC.

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... don

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 describ

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; > } &g

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 th

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 installi

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. BT

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 d

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 > > yield

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 t

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 - Web: 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 (e.g.

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 /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local. [*] h

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 /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local.

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 /lib or /usr/lib 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 S

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 beh

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 #include #include #include #include int main (void) { int i, j, k; char *infs[] = { "INF", "inf" }; if (setlocale (LC_ALL, "") == NULL)

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 versi

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 - Web: 100% accessible validated (X)HTML - Blog:

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. Th

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 pr

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

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 tes

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

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 upst

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", >/etc

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 describ

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="

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 p

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, inst

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 do

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 > | > | * intl/dcigettext.c (guess_category_value): Rewrite so that LANGUAGE > |

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 - Web: <

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, for

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" [*] http://bugs.debian.org/cgi-bin/

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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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% LANG

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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, em

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 ou

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#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 int main (void) { intmax_t x; x = INTMAX_MAX; return 0;

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 m

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.8522008497

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#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 and that return > : floating-point results is imp

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. Fo

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

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#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 ISO-8

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 b

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

On 2007-12-24 10:49:32 +, Colin Watson wrote: > I can't tell for sure from your strace (in future, use -s 1024 so that > buffers passed to system calls aren't truncated to quite such a short > length), but your diagnosis sounds right, and it doesn't sound like > OpenSSH is the appropriate place

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.tpl&source=L&listname=austin-group-l&id=11150 https://www.ope

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: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-

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 inf

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

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

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

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 th

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: .) gcc has /usr/local/include in its default search path, i

  1   2   >