dselect displays garbage in cs_CZ.UTF-8 locale
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpkg (Debian) |
New
|
Unknown
|
|||
dpkg (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
This is a UTF-8 problem common for several commandline programs. Midnight
commander has the save flaw. Some Czech characters are replaced by strange
sequences. Like:
* 0. [P]\uffff~Yístup Volba p\uffff~Yístupové metody.
1. [A]ktualizu Aktualizace informací o dostupných balících.
2. [V]yber Výb\uffff~[r balík\u016f pro instalaci a odinstalaci.
3. [N]ainstalu Instalace a aktualizace vybraných balík\u016f.
4. [K]konfigur Konfigurace v\u0161ech nezkonfigurovaných balík\u016f.
5. [O]dstra\uffff~H Odebrání ne\u017eádoucích balík\u016f.
6. [U]kon\uffff~Mit Ukon\uffff~Mení dselectu.
the \uffff characters are shown as spaces on gnome-terminal, but its of little help.
using the locale cs_CZ.ISO-8859-2 the same text displays as it should:
(obtained by luit -encoding ISO-8859-2 ssh my.czech.
* 0. [P]řístup Volba přístupové metody.
1. [A]ktualizu Aktualizace informací o dostupných balících.
2. [V]yber Výběr balíků pro instalaci a odinstalaci.
3. [N]ainstalu Instalace a aktualizace vybraných balíků.
4. [K]konfigur Konfigurace všech nezkonfigurovaných balíků.
5. [O]dstraň Odebrání nežádoucích balíků.
6. [U]končit Ukončení dselectu.
In case of dselect this problem is particulary anyoning, because if you run it with
different locale, some packages may get wrong idea about default system locale
while configured (perl).
In Debian Bug tracker #237675, Scott James Remnant (Canonical) (canonical-scott) wrote : retitle 237675 to retitle [UTF-8] patch for dselect UTF-8 support | #1 |
In Debian Bug tracker #237675, Scott James Remnant (Canonical) (canonical-scott) wrote : retitle 237675 to [UTF-8] patch for dselect UTF-8 support | #2 |
# Automatically generated email from bts, devscripts version 2.7.95.1
retitle 237675 [UTF-8] patch for dselect UTF-8 support
In Debian Bug tracker #237675, Changwoo Ryu (cwryu) wrote : Bug#237675: ok with ko_KR.utf-8 | #3 |
I tested the patch in my ko_KR.UTF-8 locale and it worked very well.
All the UTF-8 breakages seemed to be fixed.
In Debian Bug tracker #237675, Changwoo Ryu (cwryu) wrote : | #4 |
> I tested the patch in my ko_KR.UTF-8 locale and it worked very well.
> All the UTF-8 breakages seemed to be fixed.
>
>
Oops, there were some truncated strings by the multibyte-unaware use of
*addnstr() functions.
New patch attached: I wrote some replacement functions for those
functions to fix them.
In Debian Bug tracker #237675, Changwoo Ryu (cwryu) wrote : Bug#237675: new multibyte patch | #5 |
> New patch attached: I wrote some replacement functions for those
> functions to fix them.
A bit more simplified patch attached.
In Debian Bug tracker #237675, Christian Perrier (bubulle) wrote : tagging 237675 | #6 |
# Automatically generated email from bts, devscripts version 2.8.5
tags 237675 l10n
Jan (debian-gepro) wrote : | #7 |
This is a UTF-8 problem common for several commandline programs. Midnight
commander has the save flaw. Some Czech characters are replaced by strange
sequences. Like:
* 0. [P]\uffff~Yístup Volba p\uffff~Yístupové metody.
1. [A]ktualizu Aktualizace informací o dostupných balících.
2. [V]yber Výb\uffff~[r balík\u016f pro instalaci a odinstalaci.
3. [N]ainstalu Instalace a aktualizace vybraných balík\u016f.
4. [K]konfigur Konfigurace v\u0161ech nezkonfigurovaných balík\u016f.
5. [O]dstra\uffff~H Odebrání ne\u017eádoucích balík\u016f.
6. [U]kon\uffff~Mit Ukon\uffff~Mení dselectu.
the \uffff characters are shown as spaces on gnome-terminal, but its of little help.
using the locale cs_CZ.ISO-8859-2 the same text displays as it should:
(obtained by luit -encoding ISO-8859-2 ssh my.czech.
* 0. [P]řístup Volba přístupové metody.
1. [A]ktualizu Aktualizace informací o dostupných balících.
2. [V]yber Výběr balíků pro instalaci a odinstalaci.
3. [N]ainstalu Instalace a aktualizace vybraných balíků.
4. [K]konfigur Konfigurace všech nezkonfigurovaných balíků.
5. [O]dstraň Odebrání nežádoucích balíků.
6. [U]končit Ukončení dselectu.
In case of dselect this problem is particulary anyoning, because if you run it with
different locale, some packages may get wrong idea about default system locale
while configured (perl).
In Debian Bug tracker #237675, Changwoo Ryu (cwryu) wrote : Removing L10N tag, these are I18N ones | #8 |
tag 237675 - l10n
tag 257575 - l10n
thanks
They are not directly related to the L10N of specific languages, but
apply to any UTF-8 locale users. (though european users may not see
any visible problem.)
--
Changwoo Ryu
In Debian Bug tracker #237675, Changwoo Ryu (cwryu) wrote : Re: Bug#237675: [UTF-8] patch for dselect UTF-8 support | #9 |
If the patch is too long to be accepted for now, how about starting
with replacing libncurses5 with libncursesw5? Just replacing, without
touching other things, is also useful.
The only problem is that libncursesw5 is not in base... but
after sarge all programs can be replaced.
--
Changwoo Ryu
Michal Suchanek (hramrach) wrote : | #10 |
Is this on console or in X?
If in X, try setting the encoding in gnome-terminal preferences or running the
application in uxterm (that should come with X unless somebody removed it during
packaging).
Jan (debian-gepro) wrote : | #11 |
(In reply to comment #1)
It's everywhere including the console and ssh session of putty. The best "cure"
I have discovered is changing the corresponding line in
/etc/environment back to cs_CZ.ISO-8859-2 and installing the
package "fonty".
Gnome continue using UTF-8 but the remote commandline is OK
(unless you created some files with UTF-8 names).
This fix would allow using Hoary as server at least, but since there is
a fatal error in Czech Hoary installer (#8801) and Sarge is out we can spare the
effort for the present.
Colin Watson (cjwatson) wrote : | #12 |
Scott, there's a patch for UTF-8 support in Debian bug #237675; is there a
problem with it, or do you want me to review it?
Scott James Remnant (Canonical) (canonical-scott) wrote : | #13 |
Review it, if it's good to go, I'll stick it in 1.13 with pleasure
Debian Bug Importer (debzilla) wrote : | #14 |
Message-Id: <email address hidden>
Date: Fri, 12 Mar 2004 19:37:32 +0200
From: Eugeniy Meshcheryakov <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: patch for UTF-8 support
--=====
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-
Content-
Package: dselect
Version: 1.10.20
Severity: normal
Tags: patch
dselect does not support UTF-8 so I have prepared a patch (attached) to fix it.
What this patch do:
- compile dselect with libncursesw5 instead of libncurses
- calculate and use string widths in colums instead of sizes in bytes
when needed (use standart C99 functions for this).
- text wrapping code is too complicated for me to rewrite it, so i
have used libtextwrap for that.
Problems:
- textwrap hangs if string contains illegal symbols (in UTF-8), this
is bug #237630. So debconf hangs while displaying description for
some packages (doc-linux-text-pt -- is it a bug in this package
too?).
- text wrapping is different for some packages (manpages - is its'
dsecription (indentation) correct?)
- it does not display horisontal lines around section descriptions in
linux terminal with KOI8-U encoding (but displays them in jfbterm
and konsole and with UTF-8 encoding -- may be bug in libncursesw?)
- some format strings was changed, requires new translations.
I have tested this patch with ru_RU and ja_JP locales. I have not found
other problems. Text with both languages looks same with different
encodings (KOI8-R and UTF-8 for Russian, EUC-JP and UTF-8 for Japanese).
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.25
Locale: LANG=uk_UA, LC_CTYPE=uk_UA
Versions of packages dselect depends on:
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.3-2 GCC support library
ii libncursesw5 5.4-2 Shared libraries for terminal hand
ii libstdc++5 1:3.3.3-2 The GNU Standard C++ Library v3
ii libtextwrap1 0.1-1 text-wrapping library with i18n -
-- no debconf information
--=====
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-
Content-
diff -urN orig/dpkg-
--- orig/dpkg-
+++ dpkg-1.
@@ -182,12 +182,18 @@
# check for the proper curses library. This can be either
# -lcurses or -lncurses, we need to check for either one.
-AC_CHECK_
+AC_CHECK_
if test "x$CURSES_LIBS" = "x"; then
AC_MSG_WARN(no curses libr...
Debian Bug Importer (debzilla) wrote : | #15 |
Message-Id: <E1BLpzk-
Date: Thu, 6 May 2004 22:01:28 +0100
From: Scott James Remnant <email address hidden>
To: <email address hidden>
Subject: retitle 237675 to retitle [UTF-8] patch for dselect UTF-8 support
# Automatically generated email from bts, devscripts version 2.7.95.1
retitle 237675 retitle [UTF-8] patch for dselect UTF-8 support
Debian Bug Importer (debzilla) wrote : | #16 |
Message-Id: <E1BLqCw-
Date: Thu, 6 May 2004 22:15:06 +0100
From: Scott James Remnant <email address hidden>
To: <email address hidden>
Subject: retitle 237675 to [UTF-8] patch for dselect UTF-8 support
# Automatically generated email from bts, devscripts version 2.7.95.1
retitle 237675 [UTF-8] patch for dselect UTF-8 support
Debian Bug Importer (debzilla) wrote : | #17 |
Message-Id: <email address hidden>
Date: Sun, 20 Jun 2004 19:47:07 +0900
From: Changwoo Ryu <email address hidden>
To: <email address hidden>
Subject: Bug#237675: ok with ko_KR.utf-8
I tested the patch in my ko_KR.UTF-8 locale and it worked very well.
All the UTF-8 breakages seemed to be fixed.
Debian Bug Importer (debzilla) wrote : | #18 |
Message-Id: <email address hidden>
Date: Sun, 20 Jun 2004 22:08:55 +0900
From: Changwoo Ryu <email address hidden>
To: <email address hidden>
Subject: Re: Bug#237675: ok with ko_KR.utf-8
--=-d27/
Content-Type: text/plain
Content-
> I tested the patch in my ko_KR.UTF-8 locale and it worked very well.
> All the UTF-8 breakages seemed to be fixed.
>
>
Oops, there were some truncated strings by the multibyte-unaware use of
*addnstr() functions.
New patch attached: I wrote some replacement functions for those
functions to fix them.
--=-d27/
Content-
Content-Type: text/x-patch; name=dselect-
Content-
diff -uNr dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -74,6 +74,7 @@
SSD_LIBS = @SSD_LIBS@
CURSES_LIBS = @CURSES_LIBS@
+TEXTWRAP_LIBS = @TEXTWRAP_LIBS@
ZLIB_CFLAGS = @ZLIB_CFLAGS@
ZLIB_LIBS = @ZLIB_LIBS@
diff -uNr dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -184,12 +184,18 @@
# check for the proper curses library. This can be either
# -lcurses or -lncurses, we need to check for either one.
-AC_CHECK_
+AC_CHECK_
if test "x$CURSES_LIBS" = "x"; then
AC_MSG_WARN(no curses library found)
fi
AC_SUBST(
+AC_CHECK_
+if test "x$TEXTWRAP_LIBS" = "x"; then
+ AC_MSG_WARN(not textwrap library found)
+fi
+AC_SUBST(
+
DPKG_CHECK_
ZLIB_CFLAGS=
@@ -464,7 +470,7 @@
])
-AC_OUTPUT( po/Makefile.in
+AC_OUTPUT( po/Makefile.in
Makefile.conf
Makefile
include/Makefile
diff -uNr dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -6,7 +6,7 @@
Origin: debian
Bugs: debbugs:
Standards-Version: 3.5.8
-Build-Depends: debiandoc-sgml, sgml-base (>= 1.9.1), sgmltools-lite, libncurses-dev, gettext (>= 0.12.1-3), zlib1g-dev (>= 1:1.1.3-19.1), autotools-dev
+Build-Depends: debiandoc-sgml, sgml-base (>= 1.9.1), sgmltools-lite, libncursesw5-dev, gettext (>= 0.12.1-3), zlib1g-dev (>= 1:1.1.3-19.1), autotools-dev, libtextwrap-dev
Package: dpkg
Architecture: any
diff -uNr dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -5,11 +5,11 @@
default: ...
Debian Bug Importer (debzilla) wrote : | #19 |
Message-Id: <email address hidden>
Date: Wed, 23 Jun 2004 04:25:31 +0900
From: Changwoo Ryu <email address hidden>
To: <email address hidden>
Subject: Bug#237675: new multibyte patch
--=-I4inkMNQ8cH
Content-Type: text/plain
Content-
> New patch attached: I wrote some replacement functions for those
> functions to fix them.
A bit more simplified patch attached.
--=-I4inkMNQ8cH
Content-
Content-Type: text/x-patch; name=dselect-
Content-
diff -uNr -x '*~' -x autom4te.cache -x configure -x '*.po' -x '*.pot' dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -74,6 +74,7 @@
SSD_LIBS = @SSD_LIBS@
CURSES_LIBS = @CURSES_LIBS@
+TEXTWRAP_LIBS = @TEXTWRAP_LIBS@
ZLIB_CFLAGS = @ZLIB_CFLAGS@
ZLIB_LIBS = @ZLIB_LIBS@
diff -uNr -x '*~' -x autom4te.cache -x configure -x '*.po' -x '*.pot' dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -184,12 +184,18 @@
# check for the proper curses library. This can be either
# -lcurses or -lncurses, we need to check for either one.
-AC_CHECK_
+AC_CHECK_
if test "x$CURSES_LIBS" = "x"; then
AC_MSG_WARN(no curses library found)
fi
AC_SUBST(
+AC_CHECK_
+if test "x$TEXTWRAP_LIBS" = "x"; then
+ AC_MSG_WARN(not textwrap library found)
+fi
+AC_SUBST(
+
DPKG_CHECK_
ZLIB_CFLAGS=
diff -uNr -x '*~' -x autom4te.cache -x configure -x '*.po' -x '*.pot' dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -6,7 +6,7 @@
Origin: debian
Bugs: debbugs:
Standards-Version: 3.5.8
-Build-Depends: debiandoc-sgml, sgml-base (>= 1.9.1), sgmltools-lite, libncurses-dev, gettext (>= 0.12.1-3), zlib1g-dev (>= 1:1.1.3-19.1), autotools-dev
+Build-Depends: debiandoc-sgml, sgml-base (>= 1.9.1), sgmltools-lite, libncursesw5-dev, gettext (>= 0.12.1-3), zlib1g-dev (>= 1:1.1.3-19.1), autotools-dev, libtextwrap-dev
Package: dpkg
Architecture: any
diff -uNr -x '*~' -x autom4te.cache -x configure -x '*.po' -x '*.pot' dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -0,0 +1 @@
+shlibs:
Debian Bug Importer (debzilla) wrote : | #20 |
Message-Id: <email address hidden>
Date: Tue, 12 Oct 2004 14:37:15 +0200
From: Christian Perrier <email address hidden>
To: <email address hidden>
Subject: tagging 237675
# Automatically generated email from bts, devscripts version 2.8.5
tags 237675 l10n
Debian Bug Importer (debzilla) wrote : | #21 |
Message-ID: <email address hidden>
Date: Thu, 3 Mar 2005 13:50:25 +0900
From: Changwoo Ryu <email address hidden>
To: <email address hidden>
Subject: Removing L10N tag, these are I18N ones
tag 237675 - l10n
tag 257575 - l10n
thanks
They are not directly related to the L10N of specific languages, but
apply to any UTF-8 locale users. (though european users may not see
any visible problem.)
--
Changwoo Ryu
Debian Bug Importer (debzilla) wrote : | #22 |
Message-ID: <email address hidden>
Date: Thu, 3 Mar 2005 16:18:20 +0900
From: Changwoo Ryu <email address hidden>
To: <email address hidden>
Subject: Re: Bug#237675: [UTF-8] patch for dselect UTF-8 support
--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-
If the patch is too long to be accepted for now, how about starting
with replacing libncurses5 with libncursesw5? Just replacing, without
touching other things, is also useful.
The only problem is that libncursesw5 is not in base... but
after sarge all programs can be replaced.
--
Changwoo Ryu
--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-
diff -ur dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -184,7 +184,7 @@
# check for the proper curses library. This can be either
# -lcurses or -lncurses, we need to check for either one.
-AC_CHECK_
+AC_CHECK_
if test "x$CURSES_LIBS" = "x"; then
AC_MSG_WARN(no curses library found)
fi
Only in dpkg-1.
Only in dpkg-1.
diff -ur dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -1,3 +1,9 @@
+dpkg (1.10.27.ncursesw) unstable; urgency=low
+
+ * Use ncursesw instead of ncurses.
+
+ -- Changwoo Ryu <email address hidden> Thu, 3 Mar 2005 11:30:19 +0900
+
dpkg (1.10.27) unstable; urgency=low
The "Grab your gun and bring in the cat" Release.
Only in dpkg-1.
Only in dpkg-1.
Only in dpkg-1.
diff -ur dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -53,7 +53,7 @@
curkeys.o: curkeys.h
curkeys.h: keyoverride $(srcdir)
- cursesfile=`echo '#include <curses.h>' | \
+ cursesfile=`echo '#include <ncursesw/
$(CC) -E - | grep 'curses.h' | head -n 1 | \
$(SED) -e 's/^[^"]*"//; s/".*$$//'`; \
if [ "$$cursesfile" = "" ]; then echo "can't find curses file"; exit 1; fi; \
diff -ur dpkg-1.
--- dpkg-1.
+++ dpkg-1.
@@ -28,7 +28,7 @@
#include <signal.h>
#undef ERR
-#include <curses.h>
+#include <ncursesw/curses.h>
struct helpmenuentry {
char key;
diff -ur dpkg-1.
Jonathan Anderson (jonathan-anderson) wrote : | #23 |
"Review it, if it's good to go, I'll stick it in 1.13 with pleasure"
Anything happen with this? The bug is still listed as Unconfirmed...
Jan (debian-gepro) wrote : | #24 |
>Anything happen with this? The bug is still listed as Unconfirmed...
Yes this bug is still present. Since it is immedialy apparent on dselect invocation the only explanation for the fruitles wait for confirmation is a fact I am the last Chech using deselect. This brings me to the conclusion that removing the localization altogether would be a best cure. I do speek english good enough not to miss it and others apparently don't care.
In Debian Bug tracker #237675, Bruce Sass (bmsass) wrote : UTF-8 problems | #25 |
forcemerge 237675 208992
stop
fixing UTF-8 support (#237675) should also solve the issues in #208992
- Bruce
In Debian Bug tracker #237675, Nicolas François (nicolas-francois) wrote : Re: Bug#410855: menu and help text broken with Polish UTF-8 locale (pl_PL.UTF-8) | #26 |
severity 410855 normal
merge 237675 410855
thanks
On Wed, Feb 14, 2007 at 03:23:14PM +0000, <email address hidden> wrote:
> Nicolas François wrote:
> > Can you provide more information?
> > Can you for example cut and paste what you see (in a gzipped text file, or
> > a screen shot).
> > It would be nice also if you could provide what you guess should be the
> > correct form.
>
> Here's the screenshot. I think I don't need to explain which characters
> aren't properly displayed.
Thanks for the screenshot.
I forgot that there is a known issue with wide character strings in
dselect. (see #237675)
This can be fixed by linking against libncursesw5 instead of libncurses5.
I updated the simplified patch sent by Changwoo Ryu.
If it can be applied for Etch (I'm not sure this bug applies to the UTF-8
bugs which can have a freeze exception), then maybe it could be worth
adding something like HAVE_NCURSESW_
link against a simple curses library (because #include <curses.h> is
replaced by #include <ncursesw/
If it cannot be applied to Etch, it would be better to work on the more
complete patch from Eugeniy Meshcheryakov (in #237675 also).
Kind Regards,
--
Nekral
Steven Harms (sharms) wrote : | #27 |
Can you reproduce this bug on Feisty?
Changed in dpkg: | |
status: | Unconfirmed → Needs Info |
Michal Suchanek (hramrach) wrote : Re: [Bug 11922] Re: dselect displays garbage in cs_CZ.UTF-8 locale | #28 |
On 4/4/07, Steven Harms <email address hidden> wrote:
> Can you reproduce this bug on Feisty?
>
> ** Changed in: dpkg (Ubuntu)
> Status: Unconfirmed => Needs Info
>
> --
> dselect displays garbage in cs_CZ.UTF-8 locale
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
I no longer use neither dselect nor the locale. However, it might be
worth investigating if this is a problem with the Czech localization
(some improper formatting), the way some library handles unicode
locales (note that Czech would be normally latin2), or console unicode
problem, or something I cannot even think of.
Unless it is specific to Czech locale it will not be solved by
removing the Czech translation.
Jan (debian-gepro) wrote : | #29 |
Yes, I can.
>Can you reproduce this bug on Feisty?
Changed in dpkg: | |
assignee: | kamion → nobody |
status: | Needs Info → Confirmed |
In Debian Bug tracker #237675, Raphaël Hertzog (hertzog) wrote : Re: Bug#237675: [UTF-8] patch for dselect UTF-8 support | #30 |
On Thu, 03 Mar 2005, Changwoo Ryu wrote:
> If the patch is too long to be accepted for now, how about starting
> with replacing libncurses5 with libncursesw5? Just replacing, without
> touching other things, is also useful.
>
> The only problem is that libncursesw5 is not in base... but
> after sarge all programs can be replaced.
This has been done some time ago when it really broke badly. For the
rest of your patch, I just forward-ported it to the current git tree,
the fix for #342495 was in conflict with your patch and had to be redone
given that you use libtextwrap. Apart from that and from some build-system
adjustement, the patch applied mostly fine.
I built an udpated dselect and it seems to work as expected.
I'm a bit uneasy however with adding a libtextwrap dependency on dpkg for
dpkg. Given that dselect can be completely disabled in the build system it
doesn't complicate the bootstrap process of a new architecture but still
it would be nice if someone could just fix the code to not require it at
all.
Please test and keep me informed! We can then merge the patch if it
doesn't have any other side-effects.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://
In Debian Bug tracker #237675, Raphaël Hertzog (hertzog) wrote : | #31 |
On Fri, 27 Jun 2008, Raphael Hertzog wrote:
> On Thu, 03 Mar 2005, Changwoo Ryu wrote:
> > If the patch is too long to be accepted for now, how about starting
> > with replacing libncurses5 with libncursesw5? Just replacing, without
> > touching other things, is also useful.
> >
> > The only problem is that libncursesw5 is not in base... but
> > after sarge all programs can be replaced.
>
> This has been done some time ago when it really broke badly. For the
> rest of your patch, I just forward-ported it to the current git tree,
> the fix for #342495 was in conflict with your patch and had to be redone
> given that you use libtextwrap. Apart from that and from some build-system
> adjustement, the patch applied mostly fine.
Some other conflicting changes have been merged in the mean time. I
reupdated the patch and I'm keeping a branch here:
http://
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://
In Debian Bug tracker #237675, Yuri Kozlov (kozlov-y) wrote : | #32 |
Hello.
1.14.20 version have truncated menu (locale is ru_RU.UTF-8).
--
Regards,
Yuri Kozlov
rusivi2 (rusivi2-deactivatedaccount) wrote : | #33 |
Thank you for reporting this bug.
Does this occur in Lucid?
Changed in dpkg (Ubuntu): | |
status: | Confirmed → Incomplete |
Michal Suchanek (hramrach) wrote : | #34 |
no, it's fixed.
Changed in dpkg (Ubuntu): | |
status: | Incomplete → Fix Released |
# Automatically generated email from bts, devscripts version 2.7.95.1
retitle 237675 retitle [UTF-8] patch for dselect UTF-8 support