Your message dated Sun, 15 Nov 2009 12:53:22 +0000
with message-id <20091115125322.go27...@riva.ucam.org>
and subject line Re: Bug#555331: man-db: 555331: needs to depend on the locales
package?
has caused the Debian Bug report #555331,
regarding [col] improperly fails with Invalid or incomplete multibyte or wide
character
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
555331: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555331
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: bsdmainutils
Version: 8.0.1
Severity: serious
Since today I gets lots of lintian warnings (manpage-has-errors-from-man)
on my dpkg builds because col fails with:
col: Invalid or incomplete multibyte or wide character
You can reproduce it by doing this:
LANG=C man --warnings -E UTF-8 -l /usr/share/man/man8/update-alternatives.8.gz
>/dev/null
I don't know if it's col's fault or if it's man-db that does not use col
properly but since col changed recently (and not man-db), I filed the bug
against col. Note that dropping LANG=C makes the warning go away so it's
most certainly locale related. Using any other locale seems to work, even
one that is not UTF-8.
Severity serious to avoid propagation to testing until we know more on the
nature of the problem.
Cheers,
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bsdmainutils depends on:
ii bsdutils 1:2.16.1-4 Basic utilities from 4.4BSD-Lite
ii debianutils 3.2.1 Miscellaneous utilities specific t
ii libc6 2.10.1-5 GNU C Library: Shared libraries
ii libncurses5 5.7+20090803-2 shared libraries for terminal hand
bsdmainutils recommends no packages.
Versions of packages bsdmainutils suggests:
ii cpp 4:4.3.4-1 The GNU C preprocessor (cpp)
pn vacation <none> (no description available)
ii wamerican [wordlist] 6-3 American English dictionary words
ii wfrench [wordlist] 1.2.3-7 French dictionary words for /usr/s
ii whois 4.7.36 an intelligent whois client
-- no debconf information
--
Raphaël Hertzog
--- End Message ---
--- Begin Message ---
Source: man-db
Source-Version: 2.5.6-4
On Sat, Nov 14, 2009 at 09:53:37PM +0800, Paul Wise wrote:
> In an up-to-date cowbuilder chroot I still get this issue:
>
> (cowbuilder)r...@chianamo:~# LANG=C man --warnings -E UTF-8 -l
> /usr/share/man/man8/update-alternatives.8.gz >/dev/null
> col: Invalid or incomplete multibyte or wide character
> (cowbuilder)r...@chianamo:~# apt-cache policy man-db
> man-db:
> Installed: 2.5.6-4
> Candidate: 2.5.6-4
> Version table:
> *** 2.5.6-4 0
> 500 ftp://xxxxxxxxxxxxxxx sid/main Packages
> 100 /var/lib/dpkg/status
>
> Looking at the patch, I thought it would be because the locales package
> is not installed and thus /usr/share/i18n/SUPPORTED is not available.
> Unfortunately, installing locales does not silence the warning:
You've hit the corner case which I already cloned as bug 555408. I don't
think we need to keep this bug open for that as well.
As I said in a previous message:
However, such a locale is not actually guaranteed to exist. Perhaps
lintian needs to generate a UTF-8 locale if it can't find one
otherwise, a bit like the hack in installation-locale; or perhaps we
should just make sure that there's always a C.UTF-8 locale on the
system, which could be used to get UTF-8 character type semantics
without implying a particular language or country.
If you generate some random UTF-8 locale (uncomment it in
/etc/locale.gen and run 'sudo locale-gen'), then that will work around
the problem for you.
Regards,
--
Colin Watson [cjwat...@debian.org]
--- End Message ---
