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

2020-08-13 Thread Vincent Lefevre
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

2020-08-11 Thread Vincent Lefevre
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

2020-05-15 Thread Vincent Lefevre
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

2020-05-06 Thread Vincent Lefevre
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

2020-05-06 Thread Vincent Lefevre
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

2018-08-13 Thread Vincent Lefevre
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

2018-08-12 Thread Vincent Lefevre
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

2018-08-11 Thread Vincent Lefevre
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

2018-07-17 Thread Vincent Lefevre
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

2018-07-17 Thread Vincent Lefevre
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

2018-05-23 Thread Vincent Lefevre
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

2018-03-05 Thread Vincent Lefevre
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

2017-08-13 Thread Vincent Lefevre
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

2017-06-21 Thread Vincent Lefevre
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

2016-08-13 Thread Vincent Lefevre
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

2016-08-12 Thread Vincent Lefevre
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

2016-08-12 Thread Vincent Lefevre
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

2016-08-11 Thread Vincent Lefevre
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

2016-08-11 Thread Vincent Lefevre
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

2015-12-15 Thread Vincent Lefevre
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

2015-12-15 Thread Vincent Lefevre
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

2015-10-01 Thread Vincent Lefevre
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

2015-09-23 Thread Vincent Lefevre
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

2015-01-29 Thread Vincent Lefevre
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

2014-02-21 Thread Vincent Lefevre
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

2013-09-23 Thread Vincent Lefevre
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

2013-08-25 Thread Vincent Lefevre
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

2013-08-25 Thread Vincent Lefevre
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

2013-08-25 Thread Vincent Lefevre
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

2013-08-13 Thread Vincent Lefevre
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

2013-07-15 Thread Vincent Lefevre
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

2013-07-12 Thread Vincent Lefevre
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

2013-03-06 Thread Vincent Lefevre
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

2013-03-05 Thread Vincent Lefevre
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

2013-03-03 Thread Vincent Lefevre
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

2012-12-09 Thread Vincent Lefevre
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

2012-09-13 Thread Vincent Lefevre
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

2011-12-09 Thread Vincent Lefevre
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

2011-10-18 Thread Vincent Lefevre
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

2011-07-07 Thread Vincent Lefevre
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

2011-07-07 Thread Vincent Lefevre
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

2011-07-06 Thread Vincent Lefevre
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

2011-07-05 Thread Vincent Lefevre
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

2011-07-05 Thread Vincent Lefevre
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

2011-07-05 Thread Vincent Lefevre
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

2011-02-11 Thread Vincent Lefevre
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

2010-09-14 Thread Vincent Lefevre
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

2010-09-14 Thread Vincent Lefevre
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)

2010-08-17 Thread Vincent Lefevre
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)

2010-08-17 Thread Vincent Lefevre
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

2010-08-02 Thread Vincent Lefevre
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

2010-08-02 Thread Vincent Lefevre
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

2010-08-02 Thread Vincent Lefevre
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

2010-06-23 Thread Vincent Lefevre
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

2010-06-23 Thread Vincent Lefevre
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

2010-05-22 Thread Vincent Lefevre
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

2010-05-22 Thread Vincent Lefevre
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

2010-03-21 Thread Vincent Lefevre
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

2010-03-21 Thread Vincent Lefevre
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

2010-03-17 Thread Vincent Lefevre
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

2010-03-17 Thread Vincent Lefevre
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

2010-03-17 Thread Vincent Lefevre
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

2010-03-17 Thread Vincent Lefevre
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

2010-03-17 Thread Vincent Lefevre
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

2008-08-01 Thread Vincent Lefevre
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

2007-12-25 Thread Vincent Lefevre
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

2007-12-24 Thread Vincent Lefevre
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

2007-10-31 Thread Vincent Lefevre
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

2007-08-15 Thread Vincent Lefevre
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

2007-06-14 Thread Vincent Lefevre
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

2007-05-21 Thread Vincent Lefevre
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)

2007-03-19 Thread Vincent Lefevre
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

2006-12-24 Thread Vincent Lefevre
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

2006-10-27 Thread Vincent Lefevre
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

2006-10-27 Thread Vincent Lefevre
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

2006-10-25 Thread Vincent Lefevre
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)

2006-07-13 Thread Vincent Lefevre
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

2006-06-09 Thread Vincent Lefevre
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

2005-08-19 Thread Vincent Lefevre
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]

2005-08-08 Thread Vincent Lefevre
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

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

2005-08-06 Thread Vincent Lefevre
Package: locales Version: 2.3.5-3 Severity: grave Justification: renders package unusable When I try to install the locales package (as an upgrade): Setting up locales (2.3.5-3) ... Generating locales (this might take a while)... en_DK.ISO-8859-1... done en_DK.UTF-8... done

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-30 Thread Vincent Lefevre
On 2005-06-28 19:37:56 +0300, Lars Wirzenius wrote: * getgrnam(3) is wrong to say that only /etc/group is used. I've filed a bug against it (#316102). OK, but this is #316117. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog:

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-20 Thread Vincent Lefevre
On 2005-06-20 13:16:27 +0200, GOMBAS Gabor wrote: On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote: Yes, there are several gids 100. In particular, slocate has gid 21, which is group fax under Debian. Then your NIS setup is _broken_ and Debian can do nothing about

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-20 Thread Vincent Lefevre
On 2005-06-20 14:11:56 +0200, GOMBAS Gabor wrote: The rules are: 1. If you want to support a certain operating system/distribution then don't put any groups/users in NIS that conflict with the default setup of that operating system/distribution. This means that Debian (in particular)

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-20 Thread Vincent Lefevre
On 2005-06-20 15:58:00 +0200, GOMBAS Gabor wrote: On Mon, Jun 20, 2005 at 02:54:38PM +0200, Vincent Lefevre wrote: This means that Debian (in particular) won't necessarily integrate nicely in a foreign network. That's true for Solaris, AIX, Mac OS X etc. as well. That's why I said

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-19 Thread Vincent Lefevre
On 2005-06-19 15:06:20 +0200, GOMBAS Gabor wrote: On Sun, Jun 19, 2005 at 02:53:16AM +0200, Vincent Lefevre wrote: Why doesn't Debian give the choice to the user when assigning a gid? And why does it have hardcoded gids? i.e. why aren't gids allocated at installation time? Most

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-18 Thread Vincent Lefevre
On 2005-06-18 23:55:13 +0200, GOMBAS Gabor wrote: No. But if you want to use NIS you have to be familiar with the consequences. If your local NIS policy allows having groups with IDs 1000 in NIS maps, then you should better be prepared that automatic group creation _will_ fail and you have to

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-17 Thread Vincent Lefevre
On 2005-06-17 02:03:08 +0300, Lars Wirzenius wrote: Thus, I think the Linux manual page saying that getgrnam uses /etc/group only is a bug. So, that would also make programs that rely on /etc/group being used buggy. IIRC, when I want to add a local group with addgroup, it checks first if it

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-17 Thread Vincent Lefevre
On 2005-06-17 18:36:17 +0200, GOMBAS Gabor wrote: On Fri, Jun 17, 2005 at 08:51:53AM +0200, Vincent Lefevre wrote: So, that would also make programs that rely on /etc/group being used buggy. IIRC, when I want to add a local group with addgroup, it checks first if it exists with getgrnam

Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-09 Thread Vincent Lefevre
On 2005-03-09 17:43:37 +0900, GOTO Masanori wrote: I fully agreed with Denis. From the technical view point, depending on the specific locale for generic purpose is a bad idea. I close this report. You haven't proposed anything to solve the problem! -- Vincent Lefèvre [EMAIL PROTECTED] -

Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-09 Thread Vincent Lefevre
On 2005-03-09 23:12:34 +0100, Denis Barbier wrote: Because there is no problem. You said in https://bugzilla.mozilla.org/show_bug.cgi?id=140814 that you have trouble when no locale is set and unfortunately POSIX date formats are brain-dead. If you want to have ISO 8601 date formats, you

Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-02 Thread Vincent Lefevre
Package: locales Version: 2.3.2.ds1-20 Severity: wishlist Many Debian machines don't have the en_DK locale installed. This locale is important to have ISO-8601 date format in applications that use the locales. So, it should be included by default in the generated locales. Alternatively, there

Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-02 Thread Vincent Lefevre
On 2005-03-02 22:11:05 +0100, Denis Barbier wrote: That does not make sense, applications do not need any locale to write dates in the formats described in ISO 8601. Using locales for this task will cause trouble (e.g. if LC_ALL is set) without benefit. Some developers (e.g. Mozilla's) don't

Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-02 Thread Vincent Lefevre
On 2005-03-03 08:06:48 +0100, Denis Barbier wrote: On Thu, Mar 03, 2005 at 02:15:38AM +0100, Vincent Lefevre wrote: Some developers (e.g. Mozilla's) don't want to display the date in anything other than the locales. Do you have an URL where this is discussed? https://bugzilla.mozilla.org

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-02-27 Thread Vincent Lefevre
On 2005-02-28 10:12:14 +0900, GOTO Masanori wrote: At Thu, 17 Feb 2005 13:37:25 +0100, Vincent Lefevre wrote: The getgrname(3) man page says: The getgrnam() function returns a pointer to a structure containing the group information from /etc/group for the entry that matches

Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-02-17 Thread Vincent Lefevre
Package: libc6 Version: 2.3.2.ds1-20 Severity: important The getgrname(3) man page says: The getgrnam() function returns a pointer to a structure containing the group information from /etc/group for the entry that matches the group name name. But here, the getgrname function returns a

Bug#216800: powerpc rint() bug

2005-01-06 Thread Vincent Lefevre
On 2004-12-09 17:54:20 +0100, Vincent Lefevre wrote: As there have been no feedback for this bug, I finally reported it upstream: http://sources.redhat.com/bugzilla/show_bug.cgi?id=602 and a fix has just been applied to CVS. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17

Bug#216800: powerpc rint() bug

2004-12-14 Thread Vincent Lefevre
Some additional information... Here's a part of the output of my program (on a PowerPC machine): ay:~/wd/src/fp ./nearestint 4.5 1 [...] Rounding toward -oo -4.5 -3.5 -2.5 -1.5 -0.5 0.5 1.5 2.5 3.5 4.5 casttoint-4-3-2-1 0 0 1 2 3

Bug#216800: powerpc rint() bug

2004-12-09 Thread Vincent Lefevre
As there have been no feedback for this bug, I finally reported it upstream: http://sources.redhat.com/bugzilla/show_bug.cgi?id=602 -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA -

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-15 Thread Vincent Lefevre
On 2004-05-16 00:09:28 +0900, GOTO Masanori wrote: 2.4 is starting the handover process to 2.6 with its role of stable version. So if you want to fix 2.4 kernel documents, please do. I posted a message to the linux-kernel mailing-list, but people there are quite ignorant about the C language.

  1   2   >