Bug#632798: libc6: broken LANGUAGE design

2011-07-07 Thread Jonathan Nieder 
Vincent Lefevre wrote:
> On 2011-07-07 18:46:38 -0500, Jonathan Nieder wrote:

>> If ssh were to transmit it and let it
>> override /etc/default/locale, wouldn't sending LANGUAGE="" work?
>
> Only if LANGUAGE is set.

True.  In particular, if the user doesn't know to defend against a
remote LANGUAGE setting, this won't help him.

Unconditionally prepending LC_MESSAGES to the LANGUAGE list is
starting to sound more appealing.

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

The only library I've heard of that pays attention to LANGUAGE is
gettext's libintl, even on systems not based on glibc.  I think the
empty-LANGUAGE trick should be safe and portable to all systems where
the ssh server allows it to override local defaults.

Next step is to write some patches (and after that to pass them to
upstreams and learn what they think), so I will probably go quiet for
a while.  Still, I'm very grateful for your help in thinking the
design through.



-- 
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/20110708034945.GA2559@elie

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  - Web: 
100% accessible validated (X)HTML - 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-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  - Web: 
100% accessible validated (X)HTML - 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#632252: fixed in unstable

2011-07-07 Thread Witold Baryluk 
Package: libc6
Followup-For: Bug #632252

Unstable version looks to do not have this problem.
Thanks, for taking care.




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

Kernel: Linux 3.0.0-rc5-t43-prod-00159-g9508d80-dirty
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to pl_PL.utf8)
Shell: /bin/sh linked to /bin/dash

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

Versions of packages libc6 recommends:
ii  libc6-i6862.13-9 Embedded GNU C Library: Shared lib

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.40 Debian configuration management sy
pn  glibc-doc  (no description available)
ii  locales   2.13-9 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/20110708010619.25822.34359.report...@sredniczarny.smp.if.uj.edu.pl

Bug#632798: libc6: broken LANGUAGE design

2011-07-07 Thread Jonathan Nieder 
Hi again,

One more quick comment.

Vincent Lefevre 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.

The only choices I see that should be setting LANGUAGE based on the
current localechooser data file are Northern Sami, Norwegian Bokmaal,
Norwegian Nynorsk, Portuguese, Malagasy, and Wolof.  (Plus Chinese
(Traditional), Chinese (Simplified), and Portuguese (Brazil), but I
suspect those are bugs.)
 
Am I misunderstanding how LANGUAGE is supposed to be used?  Did
localechooser regress?



-- 
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/20110708003038.GA6466@elie

Bug#632798: libc6: broken LANGUAGE design

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

Ah.  localechooser sets LANGUAGE up, and then update-locale from the
"locales" package preserves it.

The weird part is that debconf ("dpkg-reconfigure locales") controls
the LANG setting but LANGUAGE has to be changed more directly
("update-locale LANGUAGE=foo").  See (*), below.

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

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

 $ LANGUAGE= LC_ALL=de_DE.UTF-8 cp
 cp: Fehlendes Dateioperand
 „cp --help“ gibt weitere Informationen.

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

The authors of update-locale must have thought the same thing.

# update-locale LANG=de_DE.UTF-8 LANGUAGE=fr:de
*** update-locale: Warning: LANGUAGE (fr:de) is not compatible with
LANG (de_DE.UTF-8). Disabling it.

See Bug#596695 for the strange history that led to that.

This seems mildly broken.  Consider the following sequence of
events: (*)

 1. Install, telling localechooser to use language A.
 2. Reconfigure using dpkg-reconfigure to switch to language B.
 3. Reconfigure using dpkg-reconfigure to switch back to language A.

At step 1, LANG and LANGUAGE are set.  At step 2, locales.postinst
decides what LANG should be.  LANG and LANGUAGE are mismatched, so the
LANGUAGE line is automatically commented.  At step 3, locales.postinst
sets LANG back, but LANGUAGE is still commented.

At last, the old mystery (1) is solved.  The above must be what
allowed LANGUAGE to be set on your system and not set on mine.

Summary of proposed changes
---

openssh-server Bug#313317:

 * Let user envvars from the whitelist override pam.  There's a patch
   already; we should just make sure it still works, ping upstream,
   and consider applying it in the meantime as a Debian-specific
   change.

Additional bugs to be cloned from this one:

 * openssh-server: expand the default envvar whitelist to include
   LANGUAGE
 * libc6: let C.UTF-8 locale suppress LANGUAGE, just like C does
 * libc6: let LANGUAGE take effect even if LC_MESSAGES refers to
   a non-existent locale
 * libc6: implicitly add LC_MESSAGES to the beginning of the
   LANGUAGE list, except when it is already in the list
 * locales: when changing the default locale, update LANGUAGE at the
   same time, so the resulting configuration can be more similar to
   what localechooser would write.

Thanks again for all your help.



--
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/20110707234638.GB28616@elie

Bug#631256: eglibc: ftbfs with binutils-gold: "These critical programs are missing or too old: ld"

2011-07-07 Thread Jonathan Nieder 
Jonathan Nieder wrote:

> eglibc does not build with ld.gold.

Quick update: with minor changes, it builds but the resulting ld.so
segfaults[*].  Almost there.

Regards,
Jonathan

[*] Roland McGrath did some work, available from upstream's
roland/gold-vs-libc branch (currently at a9d20e3d).  I also needed the
following:

-- 8< --
--- i/configure.in
+++ w/configure.in
@@ -1567,10 +1567,8 @@ changequote([,])dnl
   libc_cv_z_relro=no
   if AC_TRY_COMMAND([${CC-cc} -v --help 2>&1|grep "z relro" 
1>&AS_MESSAGE_LOG_FD])
   then
-if AC_TRY_COMMAND([${CC-cc} -Wl,--verbose 2>&1|grep DATA_SEGMENT_RELRO_END 
1>&AS_MESSAGE_LOG_FD])
-then
-  libc_cv_z_relro=yes
-fi
+# Assume the linker supports -z relro.  Debian linkers do.
+libc_cv_z_relro=yes
   fi])
   if test "$libc_cv_z_relro" = no; then
AC_MSG_ERROR(linker with -z relro support required)
-- >8 --

That gets "configure" to work, but the build fails:

| make[4]: Leaving directory `/home/jrn/src/glibc/time'
| make[3]: Leaving directory `/home/jrn/src/glibc/elf'
| make[2]: *** No rule to make target `/home/jrn/src/glibc/build/shlib.lds', 
needed by `/home/jrn/src/glibc/build/elf/sotruss-lib.so'.  Stop.
| make[2]: Leaving directory `/home/jrn/src/glibc/elf'
| make[1]: *** [elf/subdir_lib] Error 2
| make[1]: Leaving directory `/home/jrn/src/glibc'
| make: *** [all] Error 2

That's because the "use-default-link = yes" codepath is not well
tested, since ld.bfd uses "use-default-link = no".  Removing the
dependencies

$(objpfx)sotruss-lib.so: $(common-objpfx)shlib.lds
$(common-objpfx)linkobj/libc.so: $(common-objpfx)shlib.lds

gets past that hurdle.  Unfortunately it does not succeed at the
moment of truth:

| CPP='gcc -E -x c-header'  /home/jrn/src/glibc/build/elf/ld-linux-x86-64.so.2 
--library-path 
/home/jrn/src/glibc/build:/home/jrn/src/glibc/build/math:/home/jrn/src/glibc/build/elf:/home/jrn/src/glibc/build/dlfcn:/home/jrn/src/glibc/build/nss:/home/jrn/src/glibc/build/nis:/home/jrn/src/glibc/build/rt:/home/jrn/src/glibc/build/resolv:/home/jrn/src/glibc/build/crypt:/home/jrn/src/glibc/build/nptl
 /home/jrn/src/glibc/build/sunrpc/rpcgen -Y ../scripts -c 
rpcsvc/bootparam_prot.x -o /home/jrn/src/glibc/build/sunrpc/xbootparam_prot.T
| Segmentation fault (core dumped)
| make[2]: *** [/home/jrn/src/glibc/build/sunrpc/xbootparam_prot.stmp] Error 139

The backtrace from a core dump is not very helpful.

| #0  0x in ?? ()
| #1  0x2b3feb7a317e in call_init (env=0x7db60ae0, argv=0x7db60aa0, 
argc=7, l=)
| at dl-init.c:85
| #2  call_init (l=, argc=7, argv=0x7db60aa0, 
env=0x7db60ae0) at dl-init.c:35
| #3  0x2b3feb7a3266 in _dl_init (main_map=0x2b3feb7b91f8, argc=7, 
argv=0x7db60aa0, env=0x7db60ae0)
| at dl-init.c:134
| #4  0x2b3feb796b3a in _dl_start_user () from 
/home/jrn/src/glibc/build/elf/ld-linux-x86-64.so.2
| #5  0x7db61943 in ?? ()
| #6  0x0007 in ?? ()
| #7  0x7db61a82 in ?? ()
| #8  0x7db61aaa in ?? ()
| #9  0x7db61aad in ?? ()
| #10 0x7db61ab8 in ?? ()
| #11 0x7db61abb in ?? ()
| #12 0x7db61ad3 in ?? ()
| #13 0x7db61ad6 in ?? ()
| #14 0x in ?? ()



-- 
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/20110707215356.GA15205@elie