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

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

2020-08-11 Thread Vincent Lefevre
Package: libc6
Version: 2.31-3
Severity: important

Since the upgrade to 2.31-3, the translations are no longer working
in Mutt.

In my config, the charset gets automatically set to UTF-8//TRANSLIT
(possibly with something else instead of UTF-8). There is the same
issue with ISO-8859-1//TRANSLIT, 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

2020-05-15 Thread Vincent Lefevre
Package: libc6
Version: 2.30-8
Severity: normal

On the Unicode character U+1F928 and above, iswctype returns false for
all properties. It should have the graph, print and punct properties.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, '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

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

2020-05-06 Thread Vincent Lefevre
Package: locales
Version: 2.30-5
Severity: wishlist

I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when
written with digits. But the default date format seems to be the
same one as LC_TIME=C and should be improved. This has currently
been done only for US:

$ for i in $(locale -a | 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

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

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

2018-08-11 Thread Vincent Lefevre
Package: tzdata
Version: 2018e-0+deb9u1
Severity: important

On a Debian 9 machine:

patate:~> TZ=UTC date; TZ=UTC0 date
Sun Aug 12 03:02:35 CEST 2018
Sun Aug 12 01:02:35 UTC 2018

The first line is based on the /usr/share/zoneinfo/UTC file according
to strace, but this is wrong as CEST is not 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

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

2018-07-17 Thread Vincent Lefevre
Package: locales
Version: 2.27-5
Severity: normal

When upgrading, I got the following:

[...]
Setting up locales (2.27-5) ...
Generating locales (this might take a while)...
  aa_DJ.UTF-8... done
  aa_DJ.ISO-8859-1... done
  aa_ER.UTF-8... done
[...]
  zu_ZA.UTF-8... done
  zu_ZA.ISO-8859-1... 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

2018-05-23 Thread Vincent Lefevre
Control: reassign -1 libc-dev-bin
Control: found -1 2.27-3
Control: retitle -1 sprof doesn't work at all: _dl_open assertion failed

(This bug is old, and libc6-dev was split in the mean time, with
sprof now being in libc-dev-bin.)

On 2009-07-26 15:54:31 -0400, James Y Knight wrote:
> Also 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

2018-03-05 Thread Vincent Lefevre
Control: reassign -1 libc6 2.27-1
Control: retitle -1 libc6:i386 yields invalid writes, triggered by GCC's 
AddressSanitizer
Control: severity -1 serious

On 2018-03-05 14:10:56 +0100, Vincent Lefevre wrote:
> cventin:~> cat tst.c
> int main (void)
> {
>   return 0;
> }
> 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

2017-08-13 Thread Vincent Lefevre
On 2017-08-13 19:38:11 +0200, Aurelien Jarno wrote:
> This is actually not correct. gcc-multilib is required even for
> compiling with another gcc-X-mutilib compiler as it provides the
> /usr/include/linux/asm symlink.

I suppose you meant /usr/include/asm.

> I'll therefore revert the change in 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

2017-06-21 Thread Vincent Lefevre
Package: libc6-dev-i386
Version: 2.24-12
Severity: normal

The libc6-dev-i386 package has:

  Recommends: gcc-multilib

But recommended packages are installed by default, and the above
"Recommends:" is too strong as gcc-multilib is not the only way to
use libc6-dev-i386.

The issue is that 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

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

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

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

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

2016-08-11 Thread Vincent Lefevre
Package: libc6
Version: 2.23-4
Severity: normal

I always get the folloing error on this machine:

zira:~> gpg --keyserver-options verbose,debug --keyserver hkp://keys.gnupg.net 
--recv-key 
gpg: requesting key  from hkp server keys.gnupg.net
gpgkeys: curl version = GnuPG curl-shim
* 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

2015-12-15 Thread Vincent Lefevre
Control: retitle -1 tcc: segmentation fault on any code due to new binutils 
relocations
Control: tags -1 upstream

On 2015-12-15 17:14:54 +0100, Aurelien Jarno wrote:
> Control: retitle -1: segmentation fault on any code due to new binutils 
> relocations

There shouldn't be a ":" after -1.

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

2015-12-15 Thread Vincent Lefevre
Control: retitle -1 segmentation fault on any code compiled by tcc with libc6 
2.21-4

Cc to the glibc maintainers because the cause of the bug is due to
some change in glibc.

On 2015-12-15 09:35:04 +0100, Vincent Lefevre wrote:
> Code compiled by tcc segfaults:
> 
> ypig% cat conftest.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

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

2015-09-23 Thread Vincent Lefevre
Package: libc6
Version: 2.19-22
Severity: normal

strftime doesn't honor the charmap. The following shows that strftime
yields ISO-8859-1 characters while the charmap is UTF-8.

$ locale
LANG=POSIX
LANGUAGE=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=fr_FR
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
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

2015-01-29 Thread Vincent Lefevre
Control: found -1 2.13-38+deb7u7

On 2013-09-24 02:07:39 +0200, Vincent Lefevre wrote:
 The regeneration of all the locales by /usr/sbin/locale-gen is slow,
 so that it sometimes breaks programs. It currently removes the
 /usr/lib/locale/locale-archive file to rebuild it, and until the
 used 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

2014-02-21 Thread Vincent Lefevre
Control: tags -1 upstream
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16621
Control: found -1 2.18-1

Reported upstream at it still applies to 2.18.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: 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

2013-09-23 Thread Vincent Lefevre
Package: locales
Version: 2.17-93
Severity: normal

The regeneration of all the locales by /usr/sbin/locale-gen is slow,
so that it sometimes breaks programs. It currently removes the
/usr/lib/locale/locale-archive file to rebuild it, and until the
used locales are available, various programs (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

2013-08-25 Thread Vincent Lefevre
Package: libc6-x32
Version: 2.17-92
Severity: normal

The libc6-x32 package provides the /libx32 and /usr/libx32 directories,
but the /usr/local/libx32 doesn't exist. The FHS[*] says:

  If directories /libqual or /usr/libqual exist, the equivalent
  directories must also exist in /usr/local.
  

[*] 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

2013-08-25 Thread Vincent Lefevre
Package: libc6-i386
Version: 2.17-92
Severity: normal

The libc6-i386 package provides the /lib32 and /usr/lib32 directories,
but the /usr/local/lib32 directory doesn't exist. The FHS[*] says:

  If directories /libqual or /usr/libqual exist, the equivalent
  directories must also exist in /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

2013-08-25 Thread Vincent Lefevre
Package: libc6
Version: 2.17-92
Severity: normal

The libc6:amd64 package provides the /lib64 directory, but the
/usr/local/lib64 directory doesn't exist. The FHS[*] says:

  If directories /libqual or /usr/libqual exist, the equivalent
  directories must also exist in /usr/local.
  

[*] 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

2013-08-13 Thread Vincent Lefevre
Package: libc6
Version: 2.17-92
Severity: normal

Scripts tend to use LC_ALL=C.UTF-8 instead of LC_ALL=C for UTF-8 support
and to behave in a locale-independent manner. However $LANGUAGE is still
taken into account by glibc:

xvii% LANGUAGE=fr_FR LC_ALL=C.UTF-8 cp
cp: opérande de fichier manquant
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

2013-07-15 Thread Vincent Lefevre
Control: severity 716775 normal

On 2013-07-15 06:42:06 +, Debian Bug Tracking System wrote:
  # unstandardized, correct behavior unclear
  severity 716775 wishlist

This is not true. It is partially standardized, and the glibc does not
behave correctly on at least one case of specified 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

2013-07-12 Thread Vincent Lefevre
Package: libc6
Version: 2.17-7
Severity: normal

There is a mismatch between strcasecmp and toupper/tolower in the
tr_TR.iso88599 locale:

#include stdio.h
#include stdlib.h
#include locale.h
#include ctype.h
#include strings.h

int main (void)
{
  int i, j, k;
  char *infs[] = { INF, inf };

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

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

Yes, apt-get source libc6/unstable works. The problem is mentioned
here: 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

2013-03-05 Thread Vincent Lefevre
On 2013-03-03 23:49:26 -0800, Jonathan Nieder wrote:
 Jonathan Nieder wrote:
 
  debdiff attached.
 
 Better debdiff attached.

OK, but I don't know how to download the eglibc source: both
apt-get source eglibc/unstable and apt-get source -t unstable eglibc
download the experimental version. This 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

2013-03-03 Thread Vincent Lefevre
On 2013-03-03 16:33:45 -0800, Jonathan Nieder wrote:
 If someone prepares a backport of the fix for 2.13.y, would you
 like to test it?

Yes, if this doesn't introduce dependency problems on unstable.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (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

2012-12-09 Thread Vincent Lefevre
found 399904 2.13-37
thanks

On 2006-11-23 09:39:23 +0100, Werner Koch wrote:
 I was able to duplicate this after some tries.  strace shows that it
 hangs in
 
 futex(0xb7ea9880, FUTEX_WAIT, 2, NULL)  = -1 EINTR (Interrupted system call)

I can also reproduce this bug, with the same example.
The 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

2012-09-13 Thread Vincent Lefevre
Package: libc6
Version: 2.13-35
Severity: normal

The minimum positive long double value is not output correctly by
printf with the decimal conversion specifiers (e, f, g) on PowerPC
(where long double is implemented with a double-double arithmetic).
See the testcase below. There may be the same 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

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

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

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

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

2011-07-06 Thread Vincent Lefevre
Hi Jonathan,

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

2011-07-05 Thread Vincent Lefevre
Package: glibc-doc-reference
Version: 2.13-1
Severity: normal

The libc manual (libc.info.gz) says:

  8.2.1.6 User influence on `gettext'

  [...]

 The LOCALE component is computed based on the category used.  Just
  like for the `setlocale' function here comes the user selection into
  the 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

2011-07-05 Thread Vincent Lefevre
Package: libc6
Version: 2.13-10
Severity: normal

The current LANGUAGE design is broken. Here an example:

ypig% locale
LANG=POSIX
LANGUAGE=
LC_CTYPE=en_US.ISO8859-1
LC_NUMERIC=POSIX
LC_TIME=en_DK
LC_COLLATE=POSIX
LC_MONETARY=POSIX
LC_MESSAGES=fr_FR
LC_PAPER=POSIX
LC_NAME=POSIX
LC_ADDRESS=POSIX
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

2011-07-05 Thread Vincent Lefevre
On 2011-05-23 18:12:28 +, Debian Bug Tracking System wrote:
  tags 591334 + upstream wontfix
 Bug #591334 [libc6] libc6: LANGUAGE not taken into account unless LC_MESSAGES 
 is set
 Added tag(s) wontfix.
[...]

I agree with the reason given by upstream, but this is not the behavior
described 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

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

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

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

I don't 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)

2010-08-17 Thread Vincent Lefevre
Package: glibc-doc-reference
Version: 2.11.1-1
Severity: normal

The manual is obsolete. It is said:

  This is Edition 0.12, last updated 2007-10-27, of `The GNU C Library
  Reference Manual', for Version 2.8 of the GNU C Library.

But the current libc version in Debian is 2.11.

For instance, 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)

2010-08-17 Thread Vincent Lefevre
On 2010-08-17 19:20:30 +0200, Aurelien Jarno wrote:
 This is the upstream manual from glibc 2.11, even if it said the
 contrary.  Marking the bug as wontfix.

OK, it's quite surprising that the developers don't update the manual
at the same time they change the API!

-- 
Vincent Lefèvre 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

2010-08-02 Thread Vincent Lefevre
Package: libc6
Version: 2.11.2-2
Severity: normal

The LANGUAGE environment variable isn't taken into account for
translations, unless LC_MESSAGES is set. Here's an example:

ypig% unset LC_MESSAGES
ypig% LANGUAGE=fr_FR:fr cp
cp: missing file operand
Try `cp --help' for more information.
ypig% 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

2010-08-02 Thread Vincent Lefevre
tags 591334 upstream
forwarded 591334 http://sourceware.org/bugzilla/show_bug.cgi?id=11869
thanks

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (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

2010-08-02 Thread Vincent Lefevre
It could be a documentation bug[*], but I'm not sure since Debian
scripts assume that LANGUAGE can be used alone. For instance, the
/etc/default/locale file generated by Debian contains:

#  File generated by update-locale
#LANG=en_US.UTF-8
LANGUAGE=en_US:en

[*] 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

2010-06-23 Thread Vincent Lefevre
Package: libc6
Version: 2.11.2-1
Severity: normal

For fprintf (thus printf), the C standard says:

  The fprintf function returns the number of characters transmitted,
  or a negative value if an output or encoding error occurred.

But in glibc, printf doesn't return a negative value in case of 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

2010-06-23 Thread Vincent Lefevre
forwarded 586883 http://sourceware.org/bugzilla/show_bug.cgi?id=11741
thanks

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



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

2010-05-22 Thread Vincent Lefevre
Package: libc6-dev
Version: 2.10.2-8
Severity: minor

The INTMAX_MAX definition in /usr/include/stdint.h yields build
failure in 32-bit C90 mode (x86_64 machines with the -m32 gcc
switch and x86 machines).

$ cat intmax-test.c
#include stdint.h
int main (void)
{
  intmax_t x;
  x = INTMAX_MAX;
  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

2010-05-22 Thread Vincent Lefevre
On 2010-05-22 21:36:14 +, Clint Adams wrote:
 Is this patch what you want?

No, that would be incorrect, as when __WORDSIZE isn't 64,
/usr/include/stdint.h defines:

__extension__
typedef long long int   intmax_t;
__extension__
typedef unsigned long long int  uintmax_t;

i.e. intmax_t 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

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

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

2010-03-17 Thread Vincent Lefevre
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
 On amd64, only sincos has an optimized version,

It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for the sine instead of
-0.85220084976718879499 (correctly rounded value). Even the sign
is 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

2010-03-17 Thread Vincent Lefevre
On 2010-03-06 11:42:51 +0100, Jerome Vizcaino wrote:
 After many tests and research I've come to the conclusion that the
 float variants of
 sin/cos (and maybe others) are anormaly slow Debian amd64.

Note that on amd64, sin and cos may be slow, but at least they are
mostly correct (in rounding to 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

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

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

2010-03-17 Thread Vincent Lefevre
On 2010-03-17 19:31:16 +0100, Jerome Vizcaino wrote:
 I do not complain about the sin/cos performance but only on the
 float variants.

OK. I haven't looked at the code, but if sinf() simply calls sin(),
this is suboptimal and there would be room for performance boost
without sacrifying accuracy.

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

2008-08-01 Thread Vincent Lefevre
Package: locales
Version: 2.7-13
Severity: minor

It seems that the locale name are normally in alphabetical order, but
this is not the case for the following one. From the locales.postinst
file:

ar_YE.UTF-8 UTF-8
ar_YE ISO-8859-6
az_AZ.UTF-8 UTF-8
as_IN.UTF-8 UTF-8
ast_ES.UTF-8 UTF-8
ast_ES 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

2007-12-25 Thread Vincent Lefevre
On 2007-12-25 21:38:48 +, Colin Watson wrote:
 I was under the impression that it was conventional even if not required
 to reserve host zero in a given subnet to identify the network itself,
 to avoid confusion of networks with hosts.

I thought for this reason 1.0.0.0 could be detected as 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

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

2007-10-31 Thread Vincent Lefevre
Package: libc6
Version: 2.6.1-6
Severity: normal

In new versions of libc6, strtod(-0, 0) returns +0.0 instead of -0.0
(this bug isn't present in etch).

Discussion:
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tplsource=Llistname=austin-group-lid=11150
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

2007-08-15 Thread Vincent Lefevre
Package: tzdata
Version: 2007f-10
Severity: serious
Justification: Policy 10.7.3

I've upgraded tzdata from 2007f-9 to 2007f-10, and the contents of
/etc/timezone changed from Europe/Paris to User defined.

This change is incorrect and can affect some software. For instance,
/etc/init.d/cupsys 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

2007-06-14 Thread Vincent Lefevre
Note: this is upstream bug 3268:

  http://sourceware.org/bugzilla/show_bug.cgi?id=3268

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



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

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

2007-03-19 Thread Vincent Lefevre
Package: libc6
Version: 2.3.6.ds1-13
Severity: normal

The ISO C standard requires INF to be accepted by strtod:

 -- one of INF or INFINITY, ignoring case

But in Turkish locales (LC_ALL=tr_TR.iso88599), where the lowercase
'I' is the dotless 'i', INF (or similar) is not recognized as the
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

2006-12-24 Thread Vincent Lefevre
Package: libc6
Version: 2.3.6.ds1-9
Severity: normal

On this machine, there's a locale called français, but in a UTF-8
environment, locale -a doesn't output the non-ASCII character in
UTF-8:

vin:~ locale charmap
UTF-8

vin:~ locale -a | grep fran | od -Ax -txC -v
00 66 72 61 6e e7 61 69 73 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

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

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

2006-10-25 Thread Vincent Lefevre
Package: libc6
Version: 2.3.6.ds1-7
Severity: normal

(Not sure if this is a bug in libc6 or binutils or another package;
I first thought it was a bug in gcc, but a gcc developer said no:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29588.)

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

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

2006-06-09 Thread Vincent Lefevre
Package: libc6-dev
Version: 2.3.6-15
Severity: normal

The fma() function is incorrect. For instance (this example is based
on one given in the ieee754r mailing-list):

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

int main (void)
{
  double eps, e2, f, x, z;

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

2005-08-19 Thread Vincent Lefevre
Package: libc6
Version: 2.3.5-4
Severity: normal

The following program shows that putwchar() can return WEOF with
errno = 0, though it should have set it to EILSEQ (see the ISO C
standard, and it is explicitly say in the putwchar(3) man page).
It should be run with LC_CTYPE=tr_TR.UTF-8; in this 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]

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



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

2005-08-06 Thread Vincent Lefevre
Package: locales
Version: 2.3.5-3
Severity: grave
Justification: renders package unusable

When I try to install the locales package (as an upgrade):

Setting up locales (2.3.5-3) ...
Generating locales (this might take a while)...
  en_DK.ISO-8859-1... done
  en_DK.UTF-8... done
  en_US.ISO-8859-1... done
  en_US.UTF-8... done
  fr_FR.ISO-8859-1... done
  fr_FR.UTF-8... done
  [EMAIL PROTECTED] done
  [EMAIL PROTECTED] done
  ar_AE.ISO-8859-6... done
  bs_BA.ISO-8859-2... done
  el_GR.ISO-8859-7... done
  en_GB.ISO-8859-1... done
  en_GB.ISO-8859-15... done
  en_GB.UTF-8... done
  en_US.ISO-8859-15... done
  lg_UG.ISO-8859-10... done
  lt_LT.ISO-8859-13... done
  [EMAIL PROTECTED] open locale definition file [EMAIL PROTECTED]': No such 
file or directory
dpkg: error processing locales (--configure):
 subprocess post-installation script returned error exit status 4
Errors were encountered while processing:
 locales
E: Sub-process /usr/bin/dpkg returned an error code (1)

And dpkg-reconfigure locales fails too:

/usr/sbin/dpkg-reconfigure: locales is broken or not fully installed

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

Versions of packages locales depends on:
ii  debconf   1.4.55 Debian configuration management sy
ii  libc6 [glibc-2.3.5-3] 2.3.5-3GNU C Library: Shared libraries an

locales recommends no packages.

-- debconf information:
* locales/default_environment_locale: None
* locales/locales_to_be_generated: en_DK ISO-8859-1, en_DK.UTF-8 UTF-8, en_US 
ISO-8859-1, en_US.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, [EMAIL 
PROTECTED] UTF-8, [EMAIL PROTECTED] ISO-8859-15, ar_AE ISO-8859-6, bs_BA 
ISO-8859-2, el_GR ISO-8859-7, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, 
en_GB.UTF-8 UTF-8, en_US.ISO-8859-15 ISO-8859-15, lg_UG ISO-8859-10, lt_LT 
ISO-8859-13, [EMAIL PROTECTED] ISO-8859-5, tr_TR ISO-8859-9


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



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

2005-06-30 Thread Vincent Lefevre
On 2005-06-28 19:37:56 +0300, Lars Wirzenius wrote:
 * getgrnam(3) is wrong to say that only /etc/group is used. I've
 filed a bug against it (#316102).

OK, but this is #316117.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: 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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

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

OK, you didn't say that there was such a standard rule.
I've sent a mail to the admins.

-- 
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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

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

This means that Debian (in particular) won't necessarily integrate
nicely in a foreign network. There are at least 2 valid reasons that
it may be difficult to follow this rule:

  * The sysadmins cannot support every OS and cannot know every
possible conflict.

  * The NIS database may contain old groups (but still valid), and
their names may have been given even before a package/software
using these names existed. Well, this is not future-proof.

 2. If you did not follow rule #1 then don't complain when something
breaks.
 
 These rules are not standard but just plain common sense.

This is a bit naive to think that everything will work OK with rules
that are not clearly defined standards (OS-independent).

-- 
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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

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

That's why I said in particular. I don't know how these systems
set up gids, but a system vendor who would really want to avoid
these problems (knowing the local NIS policy) would be able to do
that.

  There are at least 2 valid reasons that
  it may be difficult to follow this rule:
  
* The sysadmins cannot support every OS and cannot know every
  possible conflict.
 
 Yes they should. It's their job. NIS is about _central_ management,
 which includes the list of supported configurations. If your
 configuration is not on that list, then you're on your own, and
 cannot expect things to 'just work'.

Here the users choose the OS they want, so no, the sysadmins cannot
support every OS.

-- 
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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-19 Thread Vincent Lefevre
On 2005-06-19 15:06:20 +0200, GOMBAS Gabor wrote:
 On Sun, Jun 19, 2005 at 02:53:16AM +0200, Vincent Lefevre wrote:
  Why doesn't Debian give the choice to the user when assigning a gid?
  And why does it have hardcoded gids? i.e. why aren't gids allocated
  at installation time?
 
 Most are allocated at package installation time nowadays but that won't
 help you if a group with the same name already exists in NIS.

This is annoying as this means that Debian machines won't integrate
correctly in foreign networks. Why don't these groups have a name
specific to Debian? For instance, I've noticed that exim4 creates
a Debian-exim group. So, why don't other packages follow the same
way, with a Debian-* group?

 The ones that are statically allocated have good reasons for that
 (well, except a couple of historic relics) as documented in the
 Debian policy.

The reason given by the Debian policy is:

  Because some packages need to include files which are owned by these
  users or groups, or need the ids compiled into binaries, these ids
  must be used on any Debian system only for the purpose for which
  they are allocated.

But the ids could be changed at package installation time, and it
should be possible to avoid ids hardcoded in binaries... Anyway,
since the the /etc/group file has the priority, I don't think this
is a problem (except the fact that such groups can get hidden) if
packages use local group names (Debian-*) to avoid clashes.

  Why not? For instance, there could be a file on the system that
  lists the gids not to be used for local groups.
 
 /etc/login.defs has some minimal support for this already. Also the
 Debian policy clearly lists the range for dynamic group creation. If
 your local NIS setup contradicts the Debian policy, that's bad luck
 for you.

Yes, there are several gids  100. In particular, slocate has gid 21,
which is group fax under Debian.

  But why doesn't Debian let me do that? For instance, I modified
  some local gids to avoid clashes with NIS, but during a later
  upgrade with apt, they were set back to their original values.
 
 You either did something wrong or you should file a bug against the
 base-passwd package. It should have asked on upgrade whether it
 should reset the GIDs to their original values or not.

Well, I was asked the question, but the dialog box said that if I
didn't answer positively, my Debian system would not work properly.
You see...

  This wouldn't be a problem. I'm thinking of the slocate group,
  that currently exists in the NIS database. And in fact it would be
  much better to have such a group locally in a gid range that will
  not be used by the NIS administrators. Since /etc/group has the
  priority, this would work without any problem.
 
 - If you expect the slocate database to be stored on some shared file
   system (NFS) then you must use the GID defined in NIS and should never
   allocate a different GID locally

This is not the case. This is purely Debian's slocate system, and
the files are stored in /usr/bin and /var/cache, which are local.

 - If you want the slocate database to be stored on local storage then
   you should not have put the slocate group in NIS in the first place

But this isn't me that put the slocate group in NIS. I couldn't do
anything about that (I'm not the sysadmin).

-- 
Vincent Lefvre [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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

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

Is this rule of not having NIS group IDs  1000 standard?
If so, is it possible to request that the NIS client ignores
such groups? This would make sense.

Why doesn't Debian give the choice to the user when assigning a gid?
And why does it have hardcoded gids? i.e. why aren't gids allocated
at installation time?

  I don't have such information, but I could probably ask them. The
  problem is that they don't support Debian, so that their group id
  range will conflict with Debian's group id range (in particular
  because some group ids are hardcoded in Debian).
 
 Then you have no other option than to synchronize your local group IDs
 with NIS manually.
 
 NIS enforces a central policy that is defined by the NIS administrators.
 The package management system has no way to know about that policy.

Why not? For instance, there could be a file on the system that lists
the gids not to be used for local groups.

 If you want to be part of a NIS setup you have to manually adapt the
 local system configuration to match the central policy.

But why doesn't Debian let me do that? For instance, I modified some
local gids to avoid clashes with NIS, but during a later upgrade with
apt, they were set back to their original values.

  Moreover, if some group exists in the NIS database, why isn't it
  possible to have a copy (with the same group id) in /etc/groups?
  This could be useful when the NIS server is down, for instance.
 
 It is possible but you have to do it manually. This cannot be
 automated in general (think about the group ID being changed in NIS
 but not in your local copy).

This wouldn't be a problem. I'm thinking of the slocate group,
that currently exists in the NIS database. And in fact it would be
much better to have such a group locally in a gid range that will
not be used by the NIS administrators. Since /etc/group has the
priority, this would work without any problem.

More generally, it seems perfectly valid for a Debian package that
needs to create a group for local use only to really create the
group instead of reusing a NIS one.

-- 
Vincent Lefvre [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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-17 Thread Vincent Lefevre
On 2005-06-17 02:03:08 +0300, Lars Wirzenius wrote:
 Thus, I think the Linux manual page saying that getgrnam uses
 /etc/group only is a bug.

So, that would also make programs that rely on /etc/group being used
buggy. IIRC, when I want to add a local group with addgroup, it checks
first if it exists with getgrnam, and refuses to create it if it can
be found. And this is an error if the group exists on NIS, but not
locally in /etc/groups.

Also, I wonder if the following is the correct behavior (grname is a
program that calls getgrgid or getgrnam depending on the argument):

$ ./grname doctex
42 (doctex)
$ ./grname 42
42 (shadow)

In the NIS database, group 42 is doctex, but locally, it is shadow.
My /etc/nsswitch.conf contains in particular:

group:  compat nis

IMHO, since /etc/group has the priority and group 42 exists here, then
the group doctex shouldn't have been visible.

Note that AFAIK, these mismatches are not avoidable when one wants to
use a Debian machine in a NIS network and when the administrators of
the machine and the network are not the same.

-- 
Vincent Lefvre [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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-06-17 Thread Vincent Lefevre
On 2005-06-17 18:36:17 +0200, GOMBAS Gabor wrote:
 On Fri, Jun 17, 2005 at 08:51:53AM +0200, Vincent Lefevre wrote:
  So, that would also make programs that rely on /etc/group being used
  buggy. IIRC, when I want to add a local group with addgroup, it checks
  first if it exists with getgrnam, and refuses to create it if it can
  be found. And this is an error if the group exists on NIS, but not
  locally in /etc/groups.
 
 Huh? I was administering a large NIS setup a couple of years ago and
 this _is_ the only acceptable behaviour. I'd consider blindly creating a
 local group if it already exists in NIS a serious security bug as it may
 silently break local group-based authentication schemes.

Lots of Debian packages create local groups (and in fact, this is the
only problem I have with local groups). So, what do you suggest? Not
using Debian because it is a security bug?

  $ ./grname doctex
  42 (doctex)
  $ ./grname 42
  42 (shadow)
  
 Yes, it is correct as far as libc is concerned. It is simply a
 system administration error.

So, this is a bug in Debian.

 When I was a NIS admin we had a document clearly defining the range
 of user and group IDs allowed to exist both in NIS and on the local
 machines (and it did include synchronizing even some system user and
 group IDs like mail over several operating systems). You simply
 cannot manage NIS without well-defined administrative rules.

I don't have such information, but I could probably ask them. The
problem is that they don't support Debian, so that their group id
range will conflict with Debian's group id range (in particular
because some group ids are hardcoded in Debian).

Moreover, if some group exists in the NIS database, why isn't it
possible to have a copy (with the same group id) in /etc/groups?
This could be useful when the NIS server is down, for instance.

-- 
Vincent Lefvre [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#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-09 Thread Vincent Lefevre
On 2005-03-09 17:43:37 +0900, GOTO Masanori wrote:
 I fully agreed with Denis.  From the technical view point, depending
 on the specific locale for generic purpose is a bad idea.  I close
 this report.

You haven't proposed anything to solve the problem!

-- 
Vincent Lefèvre [EMAIL PROTECTED] - 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#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

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

I didn't request that, just that it should be selected *by default*.
Many admins of Debian machines forget to install it because they
aren't aware of the problem, and if they forget it, the user can't
use this locale. Fedora and Mandrake machines don't have this problem
(i.e. the locale is installed by default).

-- 
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#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

2005-03-02 Thread Vincent Lefevre
Package: locales
Version: 2.3.2.ds1-20
Severity: wishlist

Many Debian machines don't have the en_DK locale installed. This
locale is important to have ISO-8601 date format in applications
that use the locales. So, it should be included by default in the
generated locales.

Alternatively, there could be some specific locale named ISO8601
or something like that.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages locales depends on:
ii  debconf 1.4.46   Debian configuration management sy
ii  libc6 [glibc-2.3.2.ds1-20]  2.3.2.ds1-20 GNU C Library: Shared libraries an

-- debconf information excluded


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



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

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

Some developers (e.g. Mozilla's) don't want to display the date in
anything other than the locales.

-- 
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#297742: locales: Locale en_DK should be included by default (ISO-8601 support)

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

https://bugzilla.mozilla.org/show_bug.cgi?id=140814

-- 
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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-02-27 Thread Vincent Lefevre
On 2005-02-28 10:12:14 +0900, GOTO Masanori wrote:
 At Thu, 17 Feb 2005 13:37:25 +0100,
 Vincent Lefevre wrote:
  The getgrname(3) man page says:
  
The getgrnam() function returns a pointer to a structure containing the
group information from /etc/group for the entry that matches the  group
name name.
  
  But here, the getgrname function returns a result that doesn't belong
  to /etc/group, which seems to lead by side effects to a security hole
  (more details below).
 
 Does this manpage say correctly?  i.e. Is getgrnam tightly coupled
 with /etc/group?

What do you mean?

  It gives here, where slocate is group 21 in NIS:
  
  $ ./grname slocate
  21 (slocate)
  $ grep slocate /etc/group
  zsh: exit 1 grep slocate /etc/group
  $ grep 21 /etc/group
  fax:x:21:
  
  As a consequence:
  
  # touch blah
  # chown root.slocate blah
  # ls -l blah
  -rw-r--r--  1 root fax 0 2005-02-17 13:30:13 blah
 ^^^
  
  This could also explain why groupadd (to add a group to /etc/group)
  fails if a group with the same name exists via NIS.
 
 I guess you specify in /etc/nsswitch.conf that nis is prior than
 files for group lookup.

My /etc/nsswitch.conf contains:

group:  files nis

-- 
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#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

2005-02-17 Thread Vincent Lefevre
Package: libc6
Version: 2.3.2.ds1-20
Severity: important

The getgrname(3) man page says:

  The getgrnam() function returns a pointer to a structure containing the
  group information from /etc/group for the entry that matches the  group
  name name.

But here, the getgrname function returns a result that doesn't belong
to /etc/group, which seems to lead by side effects to a security hole
(more details below).

Consider the following program:

#include stdio.h
#include stdlib.h
#include grp.h

int main (int argc, char **argv)
{
  struct group *grp;

  if (argc != 2)
{
  fprintf (stderr, Usage: grname group_name\n);
  exit (1);
}

  grp = getgrnam (argv[1]);
  if (grp == NULL)
{
  fprintf (stderr, grname: can't find group %s\n, argv[1]);
  exit (2);
}

  printf (%d (%s)\n, grp-gr_gid, grp-gr_name);

  return 0;
}

It gives here, where slocate is group 21 in NIS:

$ ./grname slocate
21 (slocate)
$ grep slocate /etc/group
zsh: exit 1 grep slocate /etc/group
$ grep 21 /etc/group
fax:x:21:

As a consequence:

# touch blah
# chown root.slocate blah
# ls -l blah
-rw-r--r--  1 root fax 0 2005-02-17 13:30:13 blah
   ^^^

This could also explain why groupadd (to add a group to /etc/group)
fails if a group with the same name exists via NIS.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information


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



Bug#216800: powerpc rint() bug

2005-01-06 Thread Vincent Lefevre
On 2004-12-09 17:54:20 +0100, Vincent Lefevre wrote:
 As there have been no feedback for this bug, I finally reported it
 upstream:
 
   http://sources.redhat.com/bugzilla/show_bug.cgi?id=602

and a fix has just been applied to CVS.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.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#216800: powerpc rint() bug

2004-12-14 Thread Vincent Lefevre
Some additional information... Here's a part of the output of my program
(on a PowerPC machine):

ay:~/wd/src/fp ./nearestint 4.5 1
[...]
Rounding toward -oo
 -4.5  -3.5  -2.5  -1.5  -0.5   0.5   1.5   2.5   3.5   4.5
casttoint-4-3-2-1 0 0 1 2 3 4  
trunc-4.0  -3.0  -2.0  -1.0  -0.0   0.0   1.0   2.0   3.0   4.0
floor-5.0  -4.0  -3.0  -2.0  -1.0   0.0   1.0   2.0   3.0   4.0
ceil -4.0  -3.0  -2.0  -1.0  -0.0   1.0   2.0   3.0   4.0   5.0
round-5.0  -4.0  -3.0  -2.0  -1.0   1.0   2.0   3.0   4.0   5.0
nearbyint-5.0  -4.0  -3.0  -2.0  -1.0   0.0   1.0   2.0   3.0   4.0
myrint   -5.0  -4.0  -3.0  -2.0  -1.0   0.0   1.0   2.0   3.0   4.0
rint -4.0  -3.0  -2.0  -1.0   0.0  -0.0   1.0   2.0   3.0   4.0
[...]

myrint corresponds to my code. As expected, it agrees with the
nearbyint glibc function (which is correct). In short, the current
rint code for negative numbers doesn't work in the rounding modes
toward -oo and toward +oo, because it does the first subtraction in
the wrong way, so that the result is rounded in the wrong direction.

Note: do not try the code on Linux/x86, or any other processor that
runs in extended precision; it will not work (in part due to a gcc
bug). Well, if you really want to try on such a machine, you can
still use the -ffloat-store compiler switch, but the results are
not guaranteed for any input.

-- 
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#216800: powerpc rint() bug

2004-12-09 Thread Vincent Lefevre
As there have been no feedback for this bug, I finally reported it
upstream:

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

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


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



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

2004-05-15 Thread Vincent Lefevre
On 2004-05-16 00:09:28 +0900, GOTO Masanori wrote:
 2.4 is starting the handover process to 2.6 with its role of stable
 version.  So if you want to fix 2.4 kernel documents, please do.

I posted a message to the linux-kernel mailing-list, but people there
are quite ignorant about the C language.

 I think we reached agreements that this bug is not glibc releated
 problem.  Thanks to Wolfram and Daniel.  I would like to close this
 bug.  Vincent, ok?

OK.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


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



  1   2   >