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

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 res

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

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

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

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 cou

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

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'

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

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

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

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)

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

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

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 ex

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

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

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

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 hav

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

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

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

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 Deb

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

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 particul

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

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 e

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

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

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

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 en_US.ISO-8859-1

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 e

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >