Matthew Burgess wrote:
Hi folks.
A recent article on lwn.net discussing LFS
(http://lwn.net/Articles/192904/) attracted the following comment:
"...it's worrying the number of little patches that the LFS
instructions say need applying to the upstream source: why aren't they
included upstream already?"
As a result, I've put the following web page together which details
the upstream progress of each of the 35 patches currently being
applied during a trunk build:
http://www.linuxfromscratch.org/~matthew/lfs-patch-status.html. The
good news is that 15 patches are backports of fixes already made
upstream and can therefore be dropped once upstream release a new
version. A further 3 patches are specific to LFS' build method so
don't need to go upstream. Unfortunately, that leaves the bad news
that we're currently using 17 patches that either upstream aren't
aware of, or they have rejected.
I'll work on getting those sent upstream, but in the mean time, if
anyone could check over the details on that page and inform me of any
errors or omissions I'll gladly update it.
Coreutils Internationalization Fixes - Fixes various bugs with multibyte
character support - The patch header says this was rejected upstream,
but planned for 6.0 - Investigate current support in coreutils CVS head.
If necessary, file bug reports concerning specific problems
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. The patch is absolutely necessary for passing the Li18nux2000
part of LSB testsuite (FIXME: LFS doesn't pass it now), so it is present
in all major distros, so in fact patched coreutils are tested better in
the real world than unpatched. However, it is also an example where
gearing the build process towards passing the testsuite is at least
questionable. The testsuite is skewed, because tests very similar to
those in LSB fail. Debian doesn't have this patch.
Another big problem with such big patches is that they often prevent
upgrading package versions. E.g., the UTF-8 LFS book (before it got
merged) once contained a warning that i18n patch is not available for
coreutils-5.93, and contained a lot of backports for other bugfixes.
Diffutils i18n - Fixes handling of whitespace in multibyte locales -
Unknown - Submit upstream, assuming its still being maintained!
Same situation as with coreutils, except that the patch is stable and
doesn't evolve. Upstream is aware of the patch for at least 4 years.
Grep Redhat Fixes - Various fixes from Redhat's Grep package including
i18n related fixes. - Some of these are upstream, others aren't. -
Reassess the patches that are still required against Grep CVS Head and
submit any unapplied ones upstream
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. They have already submitted their fixes upstream.
Groff Debian Fixes - Adds the ascii8 and nippon devices to groff, which
are required for man-db. - I can only assume this hasn't been submitted
upstream as Groff-1.19 was released without it having been applied. - We
could fix `man' so that it can handle i18n man-pages so that we don't
need man-db and therefore, presumably, this patch. Or we could submit
this patch upstream.
Rejected as a bad hack. Upstream now has Unicode-aware Groff in CVS,
using a completely different approach. Thus, the patch is obsolete, but
must stay in LFS (and groff must not be upgraded in LFS) until a
compatible version of Man appears.
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), or recoding all manual pages to UTF-8
(impossible task for BLFS, judging from Randy's refusal to perform even
an audit of the current state in
http://wiki.linuxfromscratch.org/blfs/ticket/2102). Note that the Man-DB
is compatible _only_ with Debian-patched Groff-1.18.1.1, not any later
version.
Kbd Backspace - Makes Backspace and Delete keys consistent in all i386
keymaps - Not submitted because it's possibly incomplete - Submit
upstream. Complete or otherwise, it's better than nothing and I don't
think we've had any reports of broken keymaps for a while as the patch
hasn't been updated recently.
Will do so.
Kbd GCC-4.x Fixes - Fixes compilation issues with GCC-4.x due to C
aliasing rules - Unknown - Submit upstream.
Will do so.
Linux UTF-8 Input - Fixes dead keys and copy/paste of non-ASCII
characters in UTF-8 mode on Linux console - Rejected upstream because it
changes the meaning of an existing ioctl - Drop the patch and replace it
with one that looks more likely to be accepted upstream.
Impossible without a full rewrite of the "kbd" package. This patch is
still better than nothing in terms of functionality for former
ISO-8859-2 users. A version applicable to 2.6.17 has been submitted, but
no got reply, either positive or negative. I will try again.
Sysklogd 8-bit cleanliness - Allows meaningful Russian messages in UTF-8
to be logged - Not submitted as it is deemed unlikely it'll be accepted
- Submit it upstream anyway, just in case. If it gets rejected, then
submit a bug report upstream detailing the problem
Upstream is Debian. I will submit a bug report today.
Texinfo Multibyte - Works around info's inability to wrap output from
`man' in multibyte locales - Not submitted, it's a hack - Find a
non-hackish solution and/or report the bug upstream
A non-hackish solution requires full rewrite of character handling. Way
beyond my abilities. Will submit a bug report, though.
Vim Mandir Adjusts location of man pages to meet man-db's
expectations Not submitted, N/A LFS-specific, apparently. I
think the first hunk should go upstream, as it fixes non-compliance with
the FHS. Other than that, maybe we can drop this if/when LFS uses `man'
rather than `man-db' again.
This is not LFS-specific. No known version of any Man-like program
searches in the /usr/share/man/ru.KOI8-R directory.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
