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

[Vincent Lefevre]

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: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 the libc_malloc_debug.so library.

/usr/share/doc/libc6/NEWS.gz says for 2.34:

* Debugging features in malloc such as the MALLOC_CHECK_ environment variable
  (or the glibc.malloc.check tunable), mtrace() and mcheck() have now been
  disabled by default in the main C library.  Users looking to use these
  features now need to preload a new debugging DSO libc_malloc_debug.so to get
  this functionality back.

So in the example in the mtrace(3) man page

   $ cc -g t_mtrace.c -o t_mtrace
   $ export MALLOC_TRACE=/tmp/t
   $ ./t_mtrace
   $ mtrace ./t_mtrace $MALLOC_TRACE

the 3rd command should be changed to

   $ LD_PRELOAD=libc_malloc_debug.so ./t_mtrace

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

Control: retitle -1 libc6: mtrace doesn't produce any result
Control: found -1 2.36-9+deb12u3

On 2023-10-24 14:07:10 +0200, Vincent Lefevre wrote:
> Even when MALLOC_TRACE is set, mtrace() doesn't produce any result.
> 
> I've tested the example given in the mtrace(3) man page, and the
> /tmp/t file is not created.

Same issue on cfarm29.cfarm.net (ppc64le, Debian 12.2).

The example works fine on Debian 11.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6:amd64 depends on:
ii  libgcc-s1  13.2.0-5

Versions of packages libc6:amd64 recommends:
ii  libidn2-0  2.3.4-1+b1

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.82
ii  glibc-doc  2.37-12
ii  libc-l10n  2.37-12
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.37-12

-- debconf information:
* libraries/restart-without-asking: false
  glibc/kernel-not-supported:
  glibc/kernel-too-old:
* glibc/restart-services: ssh exim4 cups cron atd
  glibc/restart-failed:
  glibc/upgrade: true
  glibc/disable-screensaver:

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

Cc'ing Axel Beckert, who maintains screen.

On 2023-01-03 02:28:14 +0100, Vincent Lefevre wrote:
> On 2023-01-02 23:08:39 +0100, Aurelien Jarno wrote:
> > This U+1FAF6 character is new in Unicode 14, which is supported starting
> > with glibc 2.35. Older glibc does not know about this character, causing
> > mutt to display it with '?'. With newer glibc mutt displays the
> > character.
> > 
> > Now I am not sure it is a bug in glibc, it rather seems an issue with
> > screen. I can reproduce the shifts in both, stable and unstable, by
> > putting this char in a file and just running cat on the file.
> 
> I've look at the "screen" code, and it has a file encoding.c with
> some kind of table (intervals) of double-width characters, and it
> gives the URL of a script to regenerate these tables.
> 
> Since these tables depend on the Unicode version (which depends on
> the libc6 version), shouldn't the screen package have a versioned
> dependency on libc6?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 sure it is a bug in glibc, it rather seems an issue with
> screen. I can reproduce the shifts in both, stable and unstable, by
> putting this char in a file and just running cat on the file.

I've look at the "screen" code, and it has a file encoding.c with
some kind of table (intervals) of double-width characters, and it
gives the URL of a script to regenerate these tables.

Since these tables depend on the Unicode version (which depends on
the libc6 version), shouldn't the screen package have a versioned
dependency on libc6?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 would be
> affected by the same bug!

Forget this remark: without "screen", there is a small display issue
in mlterm. This appears to be related to the width of the character
(mlterm considers that it takes 1 column, contrary to the other
terminals).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.
> > >
> > > 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
> > >Result: line 10 is shifted 1 column to the right, and character "v"
> > >appears on the following line.
> > 
> > I failed to reproduce that step, the 'v' appears on the last column for
> > me.
> 
> Sorry, I did the test with my own version of Mutt. So, for this
> particular behavior at step 2, you need
> 
>   mutt -n -F /dev/null -f heart-hands.mbox
> 
> i.e. with the -n option so that the system-wide Muttrc configuration
> file is not read.

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 would be
affected by the same bug!

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 problem: this appears to be a rather bold
> conclusion.  There are also newer versions of mutt, ncurses and a few
> other libraries which mutt or screen depend upon that could be
> responsible.

I've tested with the same version of Mutt (from Git). However, indeed,
ncurses is different. I doubt that other libraries matter.

> > Example to reproduce the issue with the U+1FAF6 HEART HANDS character
> > under Debian/unstable:
> >
> > 1. Run "screen" in a 80-column terminal.
> >
> > 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
> >Result: line 10 is shifted 1 column to the right, and character "v"
> >appears on the following line.
> 
> I failed to reproduce that step, the 'v' appears on the last column for
> me.

Sorry, I did the test with my own version of Mutt. So, for this
particular behavior at step 2, you need

  mutt -n -F /dev/null -f heart-hands.mbox

i.e. with the -n option so that the system-wide Muttrc configuration
file is not read.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 may select a message
to be deleted, but a different message is actually deleted.

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.

If the change has been done on purpose, then there are missing
dependency relationships that should prevent the installation
of incompatible software until such software has been updated
to support this change.

Example to reproduce the issue with the U+1FAF6 HEART HANDS character
under Debian/unstable:

1. Run "screen" in a 80-column terminal.

2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
   Result: line 10 is shifted 1 column to the right, and character "v"
   appears on the following line.

3. Create a new Screen window and switch back to the original window.
   Result: messages 1 to 9 are shifted upward.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc-s1  12.2.0-12

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.3-1+b1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.81
ii  glibc-doc  2.36-7
ii  libc-l10n  2.36-7
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.36-7

-- debconf information:
  glibc/disable-screensaver:
* glibc/restart-services: postfix ssh cups cron atd
  glibc/kernel-too-old:
* libraries/restart-without-asking: false
  glibc/restart-failed:
  glibc/kernel-not-supported:
  glibc/upgrade: true

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


heart-hands.mbox
Description: application/mbox

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

[Vincent Lefevre]

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, but
> Debian bug 884075 is not fixed. Perhaps a better match for Debian bug 884075
> is glibc bug 10844.

Bug 10844 actually seems to be a different bug.
I've reported bug 29560 upstream concerning 1.

So there are 3 upstream bugs concerning bad results with backreferences
(but the regexp's are rather different is each case):

  https://sourceware.org/bugzilla/show_bug.cgi?id=10844
(ab*){1,9}\1

  https://sourceware.org/bugzilla/show_bug.cgi?id=17356
(.{0,1})(.{0,1})(.{0,1})\3\2\1

  https://sourceware.org/bugzilla/show_bug.cgi?id=29560
^(11+)\1+$|^1?$

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 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.
> 
> It is provided like a standard locale, but has not been integrated
> directly into glibc (like the built-in C locale), so it's expected that
> the bug stills occurs.

It seems that since upstream bug 17318 has been closed, upstream
won't do anything more concerning its integration (whatever this
means) and something special will be done to fix this bug (i.e.
upstream bug 16621). According to Florian Weimer, the main problem
(as opposed to the C locale) would be to handle aliases, and indeed,
while Debian currently provides only C.UTF-8, with glibc 2.35 C.utf8
and C.utf-8 also work as aliases and are also affected by this bug
(tested on an Ubuntu 22.04 LTS machine with libc6 2.35-0ubuntu3).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

Control: retitle -1 C.UTF-8 locales should be regarded like C w.r.t. $LANGUAGE 
precedence
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16621
Control: tags -1 - fixed-upstream
Control: found -1 - 2.33-8

The bug is actually not completely fixed. Resetting the metadata
as they were in 2014 (this was the original bug report), + found
in 2.33-8.

On 2014-02-21 13:55:37 +0100, Vincent Lefevre wrote:
> Control: tags -1 upstream
> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16621
> Control: found -1 2.18-1
> 
> Reported upstream at it still applies to 2.18.

and the upstream bug is still open.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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-linux-gnu/libasan.so.6
with some executables can make the executable hang.

Examples:

With

  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 inkscape

Thread 1 (Thread 0x7f07770c8bc0 (LWP 424733) "inkscape"):
#0  __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7f077dd21be8 
<_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, 
abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=false) 
at ../sysdeps/nptl/futex-internal.c:87
err = -512
op = 393
#1  0x7f077db3f148 in __GI___futex_abstimed_wait64 
(futex_word=futex_word@entry=0x7f077dd21be8 <_nl_state_lock+8>, 
expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:112
#2  0x7f077db37ad5 in __pthread_rwlock_wrlock_full64 (abstime=0x0, 
clockid=0, rwlock=0x7f077dd21be0 <_nl_state_lock>) at 
pthread_rwlock_common.c:829
private = 0
err = 
may_share_futex_used_flag = 
wpf = 
ready = false
r = 
result = 
#3  __GI___pthread_rwlock_wrlock (rwlock=0x7f077dd21be0 <_nl_state_lock>) at 
pthread_rwlock_wrlock.c:27
result = 
#4  0x7f077db8375e in set_binding_values (domainname=0x7f077b8be5b7 
"gspell-1", dirnamep=0x0, codesetp=0x7ffdaf37e428) at bindtextdom.c:91
__p = 
binding = 
modified = 
#5  0x7f077db83bd1 in set_binding_values (codesetp=0x7ffdaf37e428, 
dirnamep=0x0, domainname=) at bindtextdom.c:82
[...]

and with

  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 vlc

Thread 1 (Thread 0x7f2f9be09340 (LWP 424824) "vlc"):
#0  __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7f2f9c651be8 
<_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, 
abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=false) 
at ../sysdeps/nptl/futex-internal.c:87
clockbit = 
err = -512
op = 393
#1  0x7f2f9c675148 in __GI___futex_abstimed_wait64 
(futex_word=futex_word@entry=0x7f2f9c651be8 <_nl_state_lock+8>, 
expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:112
No locals.
#2  0x7f2f9c66dad5 in __pthread_rwlock_wrlock_full64 (abstime=0x0, 
clockid=0, rwlock=0x7f2f9c651be0 <_nl_state_lock>) at 
pthread_rwlock_common.c:829
private = 0
err = 
may_share_futex_used_flag = 
wpf = 
ready = false
r = 
may_share_futex_used_flag = 
r = 
done = 
wpf = 
ready = 
__value = 
prefer_writer = 
private = 
wf = 
err = 
w = 
w = 
private = 
err = 
w = 
wf = 
wf = 
__value = 
#3  __GI___pthread_rwlock_wrlock (rwlock=0x7f2f9c651be0 <_nl_state_lock>) at 
pthread_rwlock_wrlock.c:27
result = 
#4  0x7f2f9c4b375e in set_binding_values (domainname=0x7f2f9c2f666b "vlc", 
dirnamep=0x0, codesetp=0x7fff24056378) at bindtextdom.c:91
__p = 
binding = 
modified = 
[...]

and similarly with gnuplot:

Thread 1 (Thread 0x7fbcf39e4bc0 (LWP 424576) "gnuplot"):
#0  __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7fbcf8be8be8 
<_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, 
abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=false) 
at ../sysdeps/nptl/futex-internal.c:87
err = -512
op = 393
#1  0x7fbcf8c06148 in __GI___futex_abstimed_wait64 
(futex_word=futex_word@entry=0x7fbcf8be8be8 <_nl_state_lock+8>, 
expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:112
#2  0x7fbcf8bfead5 in __pthread_rwlock_wrlock_full64 (abstime=0x0, 
clockid=0, rwlock=0x7fbcf8be8be0 <_nl_state_lock>) at 
pthread_rwlock_common.c:829
private = 0
err = 
may_share_futex_used_flag = 
wpf = 
ready = false
r = 
result = 
#3  __GI___pthread_rwlock_wrlock (rwlock=0x7fbcf8be8be0 <_nl_state_lock>) at 
pthread_rwlock_wrlock.c:27
result = 
#4  0x7fbcf8a4a75e in set_binding_values (domainname=0x7fbcf7de4f51 
"gtk30-properties", dirnamep=0x7fff4f41f848, codesetp=0x0) at bindtextdom.c:91
__p = 
binding = 
modified = 
[...]

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 

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

[Vincent Lefevre]

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-code=ISO-8859-1 foobar.txt

There is a mismatch between ISO-8859-15 and ISO-8859-1.

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 from the locales
> package, they can't be chosen anymore in debconf, but they are still
> supported if they were configured, or they can still be configured
> manually by editing /etc/locales.gen. However, they have indeed been
> dropped from the locales-all package.

I don't understand what you mean. The locales-all package is
documented as containing *all* supported locales.

And with it, "french" is no longer supported:

zira:~> LC_ALL=french perl /dev/null
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "french",
LC_TIME = "en_DK.utf8",
LC_CTYPE = "C.UTF-8",
LC_CHARMAP = "UTF-8",
LC_COLLATE = "POSIX",
LANG = "POSIX"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("POSIX").

(no warning with glibc 2.31-13 packages).

> > Such lines should be removed, or maybe better, replaced to use
> > the UTF-8 locales (such as fr_FR.utf8).
> 
> It's probably better to just remove that file, as it has been marked as
> obsolete for more than 13 years. It's probably something to coordinate
> with upstream.

Agreed.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc-bin   2.31-16
ii  libc-l10n  2.31-16

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: C.UTF-8
* locales/locales_to_be_generated: All locales

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.UTF-8
> $ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT
> aiconv: illegal input sequence at position 1

Note that this is not related to the charset used by the file,
but the locale under which iconv runs. For instance, there is
no issue to convert a UTF-8 files under the C locale, but using
C.UTF-8 instead yields an error:

$ echo a─b | LC_ALL=C iconv -f utf-8 -t ascii//TRANSLIT
a-b
$ echo a─b | LC_ALL=C.UTF-8 iconv -f utf-8 -t ascii//TRANSLIT
aiconv: illegal input sequence at position 1

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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: illegal input sequence at position 1

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.31-4

Versions of packages libc-bin recommends:
ii  manpages  5.08-1

libc-bin suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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
> > (possibly with something else instead of UTF-8). There is the same
> > issue with ISO-8859-1//TRANSLIT, but not with UTF-8 or ISO-8859-1.
[...]
> Thanks for the reproducer, I have been able to identify the broken
> function, I have reported the bug upstream as BZ#26383. While it is
> clearly a regression, please note that adding //TRANSLIT to the charset
> doesn't bring anything, as transliteration is always enabled for gettext
> messages.

Thanks. In case, this was not clear, I hadn't added //TRANSLIT for
gettext messages, but for general output of mail messages in the
terminal (as transliteration is not enabled by default for such
output). But it appears that the "charset" variable is used for
anything related to the terminal (which makes sense for users who
set this variable to correct the charset obtained by default from
the environment).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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, but not with UTF-8 or ISO-8859-1.

Reverting to 2.31-2 solves the issue (at least with UTF-8//TRANSLIT).

I can reproduce the issue with:

  LC_MESSAGES=fr_FR /usr/bin/mutt -F muttrc foo

where the muttrc file contains:

set charset=UTF-8//TRANSLIT

or

set charset=ISO-8859-1//TRANSLIT

I get "To: foo@..." instead of "À : foo@...".

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.2.0-5

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
ii  glibc-doc  2.31-3
ii  libc-l10n  2.31-3
ii  locales2.31-3

-- debconf information:
  glibc/kernel-not-supported:
  glibc/disable-screensaver:
* glibc/restart-services: postfix cups cron atd
  glibc/kernel-too-old:
  glibc/upgrade: true
* libraries/restart-without-asking: false
  glibc/restart-failed:

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.1.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
ii  glibc-doc  2.30-8
ii  libc-l10n  2.30-8
ii  locales2.30-8

-- debconf information:
* glibc/restart-services: postfix cups cron atd
  glibc/upgrade: true
* libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
  glibc/kernel-too-old:
  glibc/restart-failed:

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 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:
> 
> Please note that the en_US change is controversial and likely going to
> be reverted. See https://sourceware.org/bugzilla/show_bug.cgi?id=25923

I'm not sure whether this is the same thing as this one focuses
on day/month ordering, but there's the place of the year (which
was actually the main thing I was thinking about).

> I guess the same argument will apply to other locales, ie that we should
> change things that have been like that for decades.

Concerning the year, there's also a lack of consistency in Canada:

$ for i in $(locale -a | grep _CA); do printf "%-20s" $i; LC_TIME=$i date; done
en_CA   Wed May  6 17:42:39 CEST 2020
en_CA.utf8  Wed May  6 17:42:39 CEST 2020
fr_CA   mercredi 6 mai 2020, 17:42:39 (UTC+0200)
fr_CA.utf8  mercredi 6 mai 2020, 17:42:39 (UTC+0200)
ik_CA   Qit Sup  6 17:42:39 CEST 2020
iu_CA   ᐱ ᒪᐃ  6 17:42:39 CEST 2020
shs_CA  Ske Ell  6 17:42:39 CEST 2020

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 | grep en_); do printf "%-20s" $i; LC_TIME=$i date; done
en_AG   Wed  6 May 13:46:50 CEST 2020
en_AU   Wed  6 May 13:46:50 CEST 2020
en_AU.utf8  Wed  6 May 13:46:50 CEST 2020
en_BW   Wed May  6 13:46:50 CEST 2020
en_BW.utf8  Wed May  6 13:46:50 CEST 2020
en_CA   Wed May  6 13:46:50 CEST 2020
en_CA.utf8  Wed May  6 13:46:50 CEST 2020
en_DK   Wed May  6 13:46:50 CEST 2020
en_DK.iso885915 Wed May  6 13:46:50 CEST 2020
en_DK.utf8  Wed May  6 13:46:50 CEST 2020
en_GB   Wed  6 May 13:46:50 CEST 2020
en_GB.iso885915 Wed  6 May 13:46:50 CEST 2020
en_GB.utf8  Wed  6 May 13:46:50 CEST 2020
en_HK   Wed May  6 13:46:50 CEST 2020
en_HK.utf8  Wed May  6 13:46:50 CEST 2020
en_IE   Wed May  6 13:46:50 CEST 2020
en_IE.utf8  Wed May  6 13:46:50 CEST 2020
en_IE@euro  Wed May  6 13:46:50 CEST 2020
en_IL   Wed May  6 13:46:50 CEST 2020
en_IN   Wed May  6 13:46:50 CEST 2020
en_NG   Wed May  6 13:46:50 CEST 2020
en_NZ   Wed May  6 13:46:50 CEST 2020
en_NZ.utf8  Wed May  6 13:46:50 CEST 2020
en_PH   Wed May  6 13:46:50 CEST 2020
en_PH.utf8  Wed May  6 13:46:50 CEST 2020
en_SC.utf8  Wed  6 May 13:46:50 CEST 2020
en_SG   Wed May  6 13:46:50 CEST 2020
en_SG.utf8  Wed May  6 13:46:50 CEST 2020
en_US   Wed 06 May 2020 01:46:50 PM CEST
en_US.iso885915 Wed 06 May 2020 01:46:50 PM CEST
en_US.utf8  Wed 06 May 2020 01:46:50 PM CEST
en_ZA   Wed May  6 13:46:50 CEST 2020
en_ZA.utf8  Wed May  6 13:46:50 CEST 2020
en_ZM   Wed  6 May 13:46:50 CEST 2020
en_ZW   Wed May  6 13:46:50 CEST 2020
en_ZW.utf8  Wed May  6 13:46:50 CEST 2020

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc-bin   2.30-5
ii  libc-l10n  2.30-5

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: None
* locales/locales_to_be_generated: All locales

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 this.

This came from configuration of ansible:

- name: Localtime
shell: cp /usr/share/zoneinfo/Europe/Paris /etc/localtime
when: ansible_date_time.tz != "CEST" and ansible_date_time.tz != "CET"

I don't know whether this is related to default configuration or
poor documentation. I've found something similar somewhere else:

https://github.com/scline/ansible-rancher/blob/master/roles/common/tasks/ntp.yml

- name: updating server timezone settings (not persistant)
  when: ansible_date_time.tz != "{{ server_timezone }}" 
  # Skip if already correct timezone
  shell: cp /usr/share/zoneinfo/{{ server_timezone }} /etc/localtime

also wrong.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 symlink points to.

OK, I've checked FHS 3.0, and it explicitly allows symbolic links
in /etc.

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 UTC. The file is:

-rw-r--r-- 1 root root 2971 2018-05-15 10:01:38 /usr/share/zoneinfo/UTC

which doesn't seem to be the original one. I assume that it got
corrupted via a write to /etc/localtime, but /etc/localtime is
a symlink to /usr/share/zoneinfo/Etc/UTC, which is itself a
symlink to /usr/share/zoneinfo/UTC.

Now, could the write to /etc/localtime be regarded as a bug?
Probably not, because /etc/localtime is a config file, and one
is allowed to write to config files under /etc.

In short, having a symlink from a file under /etc to a file from
a package does not seem to be correct.

BTW, on https://www.virtualmin.com/node/15246 someone mentioned
another issue with a symlink: "It's not really wise to make
/etc/localtime a symlink. That used to be the standard behavior for
Linux in the past, but then someone realized that /usr/share/zoneinfo
could be on a different volume that's not always mounted, and we
definitely don't want to be without /etc/localtime, [...]"

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-7-amd64 (SMP w/16 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.61

tzdata recommends no packages.

tzdata suggests no packages.

-- no debconf information

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

[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
> p = Purge
> 
>   Package status:
> n = Not-installed
> c = Config-files
> H = Half-installed
> U = Unpacked
> F = Half-configured
> W = Triggers-awaiting
> t = Triggers-pending
> i = Installed
> 
>   Error flags:
>  = (none)
> R = Reinst-required
> 
> so that it is testing the package status of locales-all. But during
> an upgrade, the actual status is "iU " (things may be different if
> packages are upgraded separately).
> 
> Shouldn't the desired action be tested instead, i.e. '^i'?

Well, actually this is probably incorrect. It could also be on hold.
And I'm not sure what "Desired action" means exactly. If locales-all
is marked for installation in dselect, will this be "i"? In such a
case, using "Desired action" is not possible; see:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840901

Perhaps a combination of flags of "Package status"...
'^.[UFWti]'?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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... done
Generation complete.
Setting up libbinutils:amd64 (2.31-1) ...
Setting up keyutils (1.5.9-9.3) ...
Setting up locales-all (2.27-5) ...
[...]

i.e. the locales are regenerated by locales.postinst, but then
/usr/lib/locale/locale-archive is removed by locales-all.postinst,
so that the regeneration of the locales takes time and is useless.

/var/lib/dpkg/info/locales.postinst contains:

# Update requested locales if locales-all is not installed
if dpkg-query -W -f='${db:Status-Abbrev}' locales-all 2>/dev/null | grep -q 
'^.i' ; then
echo "locales-all installed, skipping locales generation"
else
locale-gen
fi

I think that the '^.i' regexp is incorrect during an upgrade.

According to the dpkg-query(1) man page:

  Desired action:
u = Unknown
i = Install
h = Hold
r = Remove
p = Purge

  Package status:
n = Not-installed
c = Config-files
H = Half-installed
U = Unpacked
F = Half-configured
W = Triggers-awaiting
t = Triggers-pending
i = Installed

  Error flags:
 = (none)
R = Reinst-required

so that it is testing the package status of locales-all. But during
an upgrade, the actual status is "iU " (things may be different if
packages are upgraded separately).

Shouldn't the desired action be tested instead, i.e. '^i'?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.67
ii  libc-bin   2.27-5
ii  libc-l10n  2.27-5

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: All locales
* locales/default_environment_locale: None

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

[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 described in this bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=458861
> 
> sprof in lenny (libc 2.7-18) is currently completely non-functional due to
> that bug.
> 
> I tried applying that patch to debian's glibc, and while it applies cleanly,
> and solves the immediate issue, I then get:
> 
> Inconsistency detected by ld.so: dl-open.c: 652: _dl_open: Assertion
> `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

This bug is still there, now with this error. With updated line number:

Inconsistency detected by ld.so: dl-open.c: 641: _dl_open: Assertion 
`_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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;
> }
> cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
> cventin:~> ./tst
> AddressSanitizer:DEADLYSIGNAL
> =
> ==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc 
> 0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
> ==25032==The signal is caused by a WRITE memory access.
> #0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
> #1 0xf7ac147d  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
> #2 0xf7aafd27  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
> #3 0xf7fa591a  (/lib/ld-linux.so.2+0xf91a)
> #4 0xf7f96cb9  (/lib/ld-linux.so.2+0xcb9)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in 
> _dl_get_tls_static_info
> ==25032==ABORTING

libc6:i386 was actually the cause (gcc-snapshot had not changed).
Reverting to 2.26-6 makes the crash disappear.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 the next upload. Feel free to report
> bugs against gcc-multilib or gcc-X-multilib if you feel it's provided in
> the wrong package.

OK, I've just reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872054

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 installing *any* compiler that depends on
libc6-dev-i386 will have the effect to install the default GCC,
introducing a potential redundancy.

An example:

zira:~> aptitude why gcc-6-multilib
i   gcc-snapshot   Dependslibc6-dev-i386 (>= 2.11)
i A libc6-dev-i386 Recommends gcc-multilib
i A gcc-multilib   Dependsgcc-6-multilib (>= 6.3.0-9~)

But that would be also true for gcc-5-multilib, which depends on
libc6-dev-i386.

The "Recommends:" would make sense only if gcc-multilib were a
virtual package provided by compilers that depend on libc6-dev-i386.
But this is not the case here.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev-i386 depends on:
ii  libc6-dev   2.24-12
ii  libc6-i386  2.24-12

Versions of packages libc6-dev-i386 recommends:
ii  gcc-multilib  4:6.3.0-4

libc6-dev-i386 suggests no packages.

-- no debconf information

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

[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, e.g. due to network congestion), if some of
> > the IP addresses are known, they could be made available to the calling
> > application in case they could be useful (e.g. for a connection). If
> > the application wants all the addresses, it can check error conditions
> > as usual.
> 
> The glibc provides getaddrinfo() which is a POSIX interface, also
> described in RFC2553. You can't change it just because you think it's
> better. Alternatively some other resolver libraries might provide the
> behaviour you need. Anyway in both cases it requires some changes on the
> application side too, which is clearly out of scope of this bug report.

It seems that POSIX doesn't specify the answer in the struct addrinfo
in case of error. But anyway, I was thinking more of an alternative
function, which could be more efficient when the goal is to do a
connection, since the applications need to be modified. Since many
applications could benefit from this, having such a function in the
GNU libc may be better than another resolver library.

Now, in the present case of keys.gnupg.net, this may be unnecessary
(see below about the 11/9/5 and the truncation bit).

> Also note that in your case the getaddrinfo() function returns an
> EAI_AGAIN error aka "Temporary failure in name resolution". The
> application (in your case gnupg) can try to handle the failure or at
> least display a better error message than "Host not found" which is
> clearly misleading in that case.

Indeed. Now, with the new gnupg 2.x that has just replaced the old
one in Debian/unstable, resolving seems to be done differently and
I no longer get an error (I've checked that "ping" still fails to
be sure that this wasn't due to something else). So, there's no bug
to report to gnupg. :)

> > And I would say that it could be the opposite. Imagine a host with
> > hundreds of millions of IP addresses...
> 
> I am sure there is a limit somewhere in one of the RFC.

I haven't found a limit (though I didn't check everything).

According to

  
http://serverfault.com/questions/652237/whats-the-maximum-number-of-ips-a-dns-a-record-can-have

there isn't a limit, but this doesn't seem to be based on RFC's,
more on testing. With the example, 1000 records are obtained per
TCP query; other records are obtained with additional TCP queries,
but only one more at a time (rotation by 1). Well, this is rather
ugly with this client.

> Anyway if such a DNS entry exists, I don't think returning a failure
> is really a problem.

And this is what the nameserver of our router is doing! Its chosen
limit can appear to be low, but in absence of specification, how
to choose a practical limit? It seems to be rare to have more than
4 A or  records. Even www.google.org has only one. BTW, I'd be
interested in some statistics.

> > > The point is that the local resolver is supposed to be working
> > > correctly.
> > 
> > and the network quality is good, which is not always the case.
> > 
> > > If it doesn't, one can easily setup a local recursive name server
> > > like unbound.
> > 
> > Unfortunately, this is not a general solution due to buggy ISP's.
> > 
> > > > 11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
> > > > keys.gnupg.net. (32)
> > > > 11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
> > > > keys.gnupg.net. (32)
> > > > 11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
> > > > 1.0.168.192.in-addr.arpa. (42)
> > > > 11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 
> > > > NXDomain* 0/1/0 (94)
> > > > 11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
> > > > 6.0.168.192.in-addr.arpa. (42)
> > > > 11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 
> > > > CNAME pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 
> > > > 78.46.223.54, A 131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 
> > > > 209.135.211.141, A 5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
> > > 
> > > This tcpdump trace doesn't show the answer header, so we don't know if
> > > the truncation flag is set. That said the 11/9/5 says that the answer
> > > contains 11 answer records, 9 name server records and 5 additional
> > > records. This clearly doesn't fit. A 

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

[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, even if there were a truncation, there shouldn't be a
> > failure: using of the returned IP addresses would be sufficient to
> > connect.
> 
> That a wrong assumption. The libc getaddrinfo interface is not to
> connect to an IP, but rather to return *all* addresses corresponding to
> a query. The returned IPs are not necessarily used for a connection
> later. 

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, e.g. due to network congestion), if some of
the IP addresses are known, they could be made available to the calling
application in case they could be useful (e.g. for a connection). If
the application wants all the addresses, it can check error conditions
as usual.

> Not returning all addresses so might lead to data loss or
> security issue.

Well, an application should not base its security on the nameserver.
It is well-known that nameservers can return fake answers.

And I would say that it could be the opposite. Imagine a host with
hundreds of millions of IP addresses...

> The point is that the local resolver is supposed to be working
> correctly.

and the network quality is good, which is not always the case.

> If it doesn't, one can easily setup a local recursive name server
> like unbound.

Unfortunately, this is not a general solution due to buggy ISP's.

> > 11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
> > keys.gnupg.net. (32)
> > 11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
> > keys.gnupg.net. (32)
> > 11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
> > 1.0.168.192.in-addr.arpa. (42)
> > 11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 NXDomain* 
> > 0/1/0 (94)
> > 11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
> > 6.0.168.192.in-addr.arpa. (42)
> > 11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 
> > CNAME pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 
> > 78.46.223.54, A 131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 
> > 209.135.211.141, A 5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
> 
> This tcpdump trace doesn't show the answer header, so we don't know if
> the truncation flag is set. That said the 11/9/5 says that the answer
> contains 11 answer records, 9 name server records and 5 additional
> records. This clearly doesn't fit. A normal DNS server would just return
> 11 answers, so 11/0/0.
> 
> That said I just realized that the strace entry in your previous email
> contains the beginning of the answer:
> 
> > 30419 recvfrom(4, 
> > "'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
> > {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 
> > [16]) = 500
> 
> Converted into hexadecimal, this is:
>   27 4a 83 80 00 01 00 0b 00 08 00 00 04 6b 65 79
>   73 05 67 6e 75 70 67 03 6e 65 74 00 00 1c 00 01
> 
> 274a is the identification. The flags are 8380 and corresponds to QR,
> TC, RD, RA. Your name server clearly says that the answer is truncated.
> On a working nameserver, the flags are 8180 for this query, so the same
> without the truncation flag.

I don't understand here. You said above "This clearly doesn't fit.",
so that it is normal that the truncation flag is set, isn't it?
Or do you mean that the answer should have been 11/0/0, so that
the truncation flag wouldn't be set as a consequence?

> Even if it is a quite standard setup, you have to admit it doesn't
> behave according to the RFC.

I wonder which part of the RFC you are talking about.

> You should complain to the manufacturer and try to get a firmware
> update.

I'll see what I can do.

> Trying to workaround things on the libc side just gives even less value
> to the RFCs, and encourage selling broken hardware.

I doubt that GNU libc would make any difference. What matters is
how MS-Windows behaves, and probably nowadays Android and iOS too.
Also, if there were conformance tests, e.g. from the Linux
community, this could help. At least the buyers would have a way
to choose, and it could be easier to report issues to the vendors.

> > FYI, I also often get 5-second timeouts in name resolution whatever
> > the host (you can see it above): I get the answer for A or , but
> > sometimes, the other answer is lost. I have a DHCP

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

[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 the number of entries in the
> host answer).

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, even if there were a truncation, there shouldn't be a
failure: using of the returned IP addresses would be sufficient to
connect.

11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
keys.gnupg.net. (32)
11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
keys.gnupg.net. (32)
11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
1.0.168.192.in-addr.arpa. (42)
11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 NXDomain* 0/1/0 
(94)
11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
6.0.168.192.in-addr.arpa. (42)
11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 CNAME 
pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 78.46.223.54, A 
131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 209.135.211.141, A 
5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
11:55:59.184491 IP 192.168.0.1.domain > 192.168.0.6.43592: 23396 NXDomain* 
0/1/0 (94)
11:56:04.102206 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
keys.gnupg.net. (32)
11:56:04.141278 ARP, Request who-has 192.168.0.6 tell 192.168.0.1, length 28
11:56:04.141296 ARP, Reply 192.168.0.6 is-at cc:3d:82:a9:e3:ea (oui Unknown), 
length 28
11:56:04.144746 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 CNAME 
pool.sks-keyservers.net., A 193.17.17.6, A 68.187.0.77, A 5.135.158.148, A 
151.252.40.184, A 198.128.3.63, A 78.46.223.54, A 131.175.15.4, A 
209.135.211.141, A 5.9.50.141, A 93.94.119.246 (502)
11:56:04.144795 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
keys.gnupg.net. (32)
11:56:04.186687 IP 192.168.0.1.domain > 192.168.0.6.41008: 31606| 11/8/0 CNAME 
pool.sks-keyservers.net.,  2a01:7e00::f03c:91ff:fe69:8da9,  
2a05:8b81:1000:76::d239,  2001:6f8:1c3c:babe::62:1,  
2001:4c80:40:628:5c70:d1ff:fe44:1424,  2001:67c:26b4::2c6b,  
2a01:4f8:161:4283:1000::203,  2a02:c200:1:10:2:6:4251:1,  
2001:720:418:caf1::8,  2001:470:d:367::555,  2a01:7a0:1::6 (500)
11:56:04.186787 IP 192.168.0.6.36060 > 192.168.0.1.domain: Flags [S], seq 
206201484, win 29200, options [mss 1460,sackOK,TS val 69369420 ecr 0,nop,wscale 
7], length 0
11:56:04.188240 IP 192.168.0.1.domain > 192.168.0.6.36060: Flags [R.], seq 0, 
ack 206201485, win 0, length 0
11:56:04.188296 IP 192.168.0.6.36366 > 192.168.0.1.domain: 19382+ A? 
keys.gnupg.net. (32)
11:56:04.229939 IP 192.168.0.1.domain > 192.168.0.6.36366: 19382 11/9/5 CNAME 
pool.sks-keyservers.net., A 93.94.119.246, A 209.135.211.141, A 78.46.223.54, A 
5.135.158.148, A 151.252.40.184, A 5.9.50.141, A 193.17.17.6, A 131.175.15.4, A 
198.128.3.63, A 68.187.0.77 (502)
11:56:04.229992 IP 192.168.0.6.36366 > 192.168.0.1.domain: 13056+ ? 
keys.gnupg.net. (32)
11:56:04.271424 IP 192.168.0.1.domain > 192.168.0.6.36366: 13056| 11/8/0 CNAME 
pool.sks-keyservers.net.,  2a01:7e00::f03c:91ff:fe69:8da9,  
2a02:c200:1:10:2:6:4251:1,  2001:67c:26b4::2c6b,  
2a05:8b81:1000:76::d239,  2001:470:d:367::555,  
2001:4c80:40:628:5c70:d1ff:fe44:1424,  2001:6f8:1c3c:babe::62:1,  
2a01:7a0:1::6,  2a01:4f8:161:4283:1000::203,  2001:720:418:caf1::8 (500)
11:56:04.271501 IP 192.168.0.6.36062 > 192.168.0.1.domain: Flags [S], seq 
3864689937, win 29200, options [mss 1460,sackOK,TS val 69369441 ecr 
0,nop,wscale 7], length 0
11:56:04.272936 IP 192.168.0.1.domain > 192.168.0.6.36062: Flags [R.], seq 0, 
ack 3864689938, win 0, length 0

> It therefore looks to me like a bug with your network setup, not a
> libc one.

Well, though I didn't want that, this is quite a standard network
setup: my machine just uses DHCP with some standard ADSL modem
router. And given that many users have similar issues and there
isn't any problem with Android, I suppose that there's some bug
on the libc side (or libc can be improved).

FYI, I also often get 5-second timeouts in name resolution whatever
the host (you can see it above): I get the answer for A or , but
sometimes, the other answer is lost. I have a DHCP hook that tests
whether I'm using this router:

[...]
  ping -n -c 1 -I "$interface" "$new_routers" > /dev/null
  if grep -i -q $mac /proc/net/arp; then
logger "Google Public DNS with TCP to avoid recurrent timeout"
[...]

and in this case, I use the Google Public DNS with TCP. But for
some reason, it seems that the /proc/net/arp doesn't contain the
MAC address yet (with the ping, this was working in the past, but
this is no longer the case), so that I just get the 

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

[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 always get. Ditto with telnet.
[...]

I'd add that there's no such name resolution failure under Android
(same network, same name server 192.168.0.1).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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
* HTTP proxy is "null"
* HTTP URL is 
"http://keys.gnupg.net:11371/pks/lookup?op=get=mr=0x;
* SRV tag is "pgpkey-http": host and port may be overridden
* HTTP auth is "null"
* HTTP method is GET
?: keys.gnupg.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver unreachable
gpg: keyserver communications error: public key not found
gpg: keyserver receive failed: public key not found
zsh: exit 2 gpg --keyserver-options verbose,debug --keyserver 
hkp://keys.gnupg.net  

even though the host exists:

zira:~> host keys.gnupg.net
keys.gnupg.net is an alias for pool.sks-keyservers.net.
pool.sks-keyservers.net has address 5.9.50.141
pool.sks-keyservers.net has address 91.143.92.136
pool.sks-keyservers.net has address 108.18.103.116
pool.sks-keyservers.net has address 131.155.141.70
pool.sks-keyservers.net has address 85.10.205.199
pool.sks-keyservers.net has address 163.172.29.20
pool.sks-keyservers.net has address 104.236.209.43
pool.sks-keyservers.net has address 84.200.66.125
pool.sks-keyservers.net has address 5.9.143.170
pool.sks-keyservers.net has address 185.95.216.79
pool.sks-keyservers.net has IPv6 address 2607:5300:60:490f:1::19
pool.sks-keyservers.net has IPv6 address 2604:a880:800:10::227:e001
pool.sks-keyservers.net has IPv6 address 2001:41d0:2:55c2:5054:ff:fe12:3
pool.sks-keyservers.net has IPv6 address 2a01:4f8:a0:4024::2:0
pool.sks-keyservers.net has IPv6 address 2a02:180:a:65:2456:6542:1101:1010
pool.sks-keyservers.net has IPv6 address 2a01:4f8:d16:24c1::2
pool.sks-keyservers.net has IPv6 address 2a01:7c8:aabc:45a:5054:ff:fe9b:59a3
pool.sks-keyservers.net has IPv6 address 2001:470:d:367::555
pool.sks-keyservers.net has IPv6 address 2a01:4f8:161:4283:1000::203
pool.sks-keyservers.net has IPv6 address 2001:4c80:40:628:5c70:d1ff:fe44:1424

This seems to be a known issue:

  https://lists.gnupg.org/pipermail/gnupg-users/2015-October/054532.html

(searching for "keys.gnupg.net: Host not found" gives much more
examples).

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 always get. Ditto with telnet.

An excerpt of the strace for gnupg:

30419 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
30419 socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.0.1")}, 16) = 0
30419 poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
30419 sendmmsg(4, {{{msg_name(0)=NULL, 
msg_iov(1)=[{"\343\376\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\1\0\1", 32}], 
msg_controllen=0, msg_flags=0}, 32}, {{msg_name(0)=NULL, 
msg_iov(1)=[{"'J\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\34\0\1", 32}], 
msg_controllen=0, msg_flags=0}, 32}}, 2, MSG_NOSIGNAL) = 2
30419 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
30419 ioctl(4, FIONREAD, [500]) = 0
30419 recvfrom(4, 
"'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 
[16]) = 500
30419 close(4)  = 0
30419 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
30419 close(4)  = 0
30419 socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.0.1")}, 16) = 0
30419 poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
30419 sendmmsg(4, {{{msg_name(0)=NULL, 
msg_iov(1)=[{"\227\30\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\1\0\1", 32}], 
msg_controllen=0, 
msg_flags=MSG_RST|MSG_ERRQUEUE|MSG_NOSIGNAL|MSG_MORE|MSG_WAITFORONE|MSG_BATCH|MSG_FASTOPEN|0x8c7a},
 32}, {{msg_name(0)=NULL, 
msg_iov(1)=[{"\347\360\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\34\0\1", 32}], 
msg_controllen=0, 
msg_flags=MSG_OOB|MSG_PEEK|MSG_CTRUNC|MSG_WAITALL|MSG_FIN|MSG_SYN|MSG_CONFIRM|MSG_WAITFORONE|MSG_BATCH|MSG_FASTOPEN|0x85b0},
 32}}, 2, MSG_NOSIGNAL) = 2
30419 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
30419 ioctl(4, FIONREAD, [500]) = 0
30419 recvfrom(4, 
"\347\360\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 
[16]) = 500
30419 close(4)  = 

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

[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 don't think it's related to the glibc. It's related to the fact that
> glibc 2.21-4 in unstable is built with a recent binutils, introducing
> some changes in the relocations. If you rebuild glibc 2.21-4 with
> binutils 2.25.1-7, the problem disappears.
[...]
> As you can see the R_X86_64_GOTPCREL has been replaced by a new
> relocation type R_X86_64_REX_GOTPCRELX. It looks like TCC doesn't
> support it.

Thanks for the information. Reported upstream in the tinycc-devel list
(I don't have the URL yet).

This is still not fixed in the git repository (mob branch).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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.c 
> int main (void)
> { return 0; }
> ypig% tcc conftest.c -o conftest
> ypig% ./conftest 
> zsh: segmentation fault (core dumped)  ./conftest

The cause is libc6 2.21. I get this problem with libc6 2.21-4,
but on another machine, after reverting to libc6 2.19-22, this
problem no longer occurs. So, I wonder whether this is a tcc
bug or a glibc one.

In the "objdump -S" output of conftest, I notice the following
difference:

libc6 2.19:

00400430 <_init>:
  400430:   48 83 ec 08 sub$0x8,%rsp
  400434:   48 8b 05 4d 01 20 00mov0x20014d(%rip),%rax# 
600588 <_init+0x200158>
[...]

libc6 2.21:

004003f0 <_init>:
  4003f0:   48 83 ec 08 sub$0x8,%rsp
  4003f4:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 4003fb 
<_init+0xb>

The 0x20014d(%rip) has changed to 0x0(%rip).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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 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_TIME is set to fr_FR, that is latin1.
> If LC_TIME is set to fr_FR.utf8, I cannot observe the problem anymore.
> 
> $ LC_TIME=fr_FR date -d 2015-02-07 +%b | hexdump -C
>   66 e9 76 72 2e 0a |f.vr..|
> 0006
> $ LC_TIME=fr_FR.utf8 date -d 2015-02-07 +%b | hexdump -C
>   66 c3 a9 76 72 2e 0a  |f..vr..|
> 0007
> 
>   If you agree with me, I let you close the bug.

I disagree. The charmap is specified by LC_CTYPE, not by LC_TIME.
See the locale(7) man page:

  LC_CTYPE
This category determines the interpretation of byte sequences
as characters (e.g., single versus multibyte characters), [...]

  LC_TIME
This category governs the formatting used for date and time
values. For example, most of Europe uses a 24-hour clock
versus the 12-hour clock used in the United States. [...]

So, the charmap part of the locale value of LC_TIME should be ignored,
just like it is for LC_MESSAGES (with LC_MESSAGES=fr_FR in a UTF-8
environment, messages are output in UTF-8, even though fr_FR is
latin1).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[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"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
$ locale charmap
UTF-8
$ date -d 2015-02-07 +%b
f�vr.
$ date -d 2015-02-07 +%B
f�vrier
$ date -d 2015-02-07 +%B | hd
  66 e9 76 72 69 65 72 0a   |f.vrier.|
0008

Note that there is no such problem with LC_MESSAGES, e.g.:

$ LC_MESSAGES=fr_FR cp
cp: opérande de fichier manquant
Saisissez « cp --help » pour plus d'informations.

is UTF-8 as expected.

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:5.2.1-17

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.57
ii  glibc-doc  2.19-22
ii  locales2.19-22

-- debconf information:
  glibc/restart-services:
  libraries/restart-without-asking: false
  glibc/restart-failed:
  glibc/disable-screensaver:
  glibc/upgrade: true

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

[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 locales are available, various programs (e.g. executed by cron)
 break.
[...]

This still occurs: on a computation server, glibc was upgraded
yesterday, and one of my programs failed with the following error.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = en_US.UTF-8,
LC_TIME = en_DK,
LC_COLLATE = POSIX,
LC_CHARMAP = UTF-8,
LANG = POSIX
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).

and locale: Cannot set LC_CTYPE to default locale: Too many levels of
symbolic links in a program started by the Perl script.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129093745.ga7...@xvii.vinc17.org

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

[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: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221125537.ga1...@xvii.vinc17.org

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

[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 (e.g. executed by cron)
break.

Instead the new locales should be built in a temporary file, say
/usr/lib/locale/locale-archive.tmp, and a mv should be done at the
end.

I can see 2 solutions (untested):

1. Create a temporary directory and use the --prefix localedef option.
This is rather inelegant, though (IMHO).

2. Modify localedef to add a new option to be able to provide a
new archive file name, and use this option.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.51
ii  libc6 [glibc-2.17-1]   2.17-93

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: en_US.UTF-8
* locales/locales_to_be_generated: All locales


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130924000739.ga20...@xvii.vinc17.org

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

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

[*] http://www.pathname.com/fhs/pub/fhs-2.3.html

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-x32 depends on:
ii  libc6  2.17-92

libc6-x32 recommends no packages.

libc6-x32 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130825124614.ga11...@xvii.vinc17.org

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

[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 /usr/local.
  

[*] http://www.pathname.com/fhs/pub/fhs-2.3.html

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-i386 depends on:
ii  libc6  2.17-92

libc6-i386 recommends no packages.

libc6-i386 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130825124949.ga12...@xvii.vinc17.org

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

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

[*] http://www.pathname.com/fhs/pub/fhs-2.3.html

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:amd64 depends on:
ii  libgcc1  1:4.8.1-9

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.50
ii  glibc-doc  2.17-92
ii  locales2.17-92

-- debconf information:
* glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: spamassassin exim4 cups cron atd apache2
* libraries/restart-without-asking: true


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130825125233.ga12...@xvii.vinc17.org

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

[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
Saisissez « cp --help » pour plus d'informations.
xvii% LANGUAGE=fr_FR LC_ALL=C cp
cp: missing file operand
Try 'cp --help' for more information.

Both should have output in English.

Glibc should apply the same rules with C.UTF-8 as with C locales.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:amd64 depends on:
ii  libgcc1  1:4.8.1-8

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.50
ii  glibc-doc  2.17-92
ii  locales2.17-92

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130813115512.ga23...@xvii.vinc17.org

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

[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 behavior (shall):
INF converted to lowercase gives ınf, but strcasecmp regards INF
and ınf as different. For both POSIX and Unicode, they shall match
in tr_TR.iso88599, due to the current behavior of tolower on 'I'.

At least POSIX must be followed.

Default caseless matching as specified by Unicode mostly corresponds
to the requirements from POSIX, with some differences. For instance,
with Unicode, ß and ss would match. This part would be a wishlist,
but this is not this bug report, which is on the specific case of the
uppercase I and dotted uppercase I in the tr_TR.iso88599 locale (note
that the behavior with tr_TR.utf8 is different, but this bug is not
about this locale).

-- 
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 / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715111827.gq1...@ioooi.vinc17.net

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

[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 (setlocale (LC_ALL, ) == NULL)
{
  fprintf (stderr, locale-test: can't set locales\n);
  exit (EXIT_FAILURE);
}

  for (i = 0; i  2; i++)
for (j = 0; j  4; j++)
  {
char s[4];
for (k = 0; k  3; k++)
  {
s[k] = infs[i][k];
if (j  k)
  s[k] = (i ? toupper : tolower)(s[k]);
  }
s[3] = '\0';
printf (%d%d %s\n,
!strcasecmp (s, INF), !strcasecmp (s, inf), s);
  }

  return 0;
}

gives:

11 INF
00 ıNF
00 ınF
00 ınf
11 inf
00 İnf
00 İNf
00 İNF

Since the modifications of the string have been done with toupper and
tolower, I would have expected 11 everywhere.

(Probably an upstream bug, but their BTS is currently down.)

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:amd64 depends on:
ii  libgcc1  1:4.8.1-6

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.50
ii  glibc-doc  2.17-7
ii  locales2.17-7

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: cups cron atd apache2
* libraries/restart-without-asking: false


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130712152427.ga16...@ypig.lip.ens-lyon.fr

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

[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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438999#10

I could build the test version and I tested all the glibc math
functions. I didn't find any error.

-- 
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 / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130306150056.gu5...@xvii.vinc17.org

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

[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 is the first time I see
something like that.

-- 
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 / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130305145045.ga2...@xvii.vinc17.org

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

[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 (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130304015525.gh5...@xvii.vinc17.org

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

[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 strace ends with:

[...]
21935 write(1, sub   4096R/F4958D46 2012-02-10\n, 32) = 32
21935 write(1, \n, 1) = 1
21935 getrusage(RUSAGE_SELF, {ru_utime={0, 768048}, ru_stime={0, 40002}, ...}) 
= 0
21935 times({tms_utime=76, tms_stime=4, tms_cutime=0, tms_cstime=0}) = 
1828252106
21935 lseek(6, 0, SEEK_SET) = 0
21935 lseek(6, 2153824, SEEK_SET)   = 2153824
21935 read(6, 
\231\1\242\4F!9\1\21\4\0\226\225\217\307\\BL\266+\37\270\34\0-Z\245\374\371\3373...,
 8192) = 8192
21935 read(6, 
f\304B\17L\266B\277\311\1\231\210F\4\20\21\2\0\6\5\2Fq\204\374\0\n\t\0205\326\254...,
 8192) = 8192
21935 --- SIGINT (Interrupt) @ 0 (0) ---
21935 munmap(0x7f5fe36c1000, 32768) = 0
21935 write(2, \n, 1) = 1
21935 write(2, gpg, 3)= 3
21935 write(2, : , 2) = 2
21935 write(2, Interrupt, 9)  = 9
21935 write(2,  caught ... exiting\n, 20) = 20
21935 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f5fe24c34f0}, NULL, 8) 
= 0
21935 unlink(/home/vinc17/.gnupg/.#lk0x124feb0.xvii.21935) = 0
21935 futex(0x7f5fe2816e60, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be 
restarted)
21935 --- SIGQUIT (Quit) @ 0 (0) ---
21935 tgkill(21935, 21935, SIGQUIT) = 0
[...]

My machine has:
gnupg 1.4.12-6
libc6 2.13-37
Linux xvii 3.5-trunk-amd64 #1 SMP Debian 3.5.5-1~experimental.1 x86_64 GNU/Linux

-- 
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 / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121209173943.ga22...@xvii.vinc17.org

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

[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 problem with other
tiny values.

#include stdio.h
#include math.h

int main (void)
{
  double d;
  long double e;

  d = nextafter (0.0, 1.0);
  printf (d = %e = %f = %g = %a\n, d, d, d, d);
  e = d;
  printf (e = %Le = %Lf = %Lg = %La\n, e, e, e, e);
  d = e;
  printf (d = %e = %f = %g = %a\n, d, d, d, d);
  printf (d = %.330f\n, d);
  printf (e = %.330Lf\n, e);
  return 0;
}

I get:

d = 4.940656e-324 = 0.00 = 4.94066e-324 = 0x0.1p-1022
e = 4.450148e-308 = 0.00 = 4.45015e-308 = 0x0.1p-1022
d = 4.940656e-324 = 0.00 = 4.94066e-324 = 0x0.1p-1022
d = 
0.0004940656
e = 
0.00044501477170144027661805

Note that 4.450148e-308 / 4.940656e-324 is about 2^53, where 53 is the
precision of a double. I suspect that the glibc code doesn't handle
small values such that one of the double's in the representation is 0.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-35
ii  libgcc1   1:4.7.1-7

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.46
pn  glibc-doc  none
ii  locales2.13-35

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
* glibc/restart-failed:
* glibc/restart-services: spamassassin openbsd-inetd exim4 cron atd
* libraries/restart-without-asking: true

-- debsums errors found:
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 5250 package 
'inn2':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 8462 package 
'libgdbmg1':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 11058 
package 'libnewt0':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 13393 
package 'docbook-mathml':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 22784 
package 'libpcd':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 31190 
package 'inn2-inews':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 33324 
package 'libisc4':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 5250 
package 'inn2':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 8462 
package 'libgdbmg1':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 11058 
package 'libnewt0':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 13393 
package 'docbook-mathml':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 22784 
package 'libpcd':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 31190 
package 'inn2-inews':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 33324 
package 'libisc4':
 missing architecture


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120913162955.ga32...@ay.vinc17.org

Bug#372544: fixed in eglibc 2.13-1

[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 fixed.

OK. I'll try to write the tests in a few weeks.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111210013811.gr5...@xvii.vinc17.org

Bug#372544: fixed in eglibc 2.13-1

[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 testcases.

Ah, I didn't see that the bug that was opened upstream yeaterday
was against an old glibc version! Still, Bruno Haible said:

I see 6 different implementations of fma(), 4 implementations of fmaf(),
and 4 implementations of fmal() in the glibc source code.
How can you guarantee that all of them are thoroughly tested?

The ones in math/s_fma.c, math/s_fmaf.c, math/s_fmal.c are definitely
buggy.

But I wonder whether Debian supports a platform with such an
implementation.

The old upstream bug http://sourceware.org/bugzilla/show_bug.cgi?id=3268
was also still open.

I'll try to write my own test suite (based on difficult cases and
with the 4 rounding modes).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018145226.gs9...@xvii.vinc17.org

Bug#632798: libc6: broken LANGUAGE design

[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 tried the
 patch, and does it work well?

No, I haven't tried it. My current workaround is to more or less force
the locales settings in my .zshenv (this is a bit more complex because
I share my config among various systems).

  However, even if this ssh bug is fixed, in case LANGUAGE is not
  defined on the ssh client's side, the system must not set it by
  default in the user's back. So, in short, LANGUAGE should not be
  set in /etc/default/locale.
 
 I am not sure I agree, even though I have my system set up locally
 not to define LANGUAGE.  If ssh were to transmit it and let it
 override /etc/default/locale, wouldn't sending LANGUAGE= work?

Only if LANGUAGE is set. But what about systems not based on glibc?
They could have a LANGUAGE environment variable with a different
meaning and setting LANGUAGE= may have a bad effect.

I wish software used some form of namespace, e.g. GLIBC_LANGUAGE.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110708023027.ga12...@prunille.vinc17.org

Bug#632798: libc6: broken LANGUAGE design

[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 displayed by gdm).
 
  FYI, I installed the machine on 2010-01-04.
 
 Now I'm confused again.  That particular LANGUAGE setting is (I hope)
 redundant next to LANG, so it should not have been set, right?  That
 is supposed to have been fixed in localechooser 1.07 (2006-03-26):
 
* Only use LANGUAGELIST list of languages when really needed, ie
  when a language needs and benefits from something else than English.
  Should avoid reports like #356997.

Could it be due to the following?

   * Prefer official language variants by adding the combination of selected
 language and country to the front on the language list (closes: #560045).
 If a preferred locale was selected, instead add the language and country
 combination from that to the languagelist as it will most likely also
 indicate the preferred language variant.

(on 23 Dec 2009).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110708023405.gb12...@prunille.vinc17.org

Bug#632798: libc6: broken LANGUAGE design

[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,
/etc/environment is empty and /etc/default/locale looks like this
 
   #  File generated by update-locale
   LANG=de_DE.UTF-8
   #LANGUAGE=en_US
 
and ssh localhost locale still shows LANGUAGE=.  Any idea what's
different between your setup and mine?

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 displayed by gdm).

FYI, I installed the machine on 2010-01-04. I did:

$ wget 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
$ wget wget 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/jigdo-cd/debian-testing-amd64-netinst.template
$ jigdo-lite debian-testing-amd64-netinst.jigdo

then

  growisofs -Z /dev/scd0=debian-testing-amd64-netinst.iso

to burn a DVD.

The installer asked me which language to use, and I chose English
(could be American English).

Note: I saw that on a machine reinstalled with Debian squeeze,
/etc/default/locale only sets LANG, but this may have been
manually set by the admin.

 2. openssh-server has the following in its default sshd/config:
 
   AcceptEnv LANG LC_*
 
That is unfortunate.  Independently of everything else, this list
ought to be expanded to include LANGUAGE.

I agree. This would be a nice addition if /etc/default/locale does
not set LANGUAGE.

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

However, even if this ssh bug is fixed, in case LANGUAGE is not
defined on the ssh client's side, the system must not set it by
default in the user's back. So, in short, LANGUAGE should not be
set in /etc/default/locale.

I agree concerning 3 and 4 (with corrected explanations).

 5. As you mentioned, when LANGUAGE has an effect, it takes precedence
over LC_MESSAGES.  The principle of least surprise might indicate
that the locale in LC_MESSAGES should be used in preference to
LANGUAGE, but that would make it impossible to express something
like what is currently meant by
 
   LANGUAGE=fr:de
   LC_MESSAGES=de
 
on an installation where most programs are translated to German.
(It means: programs using catgets should use German, while programs
using gettext should prefer French if possible.  Intent: I'd
prefer French, but barring that, please give me German instead of
English).

Hmm... OK, I thought that all programs were using gettext.

If one is willing to break with 10 years of gettext behavior, it
should be possible to change this without that downside by
prepending $LC_MESSAGES to LANGUAGE when and only when it is not
already an item in $LANGUAGE.
 
A nice side-effect would be the ability to partially work around
(2), as you mentioned.
 
 What do you think?  What pieces does the above description miss?

It would also be necessary that /etc/default/locale does not set
LANGUAGE (but perhaps this is already fixed for the new installers).
Said otherwise, as LANGUAGE is not standard (e.g. for portable Unix
scripts and other settings) and has the precedence, it should never
be set by the system, only by the user (who doesn't have necessarily
root access) if he wishes too.

And of course, the specification of LANGUAGE in the glibc manual
should be correct (bug 632795).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110706082130.gm8...@prunille.vinc17.org

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

[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 play.  Some environment variables are examined in a fixed order and
  the first environment variable set determines the return value of the
  lookup process.  In detail, for the category `LC_xxx' the following
  variables in this order are examined:

  `LANGUAGE'

  `LC_ALL'

  `LC_xxx'

  `LANG'

However, this is incorrect, and the way it is done is more complex,
as shown below:

ypig% LANGUAGE=fr_FR LC_ALL=en_US cp
cp: opérande fichier manquant
Saisissez « cp --help » pour plus d'informations.
ypig% LANGUAGE=fr_FR LC_ALL=C cp
cp: missing file operand
Try `cp --help' for more information.

According to bug 591334, this is the manual that is incorrect.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages glibc-doc-reference depends on:
ii  dpkg  1.16.0.3   Debian package management system
ii  install-info  4.13a.dfsg.1-6 Manage installed documentation in 

glibc-doc-reference recommends no packages.

glibc-doc-reference suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110706001847.ga32...@ypig.lip.ens-lyon.fr

Bug#632798: libc6: broken LANGUAGE design

[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
LC_TELEPHONE=POSIX
LC_MEASUREMENT=POSIX
LC_IDENTIFICATION=POSIX
LC_ALL=
ypig% cp
cp: opérande fichier manquant
Saisissez « cp --help » pour plus d'informations.
ypig% ssh localhost locale
Connected to ypig (from ::1)
LANG=POSIX
LANGUAGE=en_US:en
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
LC_TELEPHONE=POSIX
LC_MEASUREMENT=POSIX
LC_IDENTIFICATION=POSIX
LC_ALL=
ypig% ssh localhost cp
Connected to ypig (from ::1)
cp: missing file operand
Try `cp --help' for more information.

The problem is that the system sets LANGUAGE in the user's back, so
that the standard user's choice (LC_MESSAGES=fr_FR) is no longer taken
into account.

The best solution would be to make the standard locale system override
LANGUAGE, which could just be used as a fallback. Said otherwise, it
is equivalent to internally prepend the current LC_MESSAGES setting
(possibly coming from LANG or LC_ALL) to the LANGUAGE value.

Alternatively the system that sets LANGUAGE could be smarter (but it's
difficult to know what the user expects, in particular if SSH doesn't
transmit LANGUAGE).

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-10Embedded GNU C Library: Binaries
ii  libgcc1   1:4.6.1-2  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.40 Debian configuration management sy
ii  glibc-doc 2.13-10Embedded GNU C Library: Documentat
ii  locales   2.13-10Embedded GNU C Library: National L

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: exim4 cups cron atd apache2



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110706005459.ga1...@ypig.lip.ens-lyon.fr

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

[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 in the manual. So, I assume that this is a bug in the manual
and I've reported bug 632795 against glibc-doc-reference on this point.

There are still potential problems due to the way it is implemented.
One at least occurs under Debian, see bug 632798.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110706011417.ga13...@prunille.vinc17.org

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

[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 would create a
 directory /usr/local/lib64 to place the content; but default Debian
 setup of ldconfig does not include any of */lib64 directories, so
 those libraries would not become readily available.

I'd say that such projects are buggy as they do not follow Debian's
convention: that's up to the configure step to decide what to do,
depending on the target system.

 Having a symlink /usr/local/lib64 - /usr/local/lib should make our
 systems friendlier to the users willing sacrificing piece of mind
 by installing something 'locally'.

There would still be problems if the administrator or the end user
forgets to add symbolic links for other lib directories (e.g.
/opt/lib64 - /opt/lib, $HOME/lib64 - $HOME/lib, and so on). If
not all lib paths are consistent, this also means that incorrect
library versions could be selected, as shown here:

  http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html

Alternatively, Debian could switch to the standard convention
(even though I do not like it, I think this would be a better
solution when one needs to deal with upstream projects that do
not know about Debian).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211130923.ga16...@prunille.vinc17.org

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

[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 LANGUAGE
 | value is ignored if the selected locale is the C locale.
 
 and this NEWS entry:
 
 | Version 2.2.1
 | 
 | * The LANGUAGE environment variable is now ignored unless the locale is
 |   changed from the default C locale.

I have:

ypig:~ locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=POSIX
LC_TIME=en_DK
LC_COLLATE=POSIX
LC_MONETARY=POSIX
LC_MESSAGES=POSIX
LC_PAPER=POSIX
LC_NAME=POSIX
LC_ADDRESS=POSIX
LC_TELEPHONE=POSIX
LC_MEASUREMENT=POSIX
LC_IDENTIFICATION=POSIX
LC_ALL=

This is not the C locale. Even though POSIX and C could be regarded
as equivalent, there are still LC_CTYPE and LC_TIME, which are not in
the C/POSIX locale.

Alternatively, to avoid the problem I mentioned, the language
specified by LC_MESSAGES should be prepended to $LANGUAGE to get the
list of languages, so that a software that doesn't know $LANGUAGE
wouldn't yield surprising behavior if it sets LC_MESSAGES to some
language like en_US.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100914151721.gf1...@prunille.vinc17.org

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

[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 think this is the reason since fr_FR may need UTF-8
or ISO-8859-15 to be displayed correctly, while I get French
messages in ISO-8859-1 locales. And there's the same display
problem with:

  LC_MESSAGES=zh_CN LC_CTYPE=en_US.ISO8859-1 cp

thus without LANGUAGE at all.

IMHO, the C locale is checked mainly for programs that run
entirely under C locales (e.g. LC_ALL=C) for portable behavior.
But the test chosen by the glibc has drawbacks.

Note: some software need UTF-8 locales to behave correctly thus
requiring something like LC_ALL=en_US.UTF8, so the C locale test
isn't even the right one.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100914155150.gg1...@prunille.vinc17.org

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

[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, for customizing printf, the manual says to use
register_printf_function, but this function is now deprecated.

BTW, that's strange that the package version doesn't reflect the
glibc version the manual has been written for. This is confusing.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages glibc-doc-reference depends on:
ii  dpkg  1.15.8.4   Debian package management system
ii  install-info  4.13a.dfsg.1-5 Manage installed documentation in 

glibc-doc-reference recommends no packages.

glibc-doc-reference suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100817140457.ga17...@ypig.lip.ens-lyon.fr

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

[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 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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818003146.gi16...@prunille.vinc17.org

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

[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% LANGUAGE=fr_FR:fr LC_MESSAGES=en_US.ISO8859-1 cp
cp: opérande fichier manquant
Saisissez « cp --help » pour plus d'informations.

Note that I've chosen to set LC_MESSAGES to English to show that
LANGUAGE has the precedence, as documented. The bug is that the
LC_MESSAGES environment variable must be set, even though its
language isn't used. The value of LC_MESSAGES has some importance,
though. With POSIX or C, I still get English messages:

ypig% LANGUAGE=fr_FR:fr LC_MESSAGES=POSIX cp  
cp: missing file operand
Try `cp --help' for more information.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.11.2-2   Embedded GNU C Library: Binaries
ii  libgcc1   1:4.4.4-7  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.33 Debian configuration management sy
ii  glibc-doc 2.11.2-2   Embedded GNU C Library: Documentat
ii  locales   2.11.2-2   Embedded GNU C Library: National L

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100802091847.ga18...@ypig.lip.ens-lyon.fr

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

[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 (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100802131433.ga8...@prunille.vinc17.org

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

[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

[*] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311259

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100802133030.gb8...@prunille.vinc17.org

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

[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 output
error (at least not in some cases). For instance:

#include stdio.h

int main (void)
{
  int r;
  r = printf (%1s\n, foo);
  fprintf (stderr, %d\n, r);
  return 0;
}

Then I get:

$ ./out  /dev/null
10001
$ ./out -
8196

The first case is correct (anything can be written to /dev/null),
but in the second case (where the fd is closed), there's obviously
an output error (the return value is not 10001), but in such a case,
r should have been negative.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.11.2-1   Embedded GNU C Library: Binaries
ii  libgcc1   1:4.4.4-5  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii  glibc-doc 2.11.2-1   Embedded GNU C Library: Documentat
ii  locales   2.11.2-1   Embedded GNU C Library: National L

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: gdm exim4 cups cron atd



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100623080736.ga...@ypig.lip.ens-lyon.fr

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

[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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100623084800.gy1...@prunille.vinc17.org

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

[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;
  return 0;
}
$ gcc -m32 -ansi -pedantic-errors intmax-test.c
intmax-test.c:5:1: error: use of C99 long long integer constant

Support for intmax_t is not expected to work in C90 mode, but in
such a case, the failure should probably occur on the stdint.h
inclusion or intmax_t x; line. Otherwise I wonder whether the
failure on INTMAX_MAX is intended and/or fixable.

The consequence of this inconsistency is the following: for a
software that uses intmax_t optionally (such as MPFR), as intmax_t
works fine, autoconf detects that intmax_t is supported, but then
the build of the software fails if it uses INTMAX_MAX.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-dev depends on:
ii  libc-dev-bin  2.10.2-8   Embedded GNU C Library: Developmen
ii  libc6 2.10.2-8   Embedded GNU C Library: Shared lib
ii  linux-libc-dev2.6.32-12  Linux support headers for userspac

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]  4:4.4.3-1  The GNU C compiler
ii  gcc-4.1 [c-compiler]  4.1.2-29   The GNU C compiler
ii  gcc-4.3 [c-compiler]  4.3.4-10   The GNU C compiler
ii  gcc-4.4 [c-compiler]  4.4.4-1The GNU C compiler

Versions of packages libc6-dev suggests:
ii  glibc-doc 2.10.2-8   Embedded GNU C Library: Documentat
ii  manpages-dev  3.24-1 Manual pages about using GNU/Linux

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100522204951.ga17...@xvii.vinc17.org

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

[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 and uintmax_t are still 64 bits.

INTMAX_MAX and so on should match the intmax_t and uintmax_t
definitions.

BTW, notice that the fact that intmax_t and uintmax_t are 64 bits
is against the principle that unsigned long is the largest integer
type in C90. So, perhaps this shouldn't be hidden by __extension__
above (this would solve the problem in another way).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2010051625.gg1...@xvii.vinc17.org

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

[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 value). Even the sign
  is incorrect!
 
 Where did you get this result? In my tests both the x87 FPU and the
 current glibc code give the following result when using double variables
 and the sincos() function:
 
 sin (1e22) =  0.46261304076460174617
 cos (1e22) = -0.88656030506363692201

Actually the sincos() function uses the x87 FPU (fsincos instruction),
so that's not surprising that you get the same result.

Try with GCC = 4.4 (so that constant expressions are evaluated
with MPFR):

xvii:~ cat tst.c
#include stdio.h
#include math.h
int main (void)
{
  printf (sin (1e22) = %.17g\n, sin(1e22));
  printf (cos (1e22) = %.17g\n, cos(1e22));
  return 0;
}
xvii:~ gcc tst.c -o tst
xvii:~ ./tst
sin (1e22) = -0.85220084976718879
cos (1e22) = 0.52321478539513899

And if you don't trust MPFR, you can still try with gp (pari).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100321153036.gd1...@prunille.vinc17.org

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

[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 is not an argument for switching to
 the x87 FPU version, contrary to what your first email suggested. Both
 are wrong.

My e-mail didn't suggest that. On the contrary, the glibc sincos()
implementation shouldn't use the x87 FPU version, but should use
the generic C implementation (like sin and cos) instead.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100321211150.gb8...@prunille.vinc17.org

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

[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 incorrect!

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317102900.ga29...@prunille.vinc17.org

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

[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 nearest only). In 32-bit mode (-m32),
the hardware fsin/fcos instructions (and implementation) are used,
but they are buggy on large arguments, just like sincos in 64-bit
mode (which uses the hardware instruction fsincos), and not as
accurate as the MathLib version on small arguments (even though
MathLib has a bug in its error analysis for sin).

If you don't mind about correctness, you can still use the -ffast-math
GCC option (you don't use it in your Makefile). Depending on the
application, this can be OK, but don't complain if you get incorrect,
inaccurate or unexpected results in some cases.

This was for sin/cos. I don't know how sinf/cosf are implemented
in 32-bit and 64-bit modes, but make sure they don't have the same
problem. If they do, this bug is invalid.

Regards,

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317104738.gb29...@prunille.vinc17.org

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

[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 0.46261304076460174617 for the sine instead of
 -0.85220084976718879499 (correctly rounded value). Even the sign
 is incorrect!
 
 Sorry, but I don't see the error. Both are the correct values,
 as any values from -1 to 1.
 
 The double 1e22 is outside the *relevant* precision for double,
 e.g. a whole range of 2*pi is described with the same number (1e22).

No, this is wrong. This could be correct with interval arithmetic,
but floating-point arithmetic works differently: inputs are
regarded as *exact*. One reason is that the implementation cannot
know whether the input is really exact or not (this information
is not passed to the function). Another reason is that some
formulas (based on correlation) such as sin(x)^2 + cos(x)^2 = 1
or algorithms may fail if the implementation assumes that inputs
are regarded as some arbitrary point in an interval.

Also, IEEE 754 requires correct rounding. Support for elementary
functions is optional (Section 9), but since they are in the
library, it is much better to support them. Users/developers
who know that their software would not be affected by a poorly
accurate implementation could still use compiler options.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317133616.gr1...@prunille.vinc17.org

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

[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 results is implementationdefined,
 : as is the accuracy of the conversion between floating-point
 : internal representations and string representations performed by
 : the library functions in stdio.h, stdlib.h, and wchar.h.
 : The implementation may state that the accuracy is unknown.

The values are defined by 5.2.4.2.2p2 (see the equality). The model
is that a floating-point number represents a real number, not an
interval.

accuracy is a measure of the difference between the exact value
and the (rounded) value returned by the function.

 So maybe the bug is to define __STDC_IEC_559__ on such case.
 
 OTOH, section F9.1 don't require (my interpretation)
 trigonometric to be IEC 60559 functions. It has such requirement
 for more elementary functions, e.g. for sqrt (see section F3).

Yes, elementary functions are not covered by Annex F (which is on
the old IEEE 754-1985 standard). However, a C implementation could
claim to conform to IEEE 754 (i.e. more than being conform to
ISO C). This is more a quality of implementation.

Note: I don't know about other languages, whose implementation could
also use the glibc. They could be more restrictive than C.

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317165728.gs1...@prunille.vinc17.org

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

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

For large arguments, it would always be slower if you care about
not too bad accuracy. If you don't care because any value between
-1 and 1 is OK, then you could write a wrapper with:

  return fabsf(x)  some_bound ? sinf(x) : 0;

 Using -ffast-math gives a nice performance boost but leads to bad
 results (in our cases which may be different from the simple given
 example) so it's not really a workaround.

Yes, that's the problem with optimizations that change the semantics
(in the same way, users can complain about the 32-bit implementation
of trigonometric functions). Note that there are other compiler
options that allow a finer grain control of these optimizations.
You might want to look at them (e.g. man gcc).

-- 
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100317194313.gu1...@prunille.vinc17.org

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

[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 ISO-8859-15
be_BY.UTF-8 UTF-8

az_AZ.UTF-8 UTF-8 should be after ast_ES ISO-8859-15.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25.8-20080623 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages locales depends on:
ii  debconf [debconf-2.0] 1.5.23 Debian configuration management sy
ii  libc6 [glibc-2.7-1]   2.7-13 GNU C Library: Shared libraries

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: en_US.UTF-8
* locales/locales_to_be_generated: All locales



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 not corresponding
to a hostname.

Now, if I understand correctly (but I've only partial information
about the problem), the problem occurs with IPv6 DNS requests only,
but 1.0.0.0 is an IPv4 address. So, I suppose that there could be
a workaround.

And FYI, there doesn't seem to be any firmware upgrade for the router
(D-Link DSL-924).

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



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 their DNS
   implementation.

I'll try to see if there's one.

Well it looks like it's not a Debian problem at all right ?
 
 No idea; I reassigned it in case there was a possible workaround (e.g.
 detecting and discarding the bogus replies).

In particular if the bug in the router is widespread, a workaround
(if possible[*]) would be a good idea. Even if there are other ways
to deal with this bug, most users affected by it would wonder what
the problem is (as seen in discussions found by a search on Google).
For instance, Firefox just says:

  The connection has timed out
  The server at host is taking too long to respond.
*   The site could be temporarily unavailable or too busy. Try again
in a few moments.
*   If you are unable to load any pages, check your computer's network
connection.
*   If your computer or network is protected by a firewall or proxy,
make sure that Iceweasel is permitted to access the Web.

It may be a bit difficult for the average user to solve the problem,
due to lack of information. And if he has tried under Windows (where
the bug doesn't appear), he would think that Windows is working and
Linux isn't. :(

[*] 1.0.0.0 isn't even a valid IP address, is it?

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



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tplsource=Llistname=austin-group-lid=11151
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tplsource=Llistname=austin-group-lid=11156
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tplsource=Llistname=austin-group-lid=11159
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tplsource=Llistname=austin-group-lid=11160

Here's a program from the one written by Glenn Fowler:

#include stdio.h
#include stdlib.h

#define SHOW(f) show (#f,f)

static void show (const char *s, double x)
{
  double y = strtod (s, 0);
  printf (%-3s %3g %3g\n, s, x, y);
}

int main (void)
{
  SHOW(-0);
  SHOW(-0.);
  return 0;
}

In unstable, I get:

-00   0
-0.  -0  -0

instead of:

-00  -0
-0.  -0  -0

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1   1:4.2.2-3  GCC support library

libc6 recommends no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 does:

if [ -z $TZ -a -e /etc/timezone ]; then
TZ=`cat /etc/timezone`
export TZ
fi

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0] 1.5.14 Debian configuration management sy

tzdata recommends no packages.

-- debconf information:
  tzdata/Zones/Asia:
  tzdata/Zones/SystemV:
  tzdata/Zones/Pacific:
  tzdata/Zones/Atlantic:
  tzdata/Zones/US:
  tzdata/Zones/Etc:
  tzdata/Zones/Arctic:
  tzdata/Zones/Antarctica:
  tzdata/Zones/America:
* tzdata/Areas: Europe
  tzdata/Zones/Australia:
  tzdata/Zones/Canada:
* tzdata/Zones/Europe: Paris
  tzdata/Zones/Africa:
  tzdata/Zones/Indian:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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

[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
 and round once to the result format, according to the rounding
 mode characterized by the value of FLT_ROUNDS.
 
 I currently don't have the time to fix it, but I think this should
 be done like this:
 
 1. Compute the product as an exact sum of two FP numbers with Dekker's
algorithm.
 2. Determine the rounded results (see algorithms on FP expansions).
 
 Well, there would be 2 problems: First, the fact that values may be in
 extended precision (GCC bug). Then, the possible intermediate overflow
 or underflow should be avoided, probably by doing comparisons first
 and scale the values if need be (this problem is much less important
 than the current situation).

The overflow problem occurs on x86_64 (since SSE2 is used); see
attached C file.

I haven't tested it, but I assume that it also occurs in fmal
on all x86 machines.

-- 
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)
/* $Id: fma-tests.c 17487 2007-05-21 11:03:03Z lefevre $
 *
 * Miscellaneous fma() test.
 */

#include stdio.h
#include stdlib.h
#include float.h
#include math.h

#define WRONG(S,X,Y,Z,F,C)\
  fprintf (stderr, ERROR in test ' S '!\nfma (%a, %a, %a)\n   \
   returned %a instead of %a.\n, X, Y, Z, F, C)

/* Modified Nelson H. F. Beebe's fma() test from stds-754 list, 2006-06-09 */
static int beebe (void)
{
  volatile double eps, e2, f, x, z;

  eps = DBL_EPSILON;
  e2 = eps * eps;
  x = 1.0 + eps;
  z = -1.0 - 2.0 * eps;
  f = fma (x, x, z);
  if (f != e2)
{
  WRONG (beebe, x, x, z, f, e2);
  return 1;
}
  return 0;
}

static int overflowed_mul (void)
{
  volatile double x, f;

  x = DBL_MAX;
  f = fma (x, 2.0, -x);
  if (f != x)
{
  WRONG (overflowed_mul, x, 2.0, -x, f, x);
  return 1;
}
  return 0;
}

int main (void)
{
  int err = 0;

  err += beebe ();
  err += overflowed_mul ();
  return err;
}

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

[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
infinity. This can be seen with the following program and
LC_ALL=tr_TR.iso88599.

#include stdio.h
#include stdlib.h
#include locale.h

int main (void)
{
  double x;
  char *end;
  int err;

  if (setlocale (LC_ALL, ) == NULL)
{
  fprintf (stderr, Can't set locales\n);
  exit (EXIT_FAILURE);
}

  x = strtod (INF, end);
  err = *end != '\0';
  printf (x = %f - error: %s\n, x, err ? yes : no);

  return err;
}

Note: I reported this bug on 2005-08-22 here:

  http://sources.redhat.com/bugzilla/show_bug.cgi?id=1230

when I had the libc6 2.3.5-4 Debian package. It was fixed on 2005-09-28
in the CVS trunk. But it is still present in Debian.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686-bigmem
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages libc6 depends on:
ii  tzdata2007c-1Time Zone and Daylight Saving Time

libc6 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 0a
09

instead of:

vin:~ echo français | od -Ax -txC -v
00 66 72 61 6e c3 a7 61 69 73 0a
0a

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686-bigmem
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages libc6 depends on:
ii  tzdata2006p-1Time Zone and Daylight Saving Time

libc6 recommends no packages.

-- no debconf information

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

[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 loading shared libraries ... message).

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 -static, i.e., by not using shared
libraries.)

 But that also means that adding /usr/local/lib to /etc/ld.so.conf
 would _NOT_ solve your problem since the loader would still find
 libgmp.so.X in /usr/lib first.

So, couldn't the dynamic loader take into account /usr/local/lib
by default (before /usr/lib), just like cpp takes into account
/usr/local/include by default (before /usr/include)?

 If you want to have two different shared libraries sharing the same
 soname on the same system, then there is no other solution than setting
 LD_LIBRARY_PATH to point explicitely to the version you want to use.

If this is really the only possibility, it should probably be set
in /etc/profile in the default configuration (at install time) and
other shell init files.

-- 
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#395177: libc6: default library search path is inconsistent with gcc

[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 -static, i.e., by not using shared
  libraries.)
 
 Build-time linking has nothing to do with glibc.

Yep, but I could assign the bug only to one package.

 Besides, ld _does_ search /usr/local/lib before /usr/lib by default.

So, why do I obtain the same result with -static (i.e., with the
library from /usr/lib instead of /usr/local/lib)?

  So, couldn't the dynamic loader take into account /usr/local/lib
  by default (before /usr/lib), just like cpp takes into account
  /usr/local/include by default (before /usr/include)?
 
 That would be a security nightmare as /usr/local is often writable/owned
 by users other than root (for example, looking at my etch chroot, it is
 writable by group 'staff' by default).

One should assume that users of the 'staff' group are responsible.
And there would be the same security risks for programs compiled
and installed on the system. So, if you decide that /usr/local/lib
shouldn't be in the search paths by default, then this should be
the same for /usr/local/include.

Also, due to software installed in /usr/local (the default prefix
with configure), users often need to add /usr/local/lib to
LD_LIBRARY_PATH anyway.

  If this is really the only possibility, it should probably be set
  in /etc/profile in the default configuration (at install time) and
  other shell init files.
 
 That would be a security problem as well. Only the local system
 administrator can decide whether things installed in /usr/local should
 override system software or not.

Why does gcc search for include files in /usr/local/include before
/usr/include (on Linux machines), then?

-- 
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#395177: libc6: default library search path is inconsistent with gcc

[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, i.e. without
setting any special environment variable. Therefore, in order to be
consistent, the linker should have /usr/local/lib is its search path
too, *by default*.

Here's a way to reproduce the problem (just an example):

  0. Make sure you have default *PATH settings (i.e. no C_INCLUDE_PATH,
 no LIBRARY_PATH, no LD_LIBRARY_PATH set to some value).

  1. Install the official GMP packages, so that one has GMP 4.2.1
 files installed in /usr/include and /usr/lib directories.

  2. Download GMP 4.2.1 and replace the __GNU_MP_VERSION_PATCHLEVEL
 value, e.g. by 17.

  3. Build and install GMP 4.2.17 with configure, make, make install
 (install-nodist_includeexecHEADERS and install-libLTLIBRARIES
 are sufficient).

  4. Compile the following program with either:

   gcc -Wall gmpversion.c -o gmpversion -lgmp

or

   gcc -Wall -static gmpversion.c -o gmpversion -lgmp

#include stdio.h
#include gmp.h
int main (void)
{
  printf (GMP .  Library: %-6s -  Header: %d.%d.%d\n,
  gmp_version, __GNU_MP_VERSION, __GNU_MP_VERSION_MINOR,
  __GNU_MP_VERSION_PATCHLEVEL);
  return 0;
}

  5. Run it. You should get:

GMP .  Library: 4.2.1  -  Header: 4.2.17

This is an incorrect behavior. With default settings, one should get
the same header and library versions (whether this is 4.2.1 or 4.2.17,
I don't care, this is just a policy matter).

A solution could be: add /usr/local/lib to /etc/ld.so.conf by default.

I've not tried, though. I hope this fixes the behavior with libtool
too. But I don't know about the -static option (perhaps a bug in ld,
thus in the binutils package?).

Note: because of this problem, we get bug reports for our software
because of inconsistent header and library versions. This is a problem
with GMP in particular as GMP 4.1.4 (from Debian/stable) and GMP 4.2.1
are incompatible.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686-bigmem
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages libc6 depends on:
ii  tzdata2006n-1Time Zone and Daylight Saving Time

libc6 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 PROTECTED].

I don't understand what is the link between this bug and
linux-2.6 2.6.17-3.

-- 
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 / SPACES project at LORIA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 = DBL_EPSILON;
  e2 = eps * eps;
  x = 1.0 + eps;
  z = -1.0 - 2.0 * eps;
  f = fma (x, x, z);
  if (f != e2)
{
  fprintf (stderr, fma() is WRONG on this platform!\n
   Got %a instead of %a.\n, f, e2);
  exit (EXIT_FAILURE);
}
  return 0;
}

compiled with -std=c99 gives:

fma() is WRONG on this platform!
Got 0x0p+0 instead of 0x1p-104.

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
and round once to the result format, according to the rounding
mode characterized by the value of FLT_ROUNDS.

I currently don't have the time to fix it, but I think this should
be done like this:

1. Compute the product as an exact sum of two FP numbers with Dekker's
   algorithm.
2. Determine the rounded results (see algorithms on FP expansions).

Well, there would be 2 problems: First, the fact that values may be in
extended precision (GCC bug). Then, the possible intermediate overflow
or underflow should be avoided, probably by doing comparisons first
and scale the values if need be (this problem is much less important
than the current situation).

Note: on PowerPC, which has a hardware fma, this bug does not appear.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.4-20051215
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages libc6-dev depends on:
ii  libc62.3.6-15GNU C Library: Shared libraries
ii  linux-kernel-headers 2.6.13+0rc3-2.1 Linux Kernel Headers for developme

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]  4:4.1.1-1  The GNU C compiler
ii  gcc-3.3 [c-compiler]  1:3.3.6-13 The GNU C compiler
ii  gcc-3.4 [c-compiler]  3.4.6-1The GNU C compiler
ii  gcc-4.0 [c-compiler]  4.0.3-3The GNU C compiler
ii  gcc-4.1 [c-compiler]  4.1.1-2The GNU C compiler

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 case, it
outputs:

putwchar-test: errno = 29

putwchar-test: errno = 0 (EILSEQ = 84)

Note: the fact that fwide() is called before setlocale() is
intentional, to make the error appear.

#include stdio.h
#include stdlib.h
#include locale.h
#include wchar.h
#include wctype.h
#include errno.h

void my_putwchar (wchar_t wc)
{
  wint_t ret;

  ret = putwchar (wc);
  if (ret == wc)
return;

  putc ('\n', stderr);
  if (ret != WEOF)
fprintf (stderr, putwchar-test: internal error in putwchar\n);
  fprintf (stderr, putwchar-test: errno = %d (EILSEQ = %d)\n,
   errno, EILSEQ);
  exit (EXIT_FAILURE);
}

int main (void)
{
  wint_t wc;

  errno = 0;

  if (fwide (stdout, 1) = 0)
{
  fprintf (stderr, putwchar-test: can't set stdout's orientation\n);
  exit (EXIT_FAILURE);
}

  if (errno)
{
  fprintf (stderr, putwchar-test: errno = %d\n, errno);
  errno = 0;
}

  if (setlocale (LC_ALL, ) == NULL)
{
  fprintf (stderr, putwchar-test: can't set locales\n);
  exit (EXIT_FAILURE);
}

  wc = towlower (L'I');
  if (wc == WEOF)
{
  fprintf (stderr, putwchar-test: btowc returned WEOF\n);
  exit (EXIT_FAILURE);
}
  my_putwchar (wc);
  my_putwchar (L'\n');

  return 0;
}

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.10-20050517
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[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 editing /etc/locale.gen

This is not b since the locale was added via dpkg-reconfigure locales.

   c. This locale exists but is broken.
   d. This locale is broken, and is not provided by the locales package
  but is a local addition.

I didn't do any local addition.

 When an error occurs, we can either abort (this is the current behavior),
 or continue.  The former ensures that errors are caught and dealt with,
 but admin has then to modify a file he is not even aware of.  With the
 latter, an admin may generate all locales without noticing that
 [EMAIL PROTECTED] is broken.  Maybe a good compromise is to not abort when
 generating locales, and add a debconf note if errors occured?

Yes, and the locale could be commented out.

  (And either
 abort after explaining admin how to fix the problem, or exit gracefully)

Yes, this would be OK too.

-- 
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 / SPACES project at LORIA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]