[buildd-tools-devel] Bug#765886: Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Dima Kogan]

Hi. Thank you for your reply.


Roger Leigh <rleigh at codelibre.net> writes:

> tags 765886 - patch
> thanks
>
> On Sat, Oct 18, 2014 at 03:56:35PM -0700, Dima Kogan wrote:
>> Sbuild likes to print out unicode characters, which improves the process
>> very little, but is extremely annoying when it fails (when running on a
>> non-unicode terminal, say). This patch replaces the unicode with ascii.
>
> It's 2014; we've been using unicode by default for over a decade.  If your
> terminal doesn't support UTF-8 input, it's in need for replacement.  Part
> of the reason for doing this in sbuild was to enforce UTF-8 cleanliness
> in sbuild, and tools processing the logs.

I simply cannot agree. Unicode is a very good thing WHERE IT IS
REQUIRED. If I was using a tool that dealt with Japanese text, say, then
this tool would have a very reasonable expectation to use unicode, and
any attempts to remove that would be clearly misguided.

Here we have a tool that builds packages in a chroot. There is no
reasonable expectation that unicode is required AT ALL. And this is
evidenced by sbuild working just fine, except in a minor aspect of its
reporting: the way it draws boxes. This part is so irrelevant, if sbuild
drew no boxes at all, nobody would complain.

If you want to check UTF-8 cleanliness, there are better ways to do
that. Currently it would appear the boxes have a hidden purpose, and
that's just weird.


> That said, we could certainly revert to ASCII for non-UTF-8 locales.  I
> think your patch is too heavy-handed--it reverts to ASCII unconditionally.
> However, if you make it conditional on "nl_langinfo(CODESET) != UTF8" this
> will degrade gracefully for non-UTF-8 locales if you have a supplementary
> non-Unicode set of formatting characters to substitute.  This should be
> wrapped by POSIX.pm.  If you'd like to make this change, I'll be happy to
> review and apply it.

OK. I don't see this as a complicated issue, and I think the
previously-attached patch is "right", so I'm not going to make the
change you suggest. If that's what it would take to resolve this, then
you can close this bug. I'll simply you schroot directly.

Thank you for considering the change.