Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW. Since Etch will be Debian's first UTF-8 release - implying a migration from legacy encodings for those upgrading from Sarge, which is precisely what this tool tackles - it would be nice to approve it for Etch. -- Martin-Éric Racine http://q-funk.iki.fi
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
Martin-Éric Racine wrote:
Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW.
Since Etch will be Debian's first UTF-8 release - implying a migration
from legacy encodings for those upgrading from Sarge, which is precisely
what this tool tackles - it would be nice to approve it for Etch.
Hello,
1) [EMAIL PROTECTED]:~$ utf8migrationtool
Unexpected error: exceptions.IOError
Traceback (most recent call last):
File /usr/bin/utf8migrationtool, line 40, in ?
dmrc = getconfig()
File /usr/bin/utf8migrationtool, line 34, in getconfig
config.readfp(open(os.path.expanduser('~/.dmrc')))
IOError: [Errno 2] No such file or directory: '/home/patrakov/.dmrc'
2) The tool must handle the already-migrated case better (e.g., by adding a
line about that onto the second screen).
3) The legacy locale for Russia is ru_RU.KOI8-R, not ru_RU, and the
migration tool must handle this special case.
4) migration of encodings is only a part of the game. The most important
part is to deal with packages that do not work correctly in UTF-8 locales
and cannot be fixed (e.g., a2ps). Since this part cannot be automated (as
nobody has created such blacklist), I suggest mentioning this obstacle in
the manual page and on the welcome screen.
Thus, I cannot recommend migration of this package to Etch in its current shape.
--
Alexander E. Patrakov
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
Martin-Éric Racine wrote:
su, 2006-12-31 kello 18:55 +0500, Alexander E. Patrakov kirjoitti:
Martin-Éric Racine wrote:
Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW.
Since Etch will be Debian's first UTF-8 release - implying a migration
from legacy encodings for those upgrading from Sarge, which is precisely
what this tool tackles - it would be nice to approve it for Etch.
Hello,
1) [EMAIL PROTECTED]:~$ utf8migrationtool
Unexpected error: exceptions.IOError
Traceback (most recent call last):
File /usr/bin/utf8migrationtool, line 40, in ?
dmrc = getconfig()
File /usr/bin/utf8migrationtool, line 34, in getconfig
config.readfp(open(os.path.expanduser('~/.dmrc')))
IOError: [Errno 2] No such file or directory: '/home/patrakov/.dmrc'
Works fine here, so no comment.
This is because you have the .dmrc file. I don't (I created an empty file to
get past this error when writing my first mail). This file presumably
belongs to gdm, but I don't have gdm (I use startx), and your package
installs fine without gdm. Missing dependency?
2) The tool must handle the already-migrated case better (e.g., by adding a
line about that onto the second screen).
It does. Here, it says that the locale is already migrated. It also says
that it cannot find any files utilizing a legacy encoding.
Yes, it does, in the case when the old locale is from .dmrc.
3) The legacy locale for Russia is ru_RU.KOI8-R, not ru_RU, and the
migration tool must handle this special case.
Russian is a messy case. Too many encodings, more than half of which are
OS-specific or otherwise standards that never gained momentum. This is
further complicated by usage cases: while Unices tend to go for KOI8-R,
users that need to interact with Windows use CP1251 instead. Still, it's
up to Russian developers to add support for this; upstream simply cannot
anticipate every possible exception.
OK, I temporarily take this back (because the old report was based on empty
.dmrc - but anyway, you could take the .KOI8-R part from $LANG). However, I
replace my old report with this: when the old .dmrc contains
[Desktop]
Language=ru_RU.KOI8-R
the migration tool migrates this to ru_RU.KOI8-R.UTF-8 which is wrong. Also
it migrates [EMAIL PROTECTED] to [EMAIL PROTECTED]
The locale names generally have the form:
[EMAIL PROTECTED] (where .CODESET and @MODIFIERS may or may not be
present). The old codeset and the @euro modifier (but probably not other
modifiers) must be stripped out.
4) migration of encodings is only a part of the game. The most important
part is to deal with packages that do not work correctly in UTF-8 locales
and cannot be fixed (e.g., a2ps). Since this part cannot be automated (as
nobody has created such blacklist), I suggest mentioning this obstacle in
the manual page and on the welcome screen.
Remaining UCS issues really belong in Etch's release notes, since it is
Debian's first release claiming UTF-8 support.
Yes, they do. However, not everyone reads the release notes, so why not
point users to them explicitly on the welcome screen?
Thus, I cannot recommend migration of this package to Etch in its current shape.
And I still say this.
--
Alexander E. Patrakov
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
su, 2006-12-31 kello 18:55 +0500, Alexander E. Patrakov kirjoitti:
Martin-Éric Racine wrote:
Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW.
Since Etch will be Debian's first UTF-8 release - implying a migration
from legacy encodings for those upgrading from Sarge, which is precisely
what this tool tackles - it would be nice to approve it for Etch.
Hello,
1) [EMAIL PROTECTED]:~$ utf8migrationtool
Unexpected error: exceptions.IOError
Traceback (most recent call last):
File /usr/bin/utf8migrationtool, line 40, in ?
dmrc = getconfig()
File /usr/bin/utf8migrationtool, line 34, in getconfig
config.readfp(open(os.path.expanduser('~/.dmrc')))
IOError: [Errno 2] No such file or directory: '/home/patrakov/.dmrc'
Works fine here, so no comment.
2) The tool must handle the already-migrated case better (e.g., by adding a
line about that onto the second screen).
It does. Here, it says that the locale is already migrated. It also says
that it cannot find any files utilizing a legacy encoding.
3) The legacy locale for Russia is ru_RU.KOI8-R, not ru_RU, and the
migration tool must handle this special case.
Russian is a messy case. Too many encodings, more than half of which are
OS-specific or otherwise standards that never gained momentum. This is
further complicated by usage cases: while Unices tend to go for KOI8-R,
users that need to interact with Windows use CP1251 instead. Still, it's
up to Russian developers to add support for this; upstream simply cannot
anticipate every possible exception.
4) migration of encodings is only a part of the game. The most important
part is to deal with packages that do not work correctly in UTF-8 locales
and cannot be fixed (e.g., a2ps). Since this part cannot be automated (as
nobody has created such blacklist), I suggest mentioning this obstacle in
the manual page and on the welcome screen.
Remaining UCS issues really belong in Etch's release notes, since it is
Debian's first release claiming UTF-8 support.
Thus, I cannot recommend migration of this package to Etch in its current
shape.
I'd still go for it. Applications for which upstream cannot be bothered
with supporting UCS or locales that create exception cases are not an
excuse to deprive users of this tool.
--
Martin-Éric Racine
http://q-funk.iki.fi
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
su, 2006-12-31 kello 20:42 +0500, Alexander E. Patrakov kirjoitti:
Martin-Éric Racine wrote:
su, 2006-12-31 kello 18:55 +0500, Alexander E. Patrakov kirjoitti:
Martin-Éric Racine wrote:
Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW.
Since Etch will be Debian's first UTF-8 release - implying a migration
from legacy encodings for those upgrading from Sarge, which is precisely
what this tool tackles - it would be nice to approve it for Etch.
Hello,
1) [EMAIL PROTECTED]:~$ utf8migrationtool
Unexpected error: exceptions.IOError
Traceback (most recent call last):
File /usr/bin/utf8migrationtool, line 40, in ?
dmrc = getconfig()
File /usr/bin/utf8migrationtool, line 34, in getconfig
config.readfp(open(os.path.expanduser('~/.dmrc')))
IOError: [Errno 2] No such file or directory: '/home/patrakov/.dmrc'
Works fine here, so no comment.
This is because you have the .dmrc file. I don't (I created an empty file to
get past this error when writing my first mail). This file presumably
belongs to gdm, but I don't have gdm (I use startx), and your package
installs fine without gdm. Missing dependency?
I don't see why it would depend upon GDM, though, since Ubuntu (which is
where the package originates from) also supports KDE and XFCE.
2) The tool must handle the already-migrated case better (e.g., by adding
a
line about that onto the second screen).
It does. Here, it says that the locale is already migrated. It also says
that it cannot find any files utilizing a legacy encoding.
Yes, it does, in the case when the old locale is from .dmrc.
It's starting to look that way. :(
3) The legacy locale for Russia is ru_RU.KOI8-R, not ru_RU, and the
migration tool must handle this special case.
Russian is a messy case. Too many encodings, more than half of which are
OS-specific or otherwise standards that never gained momentum. This is
further complicated by usage cases: while Unices tend to go for KOI8-R,
users that need to interact with Windows use CP1251 instead. Still, it's
up to Russian developers to add support for this; upstream simply cannot
anticipate every possible exception.
OK, I temporarily take this back (because the old report was based on empty
.dmrc - but anyway, you could take the .KOI8-R part from $LANG). However, I
replace my old report with this: when the old .dmrc contains
[Desktop]
Language=ru_RU.KOI8-R
the migration tool migrates this to ru_RU.KOI8-R.UTF-8 which is wrong. Also
it migrates [EMAIL PROTECTED] to [EMAIL PROTECTED]
The locale names generally have the form:
[EMAIL PROTECTED] (where .CODESET and @MODIFIERS may or may not be
present). The old codeset and the @euro modifier (but probably not other
modifiers) must be stripped out.
Noted.
4) migration of encodings is only a part of the game. The most important
part is to deal with packages that do not work correctly in UTF-8 locales
and cannot be fixed (e.g., a2ps). Since this part cannot be automated (as
nobody has created such blacklist), I suggest mentioning this obstacle in
the manual page and on the welcome screen.
Remaining UCS issues really belong in Etch's release notes, since it is
Debian's first release claiming UTF-8 support.
Yes, they do. However, not everyone reads the release notes,
Which then becomes the user's own problem.
Thus, I cannot recommend migration of this package to Etch in its current
shape.
And I still say this.
Sadly, I'm starting to agree. :(
However, this also means that users will need to manually upgrade their
system, which his far from ideal.
If anyone would care to contribute code towards fixing the above, it
would still be highly relevant for Etch. At any rate, this software's
usefulness post-Etch would essentially be zero, so it's pretty much a
now-or-never case.
--
Martin-Éric Racine
http://q-funk.iki.fi
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
On Sun, Dec 31, 2006 at 08:42:40PM +0500, Alexander E. Patrakov wrote: This is because you have the .dmrc file. I don't (I created an empty file to get past this error when writing my first mail). This file presumably belongs to gdm, but I don't have gdm (I use startx), and your package installs fine without gdm. Missing dependency? I think gdm|kdm but maybe gdm|kdm|wdm is needed. xdm and startx does not work as I vaguely remember for m17n-env package I made which I requested removal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
Osamu Aoki wrote: On Sun, Dec 31, 2006 at 08:42:40PM +0500, Alexander E. Patrakov wrote: This is because you have the .dmrc file. I don't (I created an empty file to get past this error when writing my first mail). This file presumably belongs to gdm, but I don't have gdm (I use startx), and your package installs fine without gdm. Missing dependency? I think gdm|kdm but maybe gdm|kdm|wdm is needed. xdm and startx does not work as I vaguely remember for m17n-env package I made which I requested removal. Sorry for a stupid question, but what does the .dmrc file contain for a kdm or wdm user? -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
On Sunday, 31 December 2006 17:14, Alexander E. Patrakov wrote: Osamu Aoki wrote: On Sun, Dec 31, 2006 at 08:42:40PM +0500, Alexander E. Patrakov wrote: This is because you have the .dmrc file. I don't (I created an empty file to get past this error when writing my first mail). This file presumably belongs to gdm, but I don't have gdm (I use startx), and your package installs fine without gdm. Missing dependency? I think gdm|kdm but maybe gdm|kdm|wdm is needed. xdm and startx does not work as I vaguely remember for m17n-env package I made which I requested removal. Sorry for a stupid question, but what does the .dmrc file contain for a kdm or wdm user? % cat .dmrc [Desktop] Session=kde -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpcAeFvKYz1v.pgp Description: PGP signature
Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
I'd suggest keeping debian-release out of this thread and instead including debian-i18n, which is where the skills needed to fix can be found. We can include debian-release again one the issues are fixed and the package is considered fit for release. :) -- Martin-Éric Racine http://q-funk.iki.fi
