Ken Moffat wrote: > On Mon, Apr 22, 2013 at 03:57:28PM -0500, Bruce Dubbs wrote: >> >> I've already tried a DESTDIR install and it seems to work there. >> >> I'm not sure we need the --datadir entry at all. Mounts are done before >> any kbd programs are called, so having the support files in /usr >> shouldn't be a problem. >> >> ./configure --prefix=/usr --disable-vlock >> >> seems to fix things up putting all the kbd support files in /usr/share. >> >> -- Bruce >> > We move kbd_mode, loadkeys, openvt, setfont to /bin at the end of > the install with an explanation: > > "Some of the scripts in the LFS-Bootscripts package depend on > kbd_mode, loadkeys, openvt, and setfont. As /usr may not be > available during the early stages of booting, those binaries need to > be on the root partition:" > > Is that outdated ? If so, no need to move those programs. But if > we do still need to move them, I'm a lot happier with /bin/loadkeys > and /bin/setfont getting the keymaps and fonts from /lib.
I think it may be outdated. The order is: S00mountvirtfs S05modules S08localnet S10udev S20swap S30checkfs S40mountfs S45cleanfs S50udev_retry S70console S90sysctl S40mountfs will mount /usr if it's not already mounted and the first kbd based command is in S70console. I suppose it's possible that udev does something there, but AFAICT the worst thing that can happen is that some output message from a command in one of the above scripts may be in the wrong font or language. Also, the scripts themselves have no support for i18n. > With your sed : sed -i 's/@datadir@/@localedir@/' po/Makefile.in.in > and using the existing instructions with --localedir=/usr/share, > the locales do go into the correct place (from a DESTDIR build) as > you noted. > > The easiest way to test that the translations appear is to use > "dumpkeys -h". There are also translations for many of the > languages with "loadkeys.h" and a one-liner usage for "getkeycodes > -h". Those can all be run from an xterm or equivalent (that might > make more of them legible - zh_CN is never going to work in a > console. After copying kbd.mo locale files to /usr/share I've > got translations from dumpkeys with LC_ALL= cs_cz, da_DK, de_AT, > el_GR, es_ES, id_ID, it_CH, nl_BE, pl_PL, ro_RO, ru_RU, sv_FI, > tr_TR, uk_UA, vi_VN, zh_CN (all .UTF8). > > With the exception of vi_VN and zh_CN those all render in my > console with my LatGrkCyr font. Vietnamese can work, but you won't > get much else except english from a screen font that handles it. > > I suspect that the turkish is a bit garbled - it seems to have a > lot of dollar signs in it. Are those issues something that should be addressed by LFS or upstream? Also, I don't know how many people use a console any more. Virtually all of the larger distros go directly to xdm or equivalent. A remote ssh doesn't use console fonts if run from an xterm or equivalent. I do boot to a console, but most of the time my first command is startx or to access the system from another system via ssh. Occasionally I'll do a little work from the console, but that is/was only to debug the boot scripts. We've got three possibilities here: 1. Leave it alone 2. Use a sed and only change the location of the kbd.mo files 3. Put all the support files in /usr/share My initial reaction is to do 3, but I could be persuaded otherwise. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
