Bug#207806: libc6-dev: [ppc] source code compatibility broken 2.3.1->2.3.2

[Daniel Jacobowitz]

On Wed, Sep 10, 2003 at 06:29:39PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 29, 2003 at 10:38:09AM +0100, Christophe Rhodes wrote:
> > Package: libc6-dev
> > Version: 2.3.1-17
> > Severity: important
> > 
> > This isn't about the platform or version of libc6-dev generated by 
> > reportbug, sorry, but about 2.3.2 on ppc.
> > 
> > The definition of ucontext_t and mcontext_t changed for powerpc32 
> > systems between 2.3.1 and 2.3.2.  They did so in a source-code 
> > incompatible way, such that programs of the form
> > 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > void sigsegv_handler(int sig, siginfo_t *info, void *context) {
> >   printf("PC = %x", (((ucontext_t *) context)->uc_mcontext.regs)->nip);
> > }
> > 
> > int main() {
> >   struct sigaction sa;
> >   pid_t pid;
> >   sa.sa_sigaction = sigsegv_handler;
> >   sa.sa_flags = SA_SIGINFO | SA_RESTART;
> >   sigaction(SIGSEGV, $sa, NULL);
> > 
> >   pid = getpid();
> >   kill(pid, SIGSEGV);
> > }
> > 
> > no longer compile, let alone run, because the mcontext_t structure no 
> > longer has an element "regs".
> > 
> > Furthermore, the new definition does not agree with what the kernel 
> > passes to signal handlers.  If I were to adjust the source code to use 
> > the new uc_mcontext structure slot and definition, I would end up with 
> > garbage in my signal handler, because the kernel does not put any 
> > information where libc has placed uc_mcontext.  It _does_ put some in 
> > the "for backwards compatibility" area, so I can get at the information 
> > using the uc_regs and uc_oldsigmask slots, but I can't see how this 
> > change has helped anyone.
> > 
> > It may be worth mentioning Debian bug #157374, where much the same 
> > problem (on hppa and mips) was discussed and fixed.  The bottom line is 
> > that the C library and the kernel's definition of a ucontext and an 
> > mcontext must agree.
> 
> This appears to be, unfortunately, necessary.
> 
> The missing item in your research is that Linux 2.6 now (just now)
> passes the information in the new format.  Not all of the registers
> which were necessary actually fit inside the old definition.  It had to
> change.
> 
> The fact that they broke source compatibility is a bit annoying.  And
> there's no good flag that you need the new kernel in order to use the
> new interface.  Complain to libc-alpha and Paul/Steve if you want. Paul
> tells me that binary compatibility should continue to work, and that
> seems to be true, via the uc_regs pointer.

However, breaking source compatibility was not necessary.  I'm
discussing this with the kernel maintainer (Paul) now.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


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

Bug#210355: tzconfig vs tzsetup: both in base

[Joey Hess]

Package: libc6
Version: 2.3.2-4
Severity: normal

We currently have two programs in base, tzconfig and tzsetup, that do
the same things. I thought I asked for this a long time ago, but I think
tzconfig should be removed from the distribution. If there is a lot of
documentation that refers to tzconfig, or a lot of users who expect it,
I would have no problem with renaming tzsetup to tzconfig. 

If you're not familiar with tzsetup, I wrote it because we needed a
program to be called from base-config using the debconf UI. It is based
on tzconfig and it walks through the same configuration as does
tzconfig, and if run with debconf's dialog frontend, it looks rather
like tzconfig. In addition, it has a -g switch which lets it set GMT.
Internally I belive that tzsetup is better, since it does not rely on a
hardcoded list for its top-level menu, and instead bases it on the
contents of /usr/share/zoneinfo. It also lets the user back up if they
pick the wrong menu item.

It's just a waste of space and confusing to have two programs in the
base system that do the same thing.

If you agree, you could close bug #182981, maybe #179837, and reassign
#122874 to base-config.

-- 
see shy jo


pgp0.pgp
Description: PGP signature

Bug#206784: acknowledged by developer (Bug#206784: fixed in glibc 2.3.2-5)

[Greg Stark]

GOTO Masanori <[EMAIL PROTECTED]> writes:

> If POSIXLY_CORRECT is set, localedef switches its mode to verbose (so it's
> equivalent to -v option). If it's verbose mode, warning messages shows. And
> it returns !0 value.

Well, doesn't that sound like a bug? Does POSIX require all these warnings and
an error return even on successful completion? Why would anyone want a command
that always returns an error?

   --posix
  Be strictly POSIX conformant. Implies --verbose. This option
  currently has no other effect. Posix conformance is assumed if
  the environment variable POSIXLY_CORRECT is set.

It doesn't document it changing the return code, in fact it specifically says
it has no other effect.

-- 
greg



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

Bug#210353: locales: LANG= not removed from /etc/environment

[Denis Barbier]

Package: locales
Version: 2.3.2-6
Severity: normal
Tags: patch

Hi,

as explained by Joey Hess in #209279, if /etc/environment already
contains a LANG= line, it won't be removed if None was selected
in the locales/default_environment_locale question.
Here is a patch; as I proposed a patch against debian/changelog
5 minutes ago, I prefer putting a new entry just below:
  - debian/locales/DEBIAN/postinst: If /etc/environment sets the LANG
variable and a new configuration asks for not setting it, the
line was not removed from this file.

Denis
Index: locales/DEBIAN/postinst
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/postinst,v
retrieving revision 1.10
diff -u -r1.10 postinst
--- locales/DEBIAN/postinst 21 Aug 2003 04:06:18 -  1.10
+++ locales/DEBIAN/postinst 10 Sep 2003 22:48:44 -
@@ -55,6 +55,8 @@
 # Set default LANG environment variable
 if [ -e $EE ]; then
 sed -e '/^ *LANG=/d' $EE > $EE.tmp || true
+#  $EE has to be updated if $SELECTED is empty or 'None'
+cp -f $EE.tmp $EE
 else
 :> $EE.tmp
 fi

Bug#210350: locales: Do not set LANG=C in /etc/environment

[Denis Barbier]

Package: locales
Version: 2.3.2-6
Severity: normal
Tags: patch

Hi,

some people argued in #209279 that setting LANG=C in /etc/environment
does not make much sense (and also that it currently has some bad
influence on d-i).
Here is a patch to not display this locale in the
locales/default_environment_locale question; I ran debconf-updatepo
and updated debian/po/fr.po, but could not close this BR in
debian/changelog ;)

Denis
Index: changelog
===
RCS file: /cvs/glibc/glibc-package/debian/changelog,v
retrieving revision 1.295
diff -u -r1.295 changelog
--- changelog   10 Sep 2003 11:34:14 -  1.295
+++ changelog   10 Sep 2003 22:12:27 -
@@ -9,6 +9,11 @@
 - debian/patches/template.dpatch: Added DP: Related bugs: field.  You can
   use it to put which bugs are related with this dpatch.
 
+- debian/locales/DEBIAN/{config,template}: There is no reason to
+  set LANG=C in /etc/environment, so do not display this locale
+  in the locales/default_environment_locale question.
+  Update debian/po/fr.po accordingly.
+
  -- GOTO Masanori <[EMAIL PROTECTED]>  Wed, 10 Sep 2003 20:32:40 +0900
 
 glibc (2.3.2-6) unstable; urgency=low
Index: locales/DEBIAN/config
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/config,v
retrieving revision 1.7
diff -u -r1.7 config
--- locales/DEBIAN/config   27 Aug 2003 13:01:04 -  1.7
+++ locales/DEBIAN/config   10 Sep 2003 22:12:27 -
@@ -44,13 +44,10 @@
 2)
 db_get locales/locales_to_be_generated && DEFAULT_LOCALES=$(echo $RET | sed 
-e 's/None,*//g' -e 's/ [^ ]*,/,/g' -e 's/ [^ ]*$//')
 
-if test -z "$DEFAULT_LOCALES"; then
-DEFAULT_LOCALES=C
-else
-DEFAULT_LOCALES="C, $DEFAULT_LOCALES"
+if test -n "$DEFAULT_LOCALES"; then
+db_subst locales/default_environment_locale locales $DEFAULT_LOCALES
+db_input medium locales/default_environment_locale || true
 fi
-db_subst locales/default_environment_locale locales $DEFAULT_LOCALES
-db_input medium locales/default_environment_locale || true
 ;;
 *)
 break
Index: locales/DEBIAN/templates
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/templates,v
retrieving revision 1.6
diff -u -r1.6 templates
--- locales/DEBIAN/templates28 Apr 2003 04:45:02 -  1.6
+++ locales/DEBIAN/templates10 Sep 2003 22:12:27 -
@@ -12,14 +12,14 @@
 Template: locales/default_environment_locale
 Type: select
 _Choices: None, ${locales}
-Default: C
+Default: None
 _Description: Which locale should be the default in the system environment?
  Many packages in Debian use locales to display text in the correct
- language for users. The default is C but you can change this if you're not
+ language for users. You can change the default locale if you're not
  a native English speaker.
  These choices are based on which locales you have chosen to generate.
  .
  Note: This will select the language for your whole system. If you're
  running a multi-user system where not all of your users speak the language
- of your choice, then they will run into difficulties and you might want to
- leave "C" as the default locale.
+ of your choice, then they will run into difficulties and you might want
+ not to set a default locale.
Index: po/ca.po
===
RCS file: /cvs/glibc/glibc-package/debian/po/ca.po,v
retrieving revision 1.2
diff -u -r1.2 ca.po
--- po/ca.po2 May 2003 10:40:29 -   1.2
+++ po/ca.po10 Sep 2003 22:12:27 -
@@ -15,7 +15,8 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2003-05-02 14:45+0900\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2003-09-11 00:04+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n"
 "Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n"
@@ -63,8 +64,8 @@
 #, fuzzy
 msgid ""
 "Many packages in Debian use locales to display text in the correct language "
-"for users. The default is C but you can change this if you're not a native "
-"English speaker. These choices are based on which locales you have chosen to "
+"for users. You can change the default locale if you're not a native English "
+"speaker. These choices are based on which locales you have chosen to "
 "generate."
 msgstr ""
 "Molts paquets en Debian fan servir locales per a mostrar text en la llengua "
@@ -77,8 +78,8 @@
 msgid ""
 "Note: This will select the language for your whole system. If you're running "
 "a multi-user system where not all of your users speak the language of your "
-"choice, then they will run into difficulties and you might want to leave \"C"
-"\" as the default locale."
+"choice, then they will run into

Bug#207806: libc6-dev: [ppc] source code compatibility broken 2.3.1->2.3.2

[Daniel Jacobowitz]

On Fri, Aug 29, 2003 at 10:38:09AM +0100, Christophe Rhodes wrote:
> Package: libc6-dev
> Version: 2.3.1-17
> Severity: important
> 
> This isn't about the platform or version of libc6-dev generated by 
> reportbug, sorry, but about 2.3.2 on ppc.
> 
> The definition of ucontext_t and mcontext_t changed for powerpc32 
> systems between 2.3.1 and 2.3.2.  They did so in a source-code 
> incompatible way, such that programs of the form
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> void sigsegv_handler(int sig, siginfo_t *info, void *context) {
>   printf("PC = %x", (((ucontext_t *) context)->uc_mcontext.regs)->nip);
> }
> 
> int main() {
>   struct sigaction sa;
>   pid_t pid;
>   sa.sa_sigaction = sigsegv_handler;
>   sa.sa_flags = SA_SIGINFO | SA_RESTART;
>   sigaction(SIGSEGV, $sa, NULL);
> 
>   pid = getpid();
>   kill(pid, SIGSEGV);
> }
> 
> no longer compile, let alone run, because the mcontext_t structure no 
> longer has an element "regs".
> 
> Furthermore, the new definition does not agree with what the kernel 
> passes to signal handlers.  If I were to adjust the source code to use 
> the new uc_mcontext structure slot and definition, I would end up with 
> garbage in my signal handler, because the kernel does not put any 
> information where libc has placed uc_mcontext.  It _does_ put some in 
> the "for backwards compatibility" area, so I can get at the information 
> using the uc_regs and uc_oldsigmask slots, but I can't see how this 
> change has helped anyone.
> 
> It may be worth mentioning Debian bug #157374, where much the same 
> problem (on hppa and mips) was discussed and fixed.  The bottom line is 
> that the C library and the kernel's definition of a ucontext and an 
> mcontext must agree.

This appears to be, unfortunately, necessary.

The missing item in your research is that Linux 2.6 now (just now)
passes the information in the new format.  Not all of the registers
which were necessary actually fit inside the old definition.  It had to
change.

The fact that they broke source compatibility is a bit annoying.  And
there's no good flag that you need the new kernel in order to use the
new interface.  Complain to libc-alpha and Paul/Steve if you want. Paul
tells me that binary compatibility should continue to work, and that
seems to be true, via the uc_regs pointer.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


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

Re: Bug#209279: base-config: looking ugly after a d-i install

[Joey Hess]

Denis Barbier wrote:
> On Wed, Sep 10, 2003 at 01:47:25PM -0400, Joey Hess wrote:
> > Petter Reinholdtsen wrote:
> > > So I'm not sure if it should be reassigned, or just closed.  The
> > > problem is hidden with the two fixes, and the last real is probably
> > > already reported against slang.  The behaviour of the locales package
> > > is not obviously a bug, so I am reluctant to report it.
> > 
> > I belive this is a bug. I can't think of a good reason to set LANG=C in
> > /etc/environment.
> 
> The locales/default_environment_locale question asks whether a locale
> should be the default for the whole system.  If answer is None,
> /etc/environment is untouched, otherwise LANG=$locale is added into
> this file.  Are there suggestions to make it better?

It makes sense for locales other than C, but not for C. Maybe C should
not be included in the list. Then if only the C locale is selected, the
question will not be displayed, and "None" will go through to the
postinst which will not modify /etc/environment.

(As an aside, locales also adds a blank line at the top of
/etc/environment before the LANG line if that file is empty. And if I
select a default locale from the list, then reconfigure it again and
choose None, it does not remove my old selection from /etc/environment.)

-- 
see shy jo


pgp0.pgp
Description: PGP signature

Bug#210347: libc6: pthread_cond_timedwait.dpatch breaks Wine

[Ove Kaaven]

Package: libc6
Version: 2.3.2-6
Severity: important

pthread_cond_timedwait.dpatch contains this chunk

--- libc/linuxthreads/sysdeps/pthread/pthread-functions.h.jj   2003-04-20 
03:37:06.0 -0400
+++ libc/linuxthreads/sysdeps/pthread/pthread-functions.h  2003-09-01 
05:35:34.0 -0400
@@ -54,6 +54,8 @@ struct pthread_functions
 const pthread_condattr_t *);
   int (*ptr___pthread_cond_signal) (pthread_cond_t *);
   int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *);
+  int (*ptr___pthread_cond_timedwait) (pthread_cond_t *, pthread_mutex_t *,
+ const struct timespec *);
   int (*ptr_pthread_equal) (pthread_t, pthread_t);
   void (*ptr___pthread_exit) (void *);
   int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);

which inserts a new member in the middle of a structure, instead of at the
end. Non-NPTL builds of Wine actually calls __libc_pthread_init() with its
own version of this "struct pthread_functions", in order to force libc to
use Win32-compatible synchronization primitives, and this kind of change
breaks Wine. Moving the new field to the end of the structure ought to make
it easier to keep this Wine-compatible until you add NPTL support
(Wine can use native pthreads only with NPTL, not with LinuxThreads).

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux renegade 2.4.20-k6 #1 Mon Jan 13 23:49:14 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

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]

Re: Bug#209279: base-config: looking ugly after a d-i install

[Philip Blundell]

On Wed, 2003-09-10 at 20:55, Denis Barbier wrote:
> The locales/default_environment_locale question asks whether a locale
> should be the default for the whole system.  If answer is None,
> /etc/environment is untouched, otherwise LANG=$locale is added into
> this file.  Are there suggestions to make it better?

Well, the immediate problem that the debian-installer folks were having
would be solved if the default for noninteractive installs were "None"
rather than "C".  However, I also don't think the distinction between
these two cases is a particularly useful one, and it seems likely to
confuse users.  I would suggest we just remove the "C" option
altogether.

p.


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

Re: Bug#209279: base-config: looking ugly after a d-i install

[Denis Barbier]

On Wed, Sep 10, 2003 at 01:47:25PM -0400, Joey Hess wrote:
> Petter Reinholdtsen wrote:
> > So I'm not sure if it should be reassigned, or just closed.  The
> > problem is hidden with the two fixes, and the last real is probably
> > already reported against slang.  The behaviour of the locales package
> > is not obviously a bug, so I am reluctant to report it.
> 
> I belive this is a bug. I can't think of a good reason to set LANG=C in
> /etc/environment.

The locales/default_environment_locale question asks whether a locale
should be the default for the whole system.  If answer is None,
/etc/environment is untouched, otherwise LANG=$locale is added into
this file.  Are there suggestions to make it better?

Denis


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

Re: Bug#209279: base-config: looking ugly after a d-i install

[Joey Hess]

Petter Reinholdtsen wrote:
> So I'm not sure if it should be reassigned, or just closed.  The
> problem is hidden with the two fixes, and the last real is probably
> already reported against slang.  The behaviour of the locales package
> is not obviously a bug, so I am reluctant to report it.

I belive this is a bug. I can't think of a good reason to set LANG=C in
/etc/environment.

-- 
see shy jo


pgp0.pgp
Description: PGP signature

Bug#210301: locales 2.3.2-6 won't configure

[Philip Blundell]

On Wed, 2003-09-10 at 17:28, Steve Doerr wrote:
> Any ideas on how I can get more info, or get around this?

You could try adding "set -x" to the script and invoking it by hand.

p.



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

Bug#210301: locales 2.3.2-6 won't configure

[Steve Doerr]

Package: locales
Version: 2.3.2-6
locales in the unstable distro won't seem to configure for me, but the 
error doesn't offer anything as to what it's failing on.  I tried to 
move locale.gen out of the way, but it doesn't make a difference.

The error:
bash-2.03# mv locale.gen locale.gen.old
bash-2.03# apt-get install locales --reinstall
Reading Package Lists... Done
Building Dependency Tree... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 409 not 
upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up locales (2.3.2-6) ...
dpkg: error processing locales (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
locales
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any ideas on how I can get more info, or get around this?
Thanks,
Steve


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

Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work

[Vincent Lefevre]

On 2003-09-10 11:17:25 +0100, Colin Watson wrote:
> On Wed, Sep 10, 2003 at 12:10:25PM +0200, Vincent Lefevre wrote:
> > I agree, but then, why not accept "ISO-8859-1" only, from the user's
> > point of view?
> 
> You might as well just leave it at C. It doesn't provide the case
> conversion functions (say) with any extra information.

But then, I would no longer be able to use accented characters.

> More to the point, it's not implemented, not required to be implemented,
> and not necessary for localization. :)

Being able to choose "ISO-8859-1" without giving the language could be
useful to use a single value on multiple machines, as not all locales
are installed (and not anyone is root to generate the missing locales).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:  - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, 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]

cvs commit to glibc-package/debian by gotom

[Debian GLibc CVS Master]

Repository: glibc-package/debian
who:gotom
time:   Wed Sep 10 05:34:14 MDT 2003
Log Message:
  start 2.3.2-7, and move some changes which is not reflected in 2.3.2-6.
  

Files:
changed:changelog


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

Bug#205099: Please test 2.3.2-6

[Colin Watson]

Hi,

It's a possibility that the pthread fix in glibc 2.3.2-6 has sorted out
these syslog() bugs too, which both appear to be SMP/threading issues.
Could you please retest with that version?

Thanks,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work

[Colin Watson]

On Wed, Sep 10, 2003 at 12:10:25PM +0200, Vincent Lefevre wrote:
> On 2003-09-10 10:58:10 +0100, Colin Watson wrote:
> > On Wed, Sep 10, 2003 at 06:27:01PM +0900, Vincent Lefevre wrote:
> > > But case conversion rules should apply to the language of the
> > > corresponding text, which isn't necessarily the same as the
> > > language chosen by the user (with LC_CTYPE).
> > 
> > C's toupper() and tolower() functions use LC_CTYPE. It's up to the
> > application to figure out if it needs to temporarily do something
> > different.
> 
> I agree, but then, why not accept "ISO-8859-1" only, from the user's
> point of view?

You might as well just leave it at C. It doesn't provide the case
conversion functions (say) with any extra information.

More to the point, it's not implemented, not required to be implemented,
and not necessary for localization. :)

-- 
Colin Watson  [EMAIL PROTECTED]


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

Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work

[Vincent Lefevre]

On 2003-09-10 10:58:10 +0100, Colin Watson wrote:
> On Wed, Sep 10, 2003 at 06:27:01PM +0900, Vincent Lefevre wrote:
> > But case conversion rules should apply to the language of the
> > corresponding text, which isn't necessarily the same as the
> > language chosen by the user (with LC_CTYPE).
> 
> C's toupper() and tolower() functions use LC_CTYPE. It's up to the
> application to figure out if it needs to temporarily do something
> different.

I agree, but then, why not accept "ISO-8859-1" only, from the user's
point of view? Then it's up to the application to select the language.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:  - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, 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]

Bug#209402: marked as done (locales: Setting LC_CTYPE to ISO-8859-1 does not work)

[Debian Bug Tracking System]

Your message dated Wed, 10 Sep 2003 11:45:55 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 9 Sep 2003 18:35:32 +
>From [EMAIL PROTECTED] Tue Sep 09 13:35:30 2003
Return-path: <[EMAIL PROTECTED]>
Received: from (bonniot.dyndns.org) [81.182.68.79] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19wnKr-0004AW-00; Tue, 09 Sep 2003 13:35:30 -0500
Received: from daniel by bonniot.dyndns.org with local (Exim 3.36 #1 (Debian))
id 19wnKq-0001WL-00; Tue, 09 Sep 2003 20:35:28 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Daniel Bonniot <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: locales: Setting LC_CTYPE to ISO-8859-1 does not work
X-Mailer: reportbug 2.27
Date: Tue, 09 Sep 2003 20:35:27 +0200
Message-Id: <[EMAIL PROTECTED]>
Sender: Daniel Bonniot <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-6.0 required=4.0
tests=BAYES_01,HAS_PACKAGE
version=2.53-bugs.debian.org_2003_8_27
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_8_27 
(1.174.2.15-2003-03-30-exp)

Package: locales
Version: 2.3.2-5
Severity: normal


Hi,

It seems that setting LC_CTYPE to ISO-8859-1 does not work for 
choosing a this specific charset, while setting it to "french" 
works.

Starting with an empty locale setting:
$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

$ LC_CTYPE=ISO-8859-1 locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=C
LC_CTYPE=ISO-8859-1
LC_NUMERIC="C"
[...]

$ LC_CTYPE=ISO-8859-1 perl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "ISO-8859-1",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

$ LC_CTYPE=french perl
# OK
^D
$ 

Note that is is not perl specific. This started to bite me after I 
discovered that the default encoding in a JVM was ascii, although I 
expected it to be ISO-8859-1.
For instance, running a program that lists the system properties:
$ LC_CTYPE=ISO-8859-1 java -jar ~/Nice/tmp/test.jar
file.encoding = ANSI_X3.4-1968
$ LC_CTYPE=french java -jar ~/Nice/tmp/test.jar
file.encoding = ISO-8859-1

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux blanche 2.4.21-4-686 #1 Sat Aug 2 23:27:25 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

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

-- debconf information:
* locales/default_environment_locale: C
* locales/locales_to_be_generated: fr_FR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, 
hu_HU ISO-8859-2


---
Received: (at 209402-done) by bugs.debian.org; 10 Sep 2003 09:45:58 +
>From [EMAIL PROTECTED] Wed Sep 10 04:45:57 2003
Return-path: <[EMAIL PROTECTED]>
Received: from (bonniot.dyndns.org) [81.182.68.4] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19x1Xw-0005mB-00; Wed, 10 Sep 2003 04:45:57 -0500
Received: from bonniot.dyndns.org
([127.0.0.1] helo=inria.fr ident=daniel)
by bonniot.dyndns.org with esmtp (Exim 3.36 #1 (Debian))
id 19x1Xv-Sm-00
for <[EMAIL PROTECTED]>; Wed, 10 Sep 2003 11:45:55 +0200
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 10 Sep 2003 11:45:55 +0200
From: Daniel Bonniot <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030827 Debian/1.4-3
X-Accept-Language: en
MIME-Version: 1.0
CC: [EMAIL PROTECTED]
Subject: Re: Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not
 work
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Tran

Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work

[Colin Watson]

On Wed, Sep 10, 2003 at 06:27:01PM +0900, Vincent Lefevre wrote:
> On Wed, Sep 10, 2003 at 02:07:03 +0100, Colin Watson wrote:
> > The LC_CTYPE variable sets the character classification and case
> > conversion rules. Picking an encoding is just one part of this: things
> > like case conversion rules vary considerably between languages and
> > probably even variants of languages, and there isn't a reasonable way
> > for the C library to guess which one you meant.
> 
> But case conversion rules should apply to the language of the
> corresponding text, which isn't necessarily the same as the
> language chosen by the user (with LC_CTYPE).

C's toupper() and tolower() functions use LC_CTYPE. It's up to the
application to figure out if it needs to temporarily do something
different.

-- 
Colin Watson  [EMAIL PROTECTED]


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

Bug#209402: locales: Setting LC_CTYPE to ISO-8859-1 does not work

[Vincent Lefevre]

On Wed, Sep 10, 2003 at 02:07:03 +0100, Colin Watson wrote:
> On Tue, Sep 09, 2003 at 11:07:38PM +0200, Daniel Bonniot wrote:
> > Colin Watson wrote:
> > >Try 'LC_CTYPE=fr_FR.ISO-8859-1' instead. You need the language and
> > >country parts there.
> > 
> > That works. However I wonder: why do I need to specifiy a language and 
> > country? ISO-8859-1 is ISO-8859-1, independently of any specific 
> > country, after all.
> 
> The LC_CTYPE variable sets the character classification and case
> conversion rules. Picking an encoding is just one part of this: things
> like case conversion rules vary considerably between languages and
> probably even variants of languages, and there isn't a reasonable way
> for the C library to guess which one you meant.

But case conversion rules should apply to the language of the
corresponding text, which isn't necessarily the same as the
language chosen by the user (with LC_CTYPE).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:  - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, 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]