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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130203230542.ga16...@debian.lan