libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale

[Debian Bug Importer]

Automatically imported from Debian bug report #272478 http://bugs.debian.org/272478

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #272478 http://bugs.debian.org/272478

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 20 Sep 2004 12:25:55 +0200
From: Laurent Martelli <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8
 locale

Package: libglib2.0-0
Version: 2.4.6-2
Severity: serious
Tags: patch
Justification: Policy 9.9

Unless the environment G_BROKEN_FILENAMES is or G_FILENAME_ENCODING is
set to "@locale", the encoding used fr filenames is utf-8 regardless
of the encoding of the locale, which in my opinion is not a
"reasonable default". Here's a patch to use the locale's encoding if
G_FILENAME_ENCODING is not set.

--- glib-2.4.6/glib/gconvert.c 2004-09-20 12:20:31.000000000 +0200
+++ glib-2.4.6-deb/glib/gconvert.c 2004-09-20 12:20:09.000000000 +0200
@@ -1069,16 +1069,12 @@
              cache->is_utf8 = (strcmp (cache->filename_charset, "UTF-8") == 0);
            }
        }
- else if (getenv ("G_BROKEN_FILENAMES") != NULL)
+ else
        {
          cache->is_utf8 = g_get_charset (&new_charset);
          cache->filename_charset = g_strdup (new_charset);
        }
- else
- {
- cache->filename_charset = g_strdup ("UTF-8");
- cache->is_utf8 = TRUE;
- }
+
     }

   if (filename_charset)

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (ignored: LC_ALL set to fr_FR@euro)

Versions of packages libglib2.0-0 depends on:
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an

-- no debconf information

[Sebastien Bacher (seb128)]

severity 272478 wishlist
tag 272478 + wontfix
thanks

Hi,

This has already been discuted again and again upstream, there is no
better solution than the current one to have a working utf-8 support.
I'll add some pointers to previous discussion a big later. For the
moment I change the severity of the bug to wishlist + wontfix since
upstreams are not going to change that.

Thanks,

Sebastien Bacher

[Laurent Martelli (laurent-aopsys-com)]

>>>>> "Sebastien" == Sebastien Bacher <email address hidden> writes:

  Sebastien> severity 272478 wishlist tag 272478 + wontfix thanks

  Sebastien> Hi,

  Sebastien> This has already been discuted again and again upstream,
  Sebastien> there is no better solution than the current one to have
  Sebastien> a working utf-8 support. I'll add some pointers to
  Sebastien> previous discussion a big later. For the moment I change
  Sebastien> the severity of the bug to wishlist + wontfix since
  Sebastien> upstreams are not going to change that.

If a user wants UTF-8 filenames, shouldn't he use an utf-8 locale ?
And all will be fine for him with a patch like mine. The current
behavious is completly bogus with a non utf-8 locale since programs
use the locale's encoding for filenames. Am I missing something ?

--
Laurent Martelli
<email address hidden> Java Aspect Components
http://www.aopsys.com/ http://jac.objectweb.org

[Josselin Mouette (joss)]

Le lundi 20 septembre 2004 à 20:15 +0200, Laurent Martelli a écrit :
> >>>>> "Sebastien" == Sebastien Bacher <email address hidden> writes:
>
> Sebastien> severity 272478 wishlist tag 272478 + wontfix thanks
>
> Sebastien> Hi,
>
> Sebastien> This has already been discuted again and again upstream,
> Sebastien> there is no better solution than the current one to have
> Sebastien> a working utf-8 support. I'll add some pointers to
> Sebastien> previous discussion a big later. For the moment I change
> Sebastien> the severity of the bug to wishlist + wontfix since
> Sebastien> upstreams are not going to change that.
>
> If a user wants UTF-8 filenames, shouldn't he use an utf-8 locale ?
> And all will be fine for him with a patch like mine. The current
> behavious is completly bogus with a non utf-8 locale since programs
> use the locale's encoding for filenames. Am I missing something ?

You're missing the point; especially, the locale setting is not system-
wide, and the files' accessibility shouldn't be affected by a locale
change. As there is no way to tell a filesystem which encoding the
filenames are in, the only solution is to use a single encoding for all
files.
--
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
  `- Debian GNU/Linux -- The power of freedom

[Sebastien Bacher (seb128)]

Le lundi 20 septembre 2004 à 20:15 +0200, Laurent Martelli a écrit :

> If a user wants UTF-8 filenames, shouldn't he use an utf-8 locale ?
> And all will be fine for him with a patch like mine. The current
> behavious is completly bogus with a non utf-8 locale since programs
> use the locale's encoding for filenames. Am I missing something ?

Look on http://bugzilla.gnome.org/show_bug.cgi?id=94672 for example:

"We consider locale-dependent filenames to be "broken" because:

  - Multiple users may have different loclale needs, but
    can't share a filesystem if the filenames are locale-dependent.
  - If a single user needs to switch to a different locale
    temporarily, all their filenames get reinterpreted.
  - Tar files with such filenames in them aren't portable.

Etc."

or http://bugzilla.gnome.org/show_bug.cgi?id=118923

Cheers,

Sebastien Bacher

[Debian Bug Importer (debzilla)]

Message-Id: <1095701375.5929.70.camel@seb128>
Date: Mon, 20 Sep 2004 19:29:35 +0200
From: Sebastien Bacher <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non
 UTF-8 locale

severity 272478 wishlist
tag 272478 + wontfix
thanks

Hi,

This has already been discuted again and again upstream, there is no
better solution than the current one to have a working utf-8 support.
I'll add some pointers to previous discussion a big later. For the
moment I change the severity of the bug to wishlist + wontfix since
upstreams are not going to change that.

Thanks,

Sebastien Bacher

[Sebastien Bacher (seb128)]

that's not a bug

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 20 Sep 2004 20:15:17 +0200
From: Laurent Martelli <email address hidden>
To: Sebastien Bacher <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Bug#272478: libglib2.0-0: Shouldn't require to set
 G_FILENAME_ENCODING in non UTF-8 locale

>>>>> "Sebastien" == Sebastien Bacher <email address hidden> writes:

  Sebastien> severity 272478 wishlist tag 272478 + wontfix thanks

  Sebastien> Hi,

  Sebastien> This has already been discuted again and again upstream,
  Sebastien> there is no better solution than the current one to have
  Sebastien> a working utf-8 support. I'll add some pointers to
  Sebastien> previous discussion a big later. For the moment I change
  Sebastien> the severity of the bug to wishlist + wontfix since
  Sebastien> upstreams are not going to change that.

If a user wants UTF-8 filenames, shouldn't he use an utf-8 locale ?
And all will be fine for him with a patch like mine. The current
behavious is completly bogus with a non utf-8 locale since programs
use the locale's encoding for filenames. Am I missing something ?

--
Laurent Martelli
<email address hidden> Java Aspect Components
http://www.aopsys.com/ http://jac.objectweb.org

[Laurent Martelli (laurent-aopsys-com)]

>>>>> "Josselin" == Josselin Mouette <email address hidden> writes:

  Josselin> Le lundi 20 septembre 2004 à 20:15 +0200, Laurent Martelli
  Josselin> a écrit :
  >> >>>>> "Sebastien" == Sebastien Bacher <email address hidden> writes:
  >>
  Sebastien> severity 272478 wishlist tag 272478 + wontfix thanks
  >>
  Sebastien> Hi,
  >>
  Sebastien> This has already been discuted again and again upstream,
  Sebastien> there is no better solution than the current one to have
  Sebastien> a working utf-8 support. I'll add some pointers to
  Sebastien> previous discussion a big later. For the moment I change
  Sebastien> the severity of the bug to wishlist + wontfix since
  Sebastien> upstreams are not going to change that.
  >> If a user wants UTF-8 filenames, shouldn't he use an utf-8
  >> locale ? And all will be fine for him with a patch like
  >> mine. The current behavious is completly bogus with a non utf-8
  >> locale since programs use the locale's encoding for filenames. Am
  >> I missing something ?

  Josselin> You're missing the point; especially, the locale setting
  Josselin> is not system- wide, and the files' accessibility
  Josselin> shouldn't be affected by a locale change. As there is no
  Josselin> way to tell a filesystem which encoding the filenames are
  Josselin> in, the only solution is to use a single encoding for all
  Josselin> files.

Sure, but then all programs which do not consider that filenames are
utf-8 encoded are buggy. And theer is quite a number of them. So I
think it would be best for the consistency of the system that all
programs behave the same "buggy" way. Or none at all.

Like I said to Sébastien in private, it seems worse to me that a user
cannot handle 2 file with 2 programs under the same locale than one
program with 2 different locales. Systems where different users use
different locales are not going to be fixed overnight with the
behaviour of glib. They will have to reencode all their filenames in
utf-8 and be sure that users use only utf-8 locales (in order to be
able to use all the programs still buggy). I believe the transition
would be smoother for all the systems like mine (one encoding is used
on all the system by all users) -- and not harder for others using
mixed locales -- if glib defaulted to using the locale's encoding for
filenames.

Regards,
Laurent

--
Laurent Martelli
<email address hidden> Java Aspect Components
http://www.aopsys.com/ http://jac.objectweb.org

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 20 Sep 2004 20:38:15 +0200
From: Josselin Mouette <email address hidden>
To: Laurent Martelli <email address hidden>, <email address hidden>
Subject: Re: Bug#272478: libglib2.0-0: Shouldn't require to set
 G_FILENAME_ENCODING in non UTF-8 locale

--=-02ahTdexxGV5QBb21eU8
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Le lundi 20 septembre 2004 =E0 20:15 +0200, Laurent Martelli a =E9crit :
> >>>>> "Sebastien" =3D=3D Sebastien Bacher <email address hidden> writes:
>=20
> Sebastien> severity 272478 wishlist tag 272478 + wontfix thanks
>=20
> Sebastien> Hi,
>=20
> Sebastien> This has already been discuted again and again upstream,
> Sebastien> there is no better solution than the current one to have
> Sebastien> a working utf-8 support. I'll add some pointers to
> Sebastien> previous discussion a big later. For the moment I change
> Sebastien> the severity of the bug to wishlist + wontfix since
> Sebastien> upstreams are not going to change that.
>=20
> If a user wants UTF-8 filenames, shouldn't he use an utf-8 locale ?
> And all will be fine for him with a patch like mine. The current
> behavious is completly bogus with a non utf-8 locale since programs
> use the locale's encoding for filenames. Am I missing something ?

You're missing the point; especially, the locale setting is not system-
wide, and the files' accessibility shouldn't be affected by a locale
change. As there is no way to tell a filesystem which encoding the
filenames are in, the only solution is to use a single encoding for all
files.
--=20
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
  `- Debian GNU/Linux -- The power of freedom

--=-02ahTdexxGV5QBb21eU8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBTyOXrSla4ddfhTMRAjaBAJ9Y+F+MdppWF2KLZBpnsypmZbkj5QCeLkwJ
IhhjyoJ/nZk90ll/vaZo3WA=
=U8XQ
-----END PGP SIGNATURE-----

--=-02ahTdexxGV5QBb21eU8--

[Debian Bug Importer (debzilla)]

Message-Id: <1095706382.5929.80.camel@seb128>
Date: Mon, 20 Sep 2004 20:53:02 +0200
From: Sebastien Bacher <email address hidden>
To: Laurent Martelli <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#272478: libglib2.0-0: Shouldn't require to set
 G_FILENAME_ENCODING in non UTF-8 locale

Le lundi 20 septembre 2004 =E0 20:15 +0200, Laurent Martelli a =E9crit :

> If a user wants UTF-8 filenames, shouldn't he use an utf-8 locale ?
> And all will be fine for him with a patch like mine. The current
> behavious is completly bogus with a non utf-8 locale since programs
> use the locale's encoding for filenames. Am I missing something ?

Look on http://bugzilla.gnome.org/show_bug.cgi?id=3D94672 for example:

"We consider locale-dependent filenames to be "broken" because:

  - Multiple users may have different loclale needs, but
    can't share a filesystem if the filenames are locale-dependent.
  - If a single user needs to switch to a different locale
    temporarily, all their filenames get reinterpreted.
  - Tar files with such filenames in them aren't portable.

Etc."

or http://bugzilla.gnome.org/show_bug.cgi?id=3D118923

Cheers,

Sebastien Bacher

[Josselin Mouette (joss)]

Le lundi 20 septembre 2004 à 22:16 +0200, Laurent Martelli a écrit :
> Sure, but then all programs which do not consider that filenames are
> utf-8 encoded are buggy. And theer is quite a number of them. So I
> think it would be best for the consistency of the system that all
> programs behave the same "buggy" way. Or none at all.

That's what G_BROKEN_FILENAMES is for.
--
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
  `- Debian GNU/Linux -- The power of freedom

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 20 Sep 2004 22:16:14 +0200
From: Laurent Martelli <email address hidden>
To: <email address hidden>
Subject: Re: Bug#272478: libglib2.0-0: Shouldn't require to set
 G_FILENAME_ENCODING in non UTF-8 locale

>>>>> "Josselin" == Josselin Mouette <email address hidden> writes:

  Josselin> Le lundi 20 septembre 2004 �0:15 +0200, Laurent Martelli
  Josselin> a �it :
  >> >>>>> "Sebastien" == Sebastien Bacher <email address hidden> writes:
  >>
  Sebastien> severity 272478 wishlist tag 272478 + wontfix thanks
  >>
  Sebastien> Hi,
  >>
  Sebastien> This has already been discuted again and again upstream,
  Sebastien> there is no better solution than the current one to have
  Sebastien> a working utf-8 support. I'll add some pointers to
  Sebastien> previous discussion a big later. For the moment I change
  Sebastien> the severity of the bug to wishlist + wontfix since
  Sebastien> upstreams are not going to change that.
  >> If a user wants UTF-8 filenames, shouldn't he use an utf-8
  >> locale ? And all will be fine for him with a patch like
  >> mine. The current behavious is completly bogus with a non utf-8
  >> locale since programs use the locale's encoding for filenames. Am
  >> I missing something ?

  Josselin> You're missing the point; especially, the locale setting
  Josselin> is not system- wide, and the files' accessibility
  Josselin> shouldn't be affected by a locale change. As there is no
  Josselin> way to tell a filesystem which encoding the filenames are
  Josselin> in, the only solution is to use a single encoding for all
  Josselin> files.

Sure, but then all programs which do not consider that filenames are
utf-8 encoded are buggy. And theer is quite a number of them. So I
think it would be best for the consistency of the system that all
programs behave the same "buggy" way. Or none at all.

Like I said to S�stien in private, it seems worse to me that a user
cannot handle 2 file with 2 programs under the same locale than one
program with 2 different locales. Systems where different users use
different locales are not going to be fixed overnight with the
behaviour of glib. They will have to reencode all their filenames in
utf-8 and be sure that users use only utf-8 locales (in order to be
able to use all the programs still buggy). I believe the transition
would be smoother for all the systems like mine (one encoding is used
on all the system by all users) -- and not harder for others using
mixed locales -- if glib defaulted to using the locale's encoding for
filenames.

Regards,
Laurent

--
Laurent Martelli
<email address hidden> Java Aspect Components
http://www.aopsys.com/ http://jac.objectweb.org

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 20 Sep 2004 23:51:39 +0200
From: Josselin Mouette <email address hidden>
To: Laurent Martelli <email address hidden>, <email address hidden>
Subject: Re: Bug#272478: libglib2.0-0: Shouldn't require to set
 G_FILENAME_ENCODING in non UTF-8 locale

--=-O8y8wRd55U0b10WDV2RH
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Le lundi 20 septembre 2004 =E0 22:16 +0200, Laurent Martelli a =E9crit :
> Sure, but then all programs which do not consider that filenames are
> utf-8 encoded are buggy. And theer is quite a number of them. So I
> think it would be best for the consistency of the system that all
> programs behave the same "buggy" way. Or none at all.

That's what G_BROKEN_FILENAMES is for.
--=20
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
  `- Debian GNU/Linux -- The power of freedom

--=-O8y8wRd55U0b10WDV2RH
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBT1DrrSla4ddfhTMRAr1hAJ0e09AVyw49bBStcHACnBvbYl4kaQCgl5qg
Fe3QttvsqX9GyxC850Ml0Fs=
=y4Sf
-----END PGP SIGNATURE-----

--=-O8y8wRd55U0b10WDV2RH--

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.9.27
forwarded 272478 http://bugzilla.gnome.org/show_bug.cgi?id=94672; http://bugzilla.gnome.org/show_bug.cgi?id=118923

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.9.27
tags 272478 - patch

[Bts-link-upstream (bts-link-upstream)]

#
# bts-link upstream status pull for source package glib2.0
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #272478
# * http://bugzilla.gnome.org/show_bug.cgi?id=94672
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> NOTABUG
# * closed upstream
tags 272478 + fixed-upstream
usertags 272478 + status-RESOLVED resolution-NOTABUG

# remote status report for #303124
# * http://bugzilla.gnome.org/show_bug.cgi?id=329031
# * remote status changed: (?) -> UNCONFIRMED
usertags 303124 + status-UNCONFIRMED

# remote status report for #323848
# * http://bugzilla.gnome.org/show_bug.cgi?id=394687
# * remote status changed: (?) -> UNCONFIRMED
usertags 323848 + status-UNCONFIRMED

thanks

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.9.27
tags 272478 + upstream

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.9.27
tags 272478 - fixed-upstream

[Bts-link-upstream (bts-link-upstream)]

#
# bts-link upstream status pull for source package glib2.0
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #264400
# * http://bugzilla.gnome.org/show_bug.cgi?id=456383
# * remote status changed: (?) -> UNCONFIRMED
usertags 264400 + status-UNCONFIRMED

# remote status report for #272478
# * http://bugzilla.gnome.org/show_bug.cgi?id=94672
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> NOTABUG
# * closed upstream
tags 272478 + fixed-upstream
usertags 272478 + status-RESOLVED resolution-NOTABUG

# remote status report for #393845
# * http://bugzilla.gnome.org/show_bug.cgi?id=362749
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> WONTFIX
usertags 393845 + status-RESOLVED resolution-WONTFIX

# remote status report for #414655
# * http://bugzilla.gnome.org/show_bug.cgi?id=417811
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> WONTFIX
usertags 414655 + status-RESOLVED resolution-WONTFIX

# remote status report for #457933
# * http://bugzilla.gnome.org/show_bug.cgi?id=506986
# * remote status changed: (?) -> UNCONFIRMED
usertags 457933 + status-UNCONFIRMED

# remote status report for #475488
# * http://bugzilla.gnome.org/show_bug.cgi?id=316221
# * remote status changed: (?) -> NEW
usertags 475488 + status-NEW

# remote status report for #476886
# * http://bugzilla.gnome.org/show_bug.cgi?id=529034
# * remote status changed: (?) -> UNCONFIRMED
usertags 476886 + status-UNCONFIRMED

thanks