Re: console-setup for wheezy....
On Fri, Feb 01, 2013 at 04:40:17PM +0100, Julien Cristau wrote:
>
> A few questions while going through the diff:
>
> - the new xkb-keymap stuff doesn't seem to support multiple keymaps, is
> that on purpose? ("Yes" is fine, just making sure.)
The template keyboard-configuration/xkb-keymap is used for two somewhat
unrelated purposes: 1) for preseeding and 2) for the layout question in
the udeb.
Regarding 1: I have some development plans but I've decided to postpone
them and to keep the current code. As far as I can tell multiple
keymaps are supported there as long as the resulting keymap is supported
by the udeb.
Regarding 2: Yes, this is on purpose.
> - the source package contains
> debian/console-setup-{linux,freebsd}-udeb.substvars and
> Keyboard/ckb/symbols/compose which look bogus (at least they don't
> seem to be in git)
These are indeed bogus files. I suppose such files are included in all
previous uploads of mine...
> - why did the handling of bg,bg|us,bg|cs,cs|us,cs change (to apparently
> set unsupported_layout=no regardless of the XKBVARIANT value?
The specific of the Serbian (cs) and the Japanese (jp) layout is that
they both are non-Latin languages and they both include theyr own Latin
layouts in the respective XKB file. But at the same time settings
XKBLAYOUT=us,cs and XKBLAYOUT=us,jp (analogous to the other non-Latin
languages) are not wrong so I wanted to avoid triggering
unsupported_layout=yes by such settings. This leads to two regressions:
the first one is what you have noticed about the value of XKBVARIANT.
The second one is that a setting XKBLAYOUT=us,cs in the configuration
file will be corrected automatically to XKBLAYOUT=cs,cs (and similarly
for Japanese, but the previous versions of console-setup also did this).
It is possible to fix partially these regressions but I've decided not
to risk (for now) with code that can introduce worse bugs.
As for Bulgarian (bg), the change is somewhat premature. Currently this
results in bg,bg being corrected to us,bg.
> - why does the fallback case now set unsupported_layout=no?
I think the only reason this hasn't caused bugs in the previous versions
is that in all cases we have tested for [ "$unsupported_layout" = yes ]
and never for [ "$unsupported_layout" = no ].
There are only three things that can cause unsupported_layout=yes:
1. non-Latin layout combined with non-standard Latin layout (line 1034).
2. multiple layouts except the case of non-Latin layout + standard Latin
layout (line 1038)
3. non-existing layout and/or variant (line 1056).
> - it looks like the various debconf variables related to xkb options are
> initially set based on the XKBOPTIONS value in the config file, and
> then possibly reset in the loop if STATE=6. Is that even possible?
> Is there a description of the different STATE values somewhere?
I don't understand this question.
No, currently there is no such description of the different STATE values.
Anton Zinoviev
Reply to: