Re: console-data: Time to request transition to testing and upload a new version?

[Alastair McKinstry <mckinstry@computer.org>]

Frans Pop wrote:

On Saturday 26 November 2005 16:08, Christian Perrier wrote:
  

Quoting Alastair McKinstry (mckinstry@computer.org):
    

There are a lot of translations pending; Shall I roll these into a
new release and release to unstable first? I can do that today.
      

This was my suggestion but getting an ACK from the D-I team so that
we're sure of not breaking testing installs would be better.
    

Hmm. Sounds like Christian is suggesting to first let current unstable 
version migrate to testing before new upload while Alastair is suggesting 
to first upload and then migrate to testing only when new version is old 
enough.

>From a d-i release viewpoint, I don't really care. As console-data stuff 
is always included in initrd, there's no chance of breaking beta1 and 
beta2 is still far enough away.

There really is not much need to coordinate anyway unless there are 
changes that are expected to or could maybe break d-i (require 
modifications in kbd-chooser).

I guess a new console-data in theory could also break 2nd stage for 
individual languages, but personally I'm a little less concerned about 
that.

  

Ok, I am going to do a console-data release that is basically the current sid + pending
translations. Hopefully this can be promoted into testing soon.

I would like to raise something else that's a leftover from Sarge...
We currently have the following descriptions (IIRC these come from 
console-data):
at  - PC-style (AT or PS-2 connector keyboard)
usb - USB keyboard

These descriptions are very misleading:
- with 2.6 kernels "at" is used for every architecture and for any type of
  keyboard
- "usb" is not really correct as most USB-keyboards are "at" compatible;
  the correct identification would be USB-MAC or something like that.

Also, IIRC some usb-mac keyboard layouts are really at layouts?

My question is: is it worth fixing these issues, or should we wait for the 
new keyboard (?) package?

  

My plans for console-data are to hand off to kbd as quickly as possible, leaving
other optional kbd maps and fonts in a reduced optional console-data package, with kbd
taking over.

The current console-keymap-* stuff ideally should move to kbd, but I haven't planned this
in detail, or discussed it on pkg-kbd-devel before this. Comments welcome. Fixing this bug
should happen as part of that move: I think as part of that move we should consider
which keymaps go where: which ones get included in d-i (based on the experience of Sarge,
what other keymaps do people think should be listed in the installer -- all of them or a subset?)

Regards
Alastair

Cheers,
Frans