Bug#61391: keymaps.sh handles keymaps incorrectly

[<james@netcsi.com>]

Package: boot-floppies
Severity: normal
Version: 2.2.9

After comparing keymaps.tgz with my new headless-build-patched version, I
found they didn't match.  After some investigation I found that my
patched version was actually doing things right and the current release
version was doing two related things wrong:

  1) It uses dumpkeys without -f, which produces abbreviated keymaps.
     However, the version of 'loadkeys' which then processes those
     keymaps uses different and incompatible conventions for
     abbreviations.  This results in extra keybindings being defined
     in the binary keymaps that are not present in the original
     (for example, AltGr-Shift-F2 => F2 instead of VoidSymbol in
     i386/qwerty/us.kmap).

  2) It uses the console as a workspace for preprocessing keymaps,
     however for obvious usability reasons 'loadkeys' from
     console-tools doesn't clear the 'workspace' for keys not
     mentioned in the keymap being worked on.  This causes bindings
     to appear in the binary keymaps for keys that were never even
     mentioned in the original keymaps (for example 112-118 in
     us.kmap).

I can think of several possible fixes for this:

  1) Use the patch to utilities/writemaps and keymaps.sh I'll be
     posting later today to the debian-boot list.  The new
     version has considerable changes but handles most of what
     the console-tools loadkeys does so it doesn't need
     preprocessing.

  2) Modify keymaps.sh to load a blank keymap with busybox loadkmap
     (which *does* clear the keymap) between each keymap loaded,
     and use dumpkeys -f to use the dumps.  This risks making the
     console totally unusable if the build is interrupted at the
     wrong time, and still won't build on headless machines, but
     involves fewer code changes.

  3) Get the console-tools maintainer to add a small patch to add
     the -b option to console-tools loadkeys.  I assume there was
     a reason this wasn't done in the first place instead of
     keeping a modified kbd loadkeys in boot-floppies source, but
     as I don't know what that was I can't judge if it was still
     valid.  The code will then build on headless machines and
     boot-floppies source will be smaller.

  4) Use the -m option of console-tools loadkeys and some
     postprocessing to produce the binary keymaps.  This would
     build on headless machines too and would only involve
     following changes in the kernel console driver rather than
     the console-tools userland tools, and wouldn't involve
     forking anything, but it would likely be more resource-
     intensive at build time than the other options and could
     involve considerable new code being written (there are
     several tradeoffs in this one--resources required vs.
     new code, resources required vs. robustness to changes in
     console-tools, etc).

--
James Deikun, Techie(tm), CSI Multimedia
The opinions expressed &c.