Matthew Burgess wrote:
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Coreutils Internationalization Fixes - Fixes various bugs with
multibyte character support
>>
No, no action required. Such big patches should be treated as
"switching to a fork", not as regular patches. Coreutils upstream is
already aware of the patch and the problems it fixes, and validly
rejected it as badly coded.
In which case, I seriously think we should drop the patch. I know it
will cause regressions compared to the 6.2 release, but if we can write
a "known bugs" page for issues like this (pointing to upstream bug
reports) at least folks will know what does and doesn't work.
Already written. See
http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055427.html
Grep Redhat Fixes - Various fixes from Redhat's Grep package
including i18n related fixes.
>
No action required. We follow RedHat's version of Grep. If upstream
releases a new version, we wait for RedHat action and import their new
patch.
I disagree. If upstream release a new version, we should switch to that
and wait for bug reports to come in against the vanilla upstream
version. We then forward those bug reports upstream (assuming they're
not caused by incorrect build instructions, of course).
See http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055428.html
Basically, if you drop the patch, Grep will become so slow that nobody
will use UTF-8 locales. This fix is scheduled for the next-to-next
version of Grep.
Is it just CVS Groff that is Unicode-aware, or is groff-1.19.2
Unicode-aware? NEWS for 1.19.2 states that `grotty' gained
"Experimental support for zero-width and double-width characters". I
don't see anything Unicode related in NEWS or CHANGES in groff's CVS
repository (http://cvs.savannah.gnu.org/viewcvs/groff/).
Only CVS (they added the "-K" switch).
In fact, the current version of Man can be made compatible with Groff
CVS, but this means either a very long "Man configuration" page in LFS
(that's why I switched to Man-DB)
Is this just because Man has a poor default configuration? If so,
perhaps a patch could be submitted upstream to improve its out of the
box defaults.
IIRC though, the issue is that 'man' simply doesn't know
what the correct configuration is for various locales and doesn't have a
mechanism for storing them. If that's correct, the patch is likely to
be a lot more involved as it'll be a new feature, obviously.
<troll>
Please read the "man-i18n.txt" hint, make me a full-time coder with at
least $250 monthly salary (so that I can quit from both of my current
jobs), and protect me from being grabbed into the army (currently, one
of my jobs protects me) if you want this new feature.
Or, better, drop the UTF-8 support completely from LFS. It is
unmaintainable, and in fact not ready in "vanilla upstream". This also
means dropping Nautilus CD Burner from BLFS.
</troll>
OK, now seriously. Explicitly CCing Randy and Dan because of their
contribution to http://wiki.linuxfromscratch.org/blfs/ticket/2102, which
is going to be nullified.
Actually, there are two problems.
1) Man forgets to recode its output from the translator's charset to the
user's locale charset. Thus, error messages are readable only in
traditional 8-bit locales. Workaround for the current version of Man:
configure with "+lang none". Work is in progress to implement this
conversion. I have no access to the source code of development versions
of Man, but the result will be shown to me when it is ready.
2) We still need to decide on a configuration file format, so that none
of the existing configurations are broken, but that the possibility of
integrating Man into UTF-8 systems currently using Man-DB is gained.
Also, implementing the LiveCD rule "everything must work out of the box
with changed $LANG" is a big challenge with the current configuration
file format and non-UTF-8 manual pages.
With CVS version of Groff and current Man, it _is_ possible to make a
simple configuration that works for everyone. Since it essentially
inverts meanings of "good" and "bad" in terms of
http://wiki.linuxfromscratch.org/blfs/ticket/2102 (because now UTF-8
manual pages are good and everything else is bad), there will be huge
resistance from BLFS side.
Basically, that configuration is:
* Add the "+lang none" configure switch to Man.
* Store all manual pages in UTF-8 encoding (requires full rewrite of
BLFS in order to add conversion instructions. A "cron job" solution is
possible)
* The NROFF and JNROFF lines become something like (simplified):
groff -man -K UTF-8 -Tutf8 | iconv -f UTF-8 -t //TRANSLIT
Note that the "-K" option requires a CVS version of Groff.
Since this configuration is directly the opposite of the one in LFS-6.2,
and there must be at least one version of BLFS compatible with LFS-6.2,
such reconfiguration must be done _after_ the release of BLFS-6.2.
And that's really bad as we obviously miss out on any bug fixes made in
groff-1.19.x. For example, CVE-2004-0969 was fixed in 1.19.2!
And in Debian too! Just follow their patch :)
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
