libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
glib2.0 (Debian) |
Confirmed
|
Unknown
|
|||
glib2.0 (Ubuntu) |
Invalid
|
High
|
Unassigned |
Bug Description
Automatically imported from Debian bug report #272478 http://
Debian Bug Importer (debzilla) wrote : | #1 |
Debian Bug Importer (debzilla) wrote : | #2 |
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.
+++ glib-2.
@@ -1069,16 +1069,12 @@
}
}
- else if (getenv ("G_BROKEN_
+ else
{
}
- else
- {
- cache->
- 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
In Debian Bug tracker #272478, Sebastien Bacher (seb128) wrote : libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale | #3 |
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
In Debian Bug tracker #272478, Laurent Martelli (laurent-aopsys-com) wrote : Re: Bug#272478: libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale | #4 |
>>>>> "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://
In Debian Bug tracker #272478, Josselin Mouette (joss) wrote : Re: Bug#272478: libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale | #5 |
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
In Debian Bug tracker #272478, Sebastien Bacher (seb128) wrote : | #6 |
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://
"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://
Cheers,
Sebastien Bacher
Debian Bug Importer (debzilla) wrote : | #7 |
Message-Id: <1095701375.
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) wrote : | #8 |
that's not a bug
Debian Bug Importer (debzilla) wrote : | #9 |
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_
>>>>> "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://
In Debian Bug tracker #272478, Laurent Martelli (laurent-aopsys-com) wrote : Re: Bug#272478: libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale | #10 |
>>>>> "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://
Debian Bug Importer (debzilla) wrote : | #11 |
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_
--=-02ahTdexxGV
Content-Type: text/plain; charset=ISO-8859-15
Content-
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
--=-02ahTdexxGV
Content-Type: application/
Content-
=?ISO-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBTyOXrSl
IhhjyoJ/
=U8XQ
-----END PGP SIGNATURE-----
--=-02ahTdexxGV
Debian Bug Importer (debzilla) wrote : | #12 |
Message-Id: <1095706382.
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_
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://
"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://
Cheers,
Sebastien Bacher
In Debian Bug tracker #272478, Josselin Mouette (joss) wrote : Re: Bug#272478: libglib2.0-0: Shouldn't require to set G_FILENAME_ENCODING in non UTF-8 locale | #13 |
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) wrote : | #14 |
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_
>>>>> "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://
Debian Bug Importer (debzilla) wrote : | #15 |
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_
--=-O8y8wRd55U0
Content-Type: text/plain; charset=ISO-8859-15
Content-
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
--=-O8y8wRd55U0
Content-Type: application/
Content-
=?ISO-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBBT1DrrSl
Fe3QttvsqX9GyxC
=y4Sf
-----END PGP SIGNATURE-----
--=-O8y8wRd55U0
In Debian Bug tracker #272478, Loïc Minier (lool) wrote : bug 272478 is forwarded to http://bugzilla.gnome.org/show_bug.cgi?id=94672; http://bugzilla.gnome.org/show_bug.cgi?id=118923 | #16 |
# Automatically generated email from bts, devscripts version 2.9.27
forwarded 272478 http://
In Debian Bug tracker #272478, Loïc Minier (lool) wrote : tagging 272478 | #17 |
# Automatically generated email from bts, devscripts version 2.9.27
tags 272478 - patch
In Debian Bug tracker #272478, Bts-link-upstream (bts-link-upstream) wrote : [bts-link] source package glib2.0 | #18 |
#
# bts-link upstream status pull for source package glib2.0
# see http://
#
user <email address hidden>
# remote status report for #272478
# * http://
# * 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://
# * remote status changed: (?) -> UNCONFIRMED
usertags 303124 + status-UNCONFIRMED
# remote status report for #323848
# * http://
# * remote status changed: (?) -> UNCONFIRMED
usertags 323848 + status-UNCONFIRMED
thanks
In Debian Bug tracker #272478, Loïc Minier (lool) wrote : tagging 272478 | #19 |
# Automatically generated email from bts, devscripts version 2.9.27
tags 272478 + upstream
In Debian Bug tracker #272478, Loïc Minier (lool) wrote : | #20 |
# Automatically generated email from bts, devscripts version 2.9.27
tags 272478 - fixed-upstream
In Debian Bug tracker #272478, Bts-link-upstream (bts-link-upstream) wrote : [bts-link] source package glib2.0 | #21 |
#
# bts-link upstream status pull for source package glib2.0
# see http://
#
user <email address hidden>
# remote status report for #264400
# * http://
# * remote status changed: (?) -> UNCONFIRMED
usertags 264400 + status-UNCONFIRMED
# remote status report for #272478
# * http://
# * 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://
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> WONTFIX
usertags 393845 + status-RESOLVED resolution-WONTFIX
# remote status report for #414655
# * http://
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> WONTFIX
usertags 414655 + status-RESOLVED resolution-WONTFIX
# remote status report for #457933
# * http://
# * remote status changed: (?) -> UNCONFIRMED
usertags 457933 + status-UNCONFIRMED
# remote status report for #475488
# * http://
# * remote status changed: (?) -> NEW
usertags 475488 + status-NEW
# remote status report for #476886
# * http://
# * remote status changed: (?) -> UNCONFIRMED
usertags 476886 + status-UNCONFIRMED
thanks
Automatically imported from Debian bug report #272478 http:// bugs.debian. org/272478